Open Stack

Hi Kurt,

Thanks for this discussion, this is interesting.

On 6/18/21 12:05 PM, Kurt Garloff wrote:
]> Also, you can't see whether the 8 vCPUs are dedicated cores, HTs
> or oversubscribed things; you have not specified the CPU generation
> (which in my opinion makes the amd vs intel spec somewhat useless --
> somecustomers really want to know whether they have Cascade Lake
> or Ice Lake or Zen1 vs Zen2) nor a way to express generic x86 (x?).

This probably makes sense if a cluster has many types of CPU, though you
wont find that often. In our case, we only have one type of CPU per
cluster: 2x AMD EPYC 7452 32-Cores on every compute for that brand new
public cloud we're about to release (so 128 threads on each compute): so
we use the EPYC-v2 CPU model of Qemu everywhere. IMO, there's no need to
express what type of CPU if there's only one available anyways...

> Is your scheme used by a lot of providers?

I don't know, but it's used by us! :)

By the way, in our case, perf1 vs perf2 doesn't express a change of
backend. Both are using NVMe (4th gen, so REALLY fast...) on a Ceph
cluster, but it express a different IOps and bandwidth limiting.

So maybe we should find a better way to express I/O perfs than just a
lasting number? Maybe nvmeperf1 vs ssdperf1?

> If I take your scheme, the flavor would become
> "scs-x16thr-ram64-disk200-perf2-nva30-ib" or so.
> This assumes I stick to my ordering, use x for generic x86, thr for
> dedicated hyperthreads, perf2=ssd and we're using an Nvidia A30 (which
> has 56SMs not 64 so the match is not perfect) and -ib is verbose enough
> for infiniband ...

Why would someone want to use infiniband these days? We get Mellanox
cards at 2x 25Gbits/s for a very cheap price these days... And then,
same thing: why would you express the speed of your network in the
flavor, when most likely, it's going to be the same on all flavors (and
you cluster will most likely have a single type of NIC speed...)?

> It's a bit longish, but no real roadblock.

IMO, it's a way more readable this way. Long isn't a problem, really, if
it adds redability.

> I would argue that
> readibility is not better once you have spent some minutes with the
> spec.

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

Cheers,

Thomas Goirand (zigo)