Earlier  
Posted Nick Remark
#openstack-nova - 2023-01-25
17:32:44 sean-k-mooney just in the test coverage and perhapse the excpetion raised
17:33:01 sean-k-mooney we use 409 to comunicate this in other places
17:33:52 sean-k-mooney bauzas: do you want to capture that in the review
17:34:05 sean-k-mooney or shall i an link to this irc conversation
17:35:08 sean-k-mooney i think we just need a few more edgecases here https://review.opendev.org/c/openstack/nova/+/858384/34/nova/tests/functional/api_sample_tests/test_evacuate.py
17:35:10 bauzas sean-k-mooney: just left comments
17:35:33 bauzas but I can explain this to sahid later
17:35:46 sean-k-mooney ack
17:36:13 sean-k-mooney thanks for bringing this up
17:36:40 opendevreview Merged openstack/nova stable/xena: Reproduce bug 1981813 in func env https://review.opendev.org/c/openstack/nova/+/859314
17:36:45 bauzas and yeah HTTP409 Conflict makes perfect sense
17:37:37 bauzas I'll just double check the cve patches on fly
18:03:53 gibi Uggla: I left some comment in the API patch of the Manial series https://review.opendev.org/c/openstack/nova/+/836830
18:04:15 opendevreview Merged openstack/nova stable/xena: [stable-only][cve] Check VMDK create-type against an allowed list https://review.opendev.org/c/openstack/nova/+/871622
18:05:30 opendevreview Merged openstack/nova stable/xena: Gracefully ERROR in _init_instance if vnic_type changed https://review.opendev.org/c/openstack/nova/+/859315
20:08:34 opendevreview Merged openstack/nova stable/yoga: [stable-only][cve] Check VMDK create-type against an allowed list https://review.opendev.org/c/openstack/nova/+/871624
21:56:14 opendevreview Ghanshyam proposed openstack/nova stable/wallaby: DNM: testing tempest pin for stable/wallaby https://review.opendev.org/c/openstack/nova/+/871798
22:00:01 opendevreview Ghanshyam proposed openstack/nova stable/xena: DNM: testing tempest pin for stable/wallaby https://review.opendev.org/c/openstack/nova/+/871800
22:27:42 tobias-urdin proposed new releases for xena, yoga and zed to get the CVE-2022-47951 out the door, those backports are merged and no open patches on branches https://review.opendev.org/c/openstack/releases/+/871802
#openstack-nova - 2023-01-26
00:33:30 sean-k-mooney gibi: bauzas if you could take a look at this in ye're morning or melwitt if your around https://review.opendev.org/c/openstack/nova/+/867324
00:43:56 melwitt sean-k-mooney: these options don't follow how [workarounds] is supposed to be a False/True do this or don't thing :/ but I see why it's being done
00:44:31 sean-k-mooney i dont wnat to put them in the libvirt section as the workaround they are extending was ment to be deleted eventually
00:44:42 sean-k-mooney and when you use it it "taints" the domain
00:45:22 sean-k-mooney so at least downstream we had to get approval form our virt team to have this not "viod the warrenty" when it comes to support
00:46:00 sean-k-mooney i would be fine with moving them to the libvirt section if the libvirt api we asked for was actully added to libvirt
00:46:24 sean-k-mooney we ask for a top level api to do the exact same thing that did not mark the domain as tainted
00:46:46 sean-k-mooney so if that ever becomes a thing i would be happy to move the optiosn to the libvirt section
00:47:06 melwitt yeah, I saw you mentioned that in the comments. I understand why but it is kinda weird the concept of fine-tuning [workarounds] and I hope that's not going to become a thing
00:47:16 sean-k-mooney you are right about it not just being a bool however. it is still guarded by one however
00:48:07 sean-k-mooney the thing its most similar too is the interval and retires we have for volume detach
00:48:32 melwitt yeah, it's clear it's not a thing that we want to be permanent and why it wouldn't go into the normal configs
00:49:16 sean-k-mooney i did consider just suggesting hardcoding to 3 with a longer interval
00:49:34 sean-k-mooney but they already had the config option when i review for the interval
00:50:00 sean-k-mooney so i kind fo didnt wnat to have anouther patch tweeking this again later
00:51:28 sean-k-mooney https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.device_detach_attempts and https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.device_detach_timeout are the detach/attach options we added that are kind of like it
00:51:41 melwitt yeah, would've been ideal to hardcode it but if it's that fiddly then I see why we wouldn't want to have to do future tweaks to it
00:52:50 sean-k-mooney it kind of sucks that the workaround is needed but ya i expected when we added the orgianal workaround ot not need to do more then one addtional GARP
00:53:07 sean-k-mooney qemu is already doing 3 before we do anything
00:53:07 melwitt ack, I don't think the concept is itself weird, it's that you get a lot of fine-grained tuning for your one workaround 😆 I'm not suggesting blocking it but just saying it looks quite odd to me
00:53:07 melwitt ack, I don't think the concept is itself weird, it's that you get a lot of fine-grained tuning for your one workaround 😆 I'm not suggesting blocking it but just saying it looks quite odd to me
00:53:54 sean-k-mooney i agree on the odd but its pargmatic
00:54:23 sean-k-mooney its kind of like shouting at the network to say hay i really reallly really am over here now
00:54:56 melwitt lol :)
00:55:46 sean-k-mooney anyway its like 1am for me so im going to sleep came onlien to check something breilfy and got distracted with geting my email inbox to 0
00:56:29 melwitt k g'night! o/
00:56:36 sean-k-mooney o/
07:57:40 tobias-urdin eu people might start their day now :) please have a look at getting a release for the CVE out https://review.opendev.org/c/openstack/releases/+/871802
08:43:10 frickler gibi: bauzas: sean-k-mooney: ^^ I kind of agree with tobias-urdin that there is a bit of urgency behind this. not sure if release team could skip ptl approval in this case, though?
08:43:50 kashyap Is it just me or the "tempest-integrated-compute" is timing out often for others too?
08:44:22 bauzas frickler: I'm here
08:44:52 bauzas frickler: we said we were trying to also merge another CVE fix before we release this
08:50:37 bauzas ok, the other cve bug is fixed down to xena, so yeah, we can have releases
08:56:41 frickler that other CVE was https://review.opendev.org/c/openstack/nova/+/859315, right?
09:04:51 bauzas yup, just checked, reviewing now the releases patch
09:09:21 bauzas gibi: frickler: I was torn with the proposed semver of https://review.opendev.org/c/openstack/releases/+/871802 which was doing .y releases but I can live with that
09:10:18 bauzas tobias-urdin: ^ anything in particular you had in mind when you did set the releases for a .y bump ?
09:10:30 bauzas the fact that it was exposing a new conf knob, I guess ?
09:14:03 gibi I'm fine with the minor bump
09:15:05 bauzas that seems a bit agressive but thinking out more, that means that distros have to adapt their toolings if they wanna set the new conf knob
09:15:09 bauzas so yeah a .y bump seems ok
09:15:32 bauzas even if semantically, we're sending a wrong signal
09:17:16 gibi we are removing functionality with a knob by default so I'm OK to y bump it
09:17:53 gibi I double checked it seems both cve is in the release (the vnit_type on was in zed when it was master)
09:18:06 gibi so I think we are good to go
09:20:10 tobias-urdin i pretty much followed cinder that bumped minor, I guess it wouldn't hurt indicating to operations that a minor version that should be upgraded to because of CVE
09:20:38 tobias-urdin but yeah we can change if required, just wanted to make it a priority to release it so downstream can start building stuff new versions as well
09:20:48 bauzas gibi: yeah, checked the other CVE, was my main original driver for the check
09:21:07 bauzas tobias-urdin: no worries, as I said, I can live with that
09:21:24 gibi next is stable/wallaby but that needs the tempest pin first. https://review.opendev.org/q/topic:wallaby-pin-tempest
09:21:32 bauzas in theory a CVE fix doesn't require a y versioning but meh
09:21:46 tobias-urdin bauzas: ack, thanks, i will keep that in mind for the future
09:21:49 bauzas gibi: correct, I +2/+Wd a patch this morning
09:22:43 bauzas tobias-urdin: np, not anyone needs to know anything :) but if you wanna know more about semver, this is the reference page https://docs.openstack.org/pbr/latest/user/semver.html
09:23:10 bauzas gibi: do you know if gmann did the tempest patch ?
09:23:17 bauzas I can check, I just didn't had the time yet
09:23:32 gibi bauzas: here is the tempest pin series https://review.opendev.org/q/topic:wallaby-pin-tempest it needs love
09:23:44 bauzas I can surely provide love
09:23:45 gibi the DNM test patches are failing
09:24:33 bauzas then I guess the love has to be on finding why the DNM patches are failing
09:24:35 bauzas lovely
09:24:51 bauzas that's just 12 hours I haven't looked at zuul files
09:48:18 bauzas mmm
09:48:40 bauzas gibi: does those skipttest exceptions in tempest look correct to you ?
09:48:42 bauzas 2023-01-26 01:06:13.455899 | controller | unittest2.case.SkipTest: Identity api v2 is not enabled
09:48:51 bauzas I have seen gmann rechecking on such errors
09:49:06 bauzas https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_0a4/871782/2/check/tempest-full-py3/0a42465/job-output.txt
09:49:17 gibi it does not look good, but maybe gmann rechecked on it as he changed one of the depends-ons
09:50:31 bauzas I just asked for a recheck
09:50:44 bauzas on the devstack patch
09:51:03 bauzas anyway, the changes themselves on both tempest and devstack seem logic to me
09:51:04 gibi we will see
09:51:12 bauzas so I guess this is just a transient issue
09:52:22 bauzas at least keystone was running
09:53:48 sahid o/ sean-k-mooney, bauzas I have noticed your new comments
09:53:51 sahid working on it !
09:53:53 sahid thanks
09:54:33 bauzas sahid: thanks
09:54:47 bauzas sahid: ping me when you're done with those, and I'll rereview
09:55:13 sean-k-mooney[m] the rpc pin case is not something i orginally tought of but i dont think its a large change to just make sure we dont retrun a 500 from the api and add a test for that so hopefully it wont take too much to adress that
09:55:33 bauzas sahid: to clarify, sorry but you don't need to change the RPC client, just make sure that on the API you can verify it

Earlier   Later