cluster-api-provider-vsphere
cluster-api-provider-vsphere copied to clipboard
kubernetes-sigs
Validating inputs
/kind feature
Validating inputs
When an initial target cluster deployment with clusterctl fails, it's often an opaque experience. When the failure is due to invalid inputs, it's frustrating twice over since there is no reason these inputs could not be validated ahead of the bootstrap process.
This issue tracks the creation of a Golang package in CAPV to validate the manifests for Cluster and Machine objects, specifically with respect to the provider specs embedded in the aforementioned manifests.
Requirements
Please note that the below requirements are not set in stone. It's merely an attempt to describe the requested solution. It would be nice if any such solution stuck to the below details as closely as possible, but not doing so isn't a complete deal-breaker.
A solution should define the following Golang packages:
-
./pkg/apis/vsphere/v1alpha1/validate- Validates
- Types
-
./pkg/apis/vsphere/v1alpha1.VsphereClusterProviderSpec -
./pkg/apis/vsphere/v1alpha1.VsphereMachineProviderSpec
-
- Data
- Fields should adhere to rules specified in GoDocs
- Pre-pivot
- vSphere credentials
- Inventory objects, including, but not limited to:
- Datacenter(s)
- Datastore(s)
- Resource pool(s)
- Folder(s)
- Template(s)
- Types
- Imports
- Imports a single CAPV package:
./pkg/apis/vsphere/v1alpha1 - All other dependencies should be either Go stdlib or GoVmomi for validating vSphere objects. This is to ensure the validation is scoped only to a single API version
- If someone feels strongly that a validation package needs to import other CAPV packages, please make that case
- Imports a single CAPV package:
- Validates
-
./pkg/cloud/vsphere/services/validate- Validates
- Types
-
runtime.Object
-
- Types
- Imports
- The
validatepackages for all versions of the vSphere API model
- The
- Validates
Additionally, it would be nice to enhance CAPV's copy of clusterctl so that a new option to validate input is presented either as a new alpha command:
$ bin/clusterctl alpha
Alpha/Experimental features
Usage:
clusterctl alpha [command]
Available Commands:
phases Run an individual phase
validate Validates provider specs
Or as a flag, --machines-validate, on clusterctl create cluster like so:
$ clusterctl create cluster -h
Create a kubernetes cluster with one command
Usage:
clusterctl create cluster [flags]
Flags:
-a, --addon-components string A yaml file containing cluster addons to apply to the internal cluster
--bootstrap-cluster-cleanup Whether to cleanup the bootstrap cluster after bootstrap. (default true)
-e, --bootstrap-cluster-kubeconfig string Sets the bootstrap cluster to be an existing Kubernetes cluster.
--bootstrap-flags strings Command line flags to be passed to the chosen bootstrapper
--bootstrap-only-components string A yaml file containing components to apply only on the bootstrap cluster (before the provider components are applied) but not the provisioned cluster
--bootstrap-type string The cluster bootstrapper to use. (default "none")
-c, --cluster string A yaml file containing cluster object definition. Required.
-h, --help help for cluster
--kubeconfig-out string Where to output the kubeconfig for the provisioned cluster (default "kubeconfig")
-m, --machines string A yaml file containing machine object definition(s). Required.
--machines-validate Whether to validate the provider specs in the machines file
--provider string Which provider deployment logic to use. Required.
-p, --provider-components string A yaml file containing cluster api provider controllers and supporting objects. Required.
@akutz I have a simple "./pkg/apis/vsphere/v1alpha1/validate" package done that will validate all of the vSphere specific objects specified in the cluster.yaml and machines.yaml. I have it in a fork here. Right now I am testing with static values in main.go so I need to work on "clusterctl alpha" validate piece calling into this package. Before I do that just wanted to see if I am on the right track.
~/Documents/go-workspace/src/github/tkrausjr/cluster-api-provider-vsphere/pkg/apis/vsphere/v1alpha1/validate $ go run main.go
Working on connecting to vCenter @https://10.173.13.81/sdk Connected to vCenter version 6.5.0
Looking for vSphere Datacenter %!(EXTRA string=Datacenter)Datacenter found Datacenter Datacenter object Status Returned from Function is Success
Looking for vSphere datastore %!(EXTRA string=ISCSI-DATASTORE)Datastore found ISCSI-DATASTORE Datastore object Status Returned from Function is Success
Looking for vSphere network %!(EXTRA string=VLAN 1526)Network net.Reference() Network:network-19 Network object Status Returned from Function is Success
Looking for vSphere ResourcePool %!(EXTRA string=Physical-CAPV)Resource Pool found Physical-CAPV Resource Pool object Status Returned from Function is Success
Looking for vSphere Template %!(EXTRA string=ubuntu-1804-capv)VM Template found ubuntu-1804-capv VMware Template object Status Returned from Function is Success
Looking for vSphere VM Folder %!(EXTRA string=/Datacenter/vm/capv_vms)VM Folder found capv_vms VMware VM Folder object Status Returned from Function is Success
VMware Object Status Template Success VMFolder Success VCenter Success Datacenter Success Datastore Success Network Success ResourcePool Success
Per @akutz holding off on this for now until CAPI v1alpha2 releases as it will change the types we are using to validate objects in vSphere. Waiting on #472 as a dependency before we can ship this validation.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
@tkrausjr: You can't reopen an issue/PR unless you authored it or you are a collaborator.
In response to this:
/reopen /remove-lifecycle rotten
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
@detiber: Reopened this issue.
In response to this:
/reopen
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
@randomvariable: Closing this issue.
In response to this:
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.