Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-12-12
17:18:28 sean-k-mooney out of interest why do you care about the flavor
17:18:50 JayF Super common support question for Ironic admins
17:18:52 sean-k-mooney what will it be used for?
17:18:57 JayF that's the answer
17:19:10 JayF 'what flavor did you use to boot this' often dictates some actions Ironic takes on spawn
17:19:14 sean-k-mooney oh ok so the resouce class on the node is not enough
17:19:17 JayF yep
17:19:23 sean-k-mooney ok makes sense
17:19:28 sean-k-mooney this is why its there in the libvirt xml
17:19:40 sean-k-mooney but often i get a comptue log with no flavor info
17:19:46 JayF because resource_class + capabilities (not sure I'm using right nova term ?) means you might have the same node
17:19:51 sean-k-mooney so that why the flavor detail like the extra spec are useful to me
17:19:57 JayF but it gets a different deployment template, giving it different bios config on spawn
17:20:09 johnthetubaguy sean-k-mooney: FWIW, I feel like this should be "similar" to what we do with libvirt xml, to get the extra info in there.
17:20:30 JayF so you might have, supersize-node-configa supersize-node-configb and both are node.resource_class=supersize-node
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

Earlier   Later