| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-12-12 | |||
| 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 | |
| 14:09:21 | gibi | :D | |
| 14:10:01 | gibi | artom: you need to declare the_dead before | |
| 14:10:17 | gibi | :) | |
| 14:15:57 | sean-k-mooney | artom: +2 on https://review.opendev.org/c/openstack/nova/+/899776 but add a release note please if you respin | |
| 14:18:06 | sean-k-mooney | gibi: if your review then ^ is small | |
| 14:18:21 | artom | Yeah, agree on the release note | |
| 14:19:30 | sean-k-mooney | its not vital but it woudl be good to advertise this. if you want to respin anyway jsut ping me and ill take a look again | |
| 14:23:20 | opendevreview | Artom Lifshitz proposed openstack/nova master: libvirt: Stop unconditionally enabling evmcs https://review.opendev.org/c/openstack/nova/+/899776 | |
| 14:23:25 | artom | Done ^^ :) | |
| 14:30:54 | sean-k-mooney | ack +2'd | |
| 14:47:00 | kashyap | elodilles: Hi, I was just pointed to your question about https://patchwork.kernel.org/project/qemu-devel/patch/20180622003140.164613-2-mst@redhat.com/ | |
| 14:47:11 | kashyap | elodilles: It's a QEMU command-line option, as you see. We don't have a BP (not that I know of) for it | |
| 14:48:02 | kashyap | Have you tested it w/ "<qemu:commandline> | |
| 14:48:43 | kashyap | ... in the guest XML? Do you see noticeable benefits? | |
| 14:49:09 | sean-k-mooney | we do not allow <qemu:commandline> to be used in nova | |
| 14:49:29 | sean-k-mooney | so even if that worked it would need to be expose via an actual libvirt element | |
| 14:49:46 | sean-k-mooney | its fine for testing hwoever | |
| 14:50:11 | gibi | artom, sean-k-mooney +2+W | |
| 14:53:51 | sean-k-mooney | elodilles: so i had heard about the fucntionaltiy but not looked into it much | |
| 14:54:12 | sean-k-mooney | elodilles: i could see use in the future enableing this by default for guest with pinned but not mixed cpus | |
| 14:54:30 | sean-k-mooney | since this does not seam to be per core we cant supprot mixed cpus | |
| 15:00:40 | elodilles | kashyap: i'm not aware of any testing, but yeah, that's probably would be a good start to see if it has any benefit. | |
| 15:01:10 | kashyap | sean-k-mooney: I of course know we don't allow. I explicitly said "testing" there | |
| 15:01:38 | kashyap | The qemu:commandline thing. It is alwys mentioned in context of developer testing in this channel for a million years now. | |
| 15:01:54 | kashyap | elodilles: Yeah; some data on that would be good. What made you think of that feature? | |
| 15:01:55 | elodilles | sean-k-mooney: ACK, yepp, only for guests with pinned CPUs, yepp. that was my understanding too. | |
| 15:02:34 | sean-k-mooney | elodilles: if you do try this in devstack just not i disabled the apic by default in devstack becasue of a bug in cirros 5.x | |
| 15:02:35 | elodilles | kashyap: well, i got a question from downstream team :) | |