User stories
- As an admin, I want to create a new workload cluster
Background
For Cluster API clusters, we create clusters via app bundles. We create app resources in the management cluster, together with the appropriate configuration passed as Helm values YAML inside a ConfigMap.
In vintage, users used kubectl gs template clusters to generate a manifest for several resources, which would then be applied to to the management cluster using kubectl apply. The kubectl-gs command suffered from the fact that all configuration had to be passed via flags on the command line, and many of these flags were provider specific. Also the process was completely disconnected from a GitOps methodology -- neither the flags nor the output mapped to anything useful when using GitOps to manage cluster. For the latter we introduced yet another command kubectl gs gitops add workload-cluster.
Goals and requirements
-
The CLI command should work in a provider-independent way. The same flags and options should work with all providers. (There will be differences however in the configuration that is passed as an input file or via STDIN. We are working on alignment of this, separately.)
-
Users should not have to submit complete configuration. The configuration passed only has to include values where the user is overriding default values.
-
The CLI can either apply the created resources directly to the management API, to provision the cluster immediately, or can print them for further use.
-
The command should work stand-alone and should not require a connection to any management cluster, let alone authentication or authorization to access certain resources.
-
Configuration input should be validated and guidance should be given to adapt the config to fix problems.
-
When applying resources to the management cluster, the provisioning of the cluster should be tracked and meaningful process output should be given, like in the web UI.
Resources
Further spec notes
Input file:
- it could be copied from somewhere, with or without changes
- it could be piped into the command
- it could be in a file
What else we need:
- provider (this could default to the catalog on the current context MC)
- version/branch/commit (this can be defaulted to the latest)
- default apps version (can default to latest as well) and potential other configuration for it
validation:
- based on the cluster apps schema
- we should receive fine grained feedback
- we should not set values client side and rely on the schema and subsequently operators to set values
application:
-
what do we display after creation?
-
--dry-run should preview the immediate files that are applied (app resources and configmap)
-
should there be a separate status command? it would be good for other people to also look at the status
-
displaying the status in a blocking way after creation would make people afraid to cancel
-
This command will replace kubectl gs template cluster
Tasks
User stories
Background
For Cluster API clusters, we create clusters via app bundles. We create app resources in the management cluster, together with the appropriate configuration passed as Helm values YAML inside a ConfigMap.
In vintage, users used
kubectl gs template clustersto generate a manifest for several resources, which would then be applied to to the management cluster usingkubectl apply. The kubectl-gs command suffered from the fact that all configuration had to be passed via flags on the command line, and many of these flags were provider specific. Also the process was completely disconnected from a GitOps methodology -- neither the flags nor the output mapped to anything useful when using GitOps to manage cluster. For the latter we introduced yet another commandkubectl gs gitops add workload-cluster.Goals and requirements
The CLI command should work in a provider-independent way. The same flags and options should work with all providers. (There will be differences however in the configuration that is passed as an input file or via STDIN. We are working on alignment of this, separately.)
Users should not have to submit complete configuration. The configuration passed only has to include values where the user is overriding default values.
The CLI can either apply the created resources directly to the management API, to provision the cluster immediately, or can print them for further use.
The command should work stand-alone and should not require a connection to any management cluster, let alone authentication or authorization to access certain resources.
Configuration input should be validated and guidance should be given to adapt the config to fix problems.
When applying resources to the management cluster, the provisioning of the cluster should be tracked and meaningful process output should be given, like in the web UI.
Resources
Further spec notes
Input file:
What else we need:
validation:
application:
what do we display after creation?
--dry-run should preview the immediate files that are applied (app resources and configmap)
should there be a separate status command? it would be good for other people to also look at the status
displaying the status in a blocking way after creation would make people afraid to cancel
This command will replace
kubectl gs template clusterTasks