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

nova/flavors: Add KVM v1 (Cascade-Lake) flavors #7274

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

grandchild
Copy link
Contributor

As agreed in ADR core/nova/0008 "KVM flavor naming scheme" the KVM flavors (and eventually, but not in this change, the VMware flavors too) gain a new hypervisor field after the g/c/m purpose field. It's "k" for KVM/Qemu (and will be "v" for VMware).

Also the flavors will be suffixed with a "v1" hardware generation number for Cascade Lake right away.

So, the KVM counterpart for "g_c4_m16" is named "g_k_c4_m16_v1".

A per-region config flag kvm_enabled is introduced, defaulting to false, to allow per-region enablement of KVM flavors.


Note that there are a few flavors still commented out, those are legacy flavors with the AWS naming schema that are still in use, and we should decide whether we still want some of these or close variants thereof.

@sapcc-bot
Copy link
Contributor

Failed to validate the helm chart. Details. Readme.

As agreed in ADR core/nova/0008 "KVM flavor naming scheme" the KVM
flavors (and eventually, but not in this change, the VMware flavors
too) gain a new hypervisor field after the g/c/m purpose field.
It's "k" for KVM/Qemu (and will be "v" for VMware).

Also the flavors will be suffixed with a "v1" hardware generation
number for Cascade Lake right away.

So, the KVM counterpart for "g_c4_m16" is named "g_k_c4_m16_v1".

A per-region config flag `kvm_enabled` is introduced, defaulting to
false, to allow per-region enablement of KVM flavors.
@grandchild
Copy link
Contributor Author

Instead of the kvm_enabled config flag, we could also check for the presence of certain traits, like we check for any required CUSTOM_NUMA_ traits to decide whether to seed a HANA flavor. But the simple per-region flag seems less overhead for now.

@@ -33,3 +35,13 @@ extra_specs:
vmware_hana_exclusive:
<<: *vmware_common
"trait:CUSTOM_HANA_EXCLUSIVE_HOST": "required"
kvm_common: &kvm_common
"capabilities:hypervisor_type": "QEMU"
"hw:mem_page_size": "large"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That particular flag is still in discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants