| *** Adri2000_ is now known as Adri2000 | 08:29 | |
| NilsMagnus[m] | hi | 13:58 |
|---|---|---|
| Kristian[m] | Hi | 13:58 |
| tobberydberg | hi | 13:59 |
| gtema | Hey Tobby | 13:59 |
| tobberydberg | Nice to see some people here! :-) | 14:01 |
| tobberydberg | Lets see if we can record som notes for this meeting as well | 14:01 |
| tobberydberg | #startmeeting publiccloud_sig | 14:01 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:01 |
| opendevmeet | The meeting name has been set to 'publiccloud_sig' | 14:01 |
| zigo | o/ | 14:02 |
| frickler | o/ | 14:02 |
| amorin | hello | 14:02 |
| gtema | anybody here tried to pass 2022.06 guideline? | 14:03 |
| tobberydberg | Hello you all! Great to see you here | 14:03 |
| damiandabrowski | hi | 14:03 |
| tobberydberg | I created an etherpad for this meeting. .. found here https://etherpad.opendev.org/p/publiccloud-sig-kickoff | 14:03 |
| 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 |
| lhommeRares | o/ | 14:03 |
| zigo | NilsMagnus[m]: I don't think we're there yet, but eventually that's the start of the road no ? | 14:04 |
| 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:04 |
| tobberydberg | Please put your name there and help out to fill in some other blanks | 14:05 |
| 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 |
| zigo | NilsMagnus[m]: I very much agree with all the remarks you did during the Berlin summit. | 14:05 |
| 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:05 |
| zigo | gtema: Can you give an example? | 14:06 |
| gtema | image download | 14:07 |
| gtema | we forbid it from security reasons | 14:07 |
| simeon | hi! | 14:07 |
| tobberydberg | We haven't tried that to the best of my knowledge | 14:07 |
| gtema | then on the subnet it uses enable_dhcp which in neutron is an optional feature | 14:07 |
| gtema | it also requires that "default" domain exists in the cloud | 14:08 |
| zigo | That last one is obviously broken with Designate no? | 14:08 |
| zigo | Oh, sorry, right. | 14:08 |
| zigo | Domain as in Keystone... | 14:08 |
| gtema | I can't imagine as such any regular user is able to list domains, how should that work | 14:09 |
| gtema | and also quote specific networking cases that fail on our side | 14:09 |
| 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:09 |
| frickler | I'd like a different slot to avoid conflict with kolla meeting | 14:10 |
| gtema | I am ok with the time, maybe one hour later can be even better | 14:10 |
| 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 |
| zigo | One hour later would be max for me, not later (after, it's back home and dinner with familly). | 14:10 |
| amorin | same here, 3PM UTC max | 14:11 |
| amorin | at least during summer time | 14:11 |
| zigo | Anyone against 15UTC during summer dailight changes? | 14:12 |
| NilsMagnus[m] | I go with any time. sleep is overrated anyway. | 14:13 |
| gtema | you shouldn't be sleeping at that time anyway | 14:13 |
| tobberydberg | I'm ok with that as well, even if it is stretching it during summer time :-) | 14:13 |
| zigo | How often would the meeting be then? | 14:13 |
| zigo | Wouldn't 1 a week be too much? | 14:14 |
| gtema | I do not think be-weekly is required. Maybe 1x month | 14:14 |
| zigo | Works for me. | 14:14 |
| 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 |
| amorin | +1 | 14:14 |
| gtema | which TZ are they from? | 14:15 |
| frickler | maybe alternate between apac friendly and the 1500 slot? | 14:15 |
| zigo | gtema: NZ ... | 14:15 |
| 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 |
| gtema | oh, that is going to be challenging for most here | 14:15 |
| gtema | (I mean about NZ TZ) | 14:15 |
| tobberydberg | Yea, I know, that one is challenging indeed | 14:16 |
| frickler | something like 0800 UTC should be fine for europeans? | 14:16 |
| zigo | For them, it has to be in EU's morning (or USA nights...). | 14:16 |
| zigo | Yeah, 8UTC works (that's 10am in the summer). | 14:16 |
| zigo | No confict for me. | 14:16 |
| tobberydberg | for EU morning will at least map with evenings over there... | 14:17 |
| damiandabrowski | +1 for 8UTC | 14:17 |
| zigo | tobberydberg: Did you think about changing time each week, so that we cover both NZ and USA? | 14:17 |
| amorin | 8UTC ok also here | 14:17 |
| zigo | Is there anyone from north america in this group btw? | 14:17 |
| zigo | +1 too ... | 14:17 |
| tobberydberg | Do we have representation from america here as well? | 14:17 |
| tobberydberg | hehe | 14:18 |
| tobberydberg | 8UTC works very well for me as well. | 14:18 |
| tobberydberg | zigo : thought about that as an alternative as well | 14:18 |
| zigo | If none are joining from America TZ, then we can keep 8am UTC... | 14:20 |
| gtema | +0 (not perfect, but ok) | 14:21 |
| tobberydberg | Does even or odd weeks matter for people here? | 14:21 |
| amorin | no matter here | 14:21 |
| gtema | not for me | 14:21 |
| * zigo doesn't mind | 14:21 | |
| * frickler neither | 14:21 | |
| NilsMagnus[m] | are we still talking about wednesdays? | 14:21 |
| gtema | most likely, otherwise I jump off the train ;-) | 14:22 |
| tobberydberg | Hahaha | 14:22 |
| tobberydberg | My suggestion, Wednesdays odd weeks at 0800 UTC | 14:23 |
| * gtema agrees | 14:23 | |
| damiandabrowski | works for me | 14:23 |
| amorin | hum, we have large scale meeting every wed at 15UTC | 14:23 |
| amorin | are we still considering 15UTC? or only 8? | 14:23 |
| zigo | amorin: Only 8 | 14:23 |
| tobberydberg | 8 UTC suggestion right now | 14:23 |
| amorin | ok perfect then | 14:23 |
| zigo | So the kiwis can join ... :P | 14:24 |
| gtema | LOL | 14:24 |
| zigo | Next topic? Can we talk about standardizing images? | 14:25 |
| tobberydberg | Hahaha | 14:25 |
| tobberydberg | Ok. good, made a comment of this in the etherpad | 14:25 |
| tobberydberg | My plan was to discuss the goals for this group :-) | 14:26 |
| zigo | Right, sorry. | 14:26 |
| tobberydberg | I think that can be good to get on paper | 14:26 |
| NilsMagnus[m] | goal proposal: make life easier for public cloud users | 14:26 |
| tobberydberg | More of a mission NilsMagnus[m], but I totally agree | 14:27 |
| zigo | As discussed in berlin we have: | 14:27 |
| zigo | - Standadizing stuff (images, networking, flavors) so we have coherence between public clouds | 14:27 |
| zigo | - Validating public clouds (ie: refstack) | 14:27 |
| zigo | Anything else? | 14:27 |
| NilsMagnus[m] | @zigo: with "standardizing" you mean standardizing their names? then the same also applies to flavors etc.? | 14:28 |
| 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:28 |
| 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 |
| gtema | zigo: I do not believe we would be able to achieve general naming convention across all, this is utopic | 14:29 |
| 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 |
| zigo | I'm sure we all have automated tooling that we aren't sharing between each other. | 14:30 |
| zigo | That's a silly situation, IMO. | 14:30 |
| gtema | based on metadata - ok, based on names - I doubt | 14:30 |
| tobberydberg | For reference - the discussion notes from Berlin: https://etherpad.opendev.org/p/berlin-summit-future-public-cloud-sig | 14:30 |
| 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 |
| 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:31 |
| zigo | frickler: I saw it, but it's a bit over-engineered. We have something very similar in production though. | 14:32 |
| amorin | for flavors, that would be hard, it can depend a lot on the hardware.. | 14:32 |
| 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 |
| * frickler didn't mean to endorse that doc | 14:32 | |
| zigo | The biggest flow in that spec, IMO, is that it's very hard to understand from a final user point of view. | 14:32 |
| 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 |
| zigo | amorin: The point is to have a naming convention that includes the type of hardware you're proposing. | 14:33 |
| amorin | also, it's hard to rename flavor after the region has been opened... | 14:33 |
| 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 |
| amorin | I agree with gtema about metadata VS name | 14:33 |
| zigo | Is it possible to filter flavors using the openstack API ?!? | 14:34 |
| * gtema checks | 14:34 | |
| zigo | Like, can I ask nova "what are the flavors with between 10 and 20 GB RAM" ? | 14:34 |
| zigo | I don't think OpenStack has such a feature. | 14:35 |
| gtema | minDisk, minRam, is_public are supported now | 14:35 |
| zigo | Right. | 14:35 |
| NilsMagnus[m] | zigo: at least that's possible (and feasible) on the client side | 14:35 |
| zigo | But that's really not enough to get something useful. | 14:35 |
| zigo | Yeah, with some json parsing ... | 14:35 |
| NilsMagnus[m] | it's a five-liner in SDK | 14:36 |
| gtema | that is still a beginning, rest can be filtered by clients | 14:36 |
| gtema | flavors sadly are currently not supporting metadata as such | 14:37 |
| 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 |
| gtema | zigo: sure, but is OSC the only "target"? | 14:37 |
| tobberydberg | Other things mentioned in Berlin was the .well-known, test public clouds from upstram (SDK team) | 14:38 |
| 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:38 |
| gtema | yeah, I can implement this in SDK/OSC and wanted to come up with proposal what should it contain | 14:39 |
| 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 |
| tobberydberg | For sure gtema | 14:39 |
| gtema | zigo: sure? I do not see this now in the API docs | 14:40 |
| zigo | damiandabrowski: A set of common flavor, probably not, but a way to name them in a standard way, maybe. | 14:40 |
| zigo | gtema: Absolutely not sure ... :) | 14:40 |
| gtema | I know it is possible for images, but not sure about flavors | 14:40 |
| zigo | (about filters, though properties, pretty sure...) | 14:40 |
| gtema | https://docs.openstack.org/api-ref/compute/?expanded=create-flavor-detail,list-flavors-detail#list-flavors | 14:41 |
| 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 |
| 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:41 |
| gtema | hmm, interesting | 14:42 |
| * NilsMagnus[m] sent a code block: https://matrix.org/_matrix/media/r0/download/matrix.org/VtRXOvKHpeNKkRRLBHLRficx | 14:42 | |
| zigo | Though I don't think one can do "openstack flavor list --property bla=bli" to select the needed one. | 14:42 |
| gtema | aaah, they have extra_specs (from 2.61) and those work like metadata | 14:43 |
| gtema | just purely documented | 14:44 |
| gtema | so maybe what can be done is `openstack flavor set --property alias "some_standard_name" my_funny_name` | 14:44 |
| frickler | NilsMagnus[m]: just fyi sending multiline messages from the Matrix doesn't work well for normal clients | 14:45 |
| 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 |
| NilsMagnus[m] | @frickler: ah, ok, will stop then | 14:45 |
| tobberydberg | That is definitely an easier way to start with the naming situation, even though a recommended naming convention would be great | 14:46 |
| tobberydberg | (lets help out putting this into the etherpad as well) | 14:47 |
| 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:48 |
| simeon | meaning, no need to change anything but just add new ones uppon user request (through anyone admin panel or such) | 14:49 |
| 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 |
| gtema | afair there were clouds with thousands of flavors already | 14:49 |
| 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 |
| simeon | the goal is more to have one common name instead of filtering thousands of flavors :) | 14:50 |
| gtema | adding those "virtual" resources will bring just more maintenance mess with it | 14:50 |
| gtema | simeon: it is utopic to believe this is achievable across multiple clouds with their business owners | 14:51 |
| gtema | and on the other side this is what "metadata" was created for | 14:52 |
| 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 |
| gtema | I think agreeing on "alias" naming convention is achievable, but not the resource naming itself | 14:53 |
| tobberydberg | Yea, metadata is definitely the most important | 14:53 |
| tobberydberg | ....including alias.... | 14:54 |
| gtema | maybe we should then list resources for which we need "agreement" first | 14:54 |
| gtema | and then start talking on how to do this in particular | 14:54 |
| tobberydberg | So, images then ... we discussed hosting a standard set of images upstream ... is that to much to strive for? | 14:55 |
| frickler | what is upstream here? opendev? | 14:55 |
| tobberydberg | Ah, sorry ... you mean resources like ram, disk, cpu etc gtema? | 14:55 |
| tobberydberg | frickler yes | 14:56 |
| gtema | nope, flavor, image, etc | 14:56 |
| gtema | and for every one of those we would need to define set of those properties. But resource types first | 14:56 |
| tobberydberg | ok | 14:57 |
| tobberydberg | For me images and flavors are a given for a start, that will do a lot | 14:57 |
| tobberydberg | +1 | 14:57 |
| gtema | I hope nobody will have an idea of standardizing regions and AZs ;-) | 14:57 |
| frickler | I don't think opendev should host copies of distro images, if that is what you are suggesting | 14:57 |
| tobberydberg | if names of images are impossible, guess not ;-) | 14:57 |
| zigo | Sorry, but I have to go now. | 14:58 |
| gtema | feel free to extend props (and resources) on etherpad | 14:58 |
| damiandabrowski | I wonder if we want to have the same set of flavors, we are talking also about bandwidth/IOPS limits etc. | 14:58 |
| zigo | Will join next time we have a meeting, bye. | 14:58 |
| damiandabrowski | as flavors are not only about vcpu/ram/disk | 14:59 |
| 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 | 14:59 |
| 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 |
| tobberydberg | damiandabrowski ... you are thinking about volume types for the IOPS? | 15:01 |
| damiandabrowski | not exactly volume types, things like quota:disk_total_iops_sec, quota:vif_outbound_peak etc. | 15:02 |
| damiandabrowski | https://docs.openstack.org/horizon/latest/admin/manage-flavors.html#update-metadata | 15:02 |
| 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 |
| NilsMagnus[m] | import openstack... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/nuopUZNRGkSSWiIZsTJnZzYH) | 15:02 |
| NilsMagnus[m] | do we need more than ram, vcpus? I mean there are dozens of properties | 15:03 |
| 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 |
| NilsMagnus[m] | same applies to images, but these are not standardized intrinsically themselves | 15:03 |
| 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 |
| * damiandabrowski needs to leave | 15:04 | |
| 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 |
| tobberydberg | frickler get you point :-) | 15:05 |
| gtema | are we talking about which images must be on every cloud? | 15:05 |
| tobberydberg | Right | 15:05 |
| 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:05 |
| 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:06 |
| gtema | enforcing cloud to have "ubuntu" is even more utopic then having naming convention | 15:07 |
| * gtema is not agains ubuntu as such | 15:07 | |
| tobberydberg | you are probably right ... | 15:07 |
| 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:07 |
| gtema | oki | 15:08 |
| * benoit joined late | 15:08 | |
| gtema | with a review of last minutes next time pls | 15:08 |
| tobberydberg | Thanks a lot for today! Looking forward to continue this discussion next week! | 15:09 |
| tobberydberg | Absolutely! | 15:09 |
| benoit | I joined but there would be more people interested in joining this meeting but from NZ timezone | 15:09 |
| benoit | would it be possible to make it easier for such people to join? | 15:09 |
| gtema | benoit, we agreed to make it 8am UTC | 15:09 |
| tobberydberg | Next meeting will be Wednesday next week at 0800 UTC | 15:09 |
| gtema | exactly for you guys to have it easier to join | 15:10 |
| benoit | that'd be more people from Catalyst Cloud, | 15:10 |
| benoit | ah awesome | 15:10 |
| tobberydberg | I hope that will make it better | 15:10 |
| NilsMagnus[m] | okay, see you next time | 15:10 |
| tobberydberg | Take care! | 15:10 |
| gtema | see you, guys | 15:10 |
| tobberydberg | #endmeeting | 15:10 |
| opendevmeet | Meeting ended Wed Aug 10 15:10:35 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:10 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/publiccloud_sig/2022/publiccloud_sig.2022-08-10-14.01.html | 15:10 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/publiccloud_sig/2022/publiccloud_sig.2022-08-10-14.01.txt | 15:10 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/publiccloud_sig/2022/publiccloud_sig.2022-08-10-14.01.log.html | 15:10 |
| simeon | bye! | 15:10 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!