| opendevreview | melanie witt proposed openstack/nova-specs master: Re-propose specs for ephemeral encryption https://review.opendev.org/c/openstack/nova-specs/+/907654 | 01:33 |
|---|---|---|
| opendevreview | melanie witt proposed openstack/nova-specs master: Re-propose specs for ephemeral encryption https://review.opendev.org/c/openstack/nova-specs/+/907654 | 03:02 |
| opendevreview | melanie witt proposed openstack/nova-specs master: Re-propose specs for ephemeral encryption https://review.opendev.org/c/openstack/nova-specs/+/907654 | 03:32 |
| *** mklejn_ is now known as mklejn | 07:56 | |
| opendevreview | Sylvain Bauza proposed openstack/nova master: libvirt: Cap with max_instances GPU types https://review.opendev.org/c/openstack/nova/+/899625 | 10:48 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: vgpu: Allow device_addresses to not be set https://review.opendev.org/c/openstack/nova/+/902084 | 10:48 |
| ratailor | sean-k-mooney[m], gibi dtantsur could you please review https://review.opendev.org/c/openstack/openstacksdk/+/904490 and https://review.opendev.org/c/openstack/python-openstackclient/+/904569 | 13:42 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Restore original AZ when unshelve fails https://review.opendev.org/c/openstack/nova/+/911108 | 14:22 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Add a functest for verifying multiple VGPU allocations https://review.opendev.org/c/openstack/nova/+/845747 | 15:15 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Support multiple allocations for vGPUs https://review.opendev.org/c/openstack/nova/+/845757 | 15:15 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: document how to ask for more a single vGPU https://review.opendev.org/c/openstack/nova/+/906151 | 15:15 |
| elodilles | nova release liaisons, fyi: https://review.opendev.org/c/openstack/releases/+/910940 | 15:56 |
| bauzas | yup I know | 15:59 |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Mar 5 16:00:53 2024 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:01 |
| bauzas | heya everyone | 16:01 |
| fwiesel | \o | 16:01 |
| bauzas | who's around ? | 16:01 |
| Uggla | o/ | 16:02 |
| gibi | o/ | 16:03 |
| elodilles | o/ | 16:03 |
| bauzas | maybe we should skip if we don't have quorum | 16:03 |
| auniyal | o/ | 16:03 |
| bauzas | okay, let's try then to have a quick meeting | 16:04 |
| bauzas | #topic Bugs (stuck/critical) | 16:04 |
| bauzas | #info No Critical bug | 16:04 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 75 new untriaged bugs (+5 since the last meeting) | 16:04 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:04 |
| bauzas | #info bug baton is bauzas | 16:04 |
| bauzas | it's my duty, I'll look this week at the bugs because of RC1 | 16:04 |
| bauzas | moving on ? | 16:05 |
| bauzas | looks so | 16:06 |
| bauzas | #topic Gate status | 16:07 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:07 |
| bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:07 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | 16:07 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:07 |
| bauzas | anything to report ? | 16:08 |
| sean-k-mooney | there were some post job hook failures | 16:10 |
| sean-k-mooney | im just looking at them now but not sure there is a pattern | 16:10 |
| sean-k-mooney | have others seen issues with post failtures | 16:10 |
| sean-k-mooney | i saw echo 'Creating ephemeral test server on subnode' fail in two diffent test befauce we didnt get a list of flavors | 16:11 |
| sean-k-mooney | HttpException: 500: Server Error for url: https://158.69.64.59/compute/v2.1/flavors/detail?is_public=True, Internal Server Error | 16:11 |
| bauzas | yeah I did a couple of rechecks | 16:11 |
| bauzas | the ones I saw were for ceph-live-migration | 16:12 |
| sean-k-mooney | ok i guess we can see if that continues | 16:12 |
| sean-k-mooney | the ones i was looking at just now were in nova-live-migration nova-next and nova-ovs-hybrid-plug | 16:13 |
| bauzas | ack | 16:13 |
| bauzas | moving on then | 16:13 |
| sean-k-mooney | oh POST_FAILURE in 19m 30s | 16:13 |
| sean-k-mooney | so they failed on something else because that way to fast for a devstack job to be in post | 16:13 |
| sean-k-mooney | so the post playbooks are failign becuase we didnt install perperly is my guess | 16:14 |
| sean-k-mooney | we can move on | 16:15 |
| bauzas | sure | 16:15 |
| bauzas | #topic Release Planning | 16:16 |
| bauzas | #link https://releases.openstack.org/caracal/schedule.html#nova | 16:16 |
| bauzas | #info Caracal-3 (and feature freeze) delivered | 16:16 |
| bauzas | #info RC1 in 1.5 weekqs | 16:16 |
| bauzas | that's basically itr | 16:16 |
| bauzas | we'll have a caracal retro in the next PTG | 16:16 |
| bauzas | anything else ? | 16:17 |
| bauzas | #topic Review priorities | 16:18 |
| bauzas | #link https://etherpad.opendev.org/p/nova-caracal-status | 16:18 |
| bauzas | I amended the etherpad | 16:18 |
| bauzas | for this week and the next one, please look at the bugfixes | 16:18 |
| bauzas | I'll prepare a specific etherpad for RC1 | 16:18 |
| bauzas | any questions ? | 16:19 |
| bauzas | ok, moving on | 16:20 |
| bauzas | #topic Stable Branches | 16:20 |
| bauzas | elodilles: floor is yours | 16:20 |
| elodilles | #info stable gates seem to be OK | 16:20 |
| elodilles | stable/2023.2, stable/2023.1 and stable/zed respectively | 16:21 |
| elodilles | xena, wallaby and victoria will go to unmaintained in #minutes :) | 16:21 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:21 |
| elodilles | that's all i think | 16:22 |
| bauzas | elodilles: and as I said, I'll look at the paperwork :) | 16:22 |
| elodilles | bauzas: ACK, thanks in advance :] | 16:22 |
| bauzas | ok, moving on | 16:24 |
| opendevreview | sean mooney proposed openstack/nova master: add pyproject.toml to support pip 23.1 https://review.opendev.org/c/openstack/nova/+/899753 | 16:24 |
| bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | 16:25 |
| fwiesel | #info FIPS instablility caused by MAC learning issue, still debugging | 16:25 |
| bauzas | fwiesel: floor is yours :p | 16:25 |
| bauzas | fwiesel: ack | 16:25 |
| fwiesel | Digging down and learning things about OVS, but not much progress there to report | 16:25 |
| fwiesel | #info Proposed bug fixes https://review.opendev.org/c/openstack/nova/+/909474 and https://review.opendev.org/c/openstack/nova/+/910627 would bring tempest failures down to one | 16:25 |
| fwiesel | if you retry often enough, due to the MAC learning issue | 16:26 |
| fwiesel | #link http://openstack-ci-logs.global.cloud.sap/sapcc-nova-ib3088cfce4f7a0b24f05d45e7830b011c4a39f42-jf2kd/tempest.html | 16:26 |
| fwiesel | That's how it should look like then | 16:26 |
| bauzas | fwiesel: don't hesitate to ping me for reviews | 16:26 |
| fwiesel | Sure, I will. The first proposal is probably introducing a new bug, I have to dig into that first. | 16:27 |
| sean-k-mooney | fwiesel: thanks for posting the ci links in https://review.opendev.org/c/openstack/nova/+/910627 | 16:27 |
| fwiesel | Which brings us to the last one: | 16:27 |
| fwiesel | #info Outstanding failure likely not vmware specific: https://bugs.launchpad.net/nova/+bug/2055700. Rebuild + bfv + reimage-boot-volume: First driver.destroy, then driver.detach_volume (then driver.spawn) | 16:27 |
| sean-k-mooney | is VMware NSX CI the old ci acconut | 16:27 |
| fwiesel | sean-k-mooney: Yes, the VMware NSX CI is the old account from Vmware. | 16:28 |
| sean-k-mooney | ack do we have an eta for when your ci will start commenting | 16:28 |
| fwiesel | Well, I haven't prioritized it, as it is fairly instable. | 16:29 |
| sean-k-mooney | ack i guess we can look at http://openstack-ci-logs.global.cloud.sap/ | 16:29 |
| fwiesel | It would be probably just a days work to make it comment, but the output would be a bit random | 16:29 |
| sean-k-mooney | and seach by the change id | 16:29 |
| sean-k-mooney | fwiesel: basically instead of pinging you for the link on each patch i just want to find a way to look for the ci result | 16:30 |
| fwiesel | That should work. I have to check, if I haven't broken it. | 16:30 |
| sean-k-mooney | ack that will help us understand if the patches we are reviewing are fixing the probelmn and or breakign other things | 16:31 |
| fwiesel | Yes, but the CI is not yet stable for reasons outside of the patches. | 16:32 |
| sean-k-mooney | ack | 16:32 |
| bauzas | ack too | 16:32 |
| fwiesel | If you look at it the way that a test succeeds, then it really fixed, but if it fails, that it could be due to reasons not related to the patch, then it should be fine. | 16:33 |
| sean-k-mooney | yep we cant know if a fialure is infra related or not | 16:33 |
| sean-k-mooney | but if a previsoly broken functionlity passes we know ti appears to work | 16:33 |
| fwiesel | ack | 16:34 |
| fwiesel | Tomorrow, I'll make then sure that the index is still correctly updated. | 16:34 |
| fwiesel | That's from my side then. Any other questions? | 16:35 |
| fwiesel | back to you then, bauzas | 16:36 |
| bauzas | cool | 16:36 |
| bauzas | #topic Open discussion | 16:36 |
| bauzas | . | 16:36 |
| bauzas | anything else ? | 16:36 |
| sean-k-mooney | are we going to merge https://review.opendev.org/c/openstack/nova/+/902687 and the patch beloew | 16:37 |
| sean-k-mooney | you said you wanted to wait until after FF | 16:37 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/899753/11 for pyproject.toml supprot need a devstack patch so that can wait until D | 16:38 |
| sean-k-mooney | but shall we proceed with the addtion of supprot for wsgi module loading | 16:38 |
| bauzas | I'll look at those patches indeed | 16:39 |
| sean-k-mooney | cool that was all i wanted to raise | 16:39 |
| bauzas | and I'll move those in the etherpad to the bugfixes section | 16:39 |
| bauzas | anything else before we close ? | 16:40 |
| bauzas | looks not | 16:40 |
| bauzas | thanks all | 16:40 |
| bauzas | #endmeeting | 16:40 |
| opendevmeet | Meeting ended Tue Mar 5 16:40:34 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:40 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-03-05-16.00.html | 16:40 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-03-05-16.00.txt | 16:40 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-03-05-16.00.log.html | 16:40 |
| elodilles | thanks o/ | 16:40 |
| fwiesel | thanks | 16:40 |
| auniyal | sean-k-mooney, bauzas can you please have another look on these https://review.opendev.org/c/openstack/nova/+/891289 | 16:41 |
| sean-k-mooney | i was holding off on that because it was conflicting with the manila share and ephmeral encyption series | 16:42 |
| sean-k-mooney | it has both object and rpc bumps | 16:43 |
| sean-k-mooney | so we should wait until we reopen master for deveopment after RC1 | 16:43 |
| sean-k-mooney | the previous patch however https://review.opendev.org/c/openstack/nova/+/877446 could be reviewd | 16:44 |
| sean-k-mooney | thats a valid backportable bug fix so ill take a look but ill defer to bauzas wither we want to incldued it for rc1 | 16:44 |
| * bauzas clicks | 16:45 | |
| bauzas | sounds to me a bugfix | 16:45 |
| bauzas | so yeah looks a possible RC1 patch | 16:45 |
| sean-k-mooney | this is an enhancemnt based on feed back form gorka and other using the volume refrsh commands | 16:46 |
| sean-k-mooney | it adresses one of the issues they had when they actully tried to use it so its a nice addtion | 16:47 |
| bauzas | I don't see it in the etherpad | 16:47 |
| bauzas | so I'll add it | 16:47 |
| auniyal | sean-k-mooney, bauzas ack thanks | 16:48 |
| auniyal | bauzas, its there at the end, earlier I had added only the top one 891289, now added other one as well | 16:50 |
| sean-k-mooney | bauzas: stephenfin is +2 and i just reviewd it and my previous comments have been adressed so i approved https://review.opendev.org/c/openstack/nova/+/877446 | 16:51 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/891289/10 however need more care. we could include the change in RC1 but this is not backporatble | 16:52 |
| sean-k-mooney | so there is an agument to be made that we shoudl try and include it in the slurp release | 16:52 |
| dansmith | melwitt: sean-k-mooney trying to deploy the EE set locally and I get this: nova.exception.KeyManagerError: Key manager error: cannot store arbitrary keys | 16:55 |
| dansmith | from n-cpu | 16:55 |
| dansmith | I didn't apply the barbican policy changes from the jobs, which I think are just for admin access during unshelve | 16:55 |
| sean-k-mooney | you dont need the policy chnage | 16:55 |
| sean-k-mooney | but you do need to enable barbican in nova's config | 16:56 |
| sean-k-mooney | [key_manager] | 16:56 |
| sean-k-mooney | fixed_key = bae3516cc1c0eb18b05440eba8012a4a880a2ee04d584a9c1579445e675b12defdc716ec | 16:56 |
| sean-k-mooney | backend = barbican | 16:56 |
| sean-k-mooney | you do not need the fixed_key line | 16:56 |
| dansmith | ahh, okay that must be it | 16:56 |
| sean-k-mooney | just backend = barbican | 16:57 |
| dansmith | I was asking melwitt what all I needed from those jobs, and I thought it was just the devstack plugin for barbican | 16:57 |
| dansmith | that should probably go in either in the plugin or in lib/nova and not just be in the job def itself | 16:57 |
| sean-k-mooney | [[post-config|$NOVA_CONF]] | 16:57 |
| sean-k-mooney | [key_manager] | 16:57 |
| sean-k-mooney | backend = barbican | 16:57 |
| sean-k-mooney | i have that in my local.conf | 16:57 |
| dansmith | ack | 16:57 |
| sean-k-mooney | [[post-config|$NOVA_CPU_CONF]] woudl be more correct but both will work in this case | 16:58 |
| sean-k-mooney | https://termbin.com/i869 that my local.conf form my comptue althoug hi think i made some changes after the fact i.e. i checkout diffent nova banches and restarted the services | 17:00 |
| dansmith | I'm kinda wondering about the whole unshelve-by-admin thing and the required policy change | 17:01 |
| sean-k-mooney | i have a lot of stuff set in that local.conf since i used the one form the ci job as a base | 17:01 |
| sean-k-mooney | well admins proably should not be able to unshleve | 17:01 |
| dansmith | that seems like the kind of thing that security people would discourage, so I wonder if we can just block that case and say "the user has to do it" | 17:01 |
| dansmith | right exactly | 17:01 |
| sean-k-mooney | they cant as far as ia aware with cinder encypted volumes | 17:01 |
| dansmith | ++ | 17:01 |
| sean-k-mooney | right os melaniy was just checkign that it could work but not suggesting that we should do that | 17:02 |
| sean-k-mooney | i gave similar feedback before that i would prefer not to use custom policy for barbican in the final jobs | 17:02 |
| dansmith | there's existing plumbing to make it work, no? | 17:02 |
| sean-k-mooney | and just skip the admin tests that dont work | 17:02 |
| sean-k-mooney | mels code in nova would support the usecase if barbican's policy allowed it, if that is what you mean | 17:03 |
| dansmith | I haven't made it past the create patch, but IIRC there was stuff in there to support the admin case I thought | 17:03 |
| sean-k-mooney | only if you teak the policy | 17:03 |
| dansmith | right, but see what I'm saying is, maybe we should refuse it early at the api or conductor level and not fail only when we can't access the key | 17:04 |
| sean-k-mooney | it will only work for an admin otherwise if they own the vm | 17:04 |
| sean-k-mooney | ya thats a possibelity i was doing most of my testing as admin demo | 17:04 |
| sean-k-mooney | by the way did no know devstack generate a clouds.yaml with multipel diffent profiles/users | 17:05 |
| dansmith | I think, if we can tell from the api, a "409: Can't unshelve this encrypted instance" would be much nicer | 17:05 |
| dansmith | yes, that's how I get admin now, because that's the "proper way" AFAIK | 17:05 |
| sean-k-mooney | i dont think we can detect that | 17:05 |
| dansmith | we have the image properties in instance system meta right? if we haven't updated it with the encryption secret, we could/should right? | 17:06 |
| sean-k-mooney | yes but that not enough | 17:06 |
| sean-k-mooney | what we actully need to know is if barbican is using custom policy or not | 17:07 |
| sean-k-mooney | and we need to know that the admin that is making the request is doing so with a token that does not have access | 17:07 |
| dansmith | we can grab the secret uuid and see if we can show it, or we can say "you don't own this and its encrypted so I'm not even going to try" | 17:07 |
| sean-k-mooney | so really we would have to try and get the secret in the api | 17:07 |
| sean-k-mooney | and bail early if that fails | 17:07 |
| sean-k-mooney | ya | 17:07 |
| sean-k-mooney | so if your fine with doing a secret show or simialr in the api | 17:08 |
| sean-k-mooney | then we can rejct it early | 17:08 |
| dansmith | what I'm saying is, we should do that early and not fail deep in nova-compute once we have downloaded the image and discover we can't see the key | 17:08 |
| dansmith | it would be nice to do that from the api I think, and is similar to what we do with neutron ports and things, so I don't think it's a big deal | 17:08 |
| sean-k-mooney | yep thats fair | 17:08 |
| dansmith | especially since unshelve is a very infrequent operation compared to something like boot | 17:09 |
| sean-k-mooney | ya its simialr to the decorators we have for cybrog ectra to check api mivroversion or neutron extentions | 17:09 |
| sean-k-mooney | i dont think there was a check like that in the relevent patch but i dont recall so ya proably good to capture in a comment | 17:10 |
| dansmith | so now that I have that in my config, I see that devstack didn't actually deploy barbican :) | 17:11 |
| dansmith | typo, I guess | 17:14 |
| sean-k-mooney | so on the comptue you do not need the barbica plugin bu ton the contoler you do | 17:16 |
| sean-k-mooney | i can past my contoler local.conf too for reference | 17:17 |
| sean-k-mooney | https://termbin.com/6iyt | 17:17 |
| sean-k-mooney | so all i have is | 17:18 |
| sean-k-mooney | enable_service barbican | 17:18 |
| sean-k-mooney | and | 17:18 |
| sean-k-mooney | LIBS_FROM_GIT=barbican,devstack,glance,keystone,neutron,nova,placement,requirements,tempest | 17:18 |
| sean-k-mooney | enable_plugin barbican https://opendev.org/openstack/barbican | 17:18 |
| sean-k-mooney | + the keymanager thing i mentioned eariler | 17:18 |
| sean-k-mooney | oh | 17:19 |
| sean-k-mooney | i think im useing melwitt's devtack patch | 17:19 |
| dansmith | yeah I typo'd the enable_service | 17:19 |
| sean-k-mooney | oh that just creats flavors https://review.opendev.org/c/openstack/devstack/+/864160/10/lib/nova | 17:19 |
| sean-k-mooney | so you dont need that | 17:20 |
| opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Add debug logging to can_fit_pagesize https://review.opendev.org/c/openstack/nova/+/899942 | 17:47 |
| opendevreview | OpenStack Release Bot proposed openstack/nova master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/nova/+/911270 | 18:47 |
| opendevreview | OpenStack Release Bot proposed openstack/os-vif master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/os-vif/+/911272 | 18:48 |
| opendevreview | OpenStack Release Bot proposed openstack/osc-placement master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/osc-placement/+/911274 | 18:48 |
| opendevreview | OpenStack Release Bot proposed openstack/placement master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/placement/+/911276 | 18:48 |
| opendevreview | OpenStack Release Bot proposed openstack/python-novaclient master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/python-novaclient/+/911278 | 18:48 |
| opendevreview | OpenStack Release Bot proposed openstack/nova master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/nova/+/911280 | 18:49 |
| opendevreview | OpenStack Release Bot proposed openstack/os-vif master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/os-vif/+/911282 | 18:50 |
| opendevreview | OpenStack Release Bot proposed openstack/osc-placement master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/osc-placement/+/911284 | 18:50 |
| opendevreview | OpenStack Release Bot proposed openstack/placement master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/placement/+/911286 | 18:50 |
| opendevreview | OpenStack Release Bot proposed openstack/python-novaclient master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/python-novaclient/+/911288 | 18:50 |
| opendevreview | OpenStack Release Bot proposed openstack/nova master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/nova/+/911290 | 18:51 |
| opendevreview | OpenStack Release Bot proposed openstack/os-vif master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/os-vif/+/911292 | 18:51 |
| opendevreview | OpenStack Release Bot proposed openstack/osc-placement master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/osc-placement/+/911294 | 18:51 |
| opendevreview | OpenStack Release Bot proposed openstack/placement master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/placement/+/911296 | 18:52 |
| opendevreview | OpenStack Release Bot proposed openstack/python-novaclient master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/python-novaclient/+/911298 | 18:52 |
| melwitt | dansmith, sean-k-mooney: are things working ok by now or are you still having issues? | 19:27 |
| sean-k-mooney | i havent update my devstack in a week or two but it was workign fine for me | 19:27 |
| sean-k-mooney | melwitt: i think dansmith just had a typo so i assume its working ok now or htey havent gotten aroudn to restacking | 19:28 |
| melwitt | thanks sean-k-mooney | 19:28 |
| melwitt | also, regarding the policy changes in the DNM tempest jobs patch, I did that to cover as many tests as possible, so that _if_ someone had their policy set that way, to verify whether it works | 19:30 |
| stblatzheim | sean-k-mooney: Can you give a W vote for https://review.opendev.org/c/openstack/nova/+/910616 ? It's stuck before gate tests :) | 19:30 |
| melwitt | it's not a statement about it being the right thing to do | 19:30 |
| sean-k-mooney | stblatzheim: it need another stabel core to reveiw | 19:31 |
| stblatzheim | Who could I ping for this? :) | 19:31 |
| sean-k-mooney | melwitt: would you have 5 mins for ^ | 19:31 |
| dansmith | melwitt: yeah I had a typo, not sure if it finished re-stacking or not | 19:31 |
| melwitt | sean-k-mooney: sure, will look | 19:32 |
| melwitt | dansmith: ack | 19:32 |
| dansmith | sean-k-mooney: I looked at that yesterday and wanted to hear your take on your change of opinion | 19:33 |
| dansmith | I read the bug and see neutron people saying it was wrong and implying the patch is correct, | 19:33 |
| dansmith | but I didn't see any indication of "and yes this should be backported" since it presumably depends on what version(s) of neutron are in use in an older release | 19:34 |
| sean-k-mooney | so the orginal patch tried to fix it by lookging for additon aports with a diffent device owner string | 19:34 |
| sean-k-mooney | and i did not like that approch because it was wack a mole for every backend | 19:35 |
| sean-k-mooney | the current patch checks if the subnet has dhcp enabled | 19:35 |
| dansmith | oh I didn't see that it was a different approach earlier | 19:35 |
| sean-k-mooney | and then use the enable_dhcp option to tell cloud init to use dhcp | 19:35 |
| opendevreview | Merged openstack/nova master: Disconnecting volume from the compute host https://review.opendev.org/c/openstack/nova/+/877446 | 19:36 |
| dansmith | sean-k-mooney: yeah but it changes what it's looking at from neutron, but the assertion is the thing it's looking for (the dhcp flag I guess) is nowhere near new enough to be a problem for a backport? | 19:37 |
| sean-k-mooney | dansmith: os thats why i changed my mind. im fine with looking at the dhcp_enabled field on the subnet to determin if we configure cloud init for static ips or dhcp | 19:37 |
| sean-k-mooney | dansmith: let me read the bug i didnt see them respond | 19:38 |
| sean-k-mooney | ok so quickly readin gthey change this bevhiro in vitoria | 19:39 |
| sean-k-mooney | https://review.opendev.org/c/openstack/neutron/+/732364 | 19:39 |
| stblatzheim | enable_dhcp flag is there at least for 5 years (there was a try to fix this but not very well) | 19:39 |
| sean-k-mooney | so that change broke the nova intengration | 19:39 |
| sean-k-mooney | but i belive dhcp_enabled is much much older then that | 19:40 |
| dansmith | sean-k-mooney: the patch description sort of sounds like this fixes it for OVN instead of OVS, so it just kinda seemed like this might be a "make it work for my situation" sort of thing | 19:40 |
| sean-k-mooney | its part of the core subnet resouce https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/subnet.py#L109 | 19:40 |
| stblatzheim | https://github.com/openstack/nova/commit/c7f572d65b57e034c1391ed49d84f6e5f1d672ad | 19:41 |
| dansmith | sean-k-mooney: cool, fair enough, just wanted to confirm.. I saw you were "hell no" and then suddenly +2 so just wanted to make sure I understood :) | 19:41 |
| sean-k-mooney | dansmith: the pach makes use not use "does the a subnet has a dhcp port" be how we determin if the subnet has dhcp enabled | 19:41 |
| sean-k-mooney | instead we directly read the enable_dhcp field | 19:41 |
| sean-k-mooney | so we have test coverage for ml2/ovs in the ci as well | 19:42 |
| sean-k-mooney | with the ovs_hybrid_plug job | 19:42 |
| sean-k-mooney | from what i can tell enable_dhcp has been a vaild field since the creation of the api defintion in neutron-lib in 2017 and if im being honestly i think this was in quantum | 19:44 |
| sean-k-mooney | so ya i think we are good | 19:44 |
| sean-k-mooney | dansmith: thanks for follwoing up your right that i orgignally marked this as invalid | 19:44 |
| sean-k-mooney | because i do think neutron broke there api contract when they change the poer owner but it was reasonable for use to fix in nova | 19:45 |
| dansmith | yeah exactly :) | 19:45 |
| dansmith | sean-k-mooney: stblatzheim: got it | 19:49 |
| stblatzheim | :) | 19:50 |
| melwitt | dansmith: the only other thing you will need to do is make sure that whatever user you want to work with encrypted local disks has the "creator" role assigned to them. the barbican devstack plugin adds it to some users it creates https://github.com/openstack/barbican/blob/master/devstack/lib/barbican#L278 but if you use a different user you will need to add the role to that user | 20:08 |
| dansmith | oh interesting okay | 20:13 |
| melwitt | the "creator" role is what barbican uses to allow creation of secrets | 20:17 |
| dansmith | yeah I gathered :) | 20:17 |
| dansmith | quite the intuitive name ;P | 20:17 |
| opendevreview | melanie witt proposed openstack/nova master: docs: Remove warning about quota driver default change https://review.opendev.org/c/openstack/nova/+/911374 | 20:23 |
| opendevreview | Merged openstack/nova stable/2023.2: Fix nova-metadata-api for ovn dhcp native networks https://review.opendev.org/c/openstack/nova/+/910616 | 22:29 |
| opendevreview | Steven Blatzheim proposed openstack/nova stable/2023.1: Fix nova-metadata-api for ovn dhcp native networks https://review.opendev.org/c/openstack/nova/+/911070 | 22:54 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!