| tobberydberg | o/ | 08:01 |
|---|---|---|
| amorin | Hello | 08:01 |
| gtema | hey ho | 08:01 |
| frickler | \o | 08:01 |
| tobberydberg | #startmeeting publiccloud_sig | 08:02 |
| opendevmeet | Meeting started Wed Sep 14 08:02:29 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 |
| noonedeadpunk | o/ | 08:02 |
| tobberydberg | Nice to see you here all of you! | 08:04 |
| tobberydberg | Agenda, short but sweet, found here: #link https://etherpad.opendev.org/p/publiccloud-sig-meeting | 08:04 |
| gtema | same here | 08:04 |
| gtema | I am quite disappointed there is not that much feedback on something that raised so many discussions during the summit | 08:04 |
| tobberydberg | I can agree with you on that | 08:04 |
| gtema | I do not have a feeling it makes sense to discuss and agree on something if general interest is gone | 08:05 |
| tobberydberg | #topic 1. Continue the dialogues regarding naming conventions and the Goals | 08:06 |
| gtema | I agree with all 3 goals as listed on etherpad | 08:07 |
| tobberydberg | That's a good point. I don't now if the best forward is to shoot a more direct email containing an actual proposal to the mailing list and hope to get the discussion going there? | 08:08 |
| gtema | maybe. So you mean like a WG to come up with proposal and pre-agreement between involved parties and letting it being further extended later | 08:09 |
| tobberydberg | Me too ... then the plan how to accomplish that is more in the air at this point, what to standardize for example | 08:10 |
| gtema | I'll have a meeting with SovereignClousStack folks tomorrow and will try to reiterate on that | 08:11 |
| gtema | *SovereignCloudStack | 08:11 |
| tobberydberg | Sounds good! | 08:12 |
| tobberydberg | Yea, that could be one way (creating the suggestion) | 08:12 |
| tobberydberg | I don't know if this meeting slot made it harder for people to join, maybe something to ask on the mailing list as well. | 08:13 |
| gtema | :) | 08:13 |
| frickler | seems like the intended effect of allowing nz to join hasn't worked well | 08:13 |
| gtema | yeah, sadly | 08:14 |
| gtema | but I do not also see much activity from EU based folks (except of us here) | 08:14 |
| amorin | On my side (ovh) I am following the subject but I don't have any strong opinion | 08:15 |
| tobberydberg | Yea, which timezone wise should work well at least, if not conflicts... | 08:16 |
| gtema | oh, you are from ovh, good, cause I already wanted to ask if there is somebody | 08:16 |
| amorin | I am trying to get people from OVH involved but that's hard | 08:16 |
| amorin | The tz is correct IMHO | 08:16 |
| gtema | well, if there are no participants with strong opinions on the topic of standardizing names maybe we try to finally touch other topics in detail? | 08:17 |
| tobberydberg | So, suggestion from my site regarding the "standardization" parts ... we make a proposal of what to include in that. We start of with the ones that are the most obvious ones and can improve later from there. Something to give a baseline to get the structure for verification/certification parts going as well. | 08:18 |
| gtema | agree | 08:19 |
| tobberydberg | Any objections to that? ;-) | 08:20 |
| noonedeadpunk | what I'm most dissapointed with is how active SCS was on summit and how they've dissapeared after | 08:20 |
| noonedeadpunk | as they're main part with strong opinions | 08:21 |
| gtema | well, we have some hidden representatives here if I am right, but not the ones who were active on that ;-) | 08:21 |
| frickler | yeah, I'm somehow SCS but also somehow not | 08:22 |
| gtema | yeah | 08:22 |
| tobberydberg | I think that some kind of alignment with SCS makes a lot of sense | 08:22 |
| gtema | maybe on that particular topic TZ is not suiting well, cause we have now heavy meetings time mornings | 08:22 |
| gtema | maybe if we come with suggestion I can push it towards to Kurt and involve him deeper | 08:23 |
| tobberydberg | If this slot isn't working I'm happy to revisit that topic, but lets seek feedback on that... | 08:24 |
| tobberydberg | Does SCS have a "implementation" of standardization already in place? | 08:24 |
| gtema | I think it was mostly draft on their concept, but I still do not agree naming standardisation is the right way and it raised also lot of concerns once he sent it to the mailing list | 08:25 |
| frickler | I think the flavor spec is pretty detailed, not sure what you mean by implementation | 08:25 |
| frickler | https://github.com/SovereignCloudStack/Docs/blob/main/Design-Docs/flavor-naming.md | 08:26 |
| gtema | well, the repo is already in archive with doc still being draft | 08:26 |
| tobberydberg | Well, implementation was more ment "a document in place" | 08:26 |
| gtema | so it is not really clear what's the current position on that is | 08:26 |
| gtema | ah, sorry, found it in another (older) repo | 08:27 |
| frickler | flavor seems to be actively worked upon, image looks stale in comparison https://github.com/SovereignCloudStack/Docs/blob/main/Design-Docs/Image-Properties-Spec.md | 08:28 |
| gtema | yeah, I was meaning old ver in https://github.com/SovereignCloudStack/Operational-Docs/blob/main/flavor-naming-draft.MD | 08:28 |
| gtema | as far as I remember this proposal raised lot of concerns in the mailing list | 08:29 |
| gtema | and I can fully support them, it is not user friendly to force user to decrypt names | 08:29 |
| tobberydberg | The flavors part is more about the naming there, which quickly becomes very complex | 08:30 |
| gtema | correct | 08:31 |
| gtema | SCS-2C:4:10n-bms-z3hh is hard to decode | 08:31 |
| gtema | never mind, this doc can be used to gather required props for flavors from SCS pov and include them on our side | 08:32 |
| gtema | not from naming side, but from the "facts" side | 08:32 |
| frickler | I think the question is which information you want to/need to have in the flavor name or how else you would handle them | 08:32 |
| frickler | exactly, first decide on facts, then on formatting | 08:32 |
| tobberydberg | yea ... the goal for us I believe is to have enough meta data to be able via simple apis, terraform etc select a flavor based on X meta data items | 08:33 |
| gtema | right | 08:33 |
| tobberydberg | regarding oversubscription ... I like your proposal there... Clear definition from "our end" - what is heavily for example | 08:36 |
| gtema | exactly, for now I just took what scs doc is describing, but that is the point of arguing - every operator have different understanding | 08:37 |
| jmurezovh | Hi all, sorry for being late on this topic and on this meeting. Back in Berlin we talked about the alignment on the naming of a couple of equivalent flavors & images. | 08:37 |
| jmurezovh | About images, nothing prevent us from agreeing on a naming, and depending on each actor constraints, creating a duplicate of an existing image or replacing one. | 08:39 |
| gtema | I guess images themselves are much easier topic, since also most of attributes are already present. Flavors are much trickier | 08:41 |
| tobberydberg | From a programatically perspective, it is easier to filter based on properties | 08:42 |
| gtema | right | 08:42 |
| jmurezovh | Does the job | 08:43 |
| noonedeadpunk | Sorry, I'm semi around. SCS did ignore all feedback they've recieved through ML. Moreover, I created a github issue in the repo that also has been ignored. So meh... | 08:43 |
| noonedeadpunk | So Ido agree that they did smth for themselves | 08:43 |
| tobberydberg | I do not have an issue either to align to a naming. Both would of course be even better, but might be to hard to strive for initially | 08:44 |
| noonedeadpunk | but it's not a draft atm | 08:44 |
| jmurezovh | Sorry again if it's been told already: About flavors, we need to align on ONE if we want to make it happen. | 08:44 |
| tobberydberg | jmurezovh are you referring to "name" when you say that? | 08:45 |
| noonedeadpunk | but about flavors - as an operator - you would likely prefeer to search through them based on the parameters | 08:45 |
| tobberydberg | you do you mean "alignment between this SIG and SCS"? | 08:45 |
| tobberydberg | *or | 08:45 |
| tobberydberg | I see parameters as the most important one, makes it super easy for any API or tool to work properly. Parsing names as a string is harder | 08:46 |
| jmurezovh | I like the idea of a set of "OpenStack flavors". First, we need to align on the Specs of these flavors, then a way have it identified as OpenStack flavors. | 08:48 |
| jmurezovh | First point is the trickiest one. | 08:48 |
| tobberydberg | Indeed | 08:49 |
| gtema | btw, I am right now with my second ear in the presentation of the crossplane | 08:49 |
| gtema | and here the main "selling" point is to offer customer "multicloud" experience | 08:49 |
| tobberydberg | But, will all operators be willing to align to "a standard set of flavors"? (I would) | 08:50 |
| gtema | now imagine how cool would this experience be if you try to bring some standard in particular OpenStack-based clouds, but absolutely no impact on flavor naming for other providers | 08:50 |
| gtema | so I really strongly believe there is no future of discussion on standardizing naming. Only defining relevant properties can be achieved | 08:51 |
| gtema | "a standard set of flavors" - I am not sure our cloud will agree on that | 08:51 |
| gtema | this is (as also said on summit) what differentiate all of us | 08:51 |
| frickler | can there be a minimum standard set that doesn't exclude other flavors to exist? | 08:52 |
| gtema | I doubt, imagine usecase where provider is only having ARM hardware | 08:53 |
| tobberydberg | I think that is a must, BUT, based on properties rather than names ... and just a few properties ... if that is just vcpu,ram and disk | 08:53 |
| gtema | disk in the flavor is something what worries me - it's not necessarily that flavor has anything to do with storage | 08:54 |
| tobberydberg | That does not prevent us from making other properties a must to provide as well ... oversubscription etc etc | 08:54 |
| tobberydberg | but then you have 0 as disk-size, right? | 08:54 |
| tobberydberg | its still not undefined | 08:55 |
| gtema | yeah, but it is already present | 08:55 |
| tobberydberg | of course | 08:56 |
| gtema | I mean more whether SSD storage is attached to it or not - something in this direction | 08:56 |
| frickler | o.k., so multiple types of sets, then, and the provider can choose one or multiple ones? | 08:56 |
| tobberydberg | so that makes the "must have list of flavors" only include a specific set of flavor ratio of vcpu and ram maybe | 08:56 |
| gtema | yes, this should be the goal. As a user I request a VM with 2cores, 8G ram and eventually that ram must be ECC | 08:57 |
| frickler | even the ratio could differ. or does everyone have 4G ram for 1 vcpu by now? | 08:57 |
| gtema | and my "provider" (cough-cough sdk) is selecting one on the target cloud, however it is called | 08:57 |
| tobberydberg | agree | 08:57 |
| gtema | sure, but we could also implement some suggestion (either softly pick up the closest or raise exception) | 08:58 |
| tobberydberg | I guess the only way forward on the ratio is to make a suggestion that we believe every cloud should have :-) | 08:58 |
| gtema | every cloud is really tough. You need to convince your marketing that it makes sense | 08:59 |
| frickler | if we get a critical mass, that should be easy. they won't be the ugly minority most likely | 09:00 |
| tobberydberg | yea I know, but a suggestion from a start and see how that can play out | 09:00 |
| frickler | unless it turns out in the end that consumers don't care at all | 09:00 |
| tobberydberg | So, trying to summarize here a little bit from todays meeting: | 09:00 |
| tobberydberg | 1. Create a suggestion of a standard set of flavors (ratio) based on vcpu and ram | 09:01 |
| tobberydberg | 2. Define a list of additional properties (recommended or required) to specify on flavors | 09:01 |
| tobberydberg | I think if we have that we have enough for flavors at least :-) | 09:03 |
| gtema | :) | 09:03 |
| tobberydberg | I know time is up. But, should I try to get that into todays meeting notes as "one list" for a start? | 09:04 |
| gtema | yeah, why not | 09:04 |
| frickler | also add that we don't care (so much) about naming, but just about properties? | 09:05 |
| tobberydberg | Ok. I'll do that. Keep an eye on that etherpad and feel free to change/add/remove stuff from that list as well ... lets try to get rid of all questionmarks :-) | 09:05 |
| gtema | +1 | 09:05 |
| tobberydberg | +1 | 09:05 |
| tobberydberg | Ok, cool. Thanks for today then! I try to shoot a reminder before next meeting as well :-) | 09:06 |
| frickler | that would be helpful, thx | 09:06 |
| gtema | great | 09:06 |
| tobberydberg | Talk to you in two weeks! :-) | 09:08 |
| tobberydberg | #endmeeting | 09:08 |
| opendevmeet | Meeting ended Wed Sep 14 09:08:06 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 09:08 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/publiccloud_sig/2022/publiccloud_sig.2022-09-14-08.02.html | 09:08 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/publiccloud_sig/2022/publiccloud_sig.2022-09-14-08.02.txt | 09:08 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/publiccloud_sig/2022/publiccloud_sig.2022-09-14-08.02.log.html | 09:08 |
| amorin | thanks! | 09:08 |
| opendevreview | Peter Matulis proposed openstack/arch-design master: Add memory overcommit caution https://review.opendev.org/c/openstack/arch-design/+/857721 | 14:57 |
| belmoreira | Hello everyone! Let's start the Large Scale SIG meeting | 15:00 |
| * ttx is around but on unreliable conf wifi | 15:00 | |
| belmoreira | #startmeeting large_scale_sig | 15:00 |
| opendevmeet | Meeting started Wed Sep 14 15:00:37 2022 UTC and is due to finish in 60 minutes. The chair is belmoreira. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'large_scale_sig' | 15:00 |
| belmoreira | #topic Rollcall | 15:00 |
| amorin | o/ | 15:00 |
| felixhuettner[m] | o/ | 15:00 |
| ttx | o/ | 15:00 |
| ihti[m] | o/ | 15:01 |
| belmoreira | welcome everyone | 15:01 |
| belmoreira | Our agenda for today is at: | 15:01 |
| belmoreira | #link https://etherpad.openstack.org/p/large-scale-sig-meeting | 15:02 |
| belmoreira | Let's start with the first topic | 15:02 |
| belmoreira | #topic OpenInfra Live September 29 episode - Deep dive into Schwarz Gruppe | 15:02 |
| belmoreira | good to have you here felixhuettner[m] ihti[m] | 15:02 |
| belmoreira | I sent an email early today with a possible structure for the show | 15:03 |
| felixhuettner[m] | already looking forward to that session | 15:03 |
| belmoreira | have you had the opportunity to have a look? | 15:03 |
| felixhuettner[m] | yep, it looks nice for me | 15:04 |
| ihti[m] | +1 | 15:04 |
| belmoreira | amorin ttx are we missing something? | 15:04 |
| amorin | I am having a look | 15:05 |
| amorin | seems quite complete from first reading | 15:05 |
| ttx | I think it's a solid base | 15:05 |
| felixhuettner[m] | we are also already collecting stories to share :D | 15:05 |
| belmoreira | nice | 15:05 |
| amorin | great | 15:05 |
| belmoreira | we don't want to have a rigid structure... but only only some guidance | 15:06 |
| belmoreira | then we see where the conversation goes | 15:06 |
| felixhuettner[m] | yep, some ideas to throw in the discussion is always good | 15:06 |
| belmoreira | is there any topic that you don't feel comfortable to talk about? | 15:06 |
| belmoreira | ex: size of the infrastructure, software used, ... | 15:07 |
| felixhuettner[m] | no that is all fine for me | 15:07 |
| felixhuettner[m] | since we have external customers we might need to spare something out there | 15:07 |
| felixhuettner[m] | but the internal ones are crazy enough for stories to share :D | 15:07 |
| belmoreira | great | 15:07 |
| felixhuettner[m] | and i think especially about the Yaook part has a lot of ideas to share | 15:08 |
| felixhuettner[m] | *things to share | 15:08 |
| belmoreira | something interesting to mention before the move to YAOOK? | 15:09 |
| felixhuettner[m] | mmmh, maybe a short part of where we came from | 15:09 |
| felixhuettner[m] | but i don't want to be too unfriendly to our previous external service provider :) | 15:10 |
| felixhuettner[m] | but i think we can share the general reasons why we choose to switch to yaook | 15:10 |
| felixhuettner[m] | and that should be more generally applicable | 15:10 |
| amorin | you were using an upstream deployment tool? | 15:11 |
| amorin | or somthing from a vendor? | 15:11 |
| felixhuettner[m] | one from a vendor | 15:11 |
| felixhuettner[m] | lets say Salt based | 15:11 |
| felixhuettner[m] | i guess there is only one :) | 15:11 |
| amorin | ack :) | 15:11 |
| belmoreira | ok, we would not focus on the past. But maybe a general context would be good to introduce the story of yaook | 15:12 |
| belmoreira | sounds good? | 15:12 |
| felixhuettner[m] | yep, that sounds good | 15:12 |
| amorin | the story about moving from the salt stuff to yaook is a good one also I think | 15:12 |
| felixhuettner[m] | yes, that was..... lets say "interesting" | 15:12 |
| belmoreira | :) | 15:12 |
| felixhuettner[m] | allthough we managed it "mostly" without downtime | 15:12 |
| felixhuettner[m] | expect for killing neutron for 1 day | 15:13 |
| belmoreira | from my side I look forward to meet you (now with video) in two weeks. I'm sure this will be great episode | 15:13 |
| belmoreira | amorin ttx something else? or felixhuettner[m] ihti[m] do you have any question? | 15:13 |
| felixhuettner[m] | not from me, looking forward to it | 15:14 |
| amorin | I cant wait for this episode! | 15:14 |
| ihti[m] | Nothing from my side. Looking forwared to the episode :) | 15:14 |
| belmoreira | just for reference: | 15:14 |
| belmoreira | #link https://openinfra.dev/live/ | 15:14 |
| belmoreira | let's move then to the next topic | 15:15 |
| belmoreira | #topic Status on docs website transition | 15:15 |
| belmoreira | #link https://docs.openstack.org/large-scale | 15:15 |
| belmoreira | Done by ttx. Thanks. | 15:15 |
| belmoreira | Looks good to me | 15:15 |
| felixhuettner[m] | yep, looks really nice now | 15:15 |
| belmoreira | ttx, do you want to add something else? | 15:16 |
| belmoreira | humm, conference wifi :) | 15:17 |
| belmoreira | I think we can move to the next one | 15:17 |
| ttx | nope | 15:17 |
| ttx | Sorry lag | 15:17 |
| belmoreira | no problem | 15:17 |
| belmoreira | #topic Next meetings | 15:18 |
| belmoreira | in 2 weeks we have the Open Infra Live and then we go back to the IRC meeting | 15:18 |
| belmoreira | September 29 - Open Infra Live - Ops Deep Dive | 15:18 |
| belmoreira | October 12 - IRC meeting | 15:18 |
| amorin | ack | 15:19 |
| belmoreira | in October we can then reflect about the Open Infra Live episode and start to discuss what's next | 15:19 |
| belmoreira | #topic Open discussion | 15:20 |
| belmoreira | we have the following in the agenda | 15:20 |
| belmoreira | "Fix for the neutron fanout queues is merged. Do we still need to delete old queues" | 15:20 |
| felixhuettner[m] | yep, just wanted to report that back from last round | 15:21 |
| amorin | can you share the gerrit link? | 15:21 |
| belmoreira | I don't have the context about it | 15:21 |
| felixhuettner[m] | so in master there should be no longer any old fanout queues | 15:21 |
| felixhuettner[m] | #link https://bugs.launchpad.net/neutron/+bug/1586731 | 15:21 |
| felixhuettner[m] | #link https://review.opendev.org/c/openstack/neutron/+/855851 | 15:21 |
| felixhuettner[m] | #link https://review.opendev.org/c/openstack/neutron/+/856411 | 15:22 |
| felixhuettner[m] | belmoreira: the issue was that if you shutdown neutron-openvswitch-agent then there will be fanout queues left in rabbitmq | 15:22 |
| felixhuettner[m] | and they pile up a bunch of messages | 15:22 |
| amorin | that's great, we are affected by this here | 15:22 |
| belmoreira | nice | 15:22 |
| amorin | we endup with a very low expire policy to not suffer from this | 15:23 |
| amorin | so, that's a great improvment, thanks :) | 15:23 |
| felixhuettner[m] | thanks :) | 15:23 |
| belmoreira | thanks felixhuettner[m] | 15:23 |
| belmoreira | something else? before we close the meeting | 15:24 |
| ttx | nothing from me | 15:24 |
| felixhuettner[m] | not from me | 15:24 |
| belmoreira | Thank you everyone. Let's have a great "Ops Deep Dive" episode. | 15:25 |
| belmoreira | #endmeeting | 15:25 |
| opendevmeet | Meeting ended Wed Sep 14 15:25:17 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:25 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/large_scale_sig/2022/large_scale_sig.2022-09-14-15.00.html | 15:25 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/large_scale_sig/2022/large_scale_sig.2022-09-14-15.00.txt | 15:25 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/large_scale_sig/2022/large_scale_sig.2022-09-14-15.00.log.html | 15:25 |
| felixhuettner[m] | thanks everyone | 15:25 |
| ihti[m] | Thanks, see you :) | 15:25 |
| ttx | thanks belmoreira for holding the fort! | 15:25 |
| amorin | thanks! | 15:25 |
| belmoreira | and ttx enjoy the ossummit | 15:25 |
| opendevreview | Merged openstack/arch-design master: Add memory overcommit caution https://review.opendev.org/c/openstack/arch-design/+/857721 | 17:10 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!