Open Stack

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-naming-draft.MD
> 
> 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)