Decouple standard flavors from flavor naming #319
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,150 @@ | ||
| --- | ||
| title: SCS Standard Flavors and Properties | ||
| type: Standard | ||
| status: Draft | ||
| track: IaaS | ||
| --- | ||
|
|
||
| ## Introduction | ||
|
|
||
| ## Motivation | ||
|
|
||
| In OpenStack environments there is a need to define different flavors for instances. | ||
| The flavors are pre-defined by the operator, the customer can not change these. | ||
| OpenStack providers thus typically offer a large selection of flavors. | ||
|
|
||
| While flavors can be discovered (`openstack flavor list`), it is helpful for users (DevOps teams), | ||
| to have a guaranteed set of flavors available on all SCS clouds, so these need not be discovered. | ||
|
|
||
| ## Properties (extra specs) | ||
|
|
||
| The following extra specs are recognized, together with the respective semantics: | ||
|
|
||
| - `scs:name-vN=NAME` (where `N` is `1` or `2`, and `NAME` is some string) means that the | ||
| flavor is one of the | ||
| standard SCS flavors, and the requirements of Section "Standard SCS flavors" below apply. | ||
| - `scs:cpu-type=shared-core` means that _at least 20% of a core in >99% of the time_, | ||
| measured over the course of one month (1% is 7,2 h/month). The `cpu-type=shared-core` | ||
| corresponds to the `V` cpu modifier in the [flavor-naming spec](./scs-0100-v3-flavor-naming.md), | ||
| other options are `crowded-core` (`L`), `dedicated-thread` (`T`) and `dedicated-core` (`C`). | ||
| - `scs:diskN-type=ssd` (where `N` is a nonnegative integer, usually `0`) means that the | ||
|
There was a problem hiding this comment. Likewise, we should spell out the allowable We could of course reference another standard here, if we prefer so. There was a problem hiding this comment. See above. Yes, we can go ahead and standardize the extra specs fully, but I would rather do one step at a time. What we need is a proof of concept that discoverability in this way does indeed work. There was a problem hiding this comment. I never meant to do all of the There was a problem hiding this comment. Yeah, that comment of mine is obsolete by now. I understand your reasoning, and I don't oppose it. |
||
| root disk `N` must support 1000 _sequential_ IOPS per VM and it must be equipped with | ||
| power-loss protection; see [scs-0110-v1-ssd-flavors](./scs-0110-v1-ssd-flavors.md). | ||
| The `disk`N`-type=ssd` setting corresponds to the `s` disk modifier, other options | ||
| are `nvme` (`p`), `hdd` (`h`) and `network` (`n`). Only flavors without disk and | ||
| those with `diskN-type=network` can be expected to support live-migration. | ||
|
|
||
| Whenever ANY of these are present on ANY flavor, the corresponding semantics must be satisfied. | ||
|
|
||
| ## Standard SCS flavors | ||
|
|
||
| These are flavors that must exist on standard SCS clouds (x86-64). | ||
|
|
||
| ### Mandatory | ||
|
|
||
| | Recommended name | vCPUs | vCPU type | RAM [GiB] | Root disk [GB] | Disk type | | ||
| | ---------------- | ------ | ------------- | ---------- | --------------- | ---------- | | ||
| | SCS-1V-4 | 1 | shared-core | 4 | | | | ||
| | SCS-2V-8 | 2 | shared-core | 8 | | | | ||
| | SCS-4V-16 | 4 | shared-core | 16 | | | | ||
| | SCS-4V-16-100s | 4 | shared-core | 16 | 100 | ssd | | ||
| | SCS-8V-32 | 8 | shared-core | 32 | | | | ||
| | SCS-1V-2 | 1 | shared-core | 2 | | | | ||
| | SCS-2V-4 | 2 | shared-core | 4 | | | | ||
| | SCS-2V-4-20s | 2 | shared-core | 4 | 20 | ssd | | ||
| | SCS-4V-8 | 4 | shared-core | 8 | | | | ||
| | SCS-8V-16 | 8 | shared-core | 16 | | | | ||
| | SCS-16V-32 | 16 | shared-core | 32 | | | | ||
| | SCS-1V-8 | 1 | shared-core | 8 | | | | ||
| | SCS-2V-16 | 2 | shared-core | 16 | | | | ||
| | SCS-4V-32 | 4 | shared-core | 32 | | | | ||
| | SCS-1L-1 | 1 | crowded-core | 1 | | | | ||
|
|
||
| ### Recommended | ||
|
|
||
| | Recommended name | vCPUs | vCPU type | RAM [GiB] | Root disk [GB] | Disk type | | ||
| | ---------------- | ------ | ------------- | ---------- | --------------- | ---------- | | ||
| | SCS-1V-4-10 | 1 | shared-core | 4 | 10 | (any) | | ||
| | SCS-2V-8-20 | 2 | shared-core | 8 | 20 | (any) | | ||
| | SCS-4V-16-50 | 4 | shared-core | 16 | 50 | (any) | | ||
| | SCS-8V-32-100 | 8 | shared-core | 32 | 100 | (any) | | ||
| | SCS-1V-2-5 | 1 | shared-core | 2 | 5 | (any) | | ||
| | SCS-2V-4-10 | 2 | shared-core | 4 | 10 | (any) | | ||
| | SCS-4V-8-20 | 4 | shared-core | 8 | 20 | (any) | | ||
| | SCS-8V-16-50 | 8 | shared-core | 16 | 50 | (any) | | ||
| | SCS-16V-32-100 | 16 | shared-core | 32 | 100 | (any) | | ||
| | SCS-1V-8-20 | 1 | shared-core | 8 | 20 | (any) | | ||
| | SCS-2V-16-50 | 2 | shared-core | 16 | 50 | (any) | | ||
| | SCS-4V-32-100 | 4 | shared-core | 32 | 100 | (any) | | ||
| | SCS-1L-1-5 | 1 | crowded-core | 1 | 5 | (any) | | ||
|
|
||
| ### Guarantees and properties | ||
|
|
||
| The figures given in the table (number of CPUs, amount of RAM, root disk size) must match | ||
| precisely the corresponding figures in the flavor. | ||
|
|
||
| In addition, the following properties must be set (in the `extra_specs`): | ||
|
|
||
| - `scs:name-v1` to the recommended name, but with each dash AFTER the first one replaced by a colon, | ||
| - `scs:name-v2` to the recommended name, | ||
| - `scs:cpu-type` to `shared-core` or `crowded-core`, reflecting the vCPU type, | ||
| - `scs:disk0-type` not set if no disk is provided, otherwise set to `ssd` or some other | ||
| value, reflecting the disk type. | ||
|
|
||
| ### Remarks | ||
|
|
||
| We expect the most used vCPU:RAM[GiB] ratio to be 1:4. | ||
|
|
||
| Note that all vCPUs of SCS standard flavors are oversubscribed — the smallest `1L-1` | ||
| flavor allows for heavy oversubscription (note the `L`), and thus can be offered very | ||
| cheaply — imagine jump hosts ... | ||
|
|
||
| The design allows for small clouds (with CPUs with 16 Threads, 64GiB RAM | ||
| compute hosts) to offer all flavors. | ||
|
|
||
| Except for the two flavors with SSD root volume, disks types are not specified | ||
| (and expected to be network disks (Ceph/Cinder) or local SATA/SAS disks typically). | ||
|
|
||
| We only included a limited variation of disk sizes — this reflects that | ||
| for the standard networked cinder | ||
| disks, you can pass `block_device_mapping_v2` on server (VM) creation to | ||
| allocate a boot disk of any size you desire. We have scaled the few | ||
| recommended disk sizes with the amount of RAM. For each flavor there is | ||
| also one _without_ a pre-attached disk — these are meant to be used | ||
| to boot from a volume (either created beforehand or allocated on-the-fly | ||
| with `block_device_mapping_v2`, e.g. | ||
| `openstack server create --flavor SCS-1V-2 --block-device-mapping sda=IMGUUID:image:12:true` | ||
| to create a bootable 12G cinder volume from image `IMGUUID` that gets tied to the VM | ||
| instance life cycle.) | ||
|
|
||
| ## Conformance Tests | ||
|
|
||
| The script `flavors-openstack.py` will read the lists of mandatory and recommended flavors | ||
| from a yaml file provided as command-line argument, connect to an OpenStack installation, | ||
| and check whether the flavors are present and their extra specs are correct. Missing | ||
| flavors will be reported on various logging channels: error for mandatory, info for | ||
| recommended flavors. Incorrect extra specs will be reported as error in any case. | ||
| The return code will be non-zero if the test could not be performed or if any error was | ||
| reported. | ||
|
|
||
| ## Operational tooling | ||
|
|
||
| The [openstack-flavor-manager](https://github.com/osism/openstack-flavor-manager) is able to | ||
| create all standard, mandatory SCS flavors for you. It takes input that can be generated by | ||
| `flavor-manager-input.py`. | ||
|
|
||
| ## Previous standard versions | ||
|
|
||
| The list of standard flavors used to be part of the flavor naming standard up until | ||
| [version 3](scs-0100-v3-flavor-naming.md). The following changes have been made to | ||
| the list in comparison with said standard: | ||
|
|
||
| - the flavor names have been turned into recommendations, and | ||
| - the properties have been introduced in order to help discoverability. | ||
|
|
||
| Note that the flavors with fixed size root disks have all moved to Recommended | ||
| with [scs-0100-v3](scs-0100-v3-flavor-naming.md). | ||
| This means that they are not a certification requirement any longer, | ||
| but we still recommend implementing these for backwards compatibility reasons. | ||
| Also in that standard, two flavors with SSD+ root disks have been added, as defined in | ||
| [scs-0110-v1-ssd-flavors.md](scs-0110-v1-ssd-flavors.md) | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| SCS-Spec: | ||
| # Empty lists so flavor-names-openstack.py only checks the names for scs-0100. | ||
| # The list of flavors will be checked with flavors-openstack.py for scs-0103. | ||
| MandatoryFlavors: [] | ||
| RecommendedFlavors: [] |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we need to provide the full list of allowable and standardized options here?
I.e.
crowded-core(corresponding to anLencoded in the name),shared-core(akaV),dedicated-thread(T), ordedicated-core(C)?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This standard is about standard flavors. Therefore, I only listed the values that we need for the standard flavors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I would also want to skip all the extra things like CPU generation, hypervisor, GPU, IB, I would like us to at least mention the things we touch anyway: cpu-type and diskN-type. Chances are high that variations on those will be offered in the wild and I'd rather not like to ask providers to change things after the fact just because we have not completed all the extra_specs yet when we could have done the obvious ones already.
Anyhow, I am not going to veto this if everyone else wants to push this decision out for later...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, we discussed this in the Team IAM call and I pushed 074b12a as a consequence.
Rationale: Without having the full extra_specs discoverability/transparency thing defined, we have introduced the extra_specs
scs:name-v1,scs:name-v2,scs:cpu-typeandscs:diskN-typehere on the fly. If we do so, let's cover them completely and leave all other extra_specs in a future standard. This avoids confusion for the reader and avoids providers doing wild things that are hard to change once they are out in the wild.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't disagree, but I strongly oppose the breaking of due process here. It takes you a full week to write your comment, and then it can't happen quickly enough, so you push the change yourself. This is very disturbing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not mean to step on your toes.
But there was a feeling in the Team IaaS that this is ready to be merged with this little change, so I want ahead and volunteered to push it.
I agree that process-wise, this was not ideal.
I am personally not at all working in a way that I feel bad if others contribute to work in branches that I have created and mostly filled with content by pushing to them, but I fully appreciate that this may feel different and we have not spelled out what we consider best practices.
If you feel that the result is bad, please speak up loudly, so we don't merge this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't have minded a direct contribution if the back and forth hadn't been as sluggish. I had a feeling of being left out, no real cooperation happening, and your commit to the branch was only adding to that feeling.