Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-09-01
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
15:50:46 bauzas we're also creating a dependency to the virt drivers and unfortunately, Hyper-V, VMWare and Ironic could be impacted if we merge
15:51:43 bauzas lastly, I have concnerns about ensuring that the userdata API query is tied to the successfulness of the configdrive regen op
15:51:58 bauzas which would require the API call to be synchronous on a configdrive regen
15:52:21 bauzas so, my question is
15:52:31 bauzas do you really care of configdrives?
15:53:08 dansmith bauzas: we can't make the api call synchronous for config drive regen
15:53:23 dansmith that could take a long time, be dependent on the IO load on the compute, etc
15:53:25 sean-k-mooney i dont think that was an option
15:53:27 bauzas sean-k-mooney: I think it would be fair to say that this feature wouldn't be available to the other drivers while apparently they already support configdrive regen
15:53:40 bauzas eek, not regen, but creation
15:53:46 sean-k-mooney bauzas: yes that is correct
15:53:58 bauzas dansmith: right, I was pointing out loudly the problem
15:54:15 dansmith ah okay
15:54:16 bauzas this is a design problem
15:54:27 bauzas configdrives take time to regenerate
15:54:38 bauzas on the other hand, users have an API for updating userdata
15:55:02 bauzas they just assume they just have to restart their guests in order to have the latest update
15:55:21 jhartkopf bauzas: Initially we did not even want to touch config drives at all. We'd only like to update user data in the metadata service really.
15:55:32 bauzas I know
15:55:32 sean-k-mooney right but the api prevents you updating the user data if the instance has a conf driver outside of hard_reboot
15:55:34 stephenfin gibi: Sorry for the delay. I'd run through most of those PCI patches yesterday but didn't leave reviews until I got to the end of the series. Done now (y)
15:55:52 gibi stephenfin: much appreciated. I will look
15:55:56 stephenfin I went as far as sean-k-mooney did. Could go further but I see -1's from you
15:56:32 gibi stephenfin: yes, I left them -1 there as there is a bug in the scheduling part
15:56:45 gibi stephenfin: I think it is totally OK to merge it up until https://review.opendev.org/c/openstack/nova/+/850468/20
15:57:11 jhartkopf What's up with the plan you guys proposed yesterday to split the patch and only allow updating instances without config drive for now?

Earlier   Later