| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-01-06 | |||
| 13:27:12 | sean-k-mooney | so for hte last couple of release i have been debating adding 3 new weigher based on internal converstaion and customer bugs | |
| 13:27:44 | sean-k-mooney | the 3 i was condiering implemtiing were a image affinity weigher, flavor affinity weigher and boaring host weigher | |
| 13:27:54 | sean-k-mooney | the image propertiy weigher in https://blueprints.launchpad.net/nova/+spec/image-metadata-props-weigher | |
| 13:28:06 | sean-k-mooney | sounds like its similar to those in intent | |
| 13:28:46 | sean-k-mooney | i assume the intent is ot look at the image propertites in the current request and prefer or avoid host that have instnace with the same properites correct? | |
| 13:29:19 | bauzas | ah, ok | |
| 13:29:29 | sean-k-mooney | so rather then soft affinity/anti based on the flavor/image have soft affinity/antiaffinty based on the image properites | |
| 13:30:03 | sean-k-mooney | so you can pack/spread similar image in this case OS_TYPE=windows it the motivating example | |
| 13:30:15 | bauzas | yeah indeed, some *people* would want to be able to have Windows instances in some hosts | |
| 13:30:20 | bauzas | like, being packed | |
| 13:30:30 | sean-k-mooney | but without forcing it right | |
| 13:30:34 | bauzas | exactly | |
| 13:31:08 | bauzas | just because of the money you need to pass to Microsoft :) | |
| 13:31:09 | sean-k-mooney | and would this use host aggrate metadata or just the instnace on the host | |
| 13:31:34 | bauzas | I discussed about the aggregate with the *people* | |
| 13:32:00 | sean-k-mooney | ok the reason i asked that is i could see both as options but i think this would be the first aggrate aware weigher | |
| 13:32:09 | sean-k-mooney | its not actully a blocker either way | |
| 13:32:10 | bauzas | but the problem with aggregates is that you need to know *how many* hosts you will need to use per the aggregate (for example for Windows) | |
| 13:32:11 | sean-k-mooney | just wondering | |
| 13:32:31 | sean-k-mooney | ya so that why i was wondier if we woudl od this more organically | |
| 13:32:45 | sean-k-mooney | by looking at the instance already on a host rather then using aggreate metadata | |
| 13:32:51 | bauzas | of course, you can add a new host to an existing aggregate, but if you want to remove one host from an aggregate, then you need to move the instances | |
| 13:33:07 | sean-k-mooney | not nessiasrly | |
| 13:33:17 | bauzas | that's why they prefer to have a way to pack the windows instances | |
| 13:33:20 | sean-k-mooney | well ya kind of | |
| 13:33:31 | bauzas | without creating aggs | |
| 13:33:58 | sean-k-mooney | so i would be inclided ot do this without relying on aggreats | |
| 13:34:47 | sean-k-mooney | the image affiinity weigher i was condierding was a more restrctive version of that i.e. it would only look at the image uuid rather the the perperteis and try and pack/sptread based on that | |
| 13:35:31 | sean-k-mooney | if i was to implement https://blueprints.launchpad.net/nova/+spec/image-metadata-props-weigher i would not depend on host aggartes or provide two diffent implamtions | |
| 13:36:20 | sean-k-mooney | one that looked at the instnace already on the host and a second that would look at metadat on the hosts aggreates | |
| 13:37:09 | sean-k-mooney | but i think as an operator i woudl want this to work more or less automatically without requireing me to add aggreate metadata or a lot of config | |
| 13:37:16 | bauzas | exactly | |
| 13:37:36 | bauzas | that's what I wrote in the description | |
| 13:37:57 | sean-k-mooney | well the reason i started this converstaion is i did not find the descript partically clear | |
| 13:38:05 | bauzas | ha | |
| 13:38:27 | sean-k-mooney | i could read between the lines but if you wanted to ask for a specless blueprint tomorrwo i think you need a clearer description | |
| 13:38:34 | bauzas | well, I wrote the problem and I explained why aggregates can be used but why we need to create a new weigher | |
| 13:38:49 | bauzas | without using such aggs | |
| 13:38:49 | sean-k-mooney | so "That's why we would like to create a specific ImageMetadataPropsWeigher for looking at how many instances have a specific prop and then operators could use it for that case or for something else (like packing instances by machine types)" | |
| 13:38:52 | sean-k-mooney | the last line | |
| 13:38:58 | sean-k-mooney | is really want you want ot do right | |
| 13:39:11 | sean-k-mooney | it was not clear to me that you wanted to avoid aggreates | |
| 13:39:24 | bauzas | I can surely modify the description :) | |
| 13:40:41 | sean-k-mooney | if you can add someting explict like "This blueprint propsoes addign a new weigher that will pack/spread instance based on teh image properies requested by the instance and the image propeteis of existing instnace on indivugale hosts" | |
| 13:40:47 | sean-k-mooney | then i think it will be fine | |
| 13:42:06 | sean-k-mooney | the other comment i have is more na implemation detail but since all weigher are enabeld by default the multipler for this oen should likely be 0 to avoid any upgrade impact and then +/- can be used for spread/pack | |
| 13:43:07 | bauzas | sean-k-mooney: done :) | |
| 13:43:20 | sean-k-mooney | im in two minds about if this shoudl requrie a spec or not but i assuem we will discuss that in the team metting tomorow | |
| 13:43:39 | sean-k-mooney | i dont think its particallary contoverial | |
| 13:43:44 | sean-k-mooney | but we can see what others think | |
| 13:45:04 | sean-k-mooney | since we already have the instnaces in memory in the hoststate object for the affinty/anti affinity fileter this should not require any addtional db lookup so i expect teh perfoamce impact to be pretty minimal | |
| 13:45:35 | sean-k-mooney | and if the multipleer defaults to 0 there is no upgrade impact | |
| 13:45:58 | sean-k-mooney | so im leaning towards specless | |
| 13:46:22 | bauzas | sean-k-mooney: that's a good question, that's why I provided the bp, but we need to discuss this tomorrow indeed | |
| 13:48:00 | sean-k-mooney | i assume the algoitherim woudl be something like (count of common image properies in isntnace / count of total image propeies of exisiting instnaces) | |
| 13:48:33 | sean-k-mooney | that way the more image properies the current instnace as in common with the instance on a given host the more we prefer it | |
| 13:51:19 | sean-k-mooney | common/total will naturally pack or we can take 1 - (common/total) to spread by default | |
| 14:04:25 | sean-k-mooney | bauzas:i updated the whiteboard with my comments | |
| 14:06:31 | sean-k-mooney | bauzas: by the way the bill would not be huge if you spread window sinstance across all host | |
| 14:06:44 | sean-k-mooney | bauzas: microsoft only does host based liceineing on hyperv | |
| 14:07:35 | sean-k-mooney | for libvirt the volume lisenicing is not host base by vm based so packing or spreading has no impact in general on cost | |
| 14:09:18 | sean-k-mooney | the only way cost factors into this is is if you segreated your isntance today based on guest os then you may have under utilistation because fo the static partioning | |
| 14:10:51 | sean-k-mooney | which the weigher can avoid to some degree by allowing linux guests to use the slack space as you no longer need to staticly partion. in a normal libvirt deployment i would not recommend partioning host based on OS_TYPE any more really. there are some cases where it could make sense but in general no so much | |
| 14:11:15 | sean-k-mooney | the weigher is still reasonabel even with out the cost motive IMO | |
| 14:13:09 | aaron | thanks for the info sean-k-mooney - I did see your reply on the mailing list thread on this from 18 months ago. I can work around the qemu-kvm path using a symlink. I will do some testing with cold-migration rather than hacking qemu-kvm at this point | |
| 14:14:40 | sean-k-mooney | ah ok. ya the symlink shoudl work for the path issue. unfotunetly rhel adn as a result centos 8 compiled out the standard machicne tyeps from upstream qemu so its not posible to use a common machine type between centos and ubuntu | |
| 14:15:56 | sean-k-mooney | aaron: as i said on past mail thread centos 6/7 coudl live migrate to the contempoery ubuntu becasue at least in the centos 6 time it had the upstream qemu machine types so you could select a common one | |
| 14:16:40 | sean-k-mooney | in rehl 7 or 8 they stopped packaging the upstream qemu machinetype in rhel which broke this interoprablity | |
| 14:28:06 | aaron | sean-k-mooney - got it, that makes sense, thanks. i will have a play - cold migration is a valid way forward so that should be good :) | |
| 14:29:01 | aaron | (fwiw i don't have a bouncer setup atm so if I DC then i'm not being rude - my laptop has probably died/slept but I can see history on the openstack eavesdrop pages ) | |
| 14:30:32 | sean-k-mooney | no worreis i also dont use a boucher but i nerver turn off my laptop | |
| 14:30:45 | sean-k-mooney | well unless im on pto for a few weeks :) | |
| 16:21:34 | opendevreview | Takashi Kajinami proposed openstack/nova master: doc: Use dnf instead of yum https://review.opendev.org/c/openstack/nova/+/938496 | |
| 16:24:07 | opendevreview | Takashi Kajinami proposed openstack/placement master: doc: Use dnf instead of yum https://review.opendev.org/c/openstack/placement/+/938499 | |
| 17:31:54 | dansmith | artom: can you resolve the comments on your tpm spec that have been addressed? It's cluttered with lots of things, many of which seem out of date now | |
| 18:03:52 | dansmith | artom: left a bunch of comments that will make gibi hate me, let me know if you want to chat about them high-bandwidth | |
| 18:04:27 | artom | dansmith, lemme take a look | |
| 18:05:08 | artom | (I kinda assumed the original comment author would resolve their comment if my changes/response adequately addressed them. I always feel bad making others's stuff disappear) | |
| 18:07:38 | sean-k-mooney | artom: it depends, genneral expect the patch autor to mark them as done if they mad the change | |
| 18:07:51 | sean-k-mooney | but its kind fo a judgement call | |
| 18:10:41 | dansmith | yeah, which is why I hate the resolve stuff, but since it's there, someone has to do it | |
| 18:22:31 | dansmith | sean-k-mooney: iso+gpt now passing: https://review.opendev.org/c/openstack/nova/+/931833 | |
| 18:33:10 | sean-k-mooney | awsome | |
| 18:48:05 | artom | dansmith, left some answers. I fixed all the typos, but I won't push just yet with no other changes so far, pending more discussion. | |
| 19:04:39 | artom | dansmith, I think I'm coming around to your way of thinking - re: making the secrets owned by the Nova user, if that only means that compute host root and no one else gets access to them. | |
| 19:05:22 | artom | Out of respect for gibi, I'd like to get his thoughts when he's back | |
| 19:05:26 | dansmith | either that or libvirt storing them seems like the ideals you're going for.. not exposing to the api admin person, but allowing the system to reboot and migrate instances on their behalf if authorized to do so | |
| 19:05:39 | dansmith | the benefit of the former means they're not stored on disk if in the theft case | |
| 19:05:47 | dansmith | artom: for sure, wait for gibi of course | |
| 19:06:03 | artom | Storing in libvirt would break your rolling upgrades live migration point. | |
| 19:06:19 | artom | If the source isn't using the new code, it can't read it back and send it to the new dest. | |
| 19:06:34 | dansmith | yep | |
| 19:06:47 | artom | So we're converging on making it Nova-owned. | |
| 19:07:01 | dansmith | I wasn't making the argument for that being mandatory, I was saying that your argument for why it's not in your arrangement seemed weak | |
| 19:07:14 | dansmith | if there's a stronger technical reason for it, then it's reasonable | |
| 19:07:53 | artom | Ack. | |
| 19:08:08 | artom | So - do I want to rewrite this now, or chat to gibi first? | |
| 19:08:18 | dansmith | nah, wait for gibi | |
| 19:08:53 | artom | *procrastinating artom is happy* | |
| 19:41:15 | sean-k-mooney | dansmith: artom: i was try8ing to figure out why downstream ci was failing an gave up so i was not following ^ | |