search

SovereignCloudStack / cluster-stack-provider-openstack

Cluster Stack Provider OpenStack
https://scs.community/
Apache License 2.0
2 stars 0 forks source link

Add default values and override capabilities for the 'cloudName' and 'identityRef' fields within the OpenStackClusterStackReleaseTemplate #90

Closed matofeder closed 8 months ago

matofeder commented 9 months ago

/kind proposal

User Story

As a user, I want the CSPO service to come with reasonable defaults so that I can quickly set it up without much configuration. Additionally, I need the flexibility to override these defaults using optional fields in the CSPO resources.

Current State

Currently, OpenStack access is defined via clouds.yaml, stored in the secret and referenced in the OpenStackClusterStackReleaseTemplate as follows:

spec:
  cloudName: <cloud name>
  identityRef:
    kind: Secret
    name: <secret name>

Both cloudName and identityRef fields are mandatory.

Proposal

Both the cloudName and identityRef fields are optional, providing users with the ability to override default values in CSPO. The defaults for these fields are openstack for cloudName and openstack for the secret name.

Note: The openstack name of the entry in clouds.yaml file serves as a default in Horizon, see related docs

michal-gubricky commented 9 months ago

We support the idea of making both the cloudName and identityRef.name optional, as it would offer flexibility and convenience to end-users. This approach prevents the enforcement of hardcoded values in CSPO, which would then restrict cluster-stacks creators to use only those predetermined values.

On the other hand, the idea to move cloudName field into the secret is excellent and we fully back it.

What do you think about this @batistein, @janiskemper and @jschoone?

jschoone commented 9 months ago

Hi @michal-gubricky, I also like the idea, but I also wouldn't deviate too much from the CAPO approach which currently is the same as CSPO does. But I believe that these approaches are not contradictory, right?

At the end it should be user friendly. In regards of the workflow

It seems to be friendlier to have both, the cloudName and the clouds.yaml in the same secret, we just need to provide the command in the docs which can be copy-pasted.

michal-gubricky commented 9 months ago

I also like the idea, but I also wouldn't deviate too much from the CAPO approach which currently is the same as CSPO does. But I believe that these approaches are not contradictory, right?

Yes, you are right. These approaches are not contradictory.

It seems to be friendlier to have both, the cloudName and the clouds.yaml in the same secret, we just need to provide the command in the docs which can be copy-pasted.

Correct, and also requires a little change in the code.

janiskemper commented 9 months ago

I'm okay with this but I think @batistein has put more thought into this