search

SovereignCloudStack / cluster-stacks

Definition of Cluster Stacks based on the ClusterAPI ClusterClass feature
https://scs.community/
Apache License 2.0
9 stars 6 forks source link

Use SCS flavors as enum in clusterclasses #124

Open mxmxchere opened 3 months ago

mxmxchere commented 3 months ago

A good way to deal with flavors that came to my mind was to use the cc.spec.variables.schema.openAPIV3Schema.enum field. Currently we use a string that can have arbitrary values. Now that we generate our clusterclasses already, It would be nice to fetch the scs flavors definitions and to set them automatically as an enum in the clusterclass. We could (debate needed) also set certain flavors for certain tasks (only SSD for controlplane for example).

mxmxchere commented 3 months ago

additional doc: https://json-schema.org/understanding-json-schema/reference/enum

berendt commented 3 months ago

The flavors listed in the linked file are only the mandatory flavors. You probably will find a lot of more flavors on OpenStack clusters that can be used. IMO it should not be possible to only use the mandatory flavors.

mxmxchere commented 3 months ago

you're right good point. I would like to give a hint to the user which flavors are definitely there, but you are right we should not restrict the user to those. We could achieve this with an additional field that has no restrictions:

worker_flavor: enum of standard flavors overwrite_worker_flavor: string

Of course one can debate about the variable names. The reason i would like to have the enum in it, is because the UI (and other generators) needs to have a data source to parse a dropdown-menu for the flavors. The UI is meant for the 90% case where a user just wants to have something that works quickly. The 10% that want to customize their clusters a lot can then use the unrestricted overwrite_worker_flavor field.

DEiselt commented 2 months ago

Of course one can debate about the variable names. The reason i would like to have the enum in it, is because the UI (and other generators) needs to have a data source to parse a dropdown-menu for the flavors. The UI is meant for the 90% case where a user just wants to have something that works quickly. The 10% that want to customize their clusters a lot can then use the unrestricted overwrite_worker_flavor field.

But if we are strictly speaking "UI", there could also be an input field with "suggestions / autocomplete" for the mandatory flavors. This way you would be able to choose from one of the mandatories (90%) or type / copy+paste something else (10%).