Open Stack

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
> >
>
>
>