On 6/17/21 7:54 PM, Kurt Garloff wrote:
Hi,
we (SCS) are working on defining a fully open source cloud and container stack as part of the Gaia-X[1] project. The intention is to provide a common well-standardized way to deploy, manage, configure, and operate the needed software. The vision is to have a network of federated clouds that can be used as one, which requires IAM federation and a high level of compatibility and uniformity. Our project is called Sovereign Cloud Stack (SCS)[2]. Obviously, we are using existing open source projects from the OIF, the CNCF and others and are seeking alignment with these communities. Some experts well-known in the OpenStack universe are participating in our effort. On the OpenStack side, we are using OSISM[3] which leverages kolla-ansible.
We would like to seek your input and feedback into our attempt of defining a standardized naming scheme for flavors and a list of standard flavors available in all clouds that deliver SCS-compliant IaaS.
Find the draft proposal at https://github.com/SovereignCloudStack/Operational-Docs/blob/main/flavor-nam...
We prefer feedback as github issues and/or PRs. Knowing that the OpenStack community prefers gerrit, we'll of course also incorporate any comment we get via this mailing list into our thinking. We hope you can accept us pasting content from mails into github issues, so we create a track record of the taken decisions. (Please indicate if this is not OK for you and we'll refrain from doing so.)
Before you ask why we believe the proposal is useful: We are perfectly aware that it is possible to discover flavor properties; however, in many automation recipes (playbooks, terraform vars etc) we find flavor names encoded and it is one pain point having to adapt them on every cloud that you use. So we want to have some uniformity on this across SCS clouds. (With similar reasoning, expect a image naming and image metadata proposal next.)
We are looking for feedback in two directions:
(1) If you are aware of similar efforts to standardize flavor naming, please point us to it, so we can seek contact and align.
(2) Please look at the proposal itself. When looking into the details how we specify how to optionally(!) encode a number of details into flavor names, please keep in mind that this is indeed optional. We expect most flavor names to be as simple as SCS-4V:8:20 or even SCS-4V:8, even though complicated SCS-8C:32:2x200S-bms-i2-GNa:64-ib [4] is possible for clouds that provide that level of differentiation and want/need to expose this via the flavor name.
Of course, input from existing providers of OpenStack infrastructure is particularly valuable.
Feedback welcome!
[1] https://gaia-x.eu/ [2] https://scs.community/ [3] https://osism.de/ [4] In case you wonder: 8 dedicated cores, 32GiB RAM, 2x200GB SSD disks on bare metal sys, intel Cascade Lake, nVidia GPU with 64 Ampere SMs and InfiniBand.
PS: Cc'ing some folks who have contributed to this.
Hi, While I do like the idea of a standard for flavor naming, I don't like at all what I've seen as your example. IMO, it's best if more explicit. I wouldn't be able to read one of your flavor names, and immediately know what it is made of. To the contrary... We're using naming scheme like this: nvt4-a8-ram24-disk50-perf2 This means: - nvt4: nvidia T4 GPU - a8: AMD VCPU 8 (we also have i4 for example, for Intel) - ram24: 24 GB of RAM - disk50: 50 GB of local system disk - perf2: level 2 of IOps / IO bandwidth Having explicit and full "ram", "disk" and "perf" in the name helps a lot to understand. I think it's much nicer than then cryptic: "SCS-16T:64:200s-GNa:64-ib" which I would never be able to decode without a document on the side. I understand that you're attempting to make the flavor name smaller, but IMO that's a bad idea. I don't see any problem with an explicit and longer flavor name. Cheers, Thomas Goirand (zigo)