08:02:29 <tobberydberg> #startmeeting publiccloud_sig
08:02:29 <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:29 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:02:29 <opendevmeet> The meeting name has been set to 'publiccloud_sig'
08:02:47 <noonedeadpunk> o/
08:04:06 <tobberydberg> Nice to see you here all of you!
08:04:08 <tobberydberg> Agenda, short but sweet, found here: #link https://etherpad.opendev.org/p/publiccloud-sig-meeting
08:04:18 <gtema> same here
08:04:20 <gtema> I am quite disappointed there is not that much feedback on something that raised so many discussions during the summit
08:04:45 <tobberydberg> I can agree with you on that
08:05:57 <gtema> I do not have a feeling it makes sense to discuss and agree on something if general interest is gone
08:06:26 <tobberydberg> #topic 1. Continue the dialogues regarding naming conventions and the Goals
08:07:53 <gtema> I agree with all 3 goals as listed on etherpad
08:08:08 <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:09:47 <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:10:12 <tobberydberg> Me too ... then the plan how to accomplish that is more in the air at this point, what to standardize for example
08:11:08 <gtema> I'll have a meeting with SovereignClousStack folks tomorrow and will try to reiterate on that
08:11:34 <gtema> *SovereignCloudStack
08:12:06 <tobberydberg> Sounds good!
08:12:08 <tobberydberg> Yea, that could be one way (creating the suggestion)
08:13:14 <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:33 <gtema> :)
08:13:49 <frickler> seems like the intended effect of allowing nz to join hasn't worked well
08:14:35 <gtema> yeah, sadly
08:14:56 <gtema> but I do not also see much activity from EU based folks (except of us here)
08:15:39 <amorin> On my side (ovh) I am following the subject but I don't have any strong opinion
08:16:07 <tobberydberg> Yea, which timezone wise should work well at least, if not conflicts...
08:16:12 <gtema> oh, you are from ovh, good, cause I already wanted to ask if there is somebody
08:16:15 <amorin> I am trying to get people from OVH involved but that's hard
08:16:35 <amorin> The tz is correct IMHO
08:17:17 <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:18:42 <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:19:32 <gtema> agree
08:20:21 <tobberydberg> Any objections to that? ;-)
08:20:53 <noonedeadpunk> what I'm most dissapointed with is how active SCS was on summit and how they've dissapeared after
08:21:14 <noonedeadpunk> as they're main part with strong opinions
08:21:49 <gtema> well, we have some hidden representatives here if I am right, but not the ones who were active on that ;-)
08:22:09 <frickler> yeah, I'm somehow SCS but also somehow not
08:22:17 <gtema> yeah
08:22:25 <tobberydberg> I think that some kind of alignment with SCS makes a lot of sense
08:22:43 <gtema> maybe on that particular topic TZ is not suiting well, cause we have now heavy meetings time mornings
08:23:16 <gtema> maybe if we come with suggestion I can push it towards to Kurt and involve him deeper
08:24:07 <tobberydberg> If this slot isn't working I'm happy to revisit that topic, but lets seek feedback on that...
08:24:13 <tobberydberg> Does SCS have a "implementation" of standardization already in place?
08:25:05 <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:10 <frickler> I think the flavor spec is pretty detailed, not sure what you mean by implementation
08:26:11 <frickler> https://github.com/SovereignCloudStack/Docs/blob/main/Design-Docs/flavor-naming.md
08:26:40 <gtema> well, the repo is already in archive with doc still being draft
08:26:44 <tobberydberg> Well, implementation was more ment "a document in place"
08:26:54 <gtema> so it is not really clear what's the current position on that is
08:27:36 <gtema> ah, sorry, found it in another (older) repo
08:28:04 <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:38 <gtema> yeah, I was meaning old ver in https://github.com/SovereignCloudStack/Operational-Docs/blob/main/flavor-naming-draft.MD
08:29:19 <gtema> as far as I remember this proposal raised lot of concerns in the mailing list
08:29:54 <gtema> and I can fully support them, it is not user friendly to force user to decrypt names
08:30:57 <tobberydberg> The flavors part is more about the naming there, which quickly becomes very complex
08:31:09 <gtema> correct
08:31:26 <gtema> SCS-2C:4:10n-bms-z3hh is hard to decode
08:32:07 <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:21 <gtema> not from naming side, but from the "facts" side
08:32:22 <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:47 <frickler> exactly, first decide on facts, then on formatting
08:33:09 <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:21 <gtema> right
08:36:07 <tobberydberg> regarding oversubscription ... I like your proposal there... Clear definition from "our end" - what is heavily for example
08:37:24 <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:41 <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:39:30 <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:41:41 <gtema> I guess images themselves are much easier topic, since also most of attributes are already present. Flavors are much trickier
08:42:14 <tobberydberg> From a programatically perspective, it is easier to filter based on properties
08:42:25 <gtema> right
08:43:04 <jmurezovh> Does the job
08:43:25 <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:49 <noonedeadpunk> So  Ido agree that they did smth for themselves
08:44:06 <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:08 <noonedeadpunk> but it's not a draft atm
08:44:37 <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:45:08 <tobberydberg> jmurezovh are you referring to "name" when you say that?
08:45:28 <noonedeadpunk> but about flavors - as an operator - you would likely prefeer to search through them based on the parameters
08:45:35 <tobberydberg> you do you mean "alignment between this SIG and SCS"?
08:45:42 <tobberydberg> *or
08:46:51 <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:48:23 <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:40 <jmurezovh> First point is the trickiest one.
08:49:07 <tobberydberg> Indeed
08:49:26 <gtema> btw, I am right now with my second ear in the presentation of the crossplane
08:49:45 <gtema> and here the main "selling" point is to offer customer "multicloud" experience
08:50:00 <tobberydberg> But, will all operators be willing to align to "a standard set of flavors"? (I would)
08:50:35 <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:51:15 <gtema> so I really strongly believe there is no future of discussion on standardizing naming. Only defining relevant properties can be achieved
08:51:45 <gtema> "a standard set of flavors" - I am not sure our cloud will agree on that
08:51:59 <gtema> this is (as also said on summit) what differentiate all of us
08:52:37 <frickler> can there be a minimum standard set that doesn't exclude other flavors to exist?
08:53:14 <gtema> I doubt, imagine usecase where provider is only having ARM hardware
08:53:50 <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:54:32 <gtema> disk in the flavor is something what worries me - it's not necessarily that flavor has anything to do with storage
08:54:37 <tobberydberg> That does not prevent us from making other properties a must to provide as well ... oversubscription etc etc
08:54:55 <tobberydberg> but then you have 0 as disk-size, right?
08:55:07 <tobberydberg> its still not undefined
08:55:20 <gtema> yeah, but it is already present
08:56:07 <tobberydberg> of course
08:56:08 <gtema> I mean more whether SSD storage is attached to it or not - something in this direction
08:56:24 <frickler> o.k., so multiple types of sets, then, and the provider can choose one or multiple ones?
08:56:43 <tobberydberg> so that makes the "must have list of flavors" only include a specific set of flavor ratio of vcpu and ram maybe
08:57:06 <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:34 <frickler> even the ratio could differ. or does everyone have 4G ram for 1 vcpu by now?
08:57:38 <gtema> and my "provider" (cough-cough sdk) is selecting one on the target cloud, however it is called
08:57:52 <tobberydberg> agree
08:58:22 <gtema> sure, but we could also implement some suggestion (either softly pick up the closest or raise exception)
08:58:28 <tobberydberg> I guess the only way forward on the ratio is to make a suggestion that we believe every cloud should have :-)
08:59:26 <gtema> every cloud is really tough. You need to convince your marketing that it makes sense
09:00:06 <frickler> if we get a critical mass, that should be easy. they won't be the ugly minority most likely
09:00:06 <tobberydberg> yea I know, but a suggestion from a start and see how that can play out
09:00:30 <frickler> unless it turns out in the end that consumers don't care at all
09:00:57 <tobberydberg> So, trying to summarize here a little bit from todays meeting:
09:01:03 <tobberydberg> 1. Create a suggestion of a standard set of flavors (ratio) based on vcpu and ram
09:01:48 <tobberydberg> 2. Define a list of additional properties (recommended or required) to specify on flavors
09:03:05 <tobberydberg> I think if we have that we have enough for flavors at least :-)
09:03:27 <gtema> :)
09:04:09 <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:21 <gtema> yeah, why not
09:05:17 <frickler> also add that we don't care (so much) about naming, but just about properties?
09:05:25 <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:29 <gtema> +1
09:05:34 <tobberydberg> +1
09:06:32 <tobberydberg> Ok, cool. Thanks for today then! I try to shoot a reminder before next meeting as well :-)
09:06:44 <frickler> that would be helpful, thx
09:06:56 <gtema> great
09:08:05 <tobberydberg> Talk to you in two weeks! :-)
09:08:06 <tobberydberg> #endmeeting