Allow creating a new flavor

[h1r0mu-nic]

/kind feature

Describe the solution you'd like

The current CAPO assumes necessary flavors already exist and specify one of their names in the cluster configuration , but it's more convenient to create flavors dynamically.

I'd like to use GPU in a cluster created by CAPO. To do this, we have to create/configure OpenStack flavor to allow PCI passthrough in advance to create a cluster. Would be nice to automate this process by CAPO.

My suggestion is to allow CAPO to create a dedicated flavor for worker nodes and manage its life cycle along with the worker nodes lifecycle. This is a more generalized solution to the above problem, allowing users to configure flavor specs by CAPO.

Anything else you would like to add:

Here's an example of work items to implement the above suggestion.

Work items:

• add a new FlavorSpec field to OpenStackMachineSpec
  • FlavorSpec would have the parameters of the flavor create API
• add a new functions like getOrCreateFlavor/deleteFlavor to createInstanceImpl/DeleteInstance
  • getOrCreateFlavor will create a new dedicated flavor based on the FlavorSpec and deleteFlavor will delete it when a cluster is deleted

[jichenjc]

so the request is to manage the lifecycle of worker's flavor in CPO yaml (it can be dynamic then) I am not against but I don't know what's the difference compare to using ansible/bash to create flavor before apply the CAPO yaml ..

anyway, I think it's an enhancement and should be ok to add this feature ,do you want to contribute this ?

[h1r0mu-nic]

Thank you for your positive reply

using ansible or bash

Yeah, that’s possible, but I don’t want to manage both CAPI yaml and ansible playbooks/shell scripts. Sometime we need a flavor just for a cluster. It’s easier if that step is integrated in applying CAPI yaml.

do you want to contribute this ?

yes. I will create PR later.

[mdbooth]

Creating a flavor in OpenStack requires admin permissions, which we don't expect to have. CAPO is a tenant workload.

Adding this feature would double our test matrix. Currently we only test with tenant permissions. Adding this feature would require us to use admin permissions. To avoid accidental requirements for admin permissions in other places we would also have to continue to run without admin permissions.

Would we manage admin credentials in addition to tenant credentials? How would we separate them?

I'm not a fan of this feature. I think we would want a very strong argument for why the feature is essential and can't more easily be implemented by another tool.

[h1r0mu-nic]

To avoid accidental requirements for admin permissions in other places

Could you elaborate on this? I'd like to understand why using admin is not preferable in CAPO. Seems CAPO allows users to choose credentials from clouds.yaml, meaning that using admin or tenant is the user's choice.

If this is just a testing issue, what if configuring nova to allow tenant users to create flavor? (it's also likely to happen in our use case)

[jichenjc]

Seems CAPO allows users to choose credentials from clouds.yaml

I agree with this argument, I think we allow admin already (no blocking) , so 2 options if we don't have CI cover admin , and we really want to avoid admin , we should block in the code and in DOC clearly state that if we want to support admin but no CI , then we can say something like admin is not covered by CI, use by your own risk etc..

[h1r0mu-nic]

The option2 is preferable for us. Let me support our proposal a little bit. I think we have an option that adding E2E test for this feature and do NOT run that test by CI but run locally by users who use this feature.

So, should I have to discuss about this topic with other CAPO members somewhere? (e.g., office hour)

[mdbooth]

We have never prevented anybody from supplying admin credentials, but we have never used the additional permissions. CAPO is a tenant workload, and for the above reasons I'm not at all keen to change that.

It is quite simple to create a flavor using another tool. If you could describe a complete user workflow would be best served by CAPO creating the flavor that might help.

[h1r0mu-nic]

I understand that CAPO is a tenant workload. In other words, required OpenStack resources must be created by the OpenStack admin in advance.

However, as a user, we want to reduce the number of tools we depend on. As you pointed out, we can do the same thing with other tools, but our basic motivation for using CAPO is to create a k8s cluster with a single tool, ideally a few commands (i.e., don't want to manage both ansible-playbook/shell script and CAPO manifest as possible).

Please allow me to ask again, is it unacceptable to add codes that are not covered by CI, but are covered by local E2E test run by users? We can show example codes though I suppose it's not a matter of quality.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.