08:02:25 <tobberydberg> #startmeeting publiccloud_sig 08:02:25 <opendevmeet> Meeting started Wed Feb 1 08:02:25 2023 UTC and is due to finish in 60 minutes. The chair is tobberydberg. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:02:25 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:02:25 <opendevmeet> The meeting name has been set to 'publiccloud_sig' 08:02:34 <tobberydberg> No worries puck 08:02:58 <tobberydberg> I have to excuse my self every time here as well ;-) 08:03:08 <puck> :) 08:03:12 <kopecmartin> o/ 08:03:27 <tobberydberg> Thanks for putting up the agenda fkr 08:03:29 <diablo_rojo_phone> o/ 08:03:39 <tobberydberg> welcome diablo_rojo_phone :-) 08:03:48 <tobberydberg> As usual - https://etherpad.opendev.org/p/publiccloud-sig-meeting 08:03:53 <gtema> morning guys 08:04:03 <tobberydberg> morning gtema 08:05:54 <tobberydberg> Think we had good discussion last week ... discussing the interop tests, certificates etc 08:06:24 <tobberydberg> #topic 1. How to continue the "standard set of properties" work 08:07:23 <fkr> I do have a bit of embarassing question regarding that ;) 08:07:23 <gtema> A good question. Honestly speaking I am now not really having any idea 08:07:50 <tobberydberg> Plan is to continue this discussion, to me it is a little bit unclear... 08:07:52 <fkr> flavor naming. Has that been discussed? maybe before I was active here? 08:07:58 <puck> Something which I don't think has been raised is the microversions, do we want to track that? 08:08:52 <puck> I think flavor naming has been left as too hard, but that is where flavor aliases come in. 08:08:53 <tobberydberg> We have a list further down on the etherpad that contains the "items" that we decided for a bunch of meetings ago 08:08:54 <gtema> fkr: flavor naming - we discussed that it makes sense to focus on attributes and tags being present 08:09:08 <puck> (side note, I wish that we allowed alternative spellings for things like flavour) 08:09:12 <gtema> and ensuring client tools are capable to proceed with that (and select the one matching) rather then agree on naming 08:09:23 <fkr> ok. thanks. as part of SCS we standardize the flavor name and actually ran into this: https://github.com/SovereignCloudStack/standards/issues/190 ;) 08:10:03 <gtema> naming convention is doomed in my eyes, especially when multiple operators come together 08:10:27 <puck> Also, operators aren't going to rename their flavours due to a standard. 08:11:01 <fkr> but if they build greenfield they can adopt and new clouds that arise can adopt it 08:11:04 <puck> (although I guess others could be added, but that'll complicate things) 08:11:08 <puck> haha 08:11:28 <puck> fkr that is a bit nasty. 08:11:42 <puck> (colon character) 08:11:46 <fkr> sorry, confusing what I said: I did NOT mean they should rebuild greenfield 08:11:55 <fkr> puck: indeed 08:12:12 <fkr> puck: the rfc comment is helpful 08:12:27 <gtema> fkr - we are not able to properly enforce even attribute naming in varios services of OpenStack properly. Believing to enforce this to many independent organization is a bit utopic, sorry for zynism 08:12:30 <tobberydberg> Yea, we had extensive discussions regarding this. Would be so nice to have it, but super complicated to achieve I believe 08:12:43 <fkr> tobberydberg: thanks 08:13:54 <tobberydberg> Alias following a standard was the closest we god, but we dismissed that in favor for client support selecting flavor based on attributes instead 08:14:13 <puck> Will things like Terraform support that though? 08:14:45 <tobberydberg> so, if you look where it says "list based on votes" in the etherpad you'll see the list there 08:15:20 <tobberydberg> puck Well, IMO, we make sure the support is there at least to create support in other tools 08:15:33 <puck> ack 08:15:36 <tobberydberg> I assume that is the first step 08:15:44 <puck> Just a note to folks, please add your names under Participants. 08:15:54 <gtema> puck - this is up to tools maintainers to implement it. For Ansible/SDK/CLI we are responsible so we implement it. For TF I guess nobody here can give a reliable statement 08:16:25 <puck> I can check with one of my colleagues, he's been submitting patches to gophercloud which Terraform uses. 08:16:56 <tobberydberg> from that list, new things that does not exist already is: cpu - cpu_oversubscription, cpu_oversubscription_ratio - images: os_type, is_licensed 08:17:53 <tobberydberg> sounds great puck 08:17:55 <tobberydberg> The rest that are there already exist support for, right? 08:18:48 <gtema> yes, should be 08:19:05 <puck> yup 08:19:24 <tobberydberg> Ok. With that said then .... will the next step be writing specs? 08:19:35 <fkr> wohoo! 08:19:58 <puck> sounds right 08:22:27 <fkr> is there a mode in which we want to do that collaboratively? 08:23:00 <gtema> etherpad is always there for things like that ;-) 08:23:07 <diablo_rojo_phone> +2 08:23:11 <tobberydberg> Yea, I would say so too 08:23:20 <fkr> yeah, that was what came to my mind. +1. 08:23:41 <tobberydberg> But ok. What specs do we need to wite then? :-) 08:24:23 <gtema> correct question 08:24:25 <tobberydberg> One for each project affected? 08:24:52 <tobberydberg> Always becomes hairy when touching central pieces like this ;-) 08:25:53 <tobberydberg> Or is it possible to have one spec? 08:26:40 <puck> Changes to Nova and Glance though? 08:27:04 <diablo_rojo_phone> What all projects will it touch? 08:27:26 <puck> Or is it a "public cloud spec" which species what properties are expected on which resources? 08:27:32 <puck> specifies 08:27:54 <tobberydberg> Nova, Glance, SDK/OSC ... more? 08:28:06 <tobberydberg> That was what I was thinking about as well puck 08:28:24 <puck> Having a "public cloud spec" initially, then in the future rolling that into the services would be a lot easier! 08:28:24 <fkr> puck: that is a tad what I expected and from there it goes into depth for each affected component / project 08:29:35 <diablo_rojo_phone> That sounds like a good plan. 08:29:53 <tobberydberg> indeed ... if it sufficient to do it that way? 08:30:05 <puck> I think it is sufficient. 08:30:28 <puck> Would also provide a framework to define where the validation testing for public clouds should be defined. 08:31:38 <fkr> indeed. maybe that is something where scs can provide bits, since we're on exactly that at the moment 08:32:07 <tobberydberg> So, that means that we need to kick off the public cloud git repo again I assume 08:32:28 <diablo_rojo_phone> Nova will want a specific spec, but you can base it on the public cloud one. 08:33:52 <tobberydberg> Need some home for the spec at least. Is that the way to go, or can we host is somewhere else? 08:33:54 <tobberydberg> ok diablo_rojo_phone .... good to know 08:34:39 <puck> I think the options are a git repo, etherpad or the wiki. 08:34:58 <puck> It should most likely end up in a git repo. 08:36:08 <diablo_rojo_phone> Yes I would agree 08:36:39 <tobberydberg> yea, I guess so... We can start on etherpad and work that out later 08:37:38 <puck> To start with it'd hopefully be rather dynamic. 08:38:31 <tobberydberg> Lets use thi one: #link https://etherpad.opendev.org/p/publiccloud-sig-specs 08:39:29 <tobberydberg> So, aim for one spec here containing both flavors and images then? 08:39:53 <tobberydberg> And then later nail down what additional specs that needs to be produced? 08:40:58 <puck> I think so 08:42:08 <tobberydberg> Well, let's start with that at least. Super if we all can spend a few minutes with getting some basics in there. 08:43:01 <tobberydberg> Leave that topic for today? 08:43:17 <gtema> +1 08:43:18 <puck> +1 08:43:21 <fkr> +1 08:43:58 <tobberydberg> #topic 2. Invitation to Lean Coffee @ SCS 08:44:10 <tobberydberg> leave the word to you fkr :-) 08:44:17 <fkr> Once per month we have a Lean Coffee for Operators that run SCS based clouds. I initiated the format in order to have operators exchange on hurdles, problems and the fun of operating OpenStack clouds. 08:44:39 <fkr> There is a post that explains the format here: https://scs.community/2022/07/05/lean-scs-operator-coffee/ 08:45:00 <fkr> and I'd like to get more operators into that lean coffee. so this is an open invitation to you :) 08:45:30 <fkr> next one is upcoming Monday, 15:05 CET 08:45:53 <tobberydberg> How centric are the discussions/topics around SCS and clouds deployed with that stack? 08:46:02 <fkr> not really 08:46:10 <tobberydberg> Or are they more OpenStack OPS centric? 08:46:13 <fkr> mostly general openstack stuff as of now 08:46:23 <fkr> that is why I wanted to bring it here 08:46:32 <tobberydberg> ok, thanks, good to know 08:46:41 <puck> Minor suggestion, but could you please add CET to the time on that page? 08:46:52 <fkr> will do 08:47:01 <puck> ta 08:47:03 <fkr> https://scs.community/contribute/ 08:47:05 <puck> Looks interesting 08:47:22 <fkr> there is our calendar, where all our meetings (including the coffee) are visible. there is also a ics file available. 08:47:38 <fkr> would you say, it is OK to mail openstack-discuss@ with a pointer? 08:47:50 <puck> I think that is okay 08:48:51 <tobberydberg> I would say so too. Shape the message a little bit for what the discussions are about, OpenStack OPS in general and I think you'll have a better result 08:49:03 <fkr> tobberydberg: +1 thanks 08:49:44 <puck> Is it virtual coffee only, or in person as well? 08:49:53 <tobberydberg> I will pass on the invitation internally here as well 08:50:21 <tobberydberg> Are you looking fo an excuse to go to Germany puck? ;-) 08:50:25 <fkr> virtual in a jitsi session 08:50:41 <puck> Absolutely! I have a colleague who lives in France. 08:50:51 <tobberydberg> :-) 08:51:01 <fkr> puck: if you come my place, I'll have a coffee WITH cake with you! 08:51:17 <puck> Haha! I'll hold you to it! 08:51:22 <fkr> +1 08:51:43 <fkr> ok. we've got that topic covered, imho. :) 08:51:54 <tobberydberg> cool 08:52:08 <tobberydberg> #topic 3. Other matters 08:52:42 <fkr> maybe a hint for upcoming events 08:52:49 <fkr> there is fosdem this upcoming weekend 08:52:55 <fkr> in brussels 08:53:13 <fkr> however all the sessions are recorded and I _think_ also streamed 08:53:27 <fkr> https://fosdem.org/2023/ 08:53:51 <tobberydberg> Not available to go there unfortunate 08:54:00 <tobberydberg> But I saw OpenInfra is hosting some "after party thing" 08:54:14 <fkr> Saturday evening that is 08:54:41 <tobberydberg> gtema Was thinking about asking you have it goes with credentials to various clouds? Have you gotten any and/or are you in need of it? 08:54:46 <fkr> https://www.meetup.com/brussels-openinfra-meetup-group/events/290894971/ 08:54:47 <diablo_rojo_phone> Yes a happy hour I believe 08:55:27 <gtema> tobberydberg - nothing more so far. We got finally SDK and AOC released so I am unblocked to proceed with finishing auto jobs 08:55:42 <puck> Here's a thought for a topic, gettings images uploaded to public clouds by the distros. 08:56:03 <fkr> gtema: https://github.com/SovereignCloudStack/docs/blob/main/community/contribute/cloud-resources/cloud-resources.md 08:56:13 <puck> We're do all of them ourselves, but some of the images (like the SuSE Enterprise Linux) are behind paywalls, so are a hassle. 08:56:15 <fkr> gtema: we should get you into that for SDK/CLI 08:56:59 <gtema> right fkr 08:57:10 <gtema> will discuss with you all in person in Brussels ;-) 08:57:45 <fkr> +1 08:57:47 <fkr> :) 08:58:45 <tobberydberg> Not sure how you mean puck? Distros being allowed to public images directly to the clouds and make them available for customers? 08:58:57 <puck> Yeah 08:59:16 <puck> Or coordinating for consistency. 08:59:52 <puck> From what I've seen being on the debian-cloud mailing list, the distros upload images for the "big" cloud providers, but ignore the others, except for making images avilable. 09:00:02 <puck> images available for download and use from their own websites. 09:00:23 <tobberydberg> aha, you mean openstack specific built images? 09:00:29 <puck> yeah 09:00:49 <gtema> sorry guys, need to jump off for next meeting 09:00:55 <fkr> gtema: enjoy! 09:00:57 <puck> ack 09:01:01 <puck> see ya 09:01:05 <fkr> thanks for the nice session! 09:01:19 <puck> I'm okay with this topic going on the agenda for the next meeting. 09:01:23 <fkr> +1 09:01:25 <diablo_rojo_phone> Thanks everyone! 09:01:32 <diablo_rojo_phone> Have fun in Brussels! 09:01:51 <tobberydberg> would be awesome ... try to find a cloud ready image to Rocky Linux .. they only have AWS :-) 09:01:53 <tobberydberg> yea, time is up ... thanks a lot! 09:01:55 <tobberydberg> puck Feel free to add it to the agenda +1 09:02:13 <tobberydberg> #endmeeting