Open Stack

I decided to go on and did some sum up and submitted Issue [1] as was suggested at the beginning of the thread.

Please feel free to adjust it if needed and add additional thoughts!

[1] https://github.com/SovereignCloudStack/Operational-Docs/issues/18

23.06.2021, 16:51, "Julia Kreger" <juliaashleykreger at gmail.com>:
> I'm suddenly reminded of the Sydney summit where the one thing
> operators seemed to be able to agree upon, was that they would never
> be able to agree upon standard naming for flavors. In large part
> because a huge commonality was that some teams ultimately needed
> highly tuned flavors, be it baremetal or virtual machines, to achieve
> their jobs. Sometimes these flavors had to have special scheduling as
> a result. It really sounds like a space we all want to avoid, but
> humans really need easy to relate to information when starting out.
> Easy to understand and relate to also likely solves a huge number of
> the cases until we get into the hyper-scaler deployments with specific
> needs throughout their business.
>
> On Wed, Jun 23, 2021 at 6:21 AM Sean Mooney <smooney at redhat.com> wrote:
>>  On Wed, 2021-06-23 at 14:31 +0300, Dmitriy Rabotyagov wrote:
>>  > Hi!
>>  >
>>  > > The point is, a new customer will *not* spend time reading the
>>  > > spec.
>>  > > Typically, they will want to just fire-up a VM quickly without
>>  > > reading
>>  > > too much docs...
>>  >
>>  > While I find Thomases flavor naming also not really intuitive for
>>  > customers - out of nvt4-a8-ram24-disk50-perf2 I could guess only disk
>>  > size and amout of ram (is it in gygabytes?) but "SCS-16T:64:200s-
>>  > GNa:64-ib" doesn't make any sense to me at all (if I haven't read [1]
>>  > ofc).
>>  >
>>  > I totally agree that no user in Public cloud would read any spec
>>  > before launching their VM and it would be super hard to force them to
>>  > do so.
>>  >
>>  > So flavor naming should be as explicit and readable as possible and
>>  > assuming that person who will use cloud has no idea about specs we're
>>  > making. These specs should be designed for cloud providers to comply
>>  > and have same standards so users feel comfortable and secure, but
>>  > don't assume regular users to have special skills in reading what
>>  > engineers come up to. If regular users would find this hard to use,
>>  > companies might choose hapiness of customers over some compliance.
>>  >
>>  > As nova doesn't have any text description for flavors, so flavor name
>>  > is everything we have to expose to the customers and it should be
>>  > clean and readable from the first sight.
>>  >
>>  > > 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
>>  >
>>  > So what I'd suggest to cover that usecase would be smth like:
>>  > 8vCPU-24576RAM-50SSD-pGPU:T4-10kIOPS-EPYC4
>>  that is somewhat readable but in general i dont think we shoudl be
>>  advocationg for standarised naming of flavor across clouds in general.
>>  we might be able to encode some info but really user shoudl read the
>>  extra specs and falvor values not realy on a nameing scheme.
>>  >
>>  > > SCS-8C:32:2x200S-bms-i2-GNa:64-ib
>>  > > [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.
>>  >
>>  > Would be probably smth like:
>>  > 8pCPU-32768RAM-2x200SSD-2vGPU:A100-IB-Cascade
>>  >
>>  > [1]
>>  > https://github.com/SovereignCloudStack/Operational-Docs/blob/main/flavor-naming-draft.MD
>>  >


-- 
Kind Regards,
Dmitriy Rabotyagov