| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-08-30 | |||
| 20:12:26 | dansmith | has anyone other than the author tried this on a real devstack? with configdrive? | |
| 20:12:50 | sean-k-mooney[m] | no i was going to see if i could do that tonight but i might just do that torrow at this point | |
| 20:12:57 | dansmith | also, in my defense, gibi *did* ask me to review this :) | |
| 20:13:30 | dansmith | and I *did* try to punt to melwitt | |
| 20:13:46 | dansmith | and melwitt *did* sabotage her irc client so she "didn't see that" | |
| 20:13:52 | sean-k-mooney[m] | i was going to see if i could create a tempest test for this althogh im not sure how to force the vm too boot on the un upgraded node for grenade | |
| 20:14:12 | dansmith | yeah you can't really, so you have to boot two and hit both I think | |
| 20:14:29 | dansmith | but at least it would non-deterministically fail | |
| 20:14:32 | sean-k-mooney[m] | oh with the anti affintiy filter | |
| 20:15:09 | dansmith | melwitt: are you caught up yet, enough to grok that ^ plan? | |
| 20:16:12 | melwitt | dansmith: yeah I think so | |
| 20:16:30 | dansmith | and what say ye? | |
| 20:17:21 | melwitt | the plan sounds like a good compromise | |
| 20:18:44 | sean-k-mooney[m] | we can likely sync with the autour tomrrow but i can set this up and test it tomorrow in anycase and perhaps look at more testing | |
| 20:19:08 | sean-k-mooney[m] | so see if we can harden this and unblock bfv | |
| 20:20:05 | dansmith | I just un-1'd it with a writeup | |
| 20:20:24 | dansmith | sean-k-mooney[m]: are you saying that because you want to test it before it merges, given it has no real testing now? | |
| 20:20:33 | dansmith | or because you expect some change to this again? | |
| 20:21:10 | sean-k-mooney[m] | they were going to work on a followup patch to adress some nits | |
| 20:21:24 | sean-k-mooney[m] | and i want to test it and figure out what else they should add tests for in that | |
| 20:21:46 | dansmith | okay but we told them to do those as a follow-up right? | |
| 20:21:56 | sean-k-mooney[m] | yep | |
| 20:22:35 | dansmith | okay, well, tomorrow our runway is even shorter | |
| 20:22:40 | dansmith | so hopefully you can do that in the morning :) | |
| 20:23:06 | melwitt | sean-k-mooney[m]: something I was confused on was whether the admin password (if there is one) would be preserved across a configdrive recreate. it seemed like yes? based on userdata update during rebuild impl, but I couldn't find definitively how that works | |
| 20:23:20 | dansmith | I guess I thought you all were more confident in this with all the +2s it had | |
| 20:24:16 | sean-k-mooney[m] | i was priortising it more then i would otherwise becuase of the bfv series on top | |
| 20:25:37 | dansmith | yeah the ordering was unfortunate | |
| 20:26:05 | sean-k-mooney[m] | i should have reviewed it more closly sorry. thanks for reviewing though even if the timing is not idea its better to get this right | |
| 20:27:24 | dansmith | yep, so maybe if you test in the morning and +W it we can get the others in the queue and I'll start on the proper RPC stuff based on my pastebin above when I'm around | |
| 21:23:35 | opendevreview | Rajat Dhasmana proposed openstack/python-novaclient master: Add support to rebuild boot volume https://review.opendev.org/c/openstack/python-novaclient/+/827163 | |
| 21:31:59 | opendevreview | Rajat Dhasmana proposed openstack/python-novaclient master: Add support to rebuild boot volume 2.94 https://review.opendev.org/c/openstack/python-novaclient/+/827163 | |
| 21:33:02 | whoami-rajat | ^ rebased on top of 2.93 to avoid conflicts later | |
| 21:34:47 | whoami-rajat | sean-k-mooney[m], jfyi, you've a -2 on client patch of 2.93 https://review.opendev.org/c/openstack/python-novaclient/+/816158 | |
| 21:41:37 | sean-k-mooney[m] | oh i didnt clear that after you spun | |
| 21:41:50 | sean-k-mooney[m] | i proably wont review that tonight but ill drop the -2 sorry about that | |
| 21:43:01 | sean-k-mooney[m] | oh thats the user data one | |
| 21:44:25 | whoami-rajat | yep, you already dropped the -2 from mine some time back but without the user data one, my change can't get in :) | |
| 21:48:05 | sean-k-mooney[m] | i ment to do that when the spec was approved | |
| 21:50:12 | sean-k-mooney[m] | there is no reason your bfv sereise would not work with the lvm driver right | |
| 21:50:53 | sean-k-mooney[m] | i have a devstack deploying to test the user_data update but forgot to enable ceph | |
| 21:51:16 | sean-k-mooney[m] | but i can pull in your changes after and test them if i get time after | |
| 23:14:34 | sean-k-mooney[m] | dansmith: https://termbin.com/6502 | |
| 23:15:27 | sean-k-mooney[m] | ill try ubuntu 20.04 in the morning but on c9s the regenreation fails | |
| 23:15:33 | dansmith | ugh | |
| 23:15:47 | dansmith | I was not expecting that kind of failure | |
| 23:16:01 | dansmith | seems if we get to the mkisofs part we should be as good as otherwise | |
| 23:16:12 | sean-k-mooney[m] | not when we are just calling an exsiting funciton | |
| 23:16:27 | dansmith | so the configdrive was created properly on instance boot but failed on regenerate? | |
| 23:17:17 | sean-k-mooney[m] | ya it might be because of the format | |
| 23:17:28 | sean-k-mooney[m] | this might be trying to update the iso | |
| 23:18:11 | dansmith | oh you mean code that works if the iso doesn't exist but fails if it already does? | |
| 23:18:13 | sean-k-mooney[m] | when we use vfat that is allow but for iso it need to delete and recreate the file | |
| 23:18:21 | dansmith | right | |
| 23:18:39 | dansmith | I guess I expected it to overwrite, but maybe that's why permission denied, because qemu owns it now? | |
| 23:18:39 | sean-k-mooney[m] | ya the previous iff unly ran that code if the file did not exist | |
| 23:18:43 | dansmith | yeah | |
| 23:18:51 | sean-k-mooney[m] | https://review.opendev.org/c/openstack/nova/+/816157/15/nova/virt/libvirt/driver.py#4950 | |
| 23:19:01 | dansmith | man, if this really doesn't work (with isofs) and nobody tested until now ... :P | |
| 23:19:17 | sean-k-mooney[m] | the reboot continues | |
| 23:19:25 | sean-k-mooney[m] | the error is logged and ignored | |
| 23:19:41 | sean-k-mooney[m] | so if you dont actuly look at the logs it looks like it worked form the api | |
| 23:19:58 | dansmith | yeah, but I hope that's not why it went unnoticed | |
| 23:20:11 | dansmith | this is also why a tempest test would be good... | |
| 23:20:46 | dansmith | early in the bfv rebuild, we were doing the same.. quietly not doing the rebuild, and I wrote a test that touches a file, then does the rebuild, and asserts that it's gone.. and that pointed out that we weren't actually doing it | |
| 23:22:40 | sean-k-mooney[m] | lookign at the vfat path i think i twould repoen the file and reformat it https://github.com/openstack/nova/blob/master/nova/virt/configdrive.py#L100 | |
| 23:23:32 | sean-k-mooney[m] | although im kind fo surrpised its failing like this for iso | |
| 23:23:32 | sean-k-mooney[m] | the upper fucntion https://github.com/openstack/nova/blob/master/nova/virt/configdrive.py#L137 | |
| 23:23:54 | dansmith | I gotta run in a minute | |
| 23:23:59 | sean-k-mooney[m] | oh never mind | |
| 23:23:59 | dansmith | I thought you were going to do this tomorrow? | |
| 23:24:03 | sean-k-mooney[m] | yep | |
| 23:24:30 | sean-k-mooney[m] | so the uper function creates a temp dir with teh metadata files and then turns that into an iso using the final pat as the output | |
| 23:24:42 | sean-k-mooney[m] | i tought it was going to do it in the temp dir and move it | |
| 23:25:01 | sean-k-mooney[m] | so ya if qemu has a lock on that file it will cause a permission denined | |
| 23:25:14 | dansmith | well, I think libvirt chowns it before boot doesn't it? | |
| 23:25:18 | dansmith | I was thinking ownership not lock | |
| 23:27:37 | sean-k-mooney[m] | the issue is this is happening at the wrong time | |
| 23:27:40 | sean-k-mooney[m] | the vm is still runing | |
| 23:27:48 | sean-k-mooney[m] | it need to happen when the vm is stopped | |
| 23:27:50 | dansmith | oh right, before the destroyed message | |
| 23:28:21 | dansmith | if this really needs that level of care, I'm going to recommend we swap the order of the bfv stuff | |
| 23:28:24 | sean-k-mooney[m] | right now its at the top of hard reboot https://review.opendev.org/c/openstack/nova/+/816157/15/nova/virt/libvirt/driver.py#3887 | |
| 23:28:48 | dansmith | yeah, before destroy | |
| 23:29:16 | sean-k-mooney[m] | ya so i dont object to swaping the order given the issues with the user data patch as is | |
| 23:29:34 | sean-k-mooney[m] | anyway time for me to go sleep o/ | |
| 23:29:43 | dansmith | I guess if we're about to destroy, it's not *as* bad that we write to it before, but we could be competing with writes from the guest in the vfat case | |
| 23:29:48 | dansmith | still, wrong as you note | |
| 23:29:57 | dansmith | ack, thanks for testing, g'nite | |
| 23:32:45 | sean-k-mooney[m] | by the way i tested the nova-client and osc change too which do work altough im going to ask for the osc change to take a user-data file instead of a sting or atleast have that as an option | |
| 23:32:53 | sean-k-mooney[m] | im pretty sure thats what we do on boot | |
| 23:33:45 | sean-k-mooney[m] | passing the bases64 encoded sting on the command line is annowing without doing $(echo "stuff" | base64) | |
| 23:34:31 | sean-k-mooney[m] | i guess thats less important if the nova part is broken | |
| 23:35:06 | dansmith | oh yeah, I hadn't even looked | |
| 23:35:11 | dansmith | passed as a CLI string makes no sense | |
| #openstack-nova - 2022-08-31 | |||
| 06:24:54 | opendevreview | Rajat Dhasmana proposed openstack/python-novaclient master: Add support to rebuild boot volume 2.94 https://review.opendev.org/c/openstack/python-novaclient/+/827163 | |
| 07:05:41 | bauzas | good morning Nova | |
| 07:22:43 | Uggla | good morning | |
| 07:44:10 | bauzas | mmm, I forgot to ask about your preferences for that *yet again* virtual PTG | |
| 07:44:24 | bauzas | I mean, how many slots we should book | |