08:02:38 <tobberydberg> #startmeeting publiccloud_sig
08:02:38 <opendevmeet> Meeting started Wed Oct 12 08:02:38 2022 UTC and is due to finish in 60 minutes.  The chair is tobberydberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:02:38 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:02:38 <opendevmeet> The meeting name has been set to 'publiccloud_sig'
08:02:42 <frickler> \o
08:03:51 <tobberydberg> As usual, agenda etc found at https://etherpad.opendev.org/p/publiccloud-sig-meeting
08:04:45 <tobberydberg> First out, just a double check of the summarized list of properties so that I did a correct summary of our voting.
08:06:14 <puck> I think that is right.
08:06:33 <gtema> yupp, looks fine for me also
08:07:02 <fkr> ack
08:07:53 <tobberydberg> Good, sounds like we have something to start with then. Next question will then be how we should proceed? :-)
08:08:03 <puck> ha
08:08:48 <tobberydberg> Do we need clarify format of the different fields? Or is that super clear?
08:09:29 <puck> I think that specifying the format would be good, and also like, cores under cpu. Is that cpu_cores?
08:09:31 <gtema> in this world nothing is super clear
08:09:49 <gtema> especially I often observe bools are implemented as string by some services
08:10:53 <tobberydberg> puck Yes, so flavors we only have the oversubscription basically that is "new" and not already required
08:11:50 <tobberydberg> gtema Yea, would be good if we could do it correct :-)
08:12:17 <gtema> sure, but therefore it may make sense to actually define what are we expecting
08:12:33 <gtema> cause actually user (tool) would need to expect something
08:12:37 <tobberydberg> So format and potentially an "example flavor" using that would be useful for clairification
08:13:00 <tobberydberg> exactly
08:13:01 <gtema> meaning SDK/gopher/cli would need to find attr used by server and auto-correct to specific type
08:13:12 <gtema> => there is interface expectation
08:13:21 <tobberydberg> indeed
08:16:28 <gtema> independent on that - at least I do not really know how oversubscription ration is filled. So some explanation to that is also required
08:16:35 <gtema> ratio
08:17:08 <gtema> on architecture - arm or armv6 etc
08:17:39 <puck> architecture would need to be be armv6
08:18:15 <puck> boolean is 0/1 ?
08:18:52 <gtema> no, bool should stay bool: true/false
08:19:37 <fkr> gtema: on the oversubscription: oversubscribed "at least 20% of a core in >99% of the time" (oversuscription to 5x per core) is indicated by a value otherwise if more oversubscribed this needs to be indicated by a different value
08:19:38 <gtema> "vCPU (oversubscribed)" - this is from the name unclear - is this count or bool
08:20:12 <fkr> gtema: we (SCS) elaborated on that here: https://github.com/SovereignCloudStack/Docs/blob/main/Design-Docs/flavor-naming.md?plain=1#L70
08:20:12 <gtema> fkr - I want to say that if we come with some recommendation we need also to describe quite clearly what it is and how it is expected to be used
08:20:14 <tobberydberg> I started to fill in some info inline in the list, please check that and add what you think is needed
08:21:56 <fkr> gtema: if a simple ratio is used that would work, but might not reflect how it feels to the user ;) (this is the hard part of indicating this. with good workload management a factor of 1:5 might feel much better that a factor of 1:2 with crappy workloads management ;)
08:23:26 <gtema> precisely the point - you have already some definition that MAY be different for a person reading list of "required" parameters - this need to be explicitly described
08:24:21 <tobberydberg> So, my personal thoughts here are to have one field called "cpu_subscription" => "dedicated cores, dedicated threads, oversubscribed"
08:24:56 <tobberydberg> Another field called "oversubscription_ratio" => "0,5,10,X,XX"
08:25:18 <tobberydberg> Is that a way to tackle it?
08:25:56 <gtema> no clue, what if one cloud is having also ration 2 or 2.5 and user will start searching for it on another clouds?
08:26:19 * gtema fingers are not good today
08:28:02 <tobberydberg> Good point, I was thinking that the first field is "queryable" and the second more informative. But maybe that is not good enough, or maybe use the second field with "less than"??
08:28:09 <tobberydberg> Thinking out loud here ;-)
08:28:43 * fkr is pondering and thinking silently :)
08:28:52 <jmurezovh> My 2 cents: CPU oversubscription is an important parameter indeed (exposition to noisy neighbors). But regarding the ratio, I’m not sur it gives any real information about the perf we can expect. Depending on how the provider manages the scheduling / the growth of the infra, oversubscribed resources with the same ratio might performed totally differently from one to another.
08:29:11 <fkr> full ack, jmurezovh
08:29:24 <fkr> which is - I think what gtema and I tried to express
08:30:26 <fkr> the fact that oversubscription happens is vital, so that is the first field.
08:30:57 <fkr> in a discussion I was part of we wondered wether 'measured steal time' could be an indicator on how much noisy neighbour effect is present
08:31:48 <fkr> however that brings a whole load of further instrumentation alongside with it so we did abandon that for the time being
08:34:15 <fkr> so for the first (vCPU oversubscribed) it would be boolean here?
08:34:26 <tobberydberg> I would assume the goal is to give the user a certain expectation, and indeed a 10x oversubscription is scary, but at the same time most of the times they will be able to get 100% out of the virtual cores, but worst case 10%...
08:35:28 <puck> I think that requiring publishing the actual ratio might be scary to some providers. Acknowleding that there is oversubscription is something I'd hope they'd admit to.
08:35:51 <tobberydberg> fkr could make it that simple, if we don't want to cover dedicated threads, dedicated cores?
08:36:38 <tobberydberg> Totally agree with that, but will that bring enough "expectation" to the customer?
08:38:17 <puck> I think that cpu_subscription is a boolean, with an optional cpu_subscription_ratio
08:38:24 <puck> Which is an integer.
08:39:51 <tobberydberg> then a more correct term is probably "cpu_oversubscription" and "cpu_oversubscription_ratio"
08:40:04 <puck> ugh, yes, that's what I mean to type.
08:40:23 <tobberydberg> Then we are skipping the "dedicated_x" stuff
08:40:39 <fkr> tobberydberg: imho yes
08:40:55 <tobberydberg> what does others think?
08:41:19 <gtema> un-opinionated on that topic
08:42:01 <puck> I guess it comes down to the architecutre of the CPU. Perhaps it is clear if it is core/threads basd on architecture
08:44:18 <tobberydberg> and architecture is nothing we cover as of now, right?
08:45:04 <gtema> well, was not voted on
08:45:10 <gtema> indeed weird
08:45:25 <puck> Yeah, seems a useful thing to have on flavours.
08:45:40 * puck quietly grumbles about having to use flavor
08:45:46 <gtema> I would really prefer to have chance to select arm arch rather some oversubscription
08:45:52 <tobberydberg> indeed
08:45:54 <fkr> ack
08:46:17 <tobberydberg> so, lets move that "up" to the ones selected
08:46:20 <fkr> architecture is imho required. not sure, why we did not vote on that.
08:46:48 <gtema> maybe because it was split into vendor/gen/etc
08:47:02 <gtema> and on those I have (as user) absolutely no interest
08:47:16 <gtema> but arch as such is important to me
08:47:36 <fkr> +1
08:47:47 <puck> It becomes a bit murky, since our flavours are amd64, but we run on Intel CPUs.
08:48:00 <puck> Which I expect is a lot of people.
08:48:17 <tobberydberg> SCS calls this "CPU Type", right?
08:49:17 <fkr> tobberydberg: https://github.com/SovereignCloudStack/Docs/blob/main/Design-Docs/flavor-naming.md?plain=1#L46
08:49:25 <fkr> (yes ;)
08:51:51 <tobberydberg> Would we rather like to call it "cpu_type" or "cpu_architecture"?
08:52:11 <fkr> the latter imho
08:52:52 <gtema> agree, type can be misinterpreted to tons of specific things
08:53:48 <fkr> I'm also glancing at our specs document in order to identify things that can / need to be improved there (for example the architecture aka cpu type is part of the optional part currently)
08:55:52 <tobberydberg> Lets stick with architecture then
08:55:57 <fkr> +1
08:56:10 <jmurezovh> +1
08:56:56 <puck> +1
08:57:22 <gtema> +1
08:57:28 <tobberydberg> Time is flying and the hour has almost passed...we did not get to images at all. Would be good if we could "off meeting" could have a glance at exemplifying those as well
08:58:35 <tobberydberg> Would also just like to take the time to promote the operator sessions during the PTG next week.
08:58:49 <tobberydberg> Kendall wrote a blogpost about it
08:59:26 <fkr> would it make sense to switch to a weekly cadence for a while after the PTG?
08:59:28 <puck> I think that image properties are fairly well defined already.
08:59:33 <gtema> since some operators are here - is there interest on SDK/CLI operator hour?
08:59:51 <tobberydberg> #link https://www.openstack.org/blog/calling-all-openstack-operators-the-ptg-starts-monday-and-the-community-needs-your-input/
08:59:52 <tobberydberg> Just so that you all are aware of them :-)
08:59:57 <tobberydberg> I think that would be great gtema
09:00:13 <fkr> gtema: I will ask the scs operators regarding the sdk/cli operator hour
09:00:25 <fkr> pretty certain there wil be interest
09:00:29 <gtema> okay, will talk to Kendal to take it in also
09:00:31 <tobberydberg> I agree with you fkr - weekly would probably be good after next session in 2 weeks.
09:01:16 <tobberydberg> Lets reconvene in 2 weeks (after the PTG) and deal with that then.
09:01:23 <fkr> +1
09:01:36 <puck> +1
09:02:06 <tobberydberg> Thanks a lot for today and hope to see you during the PTG next week. Don't forget to take a glance at the list at the etherpad and add additional stuff ;-)
09:03:37 <gtema> thanks
09:04:51 <tobberydberg> #endmeeting