Feature Request: A new `--config` flag for `delete cluster` sub command to delete cluster with cluster configurations

[nekomeowww]

What would you like to be added

As what title has stated, I propose to add a new --config flag for delete cluster sub command to delete cluster with already written cluster configuration YAML file which benefits developers and end users to manipulate and control the clusters much quicker and easier in the workflow. As well as sharing the same resource manipulation principle of the create -f <resource specs> and delete -f <resource specs> that come from kubectl.

To use this command, users must specify the name field in the kind: Cluster configuration files, otherwise, it should terminate the deletion process and then prompt user to specify the needed to be deleted name of the cluster with --name flag instead of using --config flag

Proposed command for workflow to bootstrap and clean the cluster when the cluster is no longer needed:

# create the needed directory to store the kind cluster configurations
mkdir -p path/to/store/kind/configurations

# write the testing cluster configuration
cat > path/to/store/kind/configurations/kind-cluster.yaml <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
# must be specified
name: kind-testing-cluster
nodes:
- role: control-plane
  extraPortMappings:
  - containerPort: 80
    hostPort: 80
    protocol: TCP
>EOF

# create cluster from configuration files
kind create cluster --config path/to/store/kind/configurations/kind-cluster.yaml

# perform either testing, helm chart testing, e2e testing, etc.

# delete the testing cluster
kind delete cluster --config path/to/store/kind/configurations/kind-cluster.yaml

Why is this needed

Currently --config is one of the flags of kind create cluster, while user can specify their created cluster name in the cluster configuration file in YAML, executing kind delete cluster with a --name flag separately is often painful and involves executing kind get clusters just for getting the name and requires users to manually copy and paste the names of the desired to be deleted clusters one by one. Such unnecessary actions could possibly be simplified by providing a method to delete with the new suggested --config flag.

Consideration

Though it is a bit of overhead to introduce more proposals and discuss more suggestions here, there are several considerations for me to discover further:

1. When users are trying to manipulate many resources, the new suggested --config flag above may not be enough to cover the eventual needs of users, or sometimes useless since users might just use pre-defined Makefile and scripts to automate the testing procedures all the way down in their workflow, the introduced --config flag more seems like an shortcut to the process of parse the cluster names from the output of kind get clusters, or even get the name hardcoded in such scenarios. Here are the questions:
   1. Is this proposal an over-design?
   2. Are there any viable shortcut or solutions for this requirement that I missed or misunderstood?
2. There is another command called kind delete clusters with the --all flag available for users to choose to delete the already created clusters, if this proposal is accepted and will be indeed to be implemented, here are the questions:
   1. Should we introduce something similar to --config for the existingkind delete clusters sub command?
   2. What about the creation of multiple clusters? Should we consider introducing multi-part YAML with --- (three hyphens) for users to create and delete multiple clusters resources just like what have kubectl just supported?

[nekomeowww]

I would like to get involved and contribute the actual code implementation if this proposal gets accepted.

[tao12345666333]

I think this is not very reasonable.

First, when using kind create cluster, you can specify the cluster name with --name. In CI environments, it is common to set it as a variable for passing and directly use it during deletion.

Secondly, based on the proposal description, the configuration file requires a specified name. In practice, it is easier to pass a variable as an argument through the command line rather than writing it into a file.

So -1 from me.

[nekomeowww]

In practice, it is easier to pass a variable as an argument through the command line rather than writing it into a file.

If you'd say this is more practical in usual, then this raises a new question, what is the meaning of supporting --config for kind create cluster while it is more practical to pass arguments?

I might not express my proposal needs very well and complete. What I have described as proposal here, is to come up an idea to simplify the workflow and needed interactions made by manual input by user or automated by scripts when the workflow involves with the configuration files.

Note the configuration file is the key pre-requirements here. I do understand it is easier to pass a variable as an argument, however, I think many of the people would use the configuration file method to supply not only the nodes and extraPortMapping and etc. but also the name as the name of the cluster.

In conclusion, while the following statements are true:

1. Users have a way to keep the needed information and parameters for the proposed --config flag to work (which is how me and my colleagues' workflows relied on usually)
2. The name field in YAML isn't something that has been marked as deprecated yet
3. kind isn't something that CI/CD specific, it could be used for development, demonstration, orchestration prototyping

I think it is not so unreasonable as you said.

Anyway, I do also think this proposal makes kind more straightforward for users to reuse and understand the interaction principle with both kind create and kind delete of kind sub-command (might be a little subjective).

[stmcginnis]

I'm for this. It matches what is done with other tools like eksctl, and the implementation should be very minor. Basically, it is the same existing logic except instead of taking in the --name value directly, it would just read the name value from the provided yaml config file.

[BenTheElder]

Slightly concerned that it will confuse people as kind is designed to only need the cluster name and does not require the rest of the configuration and would not use it ...

We also prefer to match the precedence in-org for consistency with kubectl, kops, etc, FWIW.

[BenTheElder]

At the very least the usage text needs to be very clear.

Would we support this for clusters plural? We do have precedent with --all only being supported on plural and not singular (not sure if that was actually the right move though)

[nekomeowww]

Slightly concerned that it will confuse people as kind is designed to only need the cluster name and does not require the rest of the configuration and would not use it ...

The new added flag --config won't deprecate or reject the use of --name, people can still pass --name as an argument in when using kind create and kind delete without --config and any configuration files. However you prompt me with a interesting question about the combination usage of both --config and --name, should cli reject and prompt an error message to say it is not supported to use both of the flags? Or should --name gain more priority than --config whenever users whishes to do so?

At the very least the usage text needs to be very clear.

Sure it will. We could refine the helping message as good as possible.

Would we support this for clusters plural? We do have precedent with --all only being supported on plural and not singular (not sure if that was actually the right move though)

Yes, this is one of the question I came up above and wanted to discuss furthermore. If we'd say this proposal is accepted. And it will be implemented with what I have suggested and designed for now as:

when using

kind delete cluster --config <path/to/configuration/yaml>

kind would simple try to read the provided path to <path/to/configuration/yaml>, if possible, parse and obtain the name field inside of the configuration file, and use it as the value of --name to continue the deletion with the named cluster created.

Then let's move on to talk about the "clusters plural", I have asked a question above to address this considerations:

What about the creation of multiple clusters? Should we consider introducing multi-part YAML with --- (three hyphens) for users to create and delete multiple clusters resources just like what have kubectl just supported?

If the current design of kind have implemented kind delete clusters --all only for the reason where it needs to be all deleted once executed, I think we should keep the feature firstly, and then consider to support either array type --config (just like what kubectl apply -f has, the -f, --filename=[] flag) to consume and process multiple files, or support multi-part YAML with --- (three hyphens) as stated as a separated feature other than -all to prevent introduce more confusion to users.