| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-01-06 | |||
| 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 ^ | |
| 19:41:32 | artom | sean-k-mooney, don't bother, it's an infra thing | |
| 19:41:37 | sean-k-mooney | but skiming back dansmith are you in favor fo the tpm secret beign owned by nova | |
| 19:41:43 | artom | sean-k-mooney, you can just read the comments on the review | |
| 19:41:49 | artom | sean-k-mooney, tl;dr yes that you just said | |
| 20:36:34 | opendevreview | Merged openstack/nova master: Refactor response schemas for share API https://review.opendev.org/c/openstack/nova/+/936656 | |
| 21:25:52 | opendevreview | sean mooney proposed openstack/nova master: [WIP] allow discover host to be enabeld in multiple schedulers https://review.opendev.org/c/openstack/nova/+/938523 | |
| 21:37:59 | opendevreview | sean mooney proposed openstack/nova master: [WIP] allow discover host to be enabeld in multiple schedulers https://review.opendev.org/c/openstack/nova/+/938523 | |
| #openstack-nova - 2025-01-07 | |||
| 01:39:41 | opendevreview | Takashi Kajinami proposed openstack/nova master: doc: Use dnf instead of yum https://review.opendev.org/c/openstack/nova/+/938496 | |
| 11:21:18 | opendevreview | huanhongda proposed openstack/nova master: Rollback live migration when virt driver failed https://review.opendev.org/c/openstack/nova/+/938154 | |
| 14:43:37 | dansmith | artom: gibi sean-k-mooney melwitt do you want to jump on a high-bandwidth chat today about the tpm stuff? | |
| 14:44:20 | artom | Was just about to say... | |
| 14:44:33 | sean-k-mooney | am sure i can whenever | |
| 14:44:45 | sean-k-mooney | im almost doen my first pass on the vfio-variant driver spec | |
| 14:44:49 | sean-k-mooney | (the first one) | |
| 14:44:53 | dansmith | I'm pretty open today | |
| 14:45:43 | artom | The ACL vs make the Barbican secret owned by the Nova user thing is kind of a red herring, in the sense that it's an implementation detail that achieves the exact same thing (mostly): the Nova service user can read the Barbican secret. What we're really debating is - do we give access to the Nova user unconditionally, or do we make it opt-in for the user. | |
| 14:46:09 | artom | For the human user. | |
| 14:46:43 | sean-k-mooney | well there is that topci | |
| 14:46:59 | sean-k-mooney | but also shoudl we change how the vtpm secret is stored in libvirt so we can read it back | |
| 14:47:03 | dansmith | well, or if we use libvirt for it | |
| 14:47:04 | dansmith | yeah | |
| 14:47:24 | sean-k-mooney | and i think we shoudl check if libvirt can already copy it if its not marked as private for what its worth | |
| 14:47:24 | artom | That would make it a non-starter for rolling upgrades, so I thought we'd dropped that idea | |
| 14:47:38 | dansmith | and one thing we could discuss is how much of the implementation is the same (i.e. the copying of a secret from source, vs. the dest fetching it) on each thing | |
| 14:47:55 | dansmith | sean-k-mooney: I thought the spec said that wasn't implemented yet? | |
| 14:47:59 | sean-k-mooney | artom: im not conviced we shoudl be upgrading new vms to supprot this without requireing them to be cold migrated or hard rebooted or somethihng like that | |
| 14:48:15 | sean-k-mooney | dansmith: its definaly not supproted for private secrtes | |
| 14:48:39 | sean-k-mooney | but the docs for this is slightly odd so i would like to check what happens if we dont make them private | |