Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-27
15:02:41 efried Apparently we can fix it somewhere in the job definition itself, but so far nobody has gone and done that. Not sure how much of that is because nobody knows how (that's certainly *my* excuse) or just haven't had the time.
15:03:16 efried Another hesitation with that is that we *should* just go convert those jobs to zv3, which would make the problem go away, and which we're supposed to be doing anyway.
15:03:43 efried that also has been not done, and for similar reasons I imagine.
15:03:55 efried smarter people than me have made attempts, but nothing has closed
15:04:31 lyarwood efried: ack thanks, I did start looking at switching the nova-lvm job over last week but didn't post anything.
15:04:54 lyarwood sean-k-mooney: have you started converting any of the grenade jobs to zuulv3?
15:05:04 lyarwood iirc you were looking at this right?
15:05:07 efried I will personally buy a cookie for whoever makes the .gz problem go away, I don't care how.
15:21:28 gmann lyarwood: grenade job zuulv3 work https://review.opendev.org/#/q/topic:grenade_zuulv3+status:open
15:22:32 lyarwood gmann: awesome thank you, I'll take a look shortly
15:50:10 lyarwood melwitt: https://review.opendev.org/#/c/703005/ - Did you have another openstack/nova change using https://review.opendev.org/#/c/548936/ btw?
16:02:32 melwitt lyarwood: yeah, I was dual purposing this https://review.opendev.org/701478
16:03:32 lyarwood melwitt: ah cool thanks
16:04:29 melwitt I got motivated to test out the grenade change while trying to get some info on that cell timeout gate failure in grenade jobs (bc the log files are all gzipped and annoying to have to download). zuul v3 conversion solves that problem
16:13:12 dansmith efried: just want to make sure it's clear that I'm waiting for you to ack this before I really do much with it: https://review.opendev.org/#/c/631243/52
16:14:38 efried dansmith: okay, thanks for the heads up.
16:15:03 dansmith efried: seems like you haven't been through that set lately, are you planning to go through it again soon?
16:15:18 efried I can do that, yes.
16:15:33 efried dansmith: I was actually mostly waiting for you to be happy with it.
16:15:46 dansmith efried: last time I did I got to like patch #4 and found yet many more sections of code where there wasn't any testing, and/or tests that asserted things were called, but not with any specific parameters and got annoyed
16:16:03 efried okay.
16:16:14 dansmith and so I'm feeling a little like I'm the only guy digging deep on those things, which is exhausting
16:24:38 efried I'll take a thorough swipe this week. You should take some time off to prevent burnout. Go do some sledding or something.
16:25:17 dansmith well, I'm just back from time off for general burn-out reasons,
16:25:18 dansmith but I also don
16:25:51 dansmith I also don't want to get too myopic on this set, so I think it would be good to have someone else take a pass through and see if they find things I'm not seeing
16:26:26 dansmith like, a little more than just my comments get changed each time and I don't want to settle into an itemized list of "yes, my comment was addressed" without looking close enough at the whole change
16:26:40 efried ack
16:37:58 lyarwood melwitt: sorry got slightly distracted, did you want to use that change to switch things over to the new zuulv3 job or should we create a fresh one?
16:38:41 melwitt lyarwood: I'd create a fresh one. I don't know why I didn't make a fresh one, sorry
16:40:22 lyarwood melwitt: ack np I can take a swing at that now
16:40:38 melwitt lyarwood: yeah sure, go ahead. thanks
16:41:17 melwitt just have to remove the -py3 from the name, I think that's all
16:41:53 melwitt (and depends-on tosky's grenade change)
16:42:45 lyarwood melwitt: yeah, doesn't our grenade job also run some live migration tests?
16:43:06 melwitt lyarwood: I ... don't know tbh
16:44:18 lyarwood https://github.com/openstack/nova/blob/80539a5e849bf8ec1239f0ed01433a7f8a54015b/playbooks/legacy/nova-grenade-multinode/run.yaml#L57-L59 - yeah it does, I don't think the new job includes this yet.
16:44:19 melwitt note that I was referencing only the single node grenade job earlier, we also have a multinode grenade job that I did _not_ try to convert to yet using tosky's change
16:44:27 lyarwood ah okay I see
16:44:34 melwitt so that might be the one
16:44:49 melwitt and you already linked it so yes
16:46:13 tosky and tosky wasn't able to find a proper workaround for the failures when using grenade plugins (shame on him)
16:54:58 melwitt tosky: do you have a change where you are working on getting plugins to work? is that here? https://review.opendev.org/639774 is there any way we could help?
16:56:46 tosky melwitt: I don't have a change; the problem is that I'm not able to figure out where the py2 openstackclient is installed and make sure its CLI used over its py3 counterpart
16:57:08 melwitt oh, interesting
16:57:26 tosky I would expect that starting from a py3 deployment, even if the py2 version is installed afterwards, the py3 version installed first would still be the one used for the CLI
17:00:10 melwitt I would expect that as well
17:01:28 stephenfin efried: create a blueprint for what?
17:02:43 lyarwood stephenfin: https://review.opendev.org/702943 - I think he was talking about that spec that had just merged.
17:03:01 stephenfin ah, makes sense
17:03:03 stephenfin will do
17:03:32 tosky talking about jobs, a few days ago the nova-live-migration job was failing in stable/pike; do you know if it has been solved?
17:04:38 melwitt tosky: it has not been solved yet. sean-k-mooney said they would try to dig into it more soon. it's not 100% failure rate but seems like it's close to that
17:06:44 efried stephenfin: I was talking about https://review.opendev.org/#/c/682655/
17:07:04 efried It looks like you're using a new bp name for this round, but there's no bp by that name.
17:09:31 openstackgerrit Lee Yarwood proposed openstack/nova master: zuul: Switch to the Zuulv3 grenade job https://review.opendev.org/704364
17:10:50 stephenfin efried: https://blueprints.launchpad.net/nova/+spec/flavor-extra-spec-validators
17:11:00 efried thanks
17:15:19 sean-k-mooney tosky: its actully the other way around. which ever version is installed last get used but only if its the first installation
17:15:40 sean-k-mooney if you upgrade an existing install it does not replace the console script i think
17:16:11 sean-k-mooney so ify its py2 then py3 on n-1 1 and py3 only on n i thing the console scrript will point to py2
17:17:15 sean-k-mooney anyway its a bit of a pain. we likely should make the py2 install in py3 mode optional in train
17:17:26 sean-k-mooney so we can disable it in the greade job
17:18:15 sean-k-mooney but yes i will try to look at nova-live-migration this week. i think i have got a downstream backport working so i should have more time to look at it this week
17:18:35 sean-k-mooney i might try to set aside tomorow to look at it
17:26:32 stephenfin gibi: RE: https://review.opendev.org/#/c/701763/4/specs/ussuri/approved/non-admin-filter-instance-by-az.rst@83, are you saying it's not possible to use policy to allow any user access to the API?
17:28:45 gibi stephenfin: I think the policy is not per field
17:30:12 gibi stephenfin: so if we want to make some fields available for filtering to the normal user then we need to change code
17:31:39 stephenfin Oh, so even with this spec there are fields that the admin will be able to filter on but not a normal user?
17:31:52 stephenfin I missed that, if so
17:33:01 gibi stephenfin: yeah I think so
17:33:11 stephenfin riiight, okay then, my bad
17:33:16 gibi admin can filter on admin only fields too
17:33:34 gibi I mean those fields that are not returned in the GET /servers/ to non-admins
17:33:34 stephenfin lemme double that check and then I'll hit it again
17:33:44 stephenfin yeah, makes sense in hindsight
17:37:14 tosky sean-k-mooney: thanks for both :)
19:18:32 openstackgerrit Merged openstack/nova stable/pike: Avoid redundant initialize_connection on source post live migration https://review.opendev.org/683008
19:27:28 KeithMnemonic Eureka, that BDM patch on stable/pike finally merged. Thanks a ton for all of your endless help mriedem: , melwitt: and of course hemna:
19:39:04 melwitt cool KeithMnemonic
20:13:59 openstackgerrit Lee Yarwood proposed openstack/nova master: zuul: Add Fedora based jobs to the experimental queue https://review.opendev.org/701231
20:14:08 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP libvirt: Use virDomainBlockCopy to swap volumes with >= 5.10.0 https://review.opendev.org/696834
23:18:24 efried dansmith: remind me (again) which direction we're allowed to have mismatched versions: controller newer than compute or vice versa?
23:22:30 sean-k-mooney controler newer then compute i think
23:22:54 sean-k-mooney we expect the contol plane to be upgraded first
23:25:04 efried k
23:26:44 sean-k-mooney in either case the sender is ment to back level to the max version supported by the reciver if memory serves. greade upgrade the contol plane first so that is what we test.
23:27:28 efried I'm trying to understand the upgrade implications of the extra spec validation thing.
23:27:45 sean-k-mooney ah ok
23:28:53 sean-k-mooney that does rais an intersting question. if the extra specs were ovo should you allow the flaovr to be back leveled if a unsupporte extra spec was requested.
23:29:26 sean-k-mooney i have not review that proposal by the way so that is jsut me specualting but i would lean towrads no
23:29:32 efried I think it's simpler than that.
23:30:23 efried Ultimately an extra spec that's used on/by the compute (which is many of them) is being validated at the API.
23:30:50 sean-k-mooney yes at least initally
23:31:23 efried and if the versions are mismatched, we could have an extra spec that the control plane (because newer) understands, but the compute won't. If the developer of that extra spec is doing their job right, they'll have tied it to a request filter so you would never land on that compute, so probably no big deal.
23:31:48 efried But the other way around is also possible. If we deprecate/remove support for an extra spec, the control plane thinks it's invalid while the compute still supports it.
23:32:15 efried I guess that means you have to wait *two* cycles before you get to add the validator that forbids the removed extra spec.
23:32:16 efried or something.
23:33:07 sean-k-mooney ya althoguh im not sure we have ever remvoed an extra spec
23:33:28 sean-k-mooney i can think of one or two i woudl consider removing but i dont think we have ever actully done it

Earlier   Later