Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-02-12
16:30:33 sean-k-mooney i see why you want both
16:30:48 bauzas gibi's point was to optionally provide a conf option that would tell which keys to look at
16:30:53 sean-k-mooney ok then ya itmes
16:31:00 sean-k-mooney ya i really dont like that
16:31:11 bauzas I leave that comment open
16:31:22 dansmith I was really hoping we would not need to do that too
16:31:38 sean-k-mooney to me this is getting overly complex if we need per image prop wights
16:31:40 dansmith even though I gave a concrete example of how, I also gave a concrete example of how it would break down
16:31:50 bauzas but I'll repropose a new patch for fixing my items() method
16:32:49 bauzas dansmith: sean-k-mooney: well, the weigher would be defaulting to check for all props, but we could optionally change its behaviour by looking at only a few of them
16:33:05 bauzas that's the proposal I made on my last comment but I leave the comment open
16:33:11 bauzas feel free to chime in
16:33:11 sean-k-mooney filterign properties is one thing
16:33:22 sean-k-mooney per property multiplers is another
16:33:54 sean-k-mooney that the bit that im not really fond of althogh im not super happy with either
16:34:09 dansmith well my point is that I feel like the minute you start making some properties worth more than others (filtered properties count as $weight, unfiltered properties count as zero) then,
16:34:24 dansmith the ask will be to make something important (os type) more important than something less (numa, or disk or something)
16:34:36 sean-k-mooney ya
16:35:01 sean-k-mooney so ignoring the compelxity this was ment to be a very simple weigher with littel overhead
16:35:23 sean-k-mooney i.e. you could enable it with very littel conisdiertation to the schduilign performace impact
16:35:25 dansmith I think the question is not about just simplicity, but also how well it works
16:36:03 dansmith the originally-proposed mechanism was very simple and also very weak, and I assumed that was the goal... to help clump some things, but not be very strong (which needs more complexity to be effective I think)
16:36:24 dansmith honestly, this might be the kind of thing where "fix it in post" via watcher is more effective
16:36:35 sean-k-mooney right os i have wanted to do soemthign similar but idffernt for a number of years, so i propose that loose affintiy apprch"
16:37:25 sean-k-mooney what i have wanted ot add is a diffent weigher that i call the boreign host wiether that perfer hosts with less traitsand less complicate RP trees
16:38:13 dansmith correct me if I'm wrong,
16:38:44 dansmith but if you want to clump your windows instances on windows machines you can set a trait on those hosts, and a requested-but-not-required trait on the image, right?
16:38:45 sean-k-mooney baiscly avoiding host with complciated things unless you ask for it. in this uescase they wanted to group similar isntances together based on the image properies
16:38:59 sean-k-mooney dansmith: no
16:39:02 dansmith it won't dynamically scale the pool, but otherwise that will be a strong but uncomplicated magnet right?
16:39:04 sean-k-mooney we dont have prefered traits
16:39:10 dansmith no?
16:39:29 sean-k-mooney if we did have a prefered trait wiegher for that it woudl be ideal
16:39:54 sean-k-mooney but we would also have to dynmical export the widnows trait once an instnace lands on the host in that case
16:40:15 dansmith we have trait=required but no trait=anythignelse?
16:40:26 dansmith no we wouldn't
16:40:29 dansmith we could
16:40:37 dansmith but not strictly required, IMHO
16:41:03 sean-k-mooney i guess you could pre export it with provider yaml
16:41:10 dansmith right
16:41:13 sean-k-mooney i.e. tag the nodes up front
16:41:21 dansmith I think I've made this mistake before, I guess because I assume if there's an =required there must be an =somethingelse :)
16:41:46 dansmith right.. that doesn't make it fully automatic, but also makes it less complicated, predictable, and strong
16:42:28 sean-k-mooney so we coudl do both. the simple automatic clumping
16:42:36 sean-k-mooney and in the future add prefered traits supprot
16:42:42 sean-k-mooney with another weither
16:42:44 sean-k-mooney https://github.com/openstack/glance/blob/5cfecc79995c6a9524f0dbc4553b4a88761b382f/doc/source/admin/useful-image-properties.rst?plain=1#L277-L306
16:43:03 sean-k-mooney ^ we only supprot required but not forbiden or prefered in the image
16:43:09 dansmith preferred traits needs no placement support, right? just a weigher
16:43:16 dansmith yep
16:43:21 sean-k-mooney just a weigher and much of the work is done
16:43:42 sean-k-mooney we jsut need to put the provider summeries in the hoststate object
16:43:45 dansmith is that not basically the same amount of work as this? why not just do that?
16:44:09 dansmith oh, do we not have the ability to see traits on hosts from the weighers now
16:44:28 sean-k-mooney no but we already have the info in the host manger
16:44:33 sean-k-mooney we only pass the allcoations
16:44:45 sean-k-mooney so we can see what you asked for but not what is on the host
16:44:52 sean-k-mooney so we can just pass both
16:45:10 sean-k-mooney because we have both in the schduler alrady so no change to the placement request
16:45:20 dansmith ack, seems like that would be a non-trivial increase in the hoststate though
16:46:06 sean-k-mooney its more like a exnetion in the time before its garbage collected maybe
16:46:24 sean-k-mooney i think we end up keepign them in memory anyway because of the function call path but i might eb wrong
16:46:39 dansmith so we already report we just don't expose it to the weighers?/
16:46:59 sean-k-mooney yes
16:47:24 sean-k-mooney so i was randomly hackign on https://review.opendev.org/c/openstack/nova/+/933478 a while ago and wanted to use them and found its not aviabel
16:48:51 sean-k-mooney dansmith: we didnt have ether aviabel to the weiers untile pci in palcemnt and gibi only passed the allcoation since that is all they needed
16:49:19 bauzas okay, I hear your voices, I'll keep that weigher stupidly simple
16:50:03 dansmith maybe we should have a gmeet amongst the four of us and make sure we have a path forward
16:50:31 dansmith I don't think gibi is going to be happy with simple, and it may not address the actual concern according to him, so we might just want to get on the same page
16:51:22 sean-k-mooney we can if we want too
16:51:35 sean-k-mooney but i wonder if we should be rushing into the design
16:52:14 sean-k-mooney im find we havign a call to see if we have a common undersanding
16:52:50 sean-k-mooney i just wonder if we shoudl disucss this at the ptg instead. we can totally do it now if we think there is a useful veriosn we coudl deviler this cycle
16:53:26 sean-k-mooney but i dont want to merge somethign we think wont acutlly be useful
16:53:33 dansmith I don't want to rush, but I also don't think this is complicated enough that we need to push it off... it doesn't affect rpc or api, which means getting it perfect the first time is not really a big deal, IMHO
16:54:21 sean-k-mooney ack
16:54:36 sean-k-mooney fyi https://github.com/openstack/nova/blob/32326d48949525a995d132bddc90e710c229947f/nova/scheduler/manager.py#L195-L205 is where we have the allcoation and the provider summeries already
16:55:57 sean-k-mooney we also pass them into _schedule https://github.com/openstack/nova/blob/32326d48949525a995d132bddc90e710c229947f/nova/scheduler/manager.py#L195-L343
16:56:45 sean-k-mooney we are just not assocating them with the host or pasing them to get_sorted_hosts https://github.com/openstack/nova/blob/32326d48949525a995d132bddc90e710c229947f/nova/scheduler/manager.py#L421
17:28:36 gibi sorry I was not able to follow this discussion as I had parallel back to back meetings. At this point I only care about solving the real use case.
17:31:06 gibi If there is an agreement that the current proposal solves the real use case, or even solve a real use case, then I'm OK with it.
17:35:10 opendevreview Sylvain Bauza proposed openstack/nova master: Add a new ImagePropertiesWeigher https://review.opendev.org/c/openstack/nova/+/940642
17:35:21 bauzas I just uploaded a new rev
17:35:29 bauzas but I'm fried for today
17:35:48 bauzas I'll rather grab a beer and hardstop
17:36:06 bauzas -ETOOMUCHCONTEXTSWITCHING
17:37:49 sean-k-mooney ya im feeling really unproductive today for the same reason
17:44:11 gibi indeed a lot of parallel things these days
17:49:07 bauzas this chan is logged and public, but you guys know and I'm just a sad panda to not have decent time for reviewing
17:49:18 bauzas tomorrow, I'll litterally block my agenda for such thing
18:06:25 sean-k-mooney gibi: bauzas i comemted on the latest version. i think the best path forward would be to have a second patch to copy the metric where imple for matching on indiviual properteis if we really want to supprot that
18:06:57 sean-k-mooney that way we keep the syntax common between the two weigher and if we agree we want both then we can merge both pathces
18:07:12 sean-k-mooney if we think we just want to keep it simple then we merge the first one
18:43:57 mikal What user do tempest tests run as? Because https://zuul.opendev.org/t/openstack/build/a2c28aa2ebc248509f5b586411172955 is getting {'code': 403, 'message': "Policy doesn't allow os_compute_api:os-console-auth-tokens to be performed."} which it shouldn't if its an admin user.
18:48:54 dansmith depends on the test and the client you use
18:49:28 dansmith there's like a self.client and self.admin_client on most test classes, but I think maybe not always if the setup didn't foresee the need
18:49:35 dansmith but that might give you a grep thread to follow
18:49:51 sean-k-mooney if you want to call admin apis you expelcity need to use an admin client in the test ya
18:50:19 mikal Hmmm, ok. I cargo culted the vnc tests, and its using "self.servers_client", whatever that is.
18:50:43 sean-k-mooney you might be ablle to just pass admin=ture to that

Earlier   Later