| tobberydberg | o/ | 08:01 |
|---|---|---|
| gtema | morning | 08:02 |
| tobberydberg | I wonder if its more than just you and me here today :-) | 08:03 |
| gtema | yeah, nice question indeed | 08:04 |
| gtema | well, at least we can discuss here with you a bit different topic - https://review.opendev.org/c/openstack/project-config/+/847135. In OTC we developed HashiVault plugin for OTC and wanted to donate it to community but it did not went beyond proposing change to allocate project | 08:06 |
| gtema | from your perspective - do you think it should be done or in the light of recent Hashi licence change "dropped" | 08:07 |
| joek-office | Good Morning publiccloud-sig, anyone there? | 08:09 |
| gtema | yes joek-office, we are here | 08:09 |
| gtema | at least me and tobberydberg | 08:09 |
| tobberydberg | welcome | 08:09 |
| joek-office | ok, sorry for the late join. | 08:09 |
| tobberydberg | #startmeeting publiccloud_sig | 08:10 |
| opendevmeet | Meeting started Wed Nov 8 08:10:09 2023 UTC and is due to finish in 60 minutes. The chair is tobberydberg. Information about MeetBot at http://wiki.debian.org/MeetBot. | 08:10 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 08:10 |
| opendevmeet | The meeting name has been set to 'publiccloud_sig' | 08:10 |
| tobberydberg | 1. Recap vPTG | 08:11 |
| tobberydberg | fkr did write a summary that can be found here: https://etherpad.opendev.org/p/oct2023-ptg-publiccloud-sig#L64 | 08:11 |
| gtema | thanks to fkr for that, a pretty detailed recap | 08:12 |
| tobberydberg | Yes, indeed | 08:12 |
| tobberydberg | I did change the time in the schedule to out "winter time" slot, so should appear in calendars at 0900 CET | 08:13 |
| gtema | oh right. | 08:14 |
| gtema | thanks, didn't even thought about that | 08:14 |
| tobberydberg | :-) | 08:14 |
| tobberydberg | Worth highlighting from the PTG is potentially the weirdness around "standard set of properties" | 08:16 |
| gtema | indeed. | 08:16 |
| joek-office | i'm not fully ready at the moment. i'm just for ten minutes on my pc and havent read the recap. But the first look seems nice | 08:16 |
| gtema | we wanted to have another round of wider discussion of the topic, weren't we? | 08:17 |
| joek-office | yes. i remind me that we have long discussion about that. | 08:17 |
| gtema | I mean with the findings from the PTG and discussion with Nova folks | 08:17 |
| tobberydberg | yes | 08:18 |
| gtema | since more or less our initial desire is not going to fly | 08:18 |
| joek-office | if i'm really honest, i'm not fully in picture about all the things in this complex subject | 08:18 |
| joek-office | if it's possible can we outline the goals that would be reached? | 08:19 |
| tobberydberg | The ask from nova folks is for us to have a look at https://docs.openstack.org/glance/latest/user/metadefs-concepts.html | 08:20 |
| gtema | goal is that every "user" of OpenStack does not need to take care about flavor/image name, but instead specifies properties and the "code" just finds suitable for him | 08:20 |
| joek-office | ok. thanks gtema. Than i was more in picture than i think. | 08:21 |
| gtema | metadefs are indeed an interesting thing, but you can't expect operators to double data that is already out there into the metadefs and user to change deployment scripts to parse through metadef in order to find suitable flavor/image | 08:21 |
| gtema | in my eyes this is for really advanced usecases while we need first something for a regular user who "just" want to have his VM running | 08:23 |
| tobberydberg | is it even possible to filter on metadefs in the client? | 08:23 |
| tobberydberg | yea... | 08:23 |
| joek-office | I havent speak about it on the vPTG, but in the discussion my thoughts going in the direction that this is a problem or a the goal is a two way thing. One thing is the technical part. How can a client find the respective meta data. the other thing is the organisational part. more or less the definition, i think a part for scs, which metadata should be the standard set. | 08:24 |
| gtema | well, with metadefs you can find description (mapping) of metadata on the flavors/images | 08:24 |
| gtema | so technically you go 1st to metadef and grep through it to find property name you need i.e. to get count of cpus | 08:24 |
| gtema | and then you go to flavors and grep them with this metadata in mind | 08:25 |
| gtema | so you double your APIs | 08:25 |
| gtema | and the main part is not addressed - it is not possible to have filters based on metadata/extra_specs right now | 08:25 |
| gtema | so for me this is not a solution from usability pov | 08:26 |
| tobberydberg | Ok | 08:26 |
| joek-office | also these definitions are already present in the flavors. | 08:28 |
| gtema | not all of them | 08:28 |
| gtema | that was a finding of the nova operators hour | 08:28 |
| joek-office | is there any search functionality in the nova/cinder/glance client api's? | 08:28 |
| gtema | there are traits behind flavors which are sort of not always visible | 08:28 |
| gtema | there is search functionality, but not always optimal | 08:29 |
| gtema | i.e. for flavors you can't filter list based on extra_specs and this is where majority of the needed data is kept | 08:29 |
| joek-office | and why is this information not visible? Is this a techincal/security reason? | 08:29 |
| gtema | so you end up fetching 1000 flavors to filter on the client side | 08:29 |
| gtema | neither of both - it's architectural issue, that those are only something like "scheduler_hints" which are not guaranteed to be used directly | 08:30 |
| tobberydberg | which is not feasible | 08:30 |
| joek-office | can the api of the services extended to reach this search functionality on the server side? Or what is the current idea to go? | 08:31 |
| gtema | that is exactly what we wanted to discuss with a wider audience from other operators | 08:32 |
| gtema | extending is possible, but will require one of us to implement that | 08:33 |
| joek-office | ok, thank you for these explanations. | 08:33 |
| gtema | yw | 08:33 |
| joek-office | Is there a user story defined that will outline the user perspective how this will easy work or usable for the client? | 08:34 |
| gtema | it's more or less my statement to you wrt that | 08:35 |
| gtema | "goal is that every "user" of OpenStack does not need to take care about flavor/image name, but instead specifies properties and the "code" just finds suitable for him" | 08:35 |
| tobberydberg | Which seams to be a hidden gem in the traits section :-) | 08:36 |
| joek-office | yes, this is clear to me. But from this starting point there comes many questions. That should we discuss and find a quorum. | 08:37 |
| gtema | right, but it is deep | 08:37 |
| joek-office | yes, i have at the moment just three questions in my mind adn every of these question will have many following things. But is anywhere something written down like a specification/blueprint? | 08:38 |
| gtema | https://etherpad.opendev.org/p/publiccloud-sig-specs is something in written | 08:40 |
| gtema | but I guess we understood ourselves that in this form it does not make much sense | 08:40 |
| joek-office | yes, also that what i see in first fly is in my opinion the organizational part that is discussed. There is a complete lack of the technical part. | 08:41 |
| tobberydberg | I'm not fully following the whole traits thingi, I have to read up on that. But from what I can tell, will not give the user much visibility? | 08:41 |
| gtema | they are currently not visible to user at all so first we would need to make them visible | 08:42 |
| gtema | and basically filterable | 08:42 |
| gtema | https://docs.openstack.org/api-ref/placement/#list-traits | 08:43 |
| tobberydberg | And to make them visible, reflect traits info into the list of flavors? | 08:43 |
| tobberydberg | ...in a consumable fashion... | 08:44 |
| gtema | not directly. traits themselves are sort of mapping between extra_specs of flavors into something what scheduler understands | 08:45 |
| gtema | so to some extend they are there, but enduser is not able to understand them | 08:45 |
| gtema | so we need to expose this info | 08:45 |
| gtema | and make it filterable | 08:45 |
| joek-office | are there at the moment any ideas/requirements from the csp side? | 08:46 |
| joek-office | we just discuss the client side? | 08:47 |
| gtema | because the whole idea was spinning around making user life easier and portable | 08:48 |
| joek-office | when i'm right, the filtering should be done on the server side? | 08:48 |
| gtema | correct, on the server side, because there are cases with more then 1000 flavors in region | 08:48 |
| joek-office | yes, thats clear, but i think there would be also csp requirements for such a feature. | 08:48 |
| joek-office | just to get a better acceptance | 08:49 |
| gtema | well, we all wanted to exactly align from the csp side how to achieve that | 08:49 |
| joek-office | because i think the csp would have also a bit intense to adapt the filter result in a way that doesnt change the filtering but is better aligned to the csp thoughts | 08:51 |
| joek-office | things like what is when there are a new and a old ceph pool. Both will have the same flavors. in such a case the filter give back flavors for both pools and the csp would prefer the new pool | 08:53 |
| joek-office | or hide the old pool from the filtering | 08:54 |
| joek-office | to get the pool empty and then end this pool | 08:54 |
| tobberydberg | But then you will just delete the flavors connected to that pool, right? Or maybe I'm not following you here :-) | 08:56 |
| joek-office | in the end, yes. but what is in the mean time when you have deployed vm's that use the old flavors. Can you in this situation delete the flavor? or hide it? | 08:57 |
| joek-office | i think about the migration path. | 08:58 |
| joek-office | and i think that the filter/search functionality can add a sort of smooth migration path to csp's. | 08:59 |
| tobberydberg | Yea, that is a problem that we are facing as well with our current 1000 flavors we would like to get rid of.... | 08:59 |
| tobberydberg | Well, time is up and I need to run to another meeting unfortunate... Thanks for today guys! We will indeed have to come back to this topic... | 09:00 |
| joek-office | just as i mentioned above, the flavors that the csp would get rid of, are hidden for the search and so the users/clients use new flavors in favour | 09:00 |
| joek-office | ok. thanks for the time and the discussions. | 09:01 |
| gtema | he does not, because his TF/Ansible uses coded names | 09:01 |
| tobberydberg | Yes, would be a good way forward... | 09:01 |
| tobberydberg | #endmeeting | 09:02 |
| opendevmeet | Meeting ended Wed Nov 8 09:02:07 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 09:02 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/publiccloud_sig/2023/publiccloud_sig.2023-11-08-08.10.html | 09:02 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/publiccloud_sig/2023/publiccloud_sig.2023-11-08-08.10.txt | 09:02 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/publiccloud_sig/2023/publiccloud_sig.2023-11-08-08.10.log.html | 09:02 |
| joek-office | but i think to have the ability to search is just for these situations, where the client use TF/Ansible and in future should switch to the search way to find a suitable flavor | 09:02 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!