14:01:53 <tobberydberg> #startmeeting publiccloud_sig
14:01:53 <opendevmeet> Meeting started Wed Aug 10 14:01:53 2022 UTC and is due to finish in 60 minutes.  The chair is tobberydberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:53 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:53 <opendevmeet> The meeting name has been set to 'publiccloud_sig'
14:02:03 <zigo> o/
14:02:03 <frickler> o/
14:02:38 <amorin> hello
14:03:05 <gtema> anybody here tried to pass 2022.06 guideline?
14:03:08 <tobberydberg> Hello you all! Great to see you here
14:03:19 <damiandabrowski> hi
14:03:23 <tobberydberg> I created an etherpad for this meeting. .. found here https://etherpad.opendev.org/p/publiccloud-sig-kickoff
14:03:36 <NilsMagnus[m]> I'd like to start with a very wide-soped question: are we going to just discuss smaller fixes to the existing refstack process or is it also possible to dream about a general different way of public cloud certification in the O/S context?
14:03:59 <lhommeRares> o/
14:04:39 <zigo> NilsMagnus[m]: I don't think we're there yet, but eventually that's the start of the road no ?
14:04:59 <NilsMagnus[m]> I for myself see a lot of problems with the existing refstack/guidelines/tempest/etc. process it just don't matches the realities of public clouds
14:05:07 <tobberydberg> Please put your name there and help out to fill in some other blanks
14:05:36 <tobberydberg> To answer some above questions, the plan for this meeting is to set some goals for what we want to achieve  with this group
14:05:39 <zigo> NilsMagnus[m]: I very much agree with all the remarks you did during the Berlin summit.
14:05:54 <gtema> my question on 2022.06 is actually going exactly into that direction. This guideline passes so many "assumptions" that are not by default valid that we are once again thinking that this makes no sense this way
14:06:54 <zigo> gtema: Can you give an example?
14:07:03 <gtema> image download
14:07:18 <gtema> we forbid it from security reasons
14:07:36 <simeon> hi!
14:07:40 <tobberydberg> We haven't tried that to the best of my knowledge
14:07:55 <gtema> then on the subnet it uses enable_dhcp which in neutron is an optional feature
14:08:15 <gtema> it also requires that "default" domain exists in the cloud
14:08:37 <zigo> That last one is obviously broken with Designate no?
14:08:50 <zigo> Oh, sorry, right.
14:08:57 <zigo> Domain as in Keystone...
14:09:06 <gtema> I can't imagine as such any regular user is able to list domains, how should that work
14:09:34 <gtema> and also quote specific networking cases that fail on our side
14:09:50 <tobberydberg> One thing that I would like to start asking you all is time and how often to have these meetings. Is this a good time slot? Should we set up a poll with different slots and have a voting for that? What is your thoughts?
14:10:24 <frickler> I'd like a different slot to avoid conflict with kolla meeting
14:10:30 <gtema> I am ok with the time, maybe one hour later can be even better
14:10:42 <NilsMagnus[m]> <tobberydberg> "To answer some above questions..." <- One of my goals is to provide a mean/tool/way that is useful for public cloud users. They should be able to estimate if a public cloud offering deserves the label "public cloud based on openstack"
14:10:58 <zigo> One hour later would be max for me, not later (after, it's back home and dinner with familly).
14:11:26 <amorin> same here, 3PM UTC max
14:11:35 <amorin> at least during summer time
14:12:27 <zigo> Anyone against 15UTC during summer dailight changes?
14:13:02 <NilsMagnus[m]> I go with any time. sleep is overrated anyway.
14:13:18 <gtema> you shouldn't be sleeping at that time anyway
14:13:19 <tobberydberg> I'm ok with that as well, even if it is stretching it during summer time :-)
14:13:54 <zigo> How often would the meeting be then?
14:14:05 <zigo> Wouldn't 1 a week be too much?
14:14:21 <gtema> I do not think be-weekly is required. Maybe 1x month
14:14:38 <zigo> Works for me.
14:14:42 <tobberydberg> so, 1500 UTC we resolve the Kolla conflict and also seams ok to most. Did get a request from catalyst cloud to have a completely different slot for them to be able to participate
14:14:42 <amorin> +1
14:15:22 <gtema> which TZ are they from?
14:15:25 <frickler> maybe alternate between apac friendly and the 1500 slot?
14:15:28 <zigo> gtema: NZ ...
14:15:36 <tobberydberg> I think bi-weekly is a good starting point, we can change later to less or more if we feel like it
14:15:43 <gtema> oh, that is going to be challenging for most here
14:15:58 <gtema> (I mean about NZ TZ)
14:16:06 <tobberydberg> Yea, I know, that one is challenging indeed
14:16:12 <frickler> something like 0800 UTC should be fine for europeans?
14:16:26 <zigo> For them, it has to be in EU's morning (or USA nights...).
14:16:48 <zigo> Yeah, 8UTC works (that's 10am in the summer).
14:16:56 <zigo> No confict for me.
14:17:07 <tobberydberg> for EU morning will at least map with evenings over there...
14:17:23 <damiandabrowski> +1 for 8UTC
14:17:24 <zigo> tobberydberg: Did you think about changing time each week, so that we cover both NZ and USA?
14:17:39 <amorin> 8UTC ok also here
14:17:39 <zigo> Is there anyone from north america in this group btw?
14:17:46 <zigo> +1 too ...
14:17:54 <tobberydberg> Do we have representation from america here as well?
14:18:10 <tobberydberg> hehe
14:18:43 <tobberydberg> 8UTC works very well for me as well.
14:18:59 <tobberydberg> zigo : thought about that as an alternative as well
14:20:33 <zigo> If none are joining from America TZ, then we can keep 8am UTC...
14:21:02 <gtema> +0 (not perfect, but ok)
14:21:07 <tobberydberg> Does even or odd weeks matter for people here?
14:21:18 <amorin> no matter here
14:21:21 <gtema> not for me
14:21:34 * zigo doesn't mind
14:21:42 * frickler neither
14:21:58 <NilsMagnus[m]> are we still talking about wednesdays?
14:22:34 <gtema> most likely, otherwise I jump off the train ;-)
14:22:41 <tobberydberg> Hahaha
14:23:05 <tobberydberg> My suggestion, Wednesdays odd weeks at 0800 UTC
14:23:17 * gtema agrees
14:23:19 <damiandabrowski> works for me
14:23:24 <amorin> hum, we have large scale meeting every wed at 15UTC
14:23:38 <amorin> are we still considering 15UTC? or only 8?
14:23:49 <zigo> amorin: Only 8
14:23:52 <tobberydberg> 8 UTC suggestion right now
14:23:57 <amorin> ok perfect then
14:24:12 <zigo> So the kiwis can join ... :P
14:24:18 <gtema> LOL
14:25:04 <zigo> Next topic? Can we talk about standardizing images?
14:25:07 <tobberydberg> Hahaha
14:25:09 <tobberydberg> Ok. good, made a comment of this in the etherpad
14:26:11 <tobberydberg> My plan was to discuss the goals for this group :-)
14:26:17 <zigo> Right, sorry.
14:26:42 <tobberydberg> I think that can be good to get on paper
14:26:50 <NilsMagnus[m]> goal proposal: make life easier for public cloud users
14:27:30 <tobberydberg> More of a mission NilsMagnus[m], but I totally agree
14:27:34 <zigo> As discussed in berlin we have:
14:27:34 <zigo> - Standadizing stuff (images, networking, flavors) so we have coherence between public clouds
14:27:34 <zigo> - Validating public clouds (ie: refstack)
14:27:34 <zigo> Anything else?
14:28:05 <NilsMagnus[m]> @zigo: with "standardizing" you mean standardizing their names? then the same also applies to flavors etc.?
14:28:47 <zigo> NilsMagnus[m]: Content too. Like for example, for images, we need to use the same set of properties (for example --property os_distro=debian), but names are important too.
14:29:06 <tobberydberg> I agree that is really good goals that will go in the direction of what NilsMagnus[m] mentioned, make life easier for public cloud users
14:29:31 <gtema> zigo: I do not believe we would be able to achieve general naming convention across all, this is utopic
14:30:02 <zigo> For images, my idea is that we all participate in a single tooling that we would all use, so that it sets the same images, properties, tags, etc. That's probably the easiest part to achieve, and it can be a start.
14:30:18 <zigo> I'm sure we all have automated tooling that we aren't sharing between each other.
14:30:23 <zigo> That's a silly situation, IMO.
14:30:24 <gtema> based on metadata - ok, based on names - I doubt
14:30:50 <tobberydberg> For reference - the discussion notes from Berlin: https://etherpad.opendev.org/p/berlin-summit-future-public-cloud-sig
14:31:21 <frickler> for flavors, there is some prior art like e.g. https://github.com/SovereignCloudStack/Docs/blob/main/Design-Docs/flavor-naming.md
14:31:40 <zigo> gtema: If we were to settle on common recommended names, I'd be very happy of the move, and would try to follow the standard.
14:32:12 <zigo> frickler: I saw it, but it's a bit over-engineered. We have something very similar in production though.
14:32:13 <amorin> for flavors, that would be hard, it can depend a lot on the hardware..
14:32:25 <gtema> well, from my side I can only have some influence on adding some standart metadata, but naming is absolutely inachievable for me
14:32:54 * frickler didn't mean to endorse that doc
14:32:56 <zigo> The biggest flow in that spec, IMO, is that it's very hard to understand from a final user point of view.
14:33:22 <NilsMagnus[m]> For naming conventions I wonder if it is sufficient to have alias names, but I agree to gtema that selecting those instances by real properties is much better than parsing the resource's name
14:33:26 <zigo> amorin: The point is to have a naming convention that includes the type of hardware you're proposing.
14:33:27 <amorin> also, it's hard to rename flavor after the region has been opened...
14:33:43 <tobberydberg> I think metadata will take us pretty far, of course naming would be really useful for end users well. Recommendations of naming could be there though
14:33:56 <amorin> I agree with gtema about metadata VS name
14:34:18 <zigo> Is it possible to filter flavors using the openstack API ?!?
14:34:34 * gtema checks
14:34:39 <zigo> Like, can I ask nova "what are the flavors with between 10 and 20 GB RAM" ?
14:35:07 <zigo> I don't think OpenStack has such a feature.
14:35:07 <gtema> minDisk, minRam, is_public are supported now
14:35:15 <zigo> Right.
14:35:26 <NilsMagnus[m]> zigo: at least that's possible (and feasible) on the client side
14:35:27 <zigo> But that's really not enough to get something useful.
14:35:37 <zigo> Yeah, with some json parsing ...
14:36:16 <NilsMagnus[m]> it's a five-liner in SDK
14:36:22 <gtema> that is still a beginning, rest can be filtered by clients
14:37:11 <gtema> flavors sadly are currently not supporting metadata as such
14:37:18 <zigo> NilsMagnus[m]: If it's a 5 liners in SDK, then it'd be easy to add as a new feature to the standard openstack client, no?
14:37:46 <gtema> zigo: sure, but is OSC the only "target"?
14:38:32 <tobberydberg> Other things mentioned in Berlin was the .well-known, test public clouds from upstram (SDK team)
14:38:59 <damiandabrowski> on the other hand, if we can't agree on image names, i think there is absolutely no way to agree on a set of common flavors(in most cases it's more a business decision)
14:39:03 <gtema> yeah, I can implement this in SDK/OSC and wanted to come up with proposal what should it contain
14:39:25 <zigo> gtema: Flavors have properties though, which are key/value stores. We could use that, but then we need the client to be able to filter when listing them.
14:39:29 <tobberydberg> For sure gtema
14:40:10 <gtema> zigo: sure? I do not see this now in the API docs
14:40:19 <zigo> damiandabrowski: A set of common flavor, probably not, but a way to name them in a standard way, maybe.
14:40:25 <zigo> gtema: Absolutely not sure ... :)
14:40:44 <gtema> I know it is possible for images, but not sure about flavors
14:40:45 <zigo> (about filters, though properties, pretty sure...)
14:41:04 <gtema> https://docs.openstack.org/api-ref/compute/?expanded=create-flavor-detail,list-flavors-detail#list-flavors
14:41:08 <tobberydberg> Would it be impossible for clouds to have a set of standard flavors that matches the recommendations? Even if they become duplicated of other flavors?
14:41:44 <zigo> openstack flavor set --property bla=bli cpu1-ram3-disk20 <--- this works, and it's been there since like the very begining of OpenStack.
14:42:03 <gtema> hmm, interesting
14:42:54 * NilsMagnus[m] sent a code block: https://matrix.org/_matrix/media/r0/download/matrix.org/VtRXOvKHpeNKkRRLBHLRficx
14:42:57 <zigo> Though I don't think one can do "openstack flavor list --property bla=bli" to select the needed one.
14:43:47 <gtema> aaah, they have extra_specs (from 2.61) and those work like metadata
14:44:07 <gtema> just purely documented
14:44:49 <gtema> so maybe what can be done is `openstack flavor set --property alias "some_standard_name" my_funny_name`
14:45:14 <frickler> NilsMagnus[m]: just fyi sending multiline messages from the Matrix doesn't work well for normal clients
14:45:19 <gtema> this way we could have both full "metadata" stuff and also alias (which is then used on the client side for filtering)
14:45:48 <NilsMagnus[m]> @frickler: ah, ok, will stop then
14:46:52 <tobberydberg> That is definitely an easier way to start with the naming situation, even though a recommended naming convention would be great
14:47:15 <tobberydberg> (lets help out putting this into the etherpad as well)
14:48:58 <simeon> for naming, this could be a (small) set of new "private" flavors just added to provider ones, for user who ask them ? Added in their specific projects ?
14:49:26 <simeon> meaning, no need to change anything but just add new ones uppon user request (through anyone admin panel or such)
14:49:40 <NilsMagnus[m]> is our goal here to actually standardize names, or is it not rather more important to obtain the name of a {flavor, image} based on a few, important properties? (or all possible properties, which will be tough again)
14:49:41 <gtema> afair there were clouds with thousands of flavors already
14:50:32 <tobberydberg> As I see it, if there are already thousands of flavors, another 10 would make it worse ;-) (looking at our selves here)
14:50:39 <simeon> the goal is more to have one common name instead of filtering thousands of flavors :)
14:50:45 <gtema> adding those "virtual" resources will bring just more maintenance mess with it
14:51:34 <gtema> simeon: it is utopic to believe this is achievable across multiple clouds with their business owners
14:52:17 <gtema> and on the other side this is what "metadata" was created for
14:53:07 <tobberydberg> Maybe you are right gtema, but NON enforcing naming convention I guess could be a start, even if it doesn't bring any value if none is following it
14:53:39 <gtema> I think agreeing on "alias" naming convention is achievable, but not the resource naming itself
14:53:51 <tobberydberg> Yea, metadata is definitely the most important
14:54:09 <tobberydberg> ....including alias....
14:54:47 <gtema> maybe we should then list resources for which we need "agreement" first
14:54:57 <gtema> and then start talking on how to do this in particular
14:55:06 <tobberydberg> So, images then ... we discussed hosting a standard set of images upstream ... is that to much to strive for?
14:55:35 <frickler> what is upstream here? opendev?
14:55:59 <tobberydberg> Ah, sorry ... you mean resources like ram, disk, cpu etc gtema?
14:56:06 <tobberydberg> frickler yes
14:56:08 <gtema> nope, flavor, image, etc
14:56:52 <gtema> and for every one of those we would need to define set of those properties. But resource types first
14:57:07 <tobberydberg> ok
14:57:08 <tobberydberg> For me images and flavors are a given for a start, that will do a lot
14:57:27 <tobberydberg> +1
14:57:35 <gtema> I hope nobody will have an idea of standardizing regions and AZs ;-)
14:57:46 <frickler> I don't think opendev should host copies of distro images, if that is what you are suggesting
14:57:57 <tobberydberg> if names of images are impossible, guess not ;-)
14:58:33 <zigo> Sorry, but I have to go now.
14:58:41 <gtema> feel free to extend props (and resources) on etherpad
14:58:50 <damiandabrowski> I wonder if we want to have the same set of flavors, we are talking also about bandwidth/IOPS limits etc.
14:58:50 <zigo> Will join next time we have a meeting, bye.
14:59:11 <damiandabrowski> as flavors are not only about vcpu/ram/disk
14:59:13 <tobberydberg> frickler Was brought up during the summit, but maybe some reference specification of "links" to resources, also which images that are considered default for a public cloud
15:01:05 <frickler> we have a list of links to distro image source somewhere, if you want to add some machine-readable version of it, that should be possible. doing a selection would be very biased however, I doubt there could be consensus on such a thing
15:01:06 <tobberydberg> damiandabrowski ... you are thinking about volume types for the IOPS?
15:02:38 <damiandabrowski> not exactly volume types, things like quota:disk_total_iops_sec, quota:vif_outbound_peak etc.
15:02:39 <damiandabrowski> https://docs.openstack.org/horizon/latest/admin/manage-flavors.html#update-metadata
15:02:39 <tobberydberg> frickler Depends on how that list of "standard images" is composed, I mean it could be it staandard to have ubuntu 20.04, 22.04, centos 7, 8 etc
15:02:48 <NilsMagnus[m]> import openstack... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/nuopUZNRGkSSWiIZsTJnZzYH)
15:03:14 <NilsMagnus[m]> do we need more than ram, vcpus? I mean there are dozens of properties
15:03:53 <gtema> yeah Nils, but not all of them are standard. I.e. for flavor naming SCS suggest things I never even thought about
15:03:59 <NilsMagnus[m]> same applies to images, but these are not standardized intrinsically themselves
15:04:02 <frickler> tobberydberg: but then I'd object to centos and require debian instead - just for the sake of argumentation, others would talk openEuler or suse maybe
15:04:55 * damiandabrowski needs to leave
15:05:07 <tobberydberg> So, a suggestion from my side. When it comes to resources, maybe agree that flavors and images is what we start with ... might be too much with more from the start, then we have a baseline and can extend on that?
15:05:08 <tobberydberg> frickler get you point :-)
15:05:21 <gtema> are we talking about which images must be on every cloud?
15:05:30 <tobberydberg> Right
15:05:41 <NilsMagnus[m]> What I actually mean: Is this really a problem we have to solve? I wrote the threeliner to show that's easy to find out matching resources as long as the data is there
15:06:45 <gtema> requiring there must be "ubuntu" on the cloud is too much I guess. User just should have possibility to request booting server with some distro not taking care of how it is called
15:07:11 <gtema> enforcing cloud to have "ubuntu" is even more utopic then having naming convention
15:07:23 * gtema is not agains ubuntu as such
15:07:45 <tobberydberg> you are probably right ...
15:07:57 <tobberydberg> I see that we are over time here... Lets continue to add thoughts in the etherpad and then we'll continue the discussion next week.
15:08:19 <gtema> oki
15:08:33 * benoit joined late
15:08:35 <gtema> with a review of last minutes next time pls
15:09:07 <tobberydberg> Thanks a lot for today! Looking forward to continue this discussion next week!
15:09:08 <tobberydberg> Absolutely!
15:09:16 <benoit> I joined but there would be more people interested in joining this meeting but from NZ timezone
15:09:41 <benoit> would it be possible to make it easier for such people to join?
15:09:48 <gtema> benoit, we agreed to make it 8am UTC
15:09:57 <tobberydberg> Next meeting will be Wednesday next week at 0800 UTC
15:10:00 <gtema> exactly for you guys to have it easier to join
15:10:01 <benoit> that'd be more people from Catalyst Cloud,
15:10:05 <benoit> ah awesome
15:10:09 <tobberydberg> I hope that will make it better
15:10:10 <NilsMagnus[m]> okay, see you next time
15:10:22 <tobberydberg> Take care!
15:10:31 <gtema> see you, guys
15:10:35 <tobberydberg> #endmeeting