tobberydberg | Morning o/ | 08:00 |
---|---|---|
puck | Good evening! | 08:01 |
gtema | morning | 08:01 |
tobberydberg | Would have been nice with evening here right now as well ;-) | 08:01 |
fkr | o/ | 08:02 |
puck | heh | 08:02 |
fkr | good morning | 08:02 |
tobberydberg | #startmeeting publiccloud_sig | 08:02 |
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 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:02 |
opendevmeet | The meeting name has been set to 'publiccloud_sig' | 08:02 |
frickler | \o | 08:02 |
tobberydberg | As usual, agenda etc found at https://etherpad.opendev.org/p/publiccloud-sig-meeting | 08:03 |
tobberydberg | First out, just a double check of the summarized list of properties so that I did a correct summary of our voting. | 08:04 |
puck | I think that is right. | 08:06 |
gtema | yupp, looks fine for me also | 08:06 |
fkr | ack | 08:07 |
tobberydberg | Good, sounds like we have something to start with then. Next question will then be how we should proceed? :-) | 08:07 |
puck | ha | 08:08 |
tobberydberg | Do we need clarify format of the different fields? Or is that super clear? | 08:08 |
puck | I think that specifying the format would be good, and also like, cores under cpu. Is that cpu_cores? | 08:09 |
gtema | in this world nothing is super clear | 08:09 |
gtema | especially I often observe bools are implemented as string by some services | 08:09 |
tobberydberg | puck Yes, so flavors we only have the oversubscription basically that is "new" and not already required | 08:10 |
tobberydberg | gtema Yea, would be good if we could do it correct :-) | 08:11 |
gtema | sure, but therefore it may make sense to actually define what are we expecting | 08:12 |
gtema | cause actually user (tool) would need to expect something | 08:12 |
tobberydberg | So format and potentially an "example flavor" using that would be useful for clairification | 08:12 |
tobberydberg | exactly | 08:13 |
gtema | meaning SDK/gopher/cli would need to find attr used by server and auto-correct to specific type | 08:13 |
gtema | => there is interface expectation | 08:13 |
tobberydberg | indeed | 08:13 |
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 |
gtema | ratio | 08:16 |
gtema | on architecture - arm or armv6 etc | 08:17 |
puck | architecture would need to be be armv6 | 08:17 |
puck | boolean is 0/1 ? | 08:18 |
gtema | no, bool should stay bool: true/false | 08:18 |
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 |
gtema | "vCPU (oversubscribed)" - this is from the name unclear - is this count or bool | 08:19 |
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 |
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 |
tobberydberg | I started to fill in some info inline in the list, please check that and add what you think is needed | 08:20 |
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:21 |
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:23 |
tobberydberg | So, my personal thoughts here are to have one field called "cpu_subscription" => "dedicated cores, dedicated threads, oversubscribed" | 08:24 |
tobberydberg | Another field called "oversubscription_ratio" => "0,5,10,X,XX" | 08:24 |
tobberydberg | Is that a way to tackle it? | 08:25 |
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:25 |
* gtema fingers are not good today | 08:26 | |
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 |
tobberydberg | Thinking out loud here ;-) | 08:28 |
* fkr is pondering and thinking silently :) | 08:28 | |
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:28 |
fkr | full ack, jmurezovh | 08:29 |
fkr | which is - I think what gtema and I tried to express | 08:29 |
fkr | the fact that oversubscription happens is vital, so that is the first field. | 08:30 |
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:30 |
fkr | however that brings a whole load of further instrumentation alongside with it so we did abandon that for the time being | 08:31 |
fkr | so for the first (vCPU oversubscribed) it would be boolean here? | 08:34 |
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:34 |
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 |
tobberydberg | fkr could make it that simple, if we don't want to cover dedicated threads, dedicated cores? | 08:35 |
tobberydberg | Totally agree with that, but will that bring enough "expectation" to the customer? | 08:36 |
puck | I think that cpu_subscription is a boolean, with an optional cpu_subscription_ratio | 08:38 |
puck | Which is an integer. | 08:38 |
tobberydberg | then a more correct term is probably "cpu_oversubscription" and "cpu_oversubscription_ratio" | 08:39 |
puck | ugh, yes, that's what I mean to type. | 08:40 |
tobberydberg | Then we are skipping the "dedicated_x" stuff | 08:40 |
fkr | tobberydberg: imho yes | 08:40 |
tobberydberg | what does others think? | 08:40 |
gtema | un-opinionated on that topic | 08:41 |
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:42 |
tobberydberg | and architecture is nothing we cover as of now, right? | 08:44 |
gtema | well, was not voted on | 08:45 |
gtema | indeed weird | 08:45 |
puck | Yeah, seems a useful thing to have on flavours. | 08:45 |
* puck quietly grumbles about having to use flavor | 08:45 | |
gtema | I would really prefer to have chance to select arm arch rather some oversubscription | 08:45 |
tobberydberg | indeed | 08:45 |
fkr | ack | 08:45 |
tobberydberg | so, lets move that "up" to the ones selected | 08:46 |
fkr | architecture is imho required. not sure, why we did not vote on that. | 08:46 |
gtema | maybe because it was split into vendor/gen/etc | 08:46 |
gtema | and on those I have (as user) absolutely no interest | 08:47 |
gtema | but arch as such is important to me | 08:47 |
fkr | +1 | 08:47 |
puck | It becomes a bit murky, since our flavours are amd64, but we run on Intel CPUs. | 08:47 |
puck | Which I expect is a lot of people. | 08:48 |
tobberydberg | SCS calls this "CPU Type", right? | 08:48 |
fkr | tobberydberg: https://github.com/SovereignCloudStack/Docs/blob/main/Design-Docs/flavor-naming.md?plain=1#L46 | 08:49 |
fkr | (yes ;) | 08:49 |
tobberydberg | Would we rather like to call it "cpu_type" or "cpu_architecture"? | 08:51 |
fkr | the latter imho | 08:52 |
gtema | agree, type can be misinterpreted to tons of specific things | 08:52 |
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:53 |
tobberydberg | Lets stick with architecture then | 08:55 |
fkr | +1 | 08:55 |
jmurezovh | +1 | 08:56 |
puck | +1 | 08:56 |
gtema | +1 | 08:57 |
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:57 |
tobberydberg | Would also just like to take the time to promote the operator sessions during the PTG next week. | 08:58 |
tobberydberg | Kendall wrote a blogpost about it | 08:58 |
fkr | would it make sense to switch to a weekly cadence for a while after the PTG? | 08:59 |
puck | I think that image properties are fairly well defined already. | 08:59 |
gtema | since some operators are here - is there interest on SDK/CLI operator hour? | 08:59 |
tobberydberg | #link https://www.openstack.org/blog/calling-all-openstack-operators-the-ptg-starts-monday-and-the-community-needs-your-input/ | 08:59 |
tobberydberg | Just so that you all are aware of them :-) | 08:59 |
tobberydberg | I think that would be great gtema | 08:59 |
fkr | gtema: I will ask the scs operators regarding the sdk/cli operator hour | 09:00 |
fkr | pretty certain there wil be interest | 09:00 |
gtema | okay, will talk to Kendal to take it in also | 09:00 |
tobberydberg | I agree with you fkr - weekly would probably be good after next session in 2 weeks. | 09:00 |
tobberydberg | Lets reconvene in 2 weeks (after the PTG) and deal with that then. | 09:01 |
fkr | +1 | 09:01 |
puck | +1 | 09:01 |
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:02 |
gtema | thanks | 09:03 |
tobberydberg | #endmeeting | 09:04 |
opendevmeet | Meeting ended Wed Oct 12 09:04:51 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 09:04 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/publiccloud_sig/2022/publiccloud_sig.2022-10-12-08.02.html | 09:04 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/publiccloud_sig/2022/publiccloud_sig.2022-10-12-08.02.txt | 09:04 |
opendevmeet | Log: https://meetings.opendev.org/meetings/publiccloud_sig/2022/publiccloud_sig.2022-10-12-08.02.log.html | 09:04 |
ttx | o/ | 15:01 |
ttx | #startmeeting large_scale_sig | 15:01 |
opendevmeet | Meeting started Wed Oct 12 15:01:12 2022 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:01 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:01 |
opendevmeet | The meeting name has been set to 'large_scale_sig' | 15:01 |
felixhuettner[m] | o/ | 15:01 |
ttx | #topic Rollcall | 15:01 |
ttx | Who is here for the Large Scale SIG meeting? | 15:01 |
belmoreira | o/ | 15:01 |
felixhuettner[m] | o/ | 15:01 |
ttx | Sorry for the late reminder on the mailing list | 15:01 |
ramona-beermann[m] | o/ | 15:01 |
TimBeermann[m] | o/ | 15:01 |
ttx | I was traveling to OpenInfra Day Turkey earlier this week and just got back | 15:02 |
ttx | amorin: around? | 15:02 |
ttx | Our agenda for today is at: | 15:03 |
ttx | #link https://etherpad.openstack.org/p/large-scale-sig-meeting | 15:03 |
ttx | feel free to add more to it | 15:03 |
ttx | alright let's get started | 15:03 |
ttx | #topic Ops Deep Dive | 15:03 |
ttx | Two weeks ago we had our openInfra Live! Ops Deep Dive with Schwarz Group | 15:04 |
ttx | The video has been viewed 410 times on YouTube, which is on par with others in the same series | 15:04 |
ttx | (and above average for Openinfra Live) | 15:04 |
ttx | and I think it went well, what do you think? | 15:04 |
felixhuettner[m] | it was a lot of fun | 15:04 |
felixhuettner[m] | received a lot of positive feedback from collegues | 15:04 |
belmoreira | great! Good to know | 15:05 |
ttx | I'd like to arrange a new one early December, like on December 8 | 15:05 |
ttx | belmoreira: can you continue to do those? | 15:05 |
belmoreira | felixhuettner[m] is there something that you would like that we have done differently? | 15:06 |
ttx | or you don;t know yet? | 15:06 |
felixhuettner[m] | no, went really smooth | 15:06 |
belmoreira | felixhuettner[m] I would like to thank you again. It was a very good talk. | 15:07 |
belmoreira | ttx I don't know yet. But I would like to continue to be involved | 15:07 |
belmoreira | I will let you know as soon as I know | 15:08 |
ttx | I'll count you in unless you tell me otherwise :) | 15:08 |
ttx | For the next episode any suggestion who we should ask to present ? | 15:08 |
belmoreira | I didn't put a lot of thought on it... can we have our 2 weeks to think about it? | 15:09 |
ttx | we did public cloud, retail, media... I'm tempted to do banking (like societe generale) but not sure they qualify as large yet | 15:09 |
ttx | yeah we don't need to decide now | 15:10 |
ttx | anything else on the Deep dive topic? | 15:11 |
belmoreira | that would be great. But I'm not aware about their infrastructure. | 15:11 |
felixhuettner[m] | are there plans to do something like this on the Summit next year? | 15:11 |
felixhuettner[m] | might be fun to do it live | 15:12 |
ttx | felixhuettner[m]: we usually do a Large Scale session at the Forum, yes | 15:12 |
felixhuettner[m] | +1 | 15:12 |
felixhuettner[m] | yep they where quite full this year | 15:12 |
belmoreira | I see the Summit with the opportunity to connect with all community. | 15:12 |
ttx | it often ends in a rabbitMQ PTSD support group but we always uncover good questions | 15:13 |
felixhuettner[m] | :) | 15:13 |
ttx | so at Summit it's much more of a wide discussion | 15:13 |
ttx | rather than a deep dive | 15:13 |
ttx | but te goal is the same (sharing) | 15:13 |
ttx | #action all to think about who would make a great guest for the next Deep Dive episode | 15:14 |
ttx | #topic Large Scale doc | 15:14 |
ttx | #link https://docs.openstack.org/large-scale | 15:14 |
ttx | Nothing new to report here, nothing in review | 15:14 |
ttx | #topic Next meetings | 15:15 |
ttx | Next meeting is October 26, but I'll be taking some vacation so won;t be around | 15:15 |
belmoreira | uhmm... I won't be around either | 15:16 |
ttx | We can skip it but that means waiting to target a specific guest | 15:16 |
ttx | maybe we can move to email to discuss guest | 15:16 |
ttx | Then that leaves two IRC meetings to finalize our next OpenInfra Live episode on December 8 | 15:16 |
ttx | which I think is the good timing | 15:16 |
belmoreira | yes, that works | 15:17 |
ttx | Does that work? | 15:17 |
ttx | #info Skipping meeting on Oct 26 | 15:17 |
ttx | #info Next IRC meetings on Nov 9 and Nov 23 | 15:17 |
amorin | hello! sorry I cant make it before | 15:17 |
ttx | #info Next OpenInfra Live tentatively scheduled on Dec 8 | 15:17 |
ttx | I'll let you catch up and let us know your thoughts | 15:17 |
* ttx freezes | 15:17 | |
ttx | (before we switch to open discussion) | 15:18 |
ttx | amorin: all caught up? | 15:19 |
amorin | yes, done | 15:19 |
ttx | any comment/objection? | 15:19 |
amorin | checking my calendar right now | 15:19 |
amorin | for dec. 8 | 15:19 |
amorin | free slot, it's ok | 15:20 |
ttx | cool | 15:20 |
ttx | #topic Open discussion | 15:20 |
ttx | Next week is PTG, and there are quite a few sessions targeted to ops | 15:20 |
ttx | named "operator hours | 15:20 |
ttx | " | 15:20 |
ttx | like for example wednesday at 16utc Nova is holding one | 15:21 |
felixhuettner[m] | is there a schedule available somewhere? | 15:21 |
ttx | I think it is a great idea and a good opportunity for operators to bring their concerns directly to the dev teams | 15:21 |
ttx | https://ptg.opendev.org/ptg.html | 15:21 |
ttx | Event is virtual, free to join | 15:22 |
amorin | thanks, I was looking for it as well :) | 15:22 |
belmoreira | +1 | 15:22 |
felixhuettner[m] | +1 | 15:22 |
ttx | If you look at the "scheduled tracks" and click on the various days you will see some slots earmarked for "operator-hour-something" | 15:22 |
ttx | of course you can join any of the other meetings as well | 15:22 |
ttx | but that makes it easier to spot dedicated operator hour sessions | 15:23 |
belmoreira | it's a very good initiative | 15:23 |
amorin | yup | 15:23 |
ttx | Also had a question around who would be a good example of running multi-AZ (or multi-region) deployments in multiple sites around the world | 15:24 |
ttx | I know OVHcloud does it... I suspect Vexxhost would be in that case too... | 15:24 |
ttx | Anyone else? | 15:24 |
amorin | cleura? | 15:24 |
amorin | not sure about there datacenter location | 15:24 |
ttx | any private cloud? | 15:25 |
amorin | blizzard? | 15:25 |
ttx | blizzard's probably | 15:25 |
amorin | :) | 15:25 |
ttx | trying to remember from their presentation | 15:25 |
ttx | just not enough room in my brain to store all that information | 15:26 |
belmoreira | :) | 15:26 |
amorin | ubisoft? | 15:26 |
ttx | yeah those probably have some world-ly coverage | 15:27 |
belmoreira | specially when it changes so fast... I don't even try now :) We can search a little bit | 15:27 |
amorin | cleura is: https://cleura.com/services/cloud-features/regions-and-services/ | 15:27 |
belmoreira | ttx why the question? | 15:27 |
ttx | belmoreira: Socieet generale was askingas they seem to run into some issues | 15:28 |
ttx | I should know more soon | 15:28 |
ttx | just wanted to tell them they are not the first trying to do that | 15:28 |
ttx | Alright, anything else, anyone? | 15:28 |
belmoreira | ok. The challenges of having multi AVZ/multi region in the same site, should be similar | 15:29 |
felixhuettner[m] | for the same sites we have something like that | 15:30 |
felixhuettner[m] | but they are phyiscally quite close | 15:30 |
ttx | yeah they insisted about being distributed globally so maybe there is a latency or human factor | 15:30 |
ttx | anyway, thanks for the pointers :) | 15:30 |
amorin | then we can talk :) | 15:30 |
amorin | we should invite them to one of our meeting, no? | 15:31 |
belmoreira | we can always speculate for latency, central storage, ... | 15:31 |
ttx | We invited them a few times, I can re-invite | 15:31 |
ttx | Anything else before we close? | 15:31 |
ttx | I'll take that as a no... Thanks everyone! | 15:32 |
ttx | #endmeeting | 15:32 |
opendevmeet | Meeting ended Wed Oct 12 15:32:18 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:32 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/large_scale_sig/2022/large_scale_sig.2022-10-12-15.01.html | 15:32 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/large_scale_sig/2022/large_scale_sig.2022-10-12-15.01.txt | 15:32 |
opendevmeet | Log: https://meetings.opendev.org/meetings/large_scale_sig/2022/large_scale_sig.2022-10-12-15.01.log.html | 15:32 |
mdelavergne | thanks, see you | 15:32 |
felixhuettner[m] | thanks | 15:32 |
belmoreira | thanks everyone | 15:32 |
amorin | thanks | 15:32 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!