Earlier  
Posted Nick Remark
#openstack-nova - 2020-04-09
14:35:03 bauzas k
14:35:04 artom Monday too
14:35:24 bauzas so, afaict, I can see our Chinese contributors be around and maybe France
14:35:32 bauzas can't speak for Italy and Spain
14:35:36 sean-k-mooney i basically know this as FF week instead of easter
14:39:45 bauzas sean-k-mooney: my wife and I just realized on Monday it was Easter this week
14:39:51 bauzas you're not alone
14:41:55 gmann lbragstad: this can go in or should i add the diff in some doc ? - https://review.opendev.org/#/c/717879/3
14:41:56 bauzas gibi: mind giving me the gmann's policy patches ?
14:42:24 gmann bauzas: these - https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:open+OR+status:merged)
14:42:27 gibi bauzas: it is multiple thread of patches but each is on this topic https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/policy-defaults-refresh
14:42:44 stephenfin gmann: How many of those are left to do?
14:42:45 gmann bauzas: i need to update few policies also and deprecated API policy
14:42:53 stephenfin if you know off the top of your head?
14:44:28 gmann stephenfin: other than which are already up + 3 APIs new + deprecated APIs. i think doing deprecated APIs also good to update also to make it consistent as they still stay.
14:44:44 bauzas gibi: gmann: FWIW, I remember our discussions at the Shanghai PTG, any important points you wanna me to explain before I go reviewing ?
14:45:03 bauzas or is it something not new from Shanghai, just implementation thingies ?
14:45:22 nightmare_unreal Thanks.
14:45:22 nightmare_unreal if someone has time, can you look at this : https://review.opendev.org/#/c/715395/ .
14:45:30 gmann bauzas: key things is the existing test coverage at the first patch and then see how those gets changed for scope and new defaults
14:46:25 gmann bauzas: nothing new from shanghai. it is just implementation of that in all policies
14:46:27 bauzas nightmare_unreal: we're cutting M-3 tonight with Feature Freeze, I'll spend a reasonable couple of hours for reviewing bugs in the next week
14:46:41 bauzas gmann: perfect, then I know the outcomes
14:47:02 nightmare_unreal aah o.O thanks for your work :)
14:47:04 bauzas gmann: will you be around tomorrow or off ?
14:47:17 bauzas gmann: (can't remember where you live, I apologize)
14:47:20 gmann bauzas: thanks. I am working tomorrow and Monday too. might be on weekend too
14:47:25 gmann bauzas: canada
14:48:10 bauzas gmann: ok, gtk, just saying because we just discovered we'll miss a couple of countries for work tomorrow, including Canada
14:48:24 gmann yeah.
14:48:25 bauzas (at least for Red Hat)
14:50:19 artom bauzas, in practice, feature freeze is today :P
14:50:44 sean-k-mooney nightmare_unreal: that --overwrite kind of acts like a --force would
14:50:53 bauzas gmann: patches seem not to be piled in a branch, but rather only by topic name
14:51:05 bauzas artom: I fuckingly know about it
14:52:03 bauzas gmann: that makes reviewing a bit hard, I don't know where to start and a couple of patches got -1 from Zuul
14:52:03 gmann bauzas: correct. 2 are olso one which I are almost ready to go.
14:52:14 bauzas gmann: so I need guidance for reviews
14:52:34 bauzas gmann: I'd say https://review.opendev.org/#/c/718348/ is crucial before we move on
14:52:35 stephenfin bauzas: anything +2'd by me is passing CI
14:52:37 gmann bauzas: ok so there is always set of series for each API. let me find the review guidelines i sent on ML
14:52:55 stephenfin and good (IMO, of course)
14:52:56 bauzas stephenfin: you're Zuul \o/
14:53:08 bauzas we finally discovered it
14:53:11 stephenfin I wish I was that good at multitasking
14:53:39 bauzas stephenfin: raise 2 kids, get locked down and you'll be surprised about multitasking
14:53:45 sean-k-mooney stephenfin: e.g. it is force updating an allocation even if we dont think it needs healing
14:53:53 sean-k-mooney oh that was for nightmare_unreal ^
14:54:10 gmann bauzas: http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008504.html
14:54:55 bauzas gmann: perfect, thanks
14:55:33 bauzas gmann: you'd understand that I'd hold reviews on the servers API until https://review.opendev.org/#/c/718348/ get merged ?
14:56:36 bauzas in particular given the criticity of the servers API about policy enforcement
14:56:46 gmann bauzas: yeah that make sense. if test coverage is failing somewhere then it is good to wait to have clear pic of what going to be changed in scope and new defaults patches
14:57:50 gmann bauzas: true. that is one of complex one too given the lot of inline policies per attributes .
14:57:51 stephenfin bauzas: I think you missed sean-k-mooney and I's point https://review.opendev.org/#/c/715490/11/nova/virt/libvirt/driver.py@815
14:58:08 bauzas stephenfin: did I ? shit.
14:58:28 stephenfin To be clear, I agree with the change you've made in that PS, but it's not the one we were concerned about so I think there's another one to do
14:58:59 bauzas holy shit.
14:59:09 sean-k-mooney bauzas: basically the current code logs a warning if an instance was using an mdev type that cant be recreated
14:59:13 bauzas stephenfin: I absolutely missed your concern, I apologize.
14:59:16 openstackgerrit Ivaylo Mitev proposed openstack/nova master: Implementing graceful shutdown. https://review.opendev.org/666245
14:59:24 sean-k-mooney i was saying that should cause the agent not to start
14:59:41 sean-k-mooney which i think is what stephenfin ment by make it an error too right
14:59:44 bauzas sean-k-mooney: stephenfin: lemme think about it
15:00:02 bauzas I'm honestly not sure we'd have to hardstop but I could be wrong
15:01:19 bauzas stephenfin: worth accepting a FUP for the doc nit ?
15:01:22 stephenfin bauzas: What would happen in that situation? You wouldn't be able to restart the instance using the mdev because it wasn't recreated?
15:02:16 stephenfin bauzas: Yeah, I'm not sure if we can hard fail for that case (missing '[vgpu_{name}]' sections) after all
15:02:37 stephenfin We already allowed people to list multiple values in 'enabled_vgpu_types', yeah?
15:02:43 stephenfin Even though they did nothing
15:03:18 stephenfin So it's possible there are nova.conf files in the wild with e.g. '[devices] enabled_vgpu_types = nvidia-35, nvidia-36'
15:03:21 sean-k-mooney bauzas: we could not start instance vm at that point right
15:03:45 stephenfin and if they upgrade to Ussuri, they suddenly won't be able to start nova
15:03:49 stephenfin *nova-compute
15:03:58 bauzas stephenfin: I considered this point (having set multiple types while we weren't supporting it)
15:04:22 bauzas stephenfin: I think the hardstop is a reasonable failure
15:04:53 bauzas stephenfin: for operators having set multiple types, they would see that it wasn't really supported before and now they have some action to do
15:05:08 bauzas stephenfin: instead of blindly thinking it was working
15:05:19 stephenfin right, but it was allowed and didn't break anything
15:05:28 bauzas stephenfin: we only refuse to start
15:05:38 bauzas stephenfin: people can just adapt their confs if so
15:05:52 bauzas again, we made it on purpose
15:06:11 bauzas I see this as "we won't impact you if you made things the right way"
15:06:26 bauzas 'but if you made things the wrong way, it's time to change your config to make it work correctly"
15:06:30 stephenfin idk, I thought it was a given that nova.conf from N should continue to work in N+1
15:06:34 stephenfin with warnings, sure
15:06:38 bauzas stephenfin: it will
15:07:03 bauzas stephenfin: but I can honestly revert to PS10
15:07:51 bauzas stephenfin: tbc, there is zero upgrade impact for single-typed configurations
15:08:13 bauzas it's debatable tho and I don't want to hold
15:08:18 sean-k-mooney bauzas: any chace you could add a nova-staus command for this?
15:08:32 bauzas sean-k-mooney: certainly not for Train :)
15:08:41 bauzas which is the case we're discussing about
15:08:46 sean-k-mooney ah ok hehe
15:09:05 sean-k-mooney im also not sure how useful it would be given you would have eto run it on the compute node
15:09:29 stephenfin Yeah, I think what you had before was better. "Your nova.conf is wrong and needs to be fixed. We're reverting to the old Train behaviour until you do that"
15:09:46 bauzas stephenfin: okay here is a trade-off, I can write an upgrade note saying that multiple-typed confs have to adapt their confs
15:10:06 bauzas stephenfin: okay, let's revert to PS10 then
15:10:14 sean-k-mooney that still does not adress https://review.opendev.org/#/c/715490/11/nova/virt/libvirt/driver.py@815
15:10:32 bauzas sean-k-mooney: yup, it will be PS10 with recreate hard stopping

Earlier   Later