Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-02-13
15:27:27 bauzas yeah I could avoid the set calculation I think, I need to rethink the design
15:28:03 bauzas and yeah, that probably because of the values, not the keys
15:28:40 sean-k-mooney so instead of "set(inst.image_meta.properties.to_dict().items())" do ```{ "f{key},{value}" for key, value in inst.image_meta.properties.to_dict().items()}```
15:29:47 opendevreview Takashi Kajinami proposed openstack/os-vif master: Remove os-vif-linuxbridge https://review.opendev.org/c/openstack/os-vif/+/941567
15:29:51 bauzas that seems a bit hacky to me but this could work indeed
15:29:53 sean-k-mooney f goes on outside ... ```{ f"{key},{value}" for key, value in inst.image_meta.properties.to_dict().items()}```
15:30:13 bauzas yeah, I got your point, we would hash by strings :D
15:30:16 sean-k-mooney bauzas: it just relies on the fact that all stings are hashable
15:30:23 sean-k-mooney yep
15:30:32 bauzas this is fine
15:30:51 sean-k-mooney ideally i think ovo should be fixed to defien a hash on the element of a coherced list
15:30:51 bauzas but providing a fat comment would be nice I guess
15:31:08 sean-k-mooney but we proably dont want ot hold this on that
15:31:18 sean-k-mooney and ya a comment woudl be good
15:31:20 bauzas yup, FF is arriving
15:31:26 dansmith bauzas: sean-k-mooney I thought we were going to have a convo about a redesign?
15:31:35 bauzas winter is coming
15:31:36 sean-k-mooney we still can
15:31:42 sean-k-mooney dansmith: ^
15:31:47 dansmith gibi is not sufficiently convinced about the usefulness of this approach anyway
15:32:04 sean-k-mooney in my last review i suggested creating a follow up path
15:32:24 sean-k-mooney to allow per key weights using teh same syntax/code form the metrics weiher
15:32:26 bauzas if we could add that weigher as a first approach, I'm fine with a later refactoring that would fix world's problems
15:32:27 opendevreview Takashi Kajinami proposed openstack/os-vif master: Drop kuryr-kubernetes-tempest https://review.opendev.org/c/openstack/os-vif/+/941568
15:32:36 sean-k-mooney that way we can decced if we want the added complexity or not
15:32:59 bauzas sean-k-mooney: I still need to review your comments, I mostly focused on the failing jobs
15:33:01 gibi I'm open to a design discussion
15:34:00 sean-k-mooney bauzas: they were pretty minior.
15:34:25 sean-k-mooney basically if we have a more granualr approch to specifying weights per image property
15:34:48 sean-k-mooney i think there is merrit in having the behavior/syntax mirror that of the exisitng metric weigher
15:34:59 sean-k-mooney mainly just for consitency
15:35:06 bauzas okay I can take a look
15:36:25 sean-k-mooney i dont know if that woudl satisfy all open concerns or not but that was the tldr, get the simple version workign and passing then follow patch to extend and discuss later if we finally want to implement supprot for prefered traits
15:36:47 bauzas gibi: reading your comments, you know that we only compare the host properties against the exact image requested properties, right ?
15:37:36 bauzas I originally tried to compare all props as equal, but I eventually considered only the calculation of how many requested props were present on the host
15:41:39 dansmith I think gibi's point is that many irrrelevant props may be requested that dilute the scoring
15:41:40 gibi I'm not sure I see the consequences of it as I don't know what host properties means in this context
15:41:47 gibi dansmith: yes
15:42:21 gibi preferred traits in image metadata implemented as a weigher seems interesting and promising but haven't spent the time to think it through
15:42:42 sean-k-mooney gibi: its something i have wanted since before we actully had required traits
15:42:47 gibi as that would mean each image defines what property it cares about
15:43:09 sean-k-mooney if we supported prefered traits i woudl want to supprot it for both flavor and image ideally
15:43:42 sean-k-mooney but same overall impleation just way the host based on teh prefernce using the provider summaries
15:44:16 bauzas gibi: I need to validate your example in https://review.opendev.org/c/openstack/nova/+/940642/comment/932beb0e_c4933c32/
15:46:13 bauzas gibi: because while I agree with the fact that VM1 will be on host1 and VM2 on host2, I need to calculate the weight for VM3
15:46:50 dansmith to make it fully automatic you need to automatically export the trait when an instance is booted on a host, so perhaps some conf knob to expose traits of a thing automatically? l
15:46:59 dansmith auto_expose_image_props = os_type
15:47:07 gibi bauzas: my understanding is more matching properties means higher weights
15:47:26 bauzas you're right indeed, I see the problem now
15:47:43 gibi dansmith: good point, a full dynamic approach needs dynamic traits
15:47:48 bauzas well, that's not really a problem, you're diluting your need into multiple pieces
15:47:49 dansmith I again assert that for a cloudy workload that probably gets stronger with lots of boots of the same image
15:48:18 bauzas I assumed less fine-grained image properties
15:48:19 dansmith if you have tons of snowflake pet images then for sure it will be a very weak force
15:48:22 dansmith right
15:48:38 dansmith and I assumed this was a soft clumping optimization and not a hard packing mechanism
15:48:45 bauzas yup, KISS
15:48:52 dansmith because if you want the latter, it should use stronger guarantees
15:48:57 gibi dansmith: VMs from the same image attract each other I agree. So if we only have a single windows image then the solution works
15:49:20 dansmith gibi: or some small number of them that are probably going to be similar
15:49:25 bauzas we have a meeting in 20 mins
15:49:28 bauzas 10 mins*
15:49:42 bauzas but I think we need a design discussion indeed
15:50:00 bauzas so if you want, let's do that after the internal meeting, ie. 1700UTC
15:50:24 bauzas would 1700UTC work for the three of you ? sean-k-mooney gibi dansmith
15:50:34 dansmith I figure not gibi
15:50:40 dansmith but wfm
15:51:44 bauzas OK, I refreshed my brain on the metricsweigher
15:51:56 sean-k-mooney sure
15:52:13 bauzas fun fact, there was a note with my name, so I already walked that code
15:52:27 gibi dansmith: yeah this is a balancing act. if you have more windows images or if the windows images have a lot of other prop than os_type then you are losing the feature. Now the question is is this compromise acceptable for the customer requesting the feature. Telling them to limit the number of different windows VMs or limit the number of image props (it is already a lot by default from glance) might
15:52:29 bauzas but gosh my brain is so bad at remembering things
15:52:33 gibi be OK or might not. I leaning towards no. But we can probably ask :)
15:53:00 gibi bauzas: I can take a 30 min meeting after our internal call
15:53:11 bauzas gibi: sean-k-mooney's approach mimicing the metricsweigher seems a reasonable trade-off as a follow-up patch
15:53:38 dansmith gibi: yeah, all goes to how strongly you expect it to work. I expected weak optimization because it needs to be fully automatic
15:53:55 dansmith or intended to be fully automatic I mean
15:54:01 bauzas basically, it makes the weigh multiplier less easy to configure but that gives you a possibility to weigh per prop
15:54:14 sean-k-mooney for hard affinity we have the "isolating aggrates with placement" feature
15:54:22 dansmith I pretty much assume any weigher implementation is just trying to make better-than-random decisions, but not anything you'd bet on
15:54:49 dansmith bauzas: you mean my suggestion of a dict of properties and weights?
15:55:26 dansmith I think that gets closer to gibi's goal, but I also offered that suggestion along with a good example of why it's too simplistic
15:55:27 sean-k-mooney the weigher multipler is for seting the relitve weight between weighers when nomalising
15:55:50 sean-k-mooney the per property weight is internal
15:56:03 sean-k-mooney to how we calulate a weight for a given host before we normalise
15:56:13 sean-k-mooney so they have 2 distinct usecases
15:57:13 sean-k-mooney anyway shall we pick this up in an hour
15:58:51 bauzas yup, let's see ourselves in 1 hour
15:58:55 bauzas I'll ping back here
15:59:05 bauzas others can chime if they want
17:02:01 gibi need 2 minutes and I can join
17:02:32 bauzas okay, I'm starting a gmeet
17:03:52 bauzas https://meet.google.com/vye-tjns-bai <= for discussing about https://review.opendev.org/c/openstack/nova/+/940642/
17:42:13 sean-k-mooney bauzas: gibi dansmith melwitt on an unrelated note. neutron removed linuxbridge supports weeks ago
17:42:25 sean-k-mooney os-vif and nova have linux bridge jobs
17:42:45 sean-k-mooney the nova one only tirggers on specific files
17:43:17 sean-k-mooney tehre was a mailing list post about this a while ago but i just want to get poeopel opions on how to move forward
17:43:34 sean-k-mooney first ill put up a patch to drop hte job form nova's check pipeline
17:44:09 sean-k-mooney beyond that there is a patch to remove the job form os-vif but i think we should also remove the linux brindge os-vif plugin
17:44:43 sean-k-mooney os-vif's policy has always been we only have pluggins for in tree neutron backends

Earlier   Later