The clusterspec.yaml only contains information that is not specific to the plugin. Information that is specific to the test subject (i.e., the cloud under test) should be defined somewhere else.

Ah, okay. Then we need to think about some new config file where will be defined parameters/variables specific to the plugins (kind, cluster-stacks, etc.) or we can say that the user/tester needs to define some env variables before executing the plugin. What do you think?

The plugin's constructor will take the path of a config file, and that config file should contain everything that is specific to the plugin and the test subject (it could in turn refer to other files, if necessary). The path of the config file can be specified per subject in config.toml.

I thought clusterspec.yaml was the config file, as it was the only argument (called CLUSTERSPEC_PATH) you could pass to the plugin. However, it seems that it was changed in yesterday's commits. I will take a closer look into that.

It now take an additional configuration file specific to the plugin. I have also added an example file, see plugin-cluster-stacks-config.yaml.

And I have one question regarding this. How should the plugin configuration file look when you want to provision multiple clusters? Do you need a separate configuration file for each cluster, or is a single file sufficient, with the clusterspec_cluster variable determining the cluster?

In my mind, the plugin will merge the plugin configuration with the clusterspec information.

So it should be merged based on the clusterspec_cluster. In my mind, the config file for the plugin would then look something like this:

current-k8s-release:
  clouds_yaml_path: "~/.config/openstack/clouds.yaml"   # Path to the OpenStack clouds.yaml file
  cs_name: "scs"                                        # Cluster Stack Name
  cs_version: "v1"                                      # Cluster Stack Version
  # Additional configurations
  ...
  ...
  ...

current-k8s-release-1:
  ...
  ...
  ...

this should be taken from the branch (and the branch will be supplied to the plugin; the plugin need not read the clusterspec.yaml)

Yes, I agree that the cs_k8s_version should be taken from the branch parameter in the clusterspec.yaml file.

Why this change? It has nothing to do with cluster stacks.

This change is currently outdated, as the code in #753 has also been modified.

this needs to be rebased on the latest version of the target branch

Rebased onto the latest version