08:04:01 <tobberydberg> #startmeeting publiccloud_sig
08:04:01 <opendevmeet> Meeting started Wed Aug 31 08:04:01 2022 UTC and is due to finish in 60 minutes.  The chair is tobberydberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:04:01 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:04:01 <opendevmeet> The meeting name has been set to 'publiccloud_sig'
08:04:29 <tobberydberg> Agenda and meeting notes here: https://etherpad.opendev.org/p/publiccloud-sig-meeting
08:05:20 <tobberydberg> #topic 1. Last meeting log/notes review
08:06:22 <gtema> I was thinking bit further on the point with using "alias" metadata or property for having "standardized" names
08:06:43 <gtema> and I still think this is the only thing we could ever reach among different clouds
08:07:31 <tobberydberg> I agree, that is probably the way to get somewhere
08:07:57 <Puck__> Or at least have a mapping from the standardised to the local names.
08:08:18 <Puck__> Aliases would be nice.
08:08:39 <gtema> well, this kind of mapping would need to be stored somewhere
08:08:51 <gtema> if we ever reach ".well-known" - maybe
08:08:59 <gtema> but that would mean all tools need to know that
08:09:19 <tobberydberg> I had another thought though, to have a "non enforcing" naming convention as a guideline
08:09:32 <Puck__> Start with having it in docs.
08:10:10 <gtema> having some "guideline" to agree on is of course a must. Otherwise we will never proceed :)
08:10:12 <Puck__> os_distro is an example of recommended names. Dunno how well adopted they are.
08:10:26 <tobberydberg> So, the basic in being able to have somekind of mapping is "non enforcing naming convention", right?
08:11:14 <Puck__> Yeah, perhaps a survey of what is currently in use would be good. Does refstacj c
08:11:22 <gtema> I think what is important is to agree on attributes which are important and must be in some form discoverable in every cloud
08:11:30 <Puck__> Refstacj collect that? (Sorry, using a phone)
08:11:45 <gtema> os_distro - surely yes, but smth like hw_disk_bus is maybe not so important
08:12:15 <tobberydberg> +1
08:12:24 <gtema> Puck__ - refstack doesn't care at all about anything, that is why we think in the terms of public cloud alternative need to be developed
08:13:03 <gtema> it is sad that so few people are here around, as if this is again not required by anybody
08:13:09 <Puck__> Ack. Was hoping there was already some central information.
08:13:20 <tobberydberg> yes exactly
08:13:41 <tobberydberg> And for me it would be an addition to refstack and a check that can run from central location towards all public clouds in the program.
08:14:15 <Puck__> That'd be good. I don't know when we last ran refstack
08:14:38 <gtema> Puck__ - haven't you received recently reminder to upload fresh results?
08:15:02 <tobberydberg> Exactly, and can easily be faked by setting up a isolated env to run the checks, which makes the results not worth much
08:15:12 <Puck__> Erm, dunno. I'd have to go and dig. I remember it being discussed a while ago...
08:15:21 <gtema> tobberydberg: I propose to start declaring properties of things we think should be standardized and make voting to figure out what community thinks which are mandatory and which not
08:15:28 <NilsMagnus[m]> I still wonder why using the filters of meta data shouldn't be sufficient? That on turn would require some conventions for the meets data itself, for example the operating system.
08:15:51 <NilsMagnus[m]> meets=meta
08:15:57 <gtema> Nils Magnus: because first there must be agreement on what comes into metadata at all
08:16:03 <gtema> and with which name
08:16:04 <Puck__> The benefits would definitely be easier sharing if terraforn etc.
08:16:29 <tobberydberg> That is probably a good starting point. For the central rund of the full powered program we need some collab with interop SIG later on
08:16:37 <Puck__> So, perhaps we need to work out what metadata needs to be standardised?
08:16:51 <gtema> that is exactly what my proposal is about
08:17:07 <NilsMagnus[m]> Maybe we could relate to LSB (Linux standard base)?
08:17:31 <NilsMagnus[m]> For naming conventions
08:17:40 <Puck__> Refstack (or whatever) should also be run from a central location against the public facing API for each cloud.
08:17:59 <tobberydberg> Puck__ +1
08:18:23 <gtema> agree with Nils, LSB is a good start. Not 100% sure how i.e. good windows images will fit into it, but definitely worth checking
08:18:31 <tobberydberg> But as gtema says, we will need to define what to check and which attributes etc before that
08:19:39 <Puck__> Yup. Should we have people put their ideas on the etherpad to be discussed next time? (List them, put +1 against the ones you agree with )
08:20:05 <gtema> I started last time exactly this
08:20:18 <Puck__> Oh, awesome!
08:20:24 <gtema> and tried to get some of the props from SovereignCloudStack proposals
08:20:38 <gtema> (https://etherpad.opendev.org/p/publiccloud-sig-kickoff)
08:20:56 <Puck__> Okay, I see the empty list now! :)
08:21:12 <gtema> under "resources to be standardized"
08:21:20 <tobberydberg> #link  https://etherpad.opendev.org/p/publiccloud-sig-kickoff
08:21:21 <tobberydberg> You can find it there
08:21:22 <tobberydberg> haha
08:21:23 <tobberydberg> So, as starting point we will go with flavors and images
08:22:37 <gtema> I doubt there is any interest on having something more then those 2
08:22:39 <Puck__> os_distro, sw_release for metadata
08:22:52 <Puck__> Volume name
08:23:01 <Puck__> Object storage plicy
08:23:22 <Puck__> Volume type, not name (i.e nvme and IOPS)
08:23:25 <gtema> why should volume name matter?
08:24:00 <gtema> for swift policies I also do not really think it is worth of any effort - this is too variable
08:24:30 <Puck__> (The text input box on the webclient on my phone is crazy small)
08:25:05 <Puck__> Happy to be voted down, just throwing out some ideas
08:25:19 <gtema> looking at lsb and ansible I see it returns: codename=Core, description="CentOS Linux...", id=CentOS, major_release=7, release=7.5.xxxx
08:25:19 <tobberydberg> I agree that there could probably be more. But I wonder if it will be easier to solve the flavor and image situation first, as the 2 most obvious ones first before identifying more?
08:25:30 <Puck__> Ack, so re
08:25:33 <Puck__> Sure
08:26:57 <tobberydberg> os_distro mapping "id", release mapping or major_release os_version
08:27:29 <Puck__> Recommended os_distro names are already in the official docs.
08:27:53 <gtema> which docs are you refering?
08:28:04 <Puck__> Erm, hang on
08:29:19 <tobberydberg> https://docs.openstack.org/glance/latest/admin/useful-image-properties.html
08:29:20 <tobberydberg> ??
08:30:10 <Puck__> Yes, that us ut
08:30:17 <Puck__> Just found it. :)
08:31:19 <gtema> hmm, maybe then just list all of them and open voting which should become part of "standard"
08:31:20 <gtema> ?
08:31:34 <gtema> for me 80% of them are not really helpful
08:31:51 <tobberydberg> Yea, because naming will be impossible to align with
08:32:17 <gtema> not really, I can't imagine why i.e. hw_video_model would matter for me
08:33:18 <Puck__> I reckon that a minimum set should defined and others are optional.
08:33:20 <tobberydberg> No, a selected list of which attributes is needed indeed
08:34:04 <Puck__> We'd also like to see another which defines the key software installed for app specific images.
08:35:20 <gtema> tja, and this is where it gets funny - something you find important is not what others think is important
08:35:35 <Puck__> We need that for some licensing requirements. Currently were overloading os_diateo for that, which we hate.
08:36:09 <Puck__> os_distro
08:36:17 <gtema> but you can add any other property as you want. Here we need to find a common base what really matters for end user
08:37:20 <tobberydberg> could add other properties yes for licensed stuff indeed, that would be really useful
08:37:38 <tobberydberg> We have a shitty solution for that as well
08:41:01 <gtema> ok, time is ticking. I suggest everyone interested should add missing (and vote) to defined properties for flavors and images
08:41:38 <gtema> and maybe we can "touch" point of doing useful tests as part of the public clouds certification and not what currently is used by certification?
08:41:42 <tobberydberg> Yea - maybe move them over to the new etherpad first
08:41:45 <Puck__> Sorry, by battery is almost flat. I'll probably drop off soon.
08:42:31 <gtema> from SDK/cli pov I really struggle with different behavior of clouds on relatively simple cases
08:42:55 <tobberydberg> Yea, that is for a fact an issue
08:43:00 <gtema> I actually was also asking to have possibility to make sdk/cli verification on various clouds what should help improve user experience
08:43:01 <Puck__> So, a basic set of tests that should pass.
08:43:37 <Puck__> Agreed. We run various tempest tests against ours on a regular basis.
08:44:04 <tobberydberg> (moved over the notes to the new etherpad - voting could fake place there)
08:44:17 <gtema> we could build up set of useful tests with sdk and use this as some part of "certification" or at least initial information what is going wrong
08:44:44 <Puck__> Ideally clouds could flag what services they run (discovered via keystone catalogue?) And then test against those.
08:45:11 <gtema> Puck__ I am very unhappy on tempest as such, since it verifies cloud from developer perspective mostly. It barely touches "user" side
08:45:20 <tobberydberg> Like that and think that is a really good start for this
08:45:33 <tobberydberg> Puck__ That is also a really good idea
08:45:41 <gtema> sdk is already taking care of service discovery and runs only tests for available services
08:45:45 <Puck__> We made more tempest tests to test usage.
08:46:19 <gtema> on the other side we test our cloud with ansible, where we built "user scenarios" and run them in the loop
08:46:30 <Puck__> Sorry, I need head off.
08:46:40 <gtema> advantage here is that "anybody" can understand what is going on and can easily extend
08:47:00 <gtema> this does not require tempest knowledge, which is itself not very user friendly
08:47:26 <tobberydberg> I thought about "alias" as we earlier discussed as well .... worth getting that custom attribute in there to align with a "naming convention"?
08:47:37 <gtema> on the other side together with sovereign cloud stack we now integrate this approach into their "certification"
08:48:12 <tobberydberg> That is something I will have too look into, that sounds like a really good thing
08:48:48 <gtema> additional advantage out of box - we test also performance of the cloud with that for every single API call being made
08:50:07 <tobberydberg> That sounds really good as well. Even deeper, like disk, network and cpu performance?
08:50:19 <gtema> yes
08:50:26 <tobberydberg> interesting
08:50:28 <gtema> its quite extensible
08:50:53 <tobberydberg> that might be interesting to get in here in the future as well
08:50:53 <gtema> and for sure we also have possibility to monitor up to "ns lookup performance" inside the cloud
08:53:20 <tobberydberg> So, time is almost out here.. Should I send an email about the list in etherpad and ask people to go in and vote before next meeting?
08:53:21 <tobberydberg> I mean, 2 of us here right now only...
08:53:28 <gtema> :)
08:53:36 <gtema> would be good I guess
08:53:54 <tobberydberg> Do you have any personal thoughts about the "alias" thing?
08:54:35 <gtema> not really. If we agree on specific metadata being present (and really verified) we can solve the problem this way
08:54:57 <gtema> and it is easier then having cryptic names inside of aliases, which anyway need to be parsed and processed
08:55:51 <Vladi[m]> so the name convention for common base of properties should be in some special form for example starting with __ just to avoid some potential conflicts with existing properties on different clouds?
08:56:00 <tobberydberg> Yea ... alias needs to be processed to give anything useful
08:56:45 <gtema> so for me alias would contain all of the anyway agreed properties and require complex parsing to get down to things, that should be there already and make "filtering" easier
08:57:04 <gtema> I prefer much more standardizing properties and their names to alias
08:57:20 <gtema> this fits natively into the current concept without changes
08:57:35 <tobberydberg> Yup, agree on that, properties will resolve that situation as long as all clients can make the filtering based on it
08:58:32 <tobberydberg> Vladi[m] I guess that is definitely something to have in mind
08:58:42 <gtema> and this is much easier compared to following parsing names and especially extending this name by "new" additions
08:58:54 <tobberydberg> +1
08:59:28 <tobberydberg> Ok, time is up for this week. I will send out an email asking people to go in and vote, add suggestions as well if they want to.
09:00:00 <tobberydberg> Another short thing before we close this
09:00:07 <gtema> cool, thks tobberydberg
09:00:26 <tobberydberg> We missed the deadline for the PTG ... worth trying to get us in late?
09:01:13 <gtema> similar to SDK issue - do you think lot of people are going to join since it is anyway virtual (like exactly this meeting)?
09:01:33 <frickler> maybe somehow attach to the operators sessions?
09:01:39 <gtema> I would rather think on arranging ad-hock video meeting if desired
09:02:12 <tobberydberg> Yea, I agree
09:02:24 <frickler> getting some visibility on the PTG timetable might still be useful and attract some people
09:02:52 <gtema> hm, maybe
09:03:24 <tobberydberg> Good point. We can definitely check if we can tag along the operators sig if not our own...
09:04:08 <tobberydberg> Ok. I check, then we really need to avoid collisions with a few other teams for it to be worth it...
09:04:22 <gtema> ok
09:05:19 <tobberydberg> Thanks for today and see you in 2 weeks :-)
09:05:20 <tobberydberg> #endmeeting