Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use SCS flavors as enum in clusterclasses #124

Open
mxmxchere opened this issue Jun 29, 2024 · 4 comments
Open

Use SCS flavors as enum in clusterclasses #124

mxmxchere opened this issue Jun 29, 2024 · 4 comments
Labels
Container Issues or pull requests relevant for Team 2: Container Infra and Tooling

Comments

@mxmxchere
Copy link
Contributor

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).

@jschoone jschoone added the Container Issues or pull requests relevant for Team 2: Container Infra and Tooling label Jul 4, 2024
@mxmxchere
Copy link
Contributor Author

@berendt
Copy link

berendt commented Jul 4, 2024

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
Copy link
Contributor Author

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
Copy link
Contributor

DEiselt commented Jul 10, 2024

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%).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Container Issues or pull requests relevant for Team 2: Container Infra and Tooling
Projects
Status: Backlog
Development

No branches or pull requests

4 participants