| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-01 | |||
| 15:23:55 | dansmith | well, I like playing with guns, but maybe.. playing with fire? :) | |
| 15:24:00 | bauzas | if we try to update a configdrive and this doesn't work, then our user won't be happy at all | |
| 15:24:28 | bauzas | dansmith: what you prefer | |
| 15:24:32 | bauzas | or playing with teslas | |
| 15:25:06 | dansmith | as long as you mean "teslas, the unit of charge, meaning playing with dangerous high-voltage" .. then sure :D | |
| 15:25:15 | bauzas | point is, we need to only accept to update the userdata if the configdriver correctly regenerated | |
| 15:25:18 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L1060-L1092 | |
| 15:25:28 | sean-k-mooney | so ironci jsut tuns it into a string yes | |
| 15:25:48 | bauzas | dansmith: like "driving a tesla with a 10% battery for 100km" | |
| 15:25:55 | dansmith | oh I see | |
| 15:26:02 | dansmith | that *is* scary :) | |
| 15:26:10 | bauzas | this *may* work | |
| 15:26:19 | bauzas | but before driving, you need to ensure you can do it | |
| 15:26:34 | bauzas | the same goes with configdrives | |
| 15:26:50 | sean-k-mooney | and they pass it in spawn and rebuild https://github.com/openstack/nova/blob/bcdf5988f6ae902dba9b41144a7b4a60688b627c/nova/virt/ironic/driver.py#L1189-L1191 | |
| 15:26:54 | bauzas | you only accept the userdata to be updated once you're sure your configdrive is correctly regenerated | |
| 15:27:12 | dansmith | so the feeling I'm getting here is that there are a lot of open questions at this point | |
| 15:27:19 | bauzas | since the user doesn't have an idea whether the userdata is updated and only relies on the fact he/she restarted the instance | |
| 15:27:32 | sean-k-mooney | bauzas: well that is already a problem today | |
| 15:27:40 | dansmith | sean-k-mooney: no it's not | |
| 15:27:45 | bauzas | today the userdata is immutable | |
| 15:27:53 | dansmith | sean-k-mooney: if you can only provide userdata during create, it's clear what userdata the instance sees | |
| 15:28:03 | bauzas | that reminds me the discussions we had when reviewing server groups /PUT | |
| 15:28:06 | sean-k-mooney | it is the config drive is not updated today if you atach interface or volumes or update the server metadta | |
| 15:28:10 | sean-k-mooney | the user data is not statble | |
| 15:28:16 | sean-k-mooney | btu in general the config drive can be | |
| 15:28:34 | dansmith | configdrive != userdata | |
| 15:28:43 | sean-k-mooney | yep that is my point | |
| 15:28:51 | sean-k-mooney | the config drive can be stale today the user data is not | |
| 15:29:00 | sean-k-mooney | but that is only because its imutable | |
| 15:29:08 | dansmith | right | |
| 15:29:12 | dansmith | not ideal, but also not ambiguous | |
| 15:29:15 | dansmith | which is bauzas' point I think | |
| 15:29:18 | bauzas | yup | |
| 15:29:31 | bauzas | since it's immutable, this isn't a problem | |
| 15:29:36 | sean-k-mooney | sure but its expected that the user data script will likely depend on the other datta in the config drive | |
| 15:29:57 | sean-k-mooney | specificly the device role taggin info | |
| 15:29:59 | opendevreview | Dan Smith proposed openstack/nova master: WIP: Add recreate_configdrive to reboot https://review.opendev.org/c/openstack/nova/+/855529 | |
| 15:30:12 | dansmith | sean-k-mooney: here's the rpc stuff ^ passing tests, not wired into anything else | |
| 15:30:20 | dansmith | just so it's available | |
| 15:30:30 | sean-k-mooney | dansmith: but to your point it does sound like there is enough stuff that we wont have this mergable even with an FFE | |
| 15:30:32 | dansmith | needs more test coverage and an assert on soft I think | |
| 15:33:04 | bauzas | sean-k-mooney: my personal opinion is that the more I review this API change, the more I think I discover points we missed | |
| 15:33:10 | bauzas | hence my concern | |
| 15:33:15 | dansmith | so I should probably rebase that on your regen configdrive patch and I guess I can rebase the api bit on top of that and trivially wire it up | |
| 15:33:59 | bauzas | the configdrive regeneration is already a concern (making sure we validate it synchronously with the userdata update) | |
| 15:34:13 | bauzas | the fact that we leave other virt drivers in the weeds is another concern | |
| 15:34:21 | bauzas | both weren't discussed at the PTG | |
| 15:34:46 | dansmith | so on that, | |
| 15:34:53 | bauzas | and when I reviewed the spec, I was letting enough comments explaining how I was thinking the reboot solution was fragile | |
| 15:34:59 | dansmith | are we really expecting anyone to update vmware or hyperv to do this? | |
| 15:35:05 | bauzas | reasonably not | |
| 15:35:10 | dansmith | ironic perhaps, but for the above patch, | |
| 15:35:19 | dansmith | I was looking at those other drivers and wondering when they were last touched | |
| 15:35:35 | bauzas | surely, but we haven't even asked them to look | |
| 15:35:53 | dansmith | okay I guess we've had changes in 2022 for vmware | |
| 15:35:58 | dansmith | so maybe doable | |
| 15:36:31 | dansmith | not much for hyperv though | |
| 15:37:18 | dansmith | so I don't see any configdrive stuff in hyperv at first glance | |
| 15:37:48 | bauzas | fair enough, but then question | |
| 15:37:54 | bauzas | I'm an user | |
| 15:38:09 | bauzas | I wanna update my pet's userdata | |
| 15:38:13 | bauzas | I do it | |
| 15:38:33 | bauzas | and then I don't understand, my f*** script doesn't run as expected when I restart the guest | |
| 15:38:44 | bauzas | shall I open a ticket ? | |
| 15:39:08 | dansmith | oh it's in hyperv, just in vmops.py | |
| 15:39:24 | bauzas | oh, simple, your cloud was running some driver on that host that was having trouble with updating the configdrive | |
| 15:39:35 | bauzas | either because it was a legacy driver | |
| 15:39:44 | bauzas | or because something (like a perm error) expected | |
| 15:40:10 | bauzas | honestly, this spec was just about touching an internal Nova DB record | |
| 15:40:21 | bauzas | now, we're pulling way more than that | |
| 15:40:47 | dansmith | yeah, it's becoming more about configdrive than anything else | |
| 15:41:27 | sean-k-mooney | bauzas: in two converstaion but form my persepcitve i dont think we really have discoverd anythign bar the rpc change. i reveiw the spec with the understandin it was scoped to libvirt | |
| 15:42:44 | bauzas | yet again, can't we just assume to update instance's metadata only if not configdrive-driven, and leave people who care about configdrives deal with the complexity one day or another? | |
| 15:42:45 | dansmith | I dunno, I can see the argument for this being scoped to just one driver, but for something this fundamental it seems pretty unfortunate to say it's only for libvirt | |
| 15:43:10 | bauzas | I'm pretty sure we wouldn't have this back-to-back | |
| 15:44:31 | dansmith | so we reject the api call if configdrive=True always? | |
| 15:44:57 | bauzas | that's my question | |
| 15:45:10 | dansmith | doesn't that get closer to your concern on the spec that people think they have updated their instance but didn't reboot it and don't realize that cloud-init doesn't update their stuff? | |
| 15:45:29 | dansmith | I mean, that's just a misunderstanding of cloud-init, but I thought that was your concern | |
| 15:45:36 | dansmith | anyway, I dunno | |
| 15:45:37 | bauzas | if the update failed, they know the instance userdata wasn't updated | |
| 15:46:53 | bauzas | they would know this was because configdriver if they asked by boot params | |
| 15:47:15 | bauzas | but they wouldn't know if the clould defaulted to force configdrives or if the image was asking for it | |
| 15:47:22 | dansmith | right, it's not always their choice | |
| 15:47:45 | bauzas | anyway, I'm just offering a trade-off because I'm not really happy with the current state of the series | |
| 15:48:22 | bauzas | also, is the owner of the patch around ? | |
| 15:48:29 | bauzas | or are we offering our help for free ? | |
| 15:48:47 | dansmith | who is asking for this btw? | |
| 15:48:59 | dansmith | aside from the author | |
| 15:49:02 | bauzas | a private clould company | |
| 15:49:06 | bauzas | Inovex | |
| 15:49:07 | jhartkopf | I'm here | |
| 15:49:17 | bauzas | cool, glad to hear you jhartkopf | |
| 15:49:24 | bauzas | jhartkopf: lemme summarize | |
| 15:49:25 | dansmith | jhartkopf: do you care about the configdrive case? | |
| 15:49:37 | bauzas | we're having a problem with https://review.opendev.org/c/openstack/nova/+/816157/16 | |
| 15:49:45 | bauzas | and we don't know how to move forward | |
| 15:50:02 | jhartkopf | yep I quickly read your discussion | |
| 15:50:03 | bauzas | there is a proposed solution, but this is premature work and we're very late in the cycle | |