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