| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-12-12 | |||
| 17:20:38 | sean-k-mooney | johnthetubaguy: ya so the libvirt part is just using the flavor and image + the project id i think | |
| 17:20:54 | JayF | johnthetubaguy: we were just talking about maybe that code becoming common | |
| 17:21:10 | JayF | johnthetubaguy: so the ironic/libvirt driver code would just be taking a dict of metadata and putting it in the right place | |
| 17:21:12 | johnthetubaguy | sean-k-mooney: yeah, I think it makes sense to be the same, or at least similar. | |
| 17:22:18 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/config.py#L3600-L3642 | |
| 17:22:55 | sean-k-mooney | well actuly https://github.com/openstack/nova/blob/master/nova/virt/libvirt/config.py#L3600-L3699 | |
| 17:23:23 | sean-k-mooney | i have been meing to extend that for a while but it was never a high enough priority | |
| 17:23:32 | sean-k-mooney | i think that ahs most of what you want already | |
| 17:24:14 | JayF | I'm pretty sure that's *exactly* the code we had up in the meeting when we made this bp | |
| 17:24:34 | johnthetubaguy | JayF: what is missing? yeah, that is the code I was thinking about before. | |
| 17:26:12 | JayF | as long as it has the project that spawned it and the flavor that's the primary things we care about | |
| 17:26:22 | JayF | and I see a self.owner and a self.flavor | |
| 17:28:00 | johnthetubaguy | JayF: +1 I think that has it all. Feels like a case of adding to_dict(), in a way. | |
| 17:28:06 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5780 | |
| 17:28:15 | sean-k-mooney | so this is where we generate this today | |
| 17:28:17 | johnthetubaguy | ah, that was it. | |
| 17:28:32 | sean-k-mooney | we could move that up to the base virt dirver | |
| 17:28:57 | sean-k-mooney | it just taks the instance and network info today | |
| 17:29:10 | sean-k-mooney | ok so not quite | |
| 17:29:16 | sean-k-mooney | its currently building livbirt objects | |
| 17:29:39 | johnthetubaguy | Yeah, if we have something generating a dict we can both use, that would have everything we need | |
| 17:29:41 | sean-k-mooney | but we coudl build a dict or other object that is not libvirt specific | |
| 17:31:25 | JayF | and then the MVP for the Ironic change becomes "toss that metadata into the instance_info patch on spawn" and "do the proper $whatever on rebuild/other non-spawn instance modifying actions" | |
| 17:31:42 | sean-k-mooney | basically ya | |
| 17:31:45 | JayF | then we'll have an Ironic side change to respect that metadata for automatic_lessee and to add a backfill script | |
| 17:31:58 | sean-k-mooney | the libvirt driver just generate it every time we generate an xml | |
| 17:32:03 | JayF | (which the backfill script will also backfill node.lessee if configured to do so, which is why having it in Ironic is great) | |
| 17:32:09 | sean-k-mooney | so on reboot as well | |
| 17:32:13 | sean-k-mooney | im not sure if you just want to do that | |
| 17:32:21 | sean-k-mooney | and say reboot the node to backfile or not | |
| 17:32:44 | sean-k-mooney | that is how we handlel it when we add more metadata for libvirt | |
| 17:33:01 | sean-k-mooney | just tell people reboot, cold migate or anything else that updates the xml | |
| 17:33:19 | JayF | What kind of actions cause metadata to change? | |
| 17:33:24 | JayF | Let me ask that differently. | |
| 17:33:37 | JayF | What kind of non-API-initiated-actions can cause metadata to change? | |
| 17:33:42 | JayF | ^ user | |
| 17:33:50 | sean-k-mooney | interface attach/detach, resize, rebuild and evcauate | |
| 17:34:23 | sean-k-mooney | technially it wont change on reboot but we just do that anyway because its simpelr since we deltee and recreate the xml on every reboot | |
| 17:34:28 | JayF | we'd may want to consider filtering interface metadata in ironic instance_info, because ironic has it's own network info | |
| 17:34:34 | JayF | and rebuild is the only other case that impacts Ironic | |
| 17:35:07 | sean-k-mooney | i think its ok for a virt direr to profject a view of the metdata that only has the filed that makes sense to it | |
| 17:35:18 | JayF | so I think we should be able to get it to a case where Ironic instnace metadata would only change meaningfully on rebuild/spawn/destroy | |
| 17:35:38 | sean-k-mooney | ya that sounds about right | |
| 17:36:02 | johnthetubaguy | sean-k-mooney: yeah, I think the common code can provide the set of metadata allowed, Ironic can pick a subset of that, I think skipping the network bits makes sense. | |
| 17:36:22 | sean-k-mooney | with that said | |
| 17:36:38 | sean-k-mooney | on the network side i know ironci suport portgroups | |
| 17:36:56 | sean-k-mooney | but when an ironic node is assocated with a nova instance | |
| 17:37:08 | sean-k-mooney | the only addtion or remoavl of interface | |
| 17:37:13 | sean-k-mooney | should be done via nova api | |
| 17:38:10 | sean-k-mooney | im aware that vif plug in the ironic driver calls ironic which does thign with neutron | |
| 17:38:47 | sean-k-mooney | btu it shoudl not really affect which ports/port groups are assocated with the instance form a nutron point of view | |
| 17:39:43 | JayF | Yes. The feeling behind not wanting to pass thru the network metadata is much, much more basic than that: there's already like, three views to networks when people come to Ironic with support: Nova's view, Neutron's view, Ironic's view (port object)... not even counting various bifrost/whatever type of configs | |
| 17:40:07 | JayF | I just don't want to see any bugs with "here's the node.instance_info['meta']['network']" or pollute the DB with more redundant info :) | |
| 17:40:08 | sean-k-mooney | :) | |
| 17:40:35 | sean-k-mooney | well the metadta does not ahve the full network object | |
| 17:40:42 | sean-k-mooney | just the ip s | |
| 17:40:46 | sean-k-mooney | assocated with an instance | |
| 17:41:05 | sean-k-mooney | but if you already have that no need to duplciate it as you said | |
| 17:41:06 | JayF | which is actually information that people might want | |
| 17:41:14 | JayF | IP is in neutron, we don't have it in Ironic | |
| 17:41:36 | JayF | Ironic holds more of the information about the physical port: mac address, binding profile/metadata about how it's physically connected to switches, etc | |
| 17:45:06 | sean-k-mooney | the ip stuff was a relitivly late addtion | |
| 17:45:44 | sean-k-mooney | https://github.com/openstack/nova/commit/838370a49014351051bbef2d1c2ada1f47ac2bfb | |
| 17:46:03 | sean-k-mooney | it was added in wallaby | |
| 17:46:42 | sean-k-mooney | anyway that data would be avialable for you to consume if it was useful | |
| 17:47:09 | sean-k-mooney | JayF: this is the spec we used to add that https://specs.openstack.org/openstack/nova-specs/specs/wallaby/implemented/libvirt-driver-ip-metadata.html | |
| 18:39:29 | opendevreview | Stephen Finucane proposed openstack/nova master: Bump hacking version https://review.opendev.org/c/openstack/nova/+/903529 | |
| 18:39:30 | opendevreview | Stephen Finucane proposed openstack/nova master: Resolve mypy error https://review.opendev.org/c/openstack/nova/+/903530 | |
| 18:46:31 | stephenfin | That mypy fix is required to unblock an u-c bump, while the other fix and the u-c bump are required to fix installing nova (for unit tests) on Python 3.12 (Fedora 39) ^ | |
| 22:01:15 | JayF | sean-k-mooney: johnthetubaguy: Is there anything I can do to help get https://review.opendev.org/c/openstack/nova/+/900831 landed? Was hoping to get this in front of the sharding re-proposal patch, which I was hoping to do this week (about to go rev the spec) | |
| 22:41:38 | opendevreview | Merged openstack/nova master: Fix regression breaking Ironic boot-from-volume https://review.opendev.org/c/openstack/nova/+/903324 | |
| 22:41:55 | JayF | Huzzah! | |
| 23:25:07 | opendevreview | Jay Faulkner proposed openstack/nova-specs master: Re-submit Ironic-shards for Caracal https://review.opendev.org/c/openstack/nova-specs/+/902698 | |
| 23:51:59 | opendevreview | Jay Faulkner proposed openstack/nova master: [ironic] Partition & use cache for list_instance* https://review.opendev.org/c/openstack/nova/+/900831 | |
| #openstack-nova - 2023-12-13 | |||
| 00:36:52 | opendevreview | melanie witt proposed openstack/nova master: Support rebuild and unshelve with ephemeral encryption https://review.opendev.org/c/openstack/nova/+/870939 | |
| 02:29:11 | opendevreview | OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.opendev.org/c/openstack/nova/+/903427 | |
| 09:04:53 | opendevreview | Vasyl Saienko proposed openstack/nova master: Fix returning empty availability zone https://review.opendev.org/c/openstack/nova/+/902875 | |
| 09:11:18 | alisafari | sean-k-mooney Hi, could you check out these backports? https://review.opendev.org/q/topic:%22fix-traits-to-cpu-flags-mapping%22 | |
| 10:04:37 | elodilles | bauzas: sorry, i forgot to let you know that i'll be on PTO yesterday :/ | |
| 10:04:51 | bauzas | elodilles: no worries at all :) | |
| 10:04:57 | elodilles | o:) | |
| 10:05:35 | elodilles | nevertheless, i have a question: have you heard about this qemu feature: cpu-pm? -> https://patchwork.kernel.org/project/qemu-devel/patch/20180622003140.164613-2-mst@redhat.com/ | |
| 10:06:02 | elodilles | or maybe the question is also to sean-k-mooney ^^^ | |
| 10:07:36 | elodilles | do you remember maybe if someone was preparing to include this in OpenStack? a patch, a blueprint, or something like that? | |
| 10:14:40 | opendevreview | Nobuhiro MIKI proposed openstack/nova master: scheduler: Request COMPUTE_ADDRESS_SPACE_* traits https://review.opendev.org/c/openstack/nova/+/895761 | |
| 10:21:53 | opendevreview | Nobuhiro MIKI proposed openstack/nova master: libvirt: Add config option to support maxphysaddr https://review.opendev.org/c/openstack/nova/+/895759 | |
| 10:29:18 | bauzas | elodilles: sorry, just saw your ping | |
| 10:29:23 | bauzas | elodilles: nope, wasn't aware of it | |
| 10:38:10 | elodilles | bauzas: thanks. well, i'm not even sure it's still there in qemu, and i haven't seen sign of it in libvirt either, though i thought it worth a question o:) | |
| 12:50:09 | opendevreview | Stephen Finucane proposed openstack/nova master: docs: Address nits in new security group doc https://review.opendev.org/c/openstack/nova/+/903590 | |
| 13:38:56 | gibi | sean-k-mooney: an easy power management bugfix backport that has elodilles' +2 https://review.opendev.org/c/openstack/nova/+/903151 | |
| 13:47:56 | sean-k-mooney | "raise exception.InvalidConfiguration(msg) from e" ah your using that to convert the excpetion cool | |
| 13:49:48 | sean-k-mooney | +2w | |
| 14:05:10 | artom | Ooo, `raise from` is a thing? | |
| 14:05:22 | sean-k-mooney | its a python 3 only thing | |
| 14:05:23 | artom | So I could import zombie; raise zombie from the_dead? :D | |
| 14:05:24 | sean-k-mooney | but yes | |
| 14:05:36 | sean-k-mooney | ... | |
| 14:05:56 | sean-k-mooney | your a terrible terrible person. a good person but a teribel one :P | |
| 14:06:11 | artom | :D | |