08:10:09 <tobberydberg> #startmeeting publiccloud_sig
08:10:09 <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:09 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:10:09 <opendevmeet> The meeting name has been set to 'publiccloud_sig'
08:11:54 <tobberydberg> 1. Recap vPTG
08:11:55 <tobberydberg> fkr did write a summary that can be found here: https://etherpad.opendev.org/p/oct2023-ptg-publiccloud-sig#L64
08:12:31 <gtema> thanks to fkr for that, a pretty detailed recap
08:12:43 <tobberydberg> Yes, indeed
08:13:57 <tobberydberg> I did change the time in the schedule to out "winter time" slot, so should appear in calendars at 0900 CET
08:14:20 <gtema> oh right.
08:14:29 <gtema> thanks, didn't even thought about that
08:14:40 <tobberydberg> :-)
08:16:22 <tobberydberg> Worth highlighting from the PTG is potentially the weirdness around "standard set of properties"
08:16:47 <gtema> indeed.
08:16:50 <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:17:07 <gtema> we wanted to have another round of wider discussion of the topic, weren't we?
08:17:22 <joek-office> yes. i remind me that we have long discussion about that.
08:17:46 <gtema> I mean with the findings from the PTG and discussion with Nova folks
08:18:00 <tobberydberg> yes
08:18:01 <gtema> since more or less our initial desire is not going to fly
08:18:33 <joek-office> if i'm really honest, i'm not fully in picture about all the things in this complex subject
08:19:34 <joek-office> if it's possible can we outline the goals that would be reached?
08:20:07 <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:25 <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:21:10 <joek-office> ok. thanks gtema. Than i was more in picture than i think.
08:21:42 <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:23:31 <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:56 <tobberydberg> is it even possible to filter on metadefs in the client?
08:23:58 <tobberydberg> yea...
08:24:02 <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:23 <gtema> well, with metadefs you can find description (mapping) of metadata on the flavors/images
08:24:50 <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:25:02 <gtema> and then you go to flavors and grep them with this metadata in mind
08:25:15 <gtema> so you double your APIs
08:25:48 <gtema> and the main part is not addressed - it is not possible to have filters based on metadata/extra_specs right now
08:26:05 <gtema> so for me this is not a solution from usability pov
08:26:10 <tobberydberg> Ok
08:28:08 <joek-office> also these definitions are already present in the flavors.
08:28:18 <gtema> not all of them
08:28:28 <gtema> that was a finding of the nova operators hour
08:28:41 <joek-office> is there any search functionality in the nova/cinder/glance client api's?
08:28:49 <gtema> there are traits behind flavors which are sort of not always visible
08:29:17 <gtema> there is search functionality, but not always optimal
08:29:44 <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:53 <joek-office> and why is this information not visible? Is this a techincal/security reason?
08:29:58 <gtema> so you end up fetching 1000 flavors to filter on the client side
08:30:39 <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:49 <tobberydberg> which is not feasible
08:31:52 <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:32:41 <gtema> that is exactly what we wanted to discuss with a wider audience from other operators
08:33:00 <gtema> extending is possible, but will require one of us to implement that
08:33:18 <joek-office> ok, thank you for these explanations.
08:33:25 <gtema> yw
08:34:27 <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:35:03 <gtema> it's more or less my statement to you wrt that
08:35:16 <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:36:43 <tobberydberg> Which seams to be a hidden gem in the traits section :-)
08:37:02 <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:22 <gtema> right, but it is deep
08:38:22 <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:40:05 <gtema> https://etherpad.opendev.org/p/publiccloud-sig-specs is something in written
08:40:26 <gtema> but I guess we understood ourselves that in this form it does not make much sense
08:41:51 <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:57 <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:42:30 <gtema> they are currently not visible to user at all so first we would need to make them visible
08:42:37 <gtema> and basically filterable
08:43:03 <gtema> https://docs.openstack.org/api-ref/placement/#list-traits
08:43:55 <tobberydberg> And to make them visible, reflect traits info into the list of flavors?
08:44:07 <tobberydberg> ...in a consumable fashion...
08:45:09 <gtema> not directly. traits themselves are sort of mapping between extra_specs of flavors into something what scheduler understands
08:45:38 <gtema> so to some extend they are there, but enduser is not able to understand them
08:45:47 <gtema> so we need to expose this info
08:45:55 <gtema> and make it filterable
08:46:40 <joek-office> are there at the moment any ideas/requirements from the csp side?
08:47:00 <joek-office> we just discuss the client side?
08:48:05 <gtema> because the whole idea was spinning around making user life easier and portable
08:48:11 <joek-office> when i'm right, the filtering should be done on the server side?
08:48:34 <gtema> correct, on the server side, because there are cases with more then 1000 flavors in region
08:48:55 <joek-office> yes, thats clear, but i think there would be also csp requirements for such a feature.
08:49:15 <joek-office> just to get a better acceptance
08:49:27 <gtema> well, we all wanted to exactly align from the csp side how to achieve that
08:51:57 <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:53:33 <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:54:07 <joek-office> or hide the old pool from the filtering
08:54:32 <joek-office> to get the pool empty and then end this pool
08:56:45 <tobberydberg> But then you will just delete the flavors connected to that pool, right? Or maybe I'm not following you here :-)
08:57:59 <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:58:53 <joek-office> i think about the migration path.
08:59:43 <joek-office> and i think that the filter/search functionality can add a sort of smooth migration path to csp's.
08:59:56 <tobberydberg> Yea, that is a problem that we are facing as well with our current 1000 flavors we would like to get rid of....
09:00:49 <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:49 <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:01:22 <joek-office> ok. thanks for the time and the discussions.
09:01:28 <gtema> he does not, because his TF/Ansible uses coded names
09:01:52 <tobberydberg> Yes, would be a good way forward...
09:02:07 <tobberydberg> #endmeeting