| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-12-12 | |||
| 17:03:20 | sean-k-mooney | but this feels like the volume refesh commands to me | |
| 17:03:32 | sean-k-mooney | bauzas: it already can talk to ironci | |
| 17:03:33 | JayF | so while I'm happy to implement it, and I'm sure someone would find a use for it, I don't think it's in the primary path for enabling the sorta features we want | |
| 17:03:56 | sean-k-mooney | so i dont really mind where it ends up i guess but i think it woudl be nice to have | |
| 17:03:59 | bauzas | sean-k-mooney: creds and all the likes are set on nova.conf that nova-manage reads ? | |
| 17:04:30 | JayF | bauzas: you already have creds on nova-computes to do the calls you need | |
| 17:04:43 | JayF | PATCH calls to /v1/node/{UUID} | |
| 17:04:50 | bauzas | JayF: nova-manage isn't meant to be run on nova computes | |
| 17:04:55 | JayF | ack | |
| 17:05:15 | sean-k-mooney | bauzas: well its normally run on the contoler which often by acidnet is where nova-compute with ironic runs | |
| 17:05:20 | bauzas | despite we shipped that sail with the volume attach command :) | |
| 17:05:23 | sean-k-mooney | but we cant assume it will be colocated | |
| 17:06:03 | bauzas | did I say " we shipped that sail" ? oh gosh, I'm tired | |
| 17:06:21 | bauzas | anyway | |
| 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 | bauzas | time is flying tho and we're *again* late | |
| 17:07:09 | JayF | I like the idea of Ironic owning the migratino script | |
| 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 | sean-k-mooney | but if other are ok im not going to say we must have one | |
| 17:08:30 | JayF | I'd say lets revisit | |
| 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 | bauzas | and we could revisit it next week | |
| 17:08:59 | JayF | thank you | |
| 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 | bauzas | thanks all | |
| 17:09:24 | sean-k-mooney | o/ | |
| 17:09:30 | bauzas | and sorry again | |
| 17:09:32 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-12-12-16.01.log.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 | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-12-12-16.01.html | |
| 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 | bauzas | #endmeeting | |
| 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 | |