User friendly CLI command to create a cluster

anvddriesch commented 1 year ago

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

Slides of March 2023

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
- [x] Create spec draft
- [ ] Gather Giant Swarm internal feedback on spec
- [ ] Organizae customer user input / feedback for spec
- [ ] Create prototypes
- [ ] Gather feedback on prototypes
- [ ] Implement

weatherhog commented 1 year ago

payload cleaning to remove default values from user values is required

marians commented 5 months ago

@gusevda Here is a document that includes hopefully all we talked about today. I decided for Google Drive as it allows for fast and easy commenting. Could you pease glance over it?

https://docs.google.com/document/d/1l_jK3F9ePEe_Jab0UcLO7u_B24bZNbBwwzPA0hSu-LA/edit

marians commented 4 months ago

@giantswarm/team-turtles (as the ones who are supposed to do the implementation): the spec has gone into a next iteration and now waits for everybody's commenting in this RFC:

https://github.com/giantswarm/rfc/pull/98

Other KaaS teams, as technical advisors and also as possible frequent users of the command: I'm adding this to your board asking you to please provide feedback during the next 2 weeks (until June 14 roughly). @giantswarm/team-phoenix @giantswarm/team-rocket @giantswarm/team-tinkerers

yulianedyalkova commented 2 months ago

@marians what is the state of the RFC, can we now proceed with implementation?

weatherhog commented 3 weeks ago

@marians any news on this?

marians commented 3 weeks ago

There is some controversy in the RFC about an important aspect of the spec. Will try to settle this in SIG architecture or product.

giantswarm / roadmap