| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-12-12 | |||
| 16:55:42 | bauzas | JayF: 'sup ? | |
| 16:55:48 | JayF | I am unsure if John will be here, but I am. | |
| 16:55:49 | bauzas | https://blueprints.launchpad.net/nova/+spec/ironic-guest-metadata | |
| 16:55:53 | bauzas | shot | |
| 16:55:57 | bauzas | shoot* even | |
| 16:56:44 | sean-k-mooney | reading it quickly it looks reasonable but i would use flavor uuid instead of name or both | |
| 16:56:59 | bauzas | ditto here | |
| 16:57:00 | JayF | Essentially, libvirt instances get a large amount of useful metadata that Ironic would like to get as well for various uses -- the primary case that drove us to this was implementing Ironic's "automatic_lessee" support, allowing Ironic to use the project that provisioned an instance some RBAC access to it | |
| 16:57:30 | JayF | but generally many of those metadata items map to previous feature requests / things that operators have asked for in node instance_info for troubleshooting in the past (like flavor) | |
| 16:57:33 | bauzas | I only care about the upgrade path | |
| 16:57:36 | JayF | so it seemed like a good fit/easy win | |
| 16:57:37 | sean-k-mooney | so i guess my request woudl be can we update the decription with the full list of things we want to be set | |
| 16:58:04 | bauzas | would we need some interim period to ensure all computes report that metadata ? | |
| 16:58:22 | JayF | Essentially this is just additional metadata you'd set on deploy | |
| 16:58:28 | JayF | it'd be Ironic's job to do the right thing if it's set/not set | |
| 16:58:30 | sean-k-mooney | so this is settign metadta on the ironic nodes right | |
| 16:58:32 | sean-k-mooney | not the compute nodes | |
| 16:58:34 | JayF | from a Nova standpoint, it should be 100% backwards compatible | |
| 16:58:41 | sean-k-mooney | as in when an instnace is shcudled ot a node | |
| 16:58:52 | sean-k-mooney | so for upgrade i guess we coudl have a nova-manage command | |
| 16:58:57 | sean-k-mooney | to set it for existing instnces | |
| 16:59:02 | JayF | oh, you mean for backfilling instance metadata, I understand | |
| 16:59:08 | sean-k-mooney | yep | |
| 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 | |