| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-12-12 | |||
| 16:59:10 | JayF | that's a case I hadn't even consideredd! | |
| 16:59:28 | sean-k-mooney | so i assume this would normally only be set on spawn | |
| 16:59:37 | sean-k-mooney | since ironci dose not support resize | |
| 16:59:45 | sean-k-mooney | well spawn or rebuild/evacuate | |
| 17:00:02 | JayF | Alright, looks like I have two actions: 1) List all the specific fields and 2) add details about migration path for preexisting instances and how/if they get metadata | |
| 17:00:08 | JayF | sean-k-mooney: we do rebuild, very common use case | |
| 17:00:19 | sean-k-mooney | ya so we would want to update it on rebuild right | |
| 17:00:33 | sean-k-mooney | so 3 actions. list the data to set, list when it will be set | |
| 17:00:39 | bauzas | sounds then an implementation detail to me | |
| 17:00:44 | sean-k-mooney | and then if we want to have a nova-manage command to backfile then detail that too | |
| 17:00:50 | JayF | yeah but one I don't mind enumerated in the blueprint to ensure I don't miss it | |
| 17:01:27 | bauzas | nova-manage what ? fill my ironic stuff for that instance ? | |
| 17:02:05 | sean-k-mooney | bauzas: ya set the metadtaa on the corresponding ironc node for an existing instance | |
| 17:02:19 | bauzas | couldn't it be some ironic script that would gather the details from the nova API ? | |
| 17:02:23 | sean-k-mooney | that shoudl be pretty simple to do its just a ironic api call | |
| 17:02:40 | sean-k-mooney | it could btu that feels liek a worse soultion to me | |
| 17:02:49 | JayF | So I'll note | |
| 17:02:52 | bauzas | sean-k-mooney: I'm not 100% happy with a very specific virt driver method in our nova-manage command | |
| 17:03:00 | JayF | From an Ironic standpoint, having the data backfilled is not super awesome | |
| 17:03:07 | sean-k-mooney | im pretty sure it woould not be the first | |
| 17:03:09 | JayF | we aren't going to do much with it | |
| 17:03:12 | bauzas | this would require nova-manage to be able to speak the ironic language | |
| 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 | |