| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-08-30 | |||
| 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 | |
| 07:44:55 | bauzas | I'm about to book 4 x 4 slots (Tues-Fri) but I'll cancel some if we agree | |
| 07:49:25 | bauzas | just done, see the scheduled tracks https://ptg.opendev.org/ptg.html | |
| 07:49:30 | bauzas | I can unbook the slots | |
| 07:50:34 | gibi | morning | |
| 07:50:40 | gibi | bauzas: 4x4 works for me | |
| 07:50:58 | gibi | sean-k-mooney: thanks for testing the user data out. | |
| 07:51:05 | bauzas | gibi: we'll see how much we need once we have an agenda | |
| 07:51:14 | gibi | bauzas: sure | |
| 07:51:59 | gibi | sean-k-mooney, dansmith: in the light of the actual regeneration issue I agree to punt the user_data and land rebuild bfv first | |
| 07:52:47 | sean-k-mooney[m] | im locally trying to fix the patch by the way as a followup patch | |
| 08:03:32 | sean-k-mooney[m] | ok what i was trying wont work but i know what to do instead so trying that now | |
| 08:34:34 | hkominos | Hi guys. Quick question. When overriding policies for nova, Should one redefine the whole policy.json file or Can I just define the single policy that I want to override?My current policy file is empty {} | |
| 08:37:03 | bauzas | hkominos: no, you should just update what you need* | |
| 08:37:19 | gibi | hkominos: you only need to add to the file that you want to override | |
| 08:37:32 | gibi | bauzas: you won :) | |
| 08:37:37 | bauzas | \o/ | |
| 08:40:30 | hkominos | thanks you guys ! | |
| 08:40:58 | bauzas | gmann: good spot for the WIP status on my election patch | |
| 08:41:31 | bauzas | gmann: that's because I flagged the WIP status directly in Gerrit when I created the PS1 in Aug | |
| 08:41:45 | bauzas | now the patch is in active state | |
| 09:00:39 | sean-k-mooney[m] | gibi: this is such a can of worms | |
| 09:01:40 | sean-k-mooney[m] | i think to make this work we need to delete the old config drive first but that means we neeed to deal with all the image backends seperately since they dont have a rm() function | |
| 09:02:48 | bauzas | sean-k-mooney: a tl:dr about the problem ? | |
| 09:02:50 | sean-k-mooney[m] | i can add one but i was hoping this would be simple and then i rememebred this should also work for lvm and rbd so i cant just delete the file | |
| 09:03:22 | sean-k-mooney[m] | bauzas: the user data update feature is trying to rebuild the config deive on hard reboot if you updated the user data | |
| 09:03:30 | sean-k-mooney[m] | btu that fails with a permission denied\ | |
| 09:03:53 | sean-k-mooney[m] | i belive that is because the disk is owned by qemu | |
| 09:04:47 | sean-k-mooney[m] | so nova cant updated it and this need to work for rbd and lvm anyway so i cant really just assume its a file on disk and chown it | |
| 09:05:16 | sean-k-mooney[m] | the user_data feature is blocking the BFV rebuild feature because of the micorversion order | |
| 09:05:35 | sean-k-mooney[m] | so i was trying to unblock that but we are just going to have to change the order | |
| 09:06:21 | sean-k-mooney[m] | make BFV rebuild 2.93 and likely punt mutable user_data to AA | |
| 09:06:53 | sean-k-mooney[m] | there are other issue with rpc/testing in the userdata patch that likely wont get adressed without a FFE | |
| 09:07:17 | bauzas | agreed on flipping the microversions | |
| 09:07:33 | bauzas | at least for not blocking bfv rebuild | |
| 09:07:46 | gibi | sean-k-mooney[m]: do we store the config drive in lvm / rbd? I thought it is always a file on disk | |
| 09:08:03 | gibi | but agree if this is complicate then punt it | |
| 09:08:07 | bauzas | for userdata, we can't just tell "sorry you can't update your data because config drive" as this is a config-driven API behaviour | |
| 09:08:40 | bauzas | could we have a separate flag that would say "I allow you to update your userdata" and leave the responsibility to the ops to enable it ? | |
| 09:08:51 | kashyap | gibi: I think it's a file on the disk, too, the config-drive | |
| 09:08:54 | bauzas | with a caveat saying there could be perm issues with configdrive | |
| 09:09:05 | sean-k-mooney[m] | gibi: good question i belvie we do looking at the code but ill check. i know swap gets created on rbd | |
| 09:09:17 | sean-k-mooney[m] | and this appears to be using the generic imagebackend code | |
| 09:09:21 | sean-k-mooney[m] | but ill confimr again | |
| 09:10:32 | sean-k-mooney[m] | bauzas i dont think we should hack around this | |
| 09:10:54 | sean-k-mooney[m] | the feature is broken currently if you use config deive and i think its important that works | |
| 09:11:04 | sean-k-mooney[m] | espcially since we added a stadard trait for this | |
| 09:11:23 | bauzas | that's my point | |
| 09:11:28 | sean-k-mooney[m] | we could simple not report that for the libvirt driver i guess | |
| 09:11:47 | bauzas | in theory, we could only allow to update userdate if configdriver isn't in use | |
| 09:11:52 | bauzas | userdata* | |
| 09:11:52 | sean-k-mooney[m] | so in this cycle no driver would report it so you could only use this if you did not have config drive | |
| 09:12:12 | sean-k-mooney[m] | bauzas: that works today i think | |
| 09:12:13 | bauzas | but I don't wanna leak a config-driven behaviour | |
| 09:12:23 | sean-k-mooney[m] | it would not be config driven behavior | |
| 09:12:24 | bauzas | sean-k-mooney: then this is documentation | |
| 09:12:35 | sean-k-mooney[m] | we just set the compute capablity trait to false for libvirt | |
| 09:12:52 | sean-k-mooney[m] | and then when config drive works we set it to true | |
| 09:13:33 | sean-k-mooney[m] | bauzas: either way im not sure its reasonable of use to ask whoami-rajat to wait any longer given the state of the user data patch | |
| 09:13:46 | bauzas | agreed again | |
| 09:13:57 | bauzas | we should ask to flip the microversions | |
| 09:15:42 | sean-k-mooney[m] | so flip microversion and split user data patch in two. setting the capablity trait to false in all drivers in the first one and the second patch and then implemnte the config drive rebuild adn rpc change | |
| 09:16:17 | sean-k-mooney[m] | ahtough that still feels a bit wrong | |
| 09:16:18 | bauzas | rpc change becaaaaause ? | |
| 09:17:00 | sean-k-mooney[m] | because currently it uses a dirty flag in the instance system metadata to say the config drive need to be rebuilt | |
| 09:17:37 | sean-k-mooney[m] | and dansmith made a very valid point tha tthat a shadow rpc interface and we should have added that as a parmater to the reboot rpc call | |
| 09:17:54 | sean-k-mooney[m] | so that was already requested as a followup | |
| 09:17:59 | gibi | I'm OK to only allow user data update for non config drive instances in Zed. That is a good enough compromise. Also config drive is just half config drive, as it can also be requested via the API | |
| 09:18:18 | gibi | *config drive is just half config driven | |
| 09:18:43 | sean-k-mooney[m] | yes it can thats how i was testing | |
| 09:19:05 | sean-k-mooney[m] | it can be forced via nova.conf but its user requestable as you said | |
| 09:19:59 | gibi | as a side note I found a bug in the allocation candidate filtering in the PCI series. | |
| 09:20:14 | gibi | so I think what is realistic there is to land the healing part | |
| 09:20:16 | gibi | up until https://review.opendev.org/c/openstack/nova/+/850468/20 | |
| 09:20:50 | gibi | stephenfin: Sean is +2 til ^^ so if you have time :) | |
| 09:21:08 | sean-k-mooney[m] | yes that was the partion i tought made sense if we did not land it all | |
| 09:21:30 | stephenfin | okay | |
| 09:21:41 | sean-k-mooney[m] | thats everything except the schduler part | |
| 09:21:43 | gibi | also in the light of the recent shadow RPC discussion I feel that storing data in InstancePCIRequest.extra_info is also shadowy in my series | |
| 09:22:07 | gibi | sean-k-mooney[m]: yepp, that already gives visibility of the PCI resource inventories in placement which is good to have | |
| 09:22:29 | sean-k-mooney[m] | it would have been nice to have the split pools by PF change | |
| 09:22:42 | gibi | we could land that, that is not effected by the bug | |
| 09:23:02 | sean-k-mooney[m] | that would be nice since it gives preference to PFs without VFs when you ask for a PF | |
| 09:23:03 | gibi | it does not do any externally visible change\ | |
| 09:23:22 | gibi | I'm not sure it is a real preference or just an ordering change | |
| 09:23:29 | gibi | I have to look if we sort the pool | |
| 09:23:52 | sean-k-mooney[m] | i always tought the way we allocated was more or less deterministic | |
| 09:24:23 | sean-k-mooney[m] | at least it has been stable enough for use to use in the functional tests without intermient failures | |
| 09:24:31 | gibi | it is stable | |
| 09:24:44 | gibi | but it might be not stable do to sorting | |