| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-12-12 | |||
| 17:06:52 | bauzas | sounds there is kind of a grey path about what we would for non-greenfields instances | |
| 17:06:58 | bauzas | would do* | |
| 17:07:09 | JayF | I like the idea of Ironic owning the migratino script | |
| 17:07:09 | bauzas | time is flying tho and we're *again* late | |
| 17:07:18 | JayF | and will think abuot it further and likely propose that | |
| 17:07:23 | sean-k-mooney | we shoudl figure our a solution to exisitng instnace but we dont need to do that now | |
| 17:07:25 | bauzas | (I'm really sorry about it) | |
| 17:07:39 | bauzas | JayF: what would you be your preference ? | |
| 17:07:42 | sean-k-mooney | JayF: do you want to think about that for a few days and let use knwo what you think is the best approch | |
| 17:08:11 | bauzas | approving the blueprint with a note saying "this is only a path for new instances, the migration path is yet to be defined" ? | |
| 17:08:17 | sean-k-mooney | im kind of feeling liek a spec would help by the way | |
| 17:08:24 | bauzas | or we could revisit the approval in later meetings | |
| 17:08:27 | JayF | Yeah I'm thinking Ironic side script, because then we can allow the Ironic-side actions to be done, too | |
| 17:08:30 | JayF | I'd say lets revisit | |
| 17:08:30 | sean-k-mooney | but if other are ok im not going to say we must have one | |
| 17:08:39 | JayF | I think I'll get to talk to John in the intervening week | |
| 17:08:52 | bauzas | okay, I'll keep the bleuprint in the agenda | |
| 17:08:56 | JayF | I wasn't sure what the edges were on this, now I know what they are and can file them down :) | |
| 17:08:59 | JayF | thank you | |
| 17:08:59 | bauzas | and we could revisit it next week | |
| 17:09:04 | bauzas | thanks | |
| 17:09:05 | sean-k-mooney | i just dont knwo this code as well as other so it would help me to have a little more detail. but we coudl just put more detail in the blueprint | |
| 17:09:17 | bauzas | and because we're horribly late, I'll end the meeting now | |
| 17:09:24 | sean-k-mooney | o/ | |
| 17:09:24 | bauzas | thanks all | |
| 17:09:30 | bauzas | and sorry again | |
| 17:09:32 | bauzas | #endmeeting | |
| 17:09:32 | opendevmeet | Meeting ended Tue Dec 12 17:09:32 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:09:32 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-12-12-16.01.html | |
| 17:09:32 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-12-12-16.01.txt | |
| 17:09:32 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-12-12-16.01.log.html | |
| 17:09:45 | gibi | thanks bauzas | |
| 17:10:20 | JayF | sean-k-mooney: the base feature in Ironic we want to hook into is right now, w/standalone ironic, you set [conductor]automatic_lessee=true, you get node.lessee={project_id that spawned it} set automatically by Ironic, and you can use RBAC to give some Ironic API access to that node (anything from read access to ability to self-serve some maintenance items) | |
| 17:11:19 | JayF | sean-k-mooney: so doing a backfill using nova-based script would be awkward, because we could backfill the nova half but the Ironic side wouldn't have taken the "on spawn" action... but if we do it from Ironic side, it can pull info from Nova, make the change to put the metadata on the node, and also use Ironic config to flip other node settings as needed (for example: setting | |
| 17:11:21 | JayF | node lessee) | |
| 17:12:13 | sean-k-mooney | JayF: ok so you think it would be better to have an ironic-manage or even an ironic api endpoint | |
| 17:12:22 | sean-k-mooney | to trigger the backfile or just od it with a script | |
| 17:13:22 | sean-k-mooney | i tought it might be simlpel to just have nova-manage call the function that normally generates the metatada we would set and call the ironic api with that | |
| 17:13:27 | JayF | A script, for sure, and I could see the shape of that script being such that nova-backfill is an option on it | |
| 17:13:31 | sean-k-mooney | but if that is not simple then no need to do it in nova | |
| 17:13:43 | JayF | Yeah but like I said, that's only like, half of the equation and alone is not super valuable | |
| 17:14:03 | sean-k-mooney | ack | |
| 17:14:27 | sean-k-mooney | for what its wroth you have remined me that i have wanted to extend the metadata in the libvirt xml for years | |
| 17:14:50 | sean-k-mooney | sepeicicly i want to have both the image and flagor (name and uuid) and have the image /falvor extra specs direclly in the metadata | |
| 17:14:52 | JayF | well that's like, another thing I wanted to say | |
| 17:15:07 | JayF | Why do we want a libvirt metadata list and an Ironic metadata list? | |
| 17:15:25 | JayF | can there not just be a "here's a big list of instance metadata that hypervisors that care about metadata cna have" | |
| 17:15:49 | sean-k-mooney | we coudld have this in common code yes | |
| 17:16:06 | JayF | John and I were looking at this, and that's where the bp came from | |
| 17:16:08 | sean-k-mooney | all the dirver need to do is transform the dic of metadta to where it stores it | |
| 17:16:29 | JayF | ++ that would be ideal | |
| 17:16:52 | sean-k-mooney | so the reaosn i want to add both the name and uuid is the image uses one and the flavor uese the other | |
| 17:16:57 | sean-k-mooney | both shoudl use both | |
| 17:17:20 | sean-k-mooney | and the extra_specs/image properties are so if you dont ahve a db dump | |
| 17:17:23 | JayF | the only fields I have strong feelings about are any-flavor-identifier-at-all and the project information | |
| 17:17:29 | sean-k-mooney | you can just look at the xml and know everything about it | |
| 17:17:30 | JayF | the rest of them are things that are situationally useful | |
| 17:18:00 | JayF | almost all of those metadata fields in the libvirt driver, I was able to think of a time troubleshooting when that in node.instance_info would've been useful :) | |
| 17:18:19 | sean-k-mooney | JayF: related question | |
| 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 | |