Wednesday, 2022-10-12

tobberydbergMorning o/08:00
puckGood evening!08:01
gtemamorning08:01
tobberydbergWould have been nice with evening here right now as well ;-) 08:01
fkro/08:02
puckheh08:02
fkrgood morning08:02
tobberydberg#startmeeting publiccloud_sig08:02
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.08:02
opendevmeetThe meeting name has been set to 'publiccloud_sig'08:02
frickler\o08:02
tobberydbergAs usual, agenda etc found at https://etherpad.opendev.org/p/publiccloud-sig-meeting08:03
tobberydbergFirst out, just a double check of the summarized list of properties so that I did a correct summary of our voting.08:04
puckI think that is right.08:06
gtemayupp, looks fine for me also08:06
fkrack08:07
tobberydbergGood, sounds like we have something to start with then. Next question will then be how we should proceed? :-) 08:07
puckha08:08
tobberydbergDo we need clarify format of the different fields? Or is that super clear? 08:08
puckI think that specifying the format would be good, and also like, cores under cpu. Is that cpu_cores?08:09
gtemain this world nothing is super clear08:09
gtemaespecially I often observe bools are implemented as string by some services08:09
tobberydbergpuck Yes, so flavors we only have the oversubscription basically that is "new" and not already required08:10
tobberydberggtema Yea, would be good if we could do it correct :-) 08:11
gtemasure, but therefore it may make sense to actually define what are we expecting08:12
gtemacause actually user (tool) would need to expect something08:12
tobberydbergSo format and potentially an "example flavor" using that would be useful for clairification 08:12
tobberydbergexactly 08:13
gtemameaning SDK/gopher/cli would need to find attr used by server and auto-correct to specific type08:13
gtema=> there is interface expectation08:13
tobberydbergindeed 08:13
gtemaindependent on that - at least I do not really know how oversubscription ration is filled. So some explanation to that is also required08:16
gtemaratio08:16
gtemaon architecture - arm or armv6 etc08:17
puckarchitecture would need to be be armv608:17
puckboolean is 0/1 ?08:18
gtemano, bool should stay bool: true/false08:18
fkrgtema: 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 value08:19
gtema"vCPU (oversubscribed)" - this is from the name unclear - is this count or bool08:19
fkrgtema: we (SCS) elaborated on that here: https://github.com/SovereignCloudStack/Docs/blob/main/Design-Docs/flavor-naming.md?plain=1#L7008:20
gtemafkr - 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 used08:20
tobberydbergI started to fill in some info inline in the list, please check that and add what you think is needed08:20
fkrgtema: 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
gtemaprecisely the point - you have already some definition that MAY be different for a person reading list of "required" parameters - this need to be explicitly described08:23
tobberydbergSo, my personal thoughts here are to have one field called "cpu_subscription" => "dedicated cores, dedicated threads, oversubscribed"08:24
tobberydbergAnother field called "oversubscription_ratio" => "0,5,10,X,XX" 08:24
tobberydbergIs that a way to tackle it?08:25
gtemano 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 today08:26
tobberydbergGood 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
tobberydbergThinking out loud here ;-) 08:28
* fkr is pondering and thinking silently :)08:28
jmurezovhMy 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
fkrfull ack, jmurezovh 08:29
fkrwhich is - I think what gtema and I tried to express08:29
fkrthe fact that oversubscription happens is vital, so that is the first field. 08:30
fkrin a discussion I was part of we wondered wether 'measured steal time' could be an indicator on how much noisy neighbour effect is present08:30
fkrhowever that brings a whole load of further instrumentation alongside with it so we did abandon that for the time being08:31
fkrso for the first (vCPU oversubscribed) it would be boolean here?08:34
tobberydbergI 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
puckI 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
tobberydbergfkr could make it that simple, if we don't want to cover dedicated threads, dedicated cores?08:35
tobberydbergTotally agree with that, but will that bring enough "expectation" to the customer?08:36
puckI think that cpu_subscription is a boolean, with an optional cpu_subscription_ratio08:38
puckWhich is an integer.08:38
tobberydbergthen a more correct term is probably "cpu_oversubscription" and "cpu_oversubscription_ratio"08:39
puckugh, yes, that's what I mean to type.08:40
tobberydbergThen we are skipping the "dedicated_x" stuff08:40
fkrtobberydberg: imho yes08:40
tobberydbergwhat does others think?08:40
gtemaun-opinionated on that topic08:41
puckI guess it comes down to the architecutre of the CPU. Perhaps it is clear if it is core/threads basd on architecture08:42
tobberydbergand architecture is nothing we cover as of now, right?08:44
gtemawell, was not voted on08:45
gtemaindeed weird08:45
puckYeah, seems a useful thing to have on flavours.08:45
* puck quietly grumbles about having to use flavor08:45
gtemaI would really prefer to have chance to select arm arch rather some oversubscription08:45
tobberydbergindeed08:45
fkrack08:45
tobberydbergso, lets move that "up" to the ones selected08:46
fkrarchitecture is imho required. not sure, why we did not vote on that.08:46
gtemamaybe because it was split into vendor/gen/etc08:46
gtemaand on those I have (as user) absolutely no interest08:47
gtemabut arch as such is important to me08:47
fkr+108:47
puckIt becomes a bit murky, since our flavours are amd64, but we run on Intel CPUs.08:47
puckWhich I expect is a lot of people.08:48
tobberydbergSCS calls this "CPU Type", right?08:48
fkrtobberydberg: https://github.com/SovereignCloudStack/Docs/blob/main/Design-Docs/flavor-naming.md?plain=1#L4608:49
fkr(yes ;)08:49
tobberydbergWould we rather like to call it "cpu_type" or "cpu_architecture"?08:51
fkrthe latter imho08:52
gtemaagree, type can be misinterpreted to tons of specific things08:52
fkrI'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
tobberydbergLets stick with architecture then08:55
fkr+108:55
jmurezovh+108:56
puck+108:56
gtema+108:57
tobberydbergTime 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 well08:57
tobberydbergWould also just like to take the time to promote the operator sessions during the PTG next week.08:58
tobberydbergKendall wrote a blogpost about it08:58
fkrwould it make sense to switch to a weekly cadence for a while after the PTG?08:59
puckI think that image properties are fairly well defined already.08:59
gtemasince 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
tobberydbergJust so that you all are aware of them :-) 08:59
tobberydbergI think that would be great gtema 08:59
fkrgtema: I will ask the scs operators regarding the sdk/cli operator hour09:00
fkrpretty certain there wil be interest09:00
gtemaokay, will talk to Kendal to take it in also09:00
tobberydbergI agree with you fkr - weekly would probably be good after next session in 2 weeks. 09:00
tobberydbergLets reconvene in 2 weeks (after the PTG) and deal with that then. 09:01
fkr+109:01
puck+109:01
tobberydbergThanks 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
gtemathanks09:03
tobberydberg#endmeeting09:04
opendevmeetMeeting ended Wed Oct 12 09:04:51 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)09:04
opendevmeetMinutes:        https://meetings.opendev.org/meetings/publiccloud_sig/2022/publiccloud_sig.2022-10-12-08.02.html09:04
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/publiccloud_sig/2022/publiccloud_sig.2022-10-12-08.02.txt09:04
opendevmeetLog:            https://meetings.opendev.org/meetings/publiccloud_sig/2022/publiccloud_sig.2022-10-12-08.02.log.html09:04
ttxo/15:01
ttx#startmeeting large_scale_sig15:01
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:01
opendevmeetThe meeting name has been set to 'large_scale_sig'15:01
felixhuettner[m]o/15:01
ttx#topic Rollcall15:01
ttxWho is here for the Large Scale SIG meeting?15:01
belmoreirao/15:01
felixhuettner[m]o/15:01
ttxSorry for the late reminder on the mailing list15:01
ramona-beermann[m]o/15:01
TimBeermann[m]o/15:01
ttxI was traveling to OpenInfra Day Turkey earlier this week and just got back15:02
ttxamorin: around?15:02
ttxOur agenda for today is at:15:03
ttx#link https://etherpad.openstack.org/p/large-scale-sig-meeting15:03
ttxfeel free to add more to it15:03
ttxalright let's get started15:03
ttx#topic Ops Deep Dive15:03
ttxTwo weeks ago we had our openInfra Live! Ops Deep Dive with Schwarz Group15:04
ttxThe video has been viewed 410 times on YouTube, which is on par with others in the same series15:04
ttx(and above average for Openinfra Live)15:04
ttxand I think it went well, what do you think?15:04
felixhuettner[m]it was a lot of fun15:04
felixhuettner[m]received a lot of positive feedback from collegues15:04
belmoreiragreat! Good to know15:05
ttxI'd like to arrange a new one early December, like on December 815:05
ttxbelmoreira: can you continue to do those?15:05
belmoreirafelixhuettner[m] is there something that you would like that we have done differently?15:06
ttxor you don;t know yet?15:06
felixhuettner[m]no, went really smooth15:06
belmoreirafelixhuettner[m] I would like to thank you again. It was a very good talk.15:07
belmoreirattx I don't know yet. But I would like to continue to be involved15:07
belmoreiraI will let you know as soon as I know15:08
ttxI'll count you in unless you tell me otherwise :)15:08
ttxFor the next episode any suggestion who we should ask to present ?15:08
belmoreiraI didn't put a lot of thought on it... can we have our 2 weeks to think about it?15:09
ttxwe did public cloud, retail, media... I'm tempted to do banking (like societe generale) but not sure they qualify as large yet15:09
ttxyeah we don't need to decide now15:10
ttxanything else on the Deep dive topic?15:11
belmoreirathat 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 live15:12
ttxfelixhuettner[m]: we usually do a Large Scale session at the Forum, yes15:12
felixhuettner[m]+115:12
felixhuettner[m]yep they where quite full this year15:12
belmoreiraI see the Summit with the opportunity to connect with all community.15:12
ttxit often ends in a rabbitMQ PTSD support group but we always uncover good questions15:13
felixhuettner[m]:)15:13
ttxso at Summit it's much more of a wide discussion 15:13
ttxrather than a deep dive15:13
ttxbut 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 episode15:14
ttx#topic Large Scale doc15:14
ttx#link https://docs.openstack.org/large-scale15:14
ttxNothing new to report here, nothing in review15:14
ttx#topic Next meetings15:15
ttxNext meeting is October 26, but I'll be taking some vacation so won;t be around15:15
belmoreirauhmm... I won't be around either15:16
ttxWe can skip it but that means waiting to target a specific guest15:16
ttxmaybe we can move to email to discuss guest15:16
ttxThen that leaves two IRC meetings to finalize our next OpenInfra Live episode on December 815:16
ttxwhich I think is the good timing15:16
belmoreirayes, that works15:17
ttxDoes that work?15:17
ttx#info Skipping meeting on Oct 2615:17
ttx#info Next IRC meetings on Nov 9 and Nov 2315:17
amorinhello! sorry I cant make it before15:17
ttx#info Next OpenInfra Live tentatively scheduled on Dec 815:17
ttxI'll let you catch up and let us know your thoughts15:17
* ttx freezes15:17
ttx(before we switch to open discussion)15:18
ttxamorin: all caught up?15:19
amorinyes, done15:19
ttxany comment/objection?15:19
amorinchecking my calendar right now15:19
amorinfor dec. 815:19
amorinfree slot, it's ok15:20
ttxcool15:20
ttx#topic Open discussion15:20
ttxNext week is PTG, and there are quite a few sessions targeted to ops15:20
ttxnamed "operator hours15:20
ttx"15:20
ttxlike for example wednesday at 16utc Nova is holding one15:21
felixhuettner[m]is there a schedule available somewhere?15:21
ttxI think it is a great idea and a good opportunity for operators to bring their concerns directly to the dev teams15:21
ttxhttps://ptg.opendev.org/ptg.html15:21
ttxEvent is virtual, free to join15:22
amorinthanks, I was looking for it as well :)15:22
belmoreira+115:22
felixhuettner[m]+115:22
ttxIf you look at the "scheduled tracks" and click on the various days you will see some slots earmarked for "operator-hour-something"15:22
ttxof course you can join any of the other meetings as well15:22
ttxbut that makes it easier to spot dedicated operator hour sessions15:23
belmoreirait's a very good initiative15:23
amorinyup15:23
ttxAlso had a question around who would be a good example of running multi-AZ (or multi-region) deployments in multiple sites around the world15:24
ttxI know OVHcloud does it... I suspect Vexxhost would be in that case too...15:24
ttxAnyone else?15:24
amorincleura?15:24
amorinnot sure about there datacenter location15:24
ttxany private cloud?15:25
amorinblizzard?15:25
ttxblizzard's probably15:25
amorin:)15:25
ttxtrying to remember from their presentation15:25
ttxjust not enough room in my brain to store all that information15:26
belmoreira:)15:26
amorinubisoft?15:26
ttxyeah those probably have some world-ly coverage15:27
belmoreiraspecially when it changes so fast... I don't even try now :) We can search a little bit15:27
amorincleura is: https://cleura.com/services/cloud-features/regions-and-services/15:27
belmoreirattx why the question?15:27
ttxbelmoreira: Socieet generale was askingas they seem to run into some issues15:28
ttxI should know more soon15:28
ttxjust wanted to tell them they are not the first trying to do that15:28
ttxAlright, anything else, anyone?15:28
belmoreiraok. The challenges of having multi AVZ/multi region in the same site, should be similar15:29
felixhuettner[m]for the same sites we have something like that15:30
felixhuettner[m]but they are phyiscally quite close15:30
ttxyeah they insisted about being distributed globally so maybe there is a latency or human factor15:30
ttxanyway, thanks for the pointers :)15:30
amorinthen we can talk :)15:30
amorinwe should invite them to one of our meeting, no?15:31
belmoreirawe can always speculate for latency, central storage, ... 15:31
ttxWe invited them a few times, I can re-invite15:31
ttxAnything else before we close?15:31
ttxI'll take that as a no... Thanks everyone!15:32
ttx#endmeeting15:32
opendevmeetMeeting ended Wed Oct 12 15:32:18 2022 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:32
opendevmeetMinutes:        https://meetings.opendev.org/meetings/large_scale_sig/2022/large_scale_sig.2022-10-12-15.01.html15:32
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/large_scale_sig/2022/large_scale_sig.2022-10-12-15.01.txt15:32
opendevmeetLog:            https://meetings.opendev.org/meetings/large_scale_sig/2022/large_scale_sig.2022-10-12-15.01.log.html15:32
mdelavergnethanks, see you15:32
felixhuettner[m]thanks15:32
belmoreirathanks everyone15:32
amorinthanks15:32

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!