Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-10
14:57:09 SteelyDan he copied it from boot, so should be in there
14:57:31 fried_rice is Matt already pto at this point?
14:57:32 sean-k-mooney ok i was just wondering if that patch would have broken nova-net migration also
14:57:36 SteelyDan if utils.is_neutron() and deadline:
14:57:46 sean-k-mooney which would be another reason to revert if it had
14:57:47 SteelyDan sean-k-mooney: ^
14:57:57 sean-k-mooney ah ok cool
14:58:52 melwitt fried_rice: matt's not on PTO, traveling to china for work
14:59:15 fried_rice melwitt: Oh, is he still going to be working on code?
14:59:16 melwitt but I do think he's gone already and won't be around during US hours next week
15:00:08 fried_rice melwitt: Currently just wondering whether I (or someone) should take over his patch that's on the rc2 candidate list
15:00:14 melwitt not sure, depends on his schedule while he's over there, I imagine
15:00:20 sean-k-mooney fried_rice: i think he said he would try to be back online again later
15:01:58 SteelyDan fried_rice: which patch is that?
15:02:15 fried_rice SteelyDan: https://review.openstack.org/#/c/590445/
15:02:20 melwitt SteelyDan: that's right, mriedem also wanted to land the "stop spamming the placement logs" patch for rc2
15:02:25 SteelyDan fried_rice: ack
15:02:39 SteelyDan melwitt: ack
15:02:44 SteelyDan acks for everyone
15:02:57 melwitt you get an ack and you get an ack and
15:03:31 fried_rice Can I get an aaaar, maybe from lyaaaaaarwood?
15:04:03 sean-k-mooney fried_rice: look like cdent would like some rewording of the commit message first
15:04:21 fried_rice Yeah, I'm going to ask cdent to fix it up himself, assuming that's all that's needed.
15:05:23 cdent yeah, I can fix that. I wasn't sure if matt was still around or not, and wasn't sure if people would really care, but that thing has proven a source of confusion before, so I didn't want us to add to it
15:05:32 SteelyDan fried_rice: is this the bug you were asking about? because that patch should have a bug and be rc-potential tagged, IMHO
15:05:57 sean-k-mooney i have not done anything with the logging filters but it looks reaonable at a glance
15:06:06 fried_rice SteelyDan: I was actually asking about
15:06:06 fried_rice https://review.openstack.org/#/c/590388/ - big perf improvement in the (for now and the near future) most common code path in GET /allocation_candidates
15:06:06 fried_rice https://review.openstack.org/#/c/590041/ - debug logging in GET /allocation_candidates per http://lists.openstack.org/pipermail/openstack-dev/2018-August/132735.html
15:06:47 fried_rice SteelyDan: But yeah, Matt's needs a bug too. <== cdent (If you're still super busy, I can open that up and update the commit message whenever you're done with your reword)
15:07:32 SteelyDan fried_rice: that placement perf one going into rc2 concerns me
15:07:47 fried_rice leakypipes: heads up ^
15:07:54 SteelyDan seems like good as-soon-as-we-release fodder
15:08:13 fried_rice SteelyDan: Okay, that wfm; just know for sure we want it to be in Rocky.
15:08:13 cdent fried_rice: i'm almost ready to context switch, so will catch up with you in a few minutes on what needs to be done
15:08:16 SteelyDan it's a lot of change, no test change (presumably because it's a refactor) but.. man.
15:08:19 fried_rice cdent: ack
15:08:47 fried_rice SteelyDan: Yeah, confidence comes from the fact that it *didn't* break the dozen layers of testing sitting above it.
15:08:54 SteelyDan it's just perf, not a critical fix, so backport after the release, IMHO
15:08:59 SteelyDan I'll comment on th epad
15:09:32 fried_rice Then I imagine the other one (split-out with debug messages) will be similar.
15:11:38 SteelyDan commented on that as well
15:12:56 fried_rice rgr. I still don't quite understand what motivates the decision to put something in rc or not. Like, why is the "gold" release significant? Clearly we find bugs later and fix them, so nobody is going to be running with gold for long, are they?
15:13:46 cdent fried_rice: i too have that confusion
15:13:46 fried_rice I mean, I get that the process is the process, and I'm not trying to buck it (unless it really is nonsensical and just there out of momentum). Just trying to understand it.
15:13:54 cdent ditto
15:14:35 SteelyDan fried_rice: here you go: https://docs.openstack.org/project-team-guide/release-management.html#release-candidate-period-release-3
15:17:16 leakypipes fried_rice: was breakfasting... reading back.
15:17:36 leakypipes SteelyDan: which perf patch are we referring to? the "use simple code paths when possible" one?
15:17:51 SteelyDan leakypipes: the one that fried_rice put on the rc etherpad
15:17:55 SteelyDan I've since closed it
15:19:08 sean-k-mooney leakypipes: this one https://review.openstack.org/#/c/590388/
15:20:56 leakypipes sean-k-mooney: ack. I'm not going to get into the conversation about what should go in RC/stable/whatevs. That patch reduces the scheduling time for a common request for CPU, RAM and disk by around 300%. I think it's good as is but I've given up arguing about releases and RCs and whatnot.
15:21:49 leakypipes sean-k-mooney: I'm more than comfortable if it goes in to an RC or if it doesn't. really won't bother me either way.
15:22:34 sean-k-mooney leakypipes: o really just looking at it now.
15:23:01 sean-k-mooney i take it its just avoiding a lot of work id did not need to do in the simple cases
15:24:01 leakypipes sean-k-mooney: correct.
15:26:03 sean-k-mooney cool well im going to switch to my other laptop and see if i can get triplo to finish deploying in vms...
15:26:19 sean-k-mooney o/
15:30:31 leakypipes sean-k-mooney: sorry, it's technically a 70% decrease in runtime.
15:30:49 mriedem hey party people
15:31:01 leakypipes sean-k-mooney: 3.69 seconds vs 1.10 seconds to perform the allocation candidates search for 1000 providers having inventory of CPU, RAM and disk
15:31:57 openstackgerrit Chris Dent proposed openstack/nova master: placement: ignore policy scope check failures if not enforcing scope https://review.openstack.org/590445
15:32:32 sean-k-mooney leakypipes: clearly you should repeat the calulation 2 more times just to be sure .
15:32:51 sean-k-mooney you would still finish faster :)
15:32:56 leakypipes heh
15:33:19 fried_rice mriedem: O hey mon, we took over ---^ because we thought you were out til at least Monday
15:34:02 mriedem where is dan?
15:34:09 leakypipes I was thinking of ((1.10-3.69)/1.10)*100 which would be ~235% increase in time. But the percentage decrease from 3.69 -> 1.10 is ((3.69-1.10)/3.69)*100 is ~70% decrease in time
15:34:17 melwitt mriedem: SteelyDan
15:34:53 mriedem oh
15:35:01 mriedem SteelyDan: got that vif plug timeout to 30 seconds, hit it here http://logs.openstack.org/08/553608/11/check/neutron-tempest-linuxbridge/992de45/logs/screen-n-cpu.txt.gz#_Aug_10_13_45_47_903132
15:35:09 mriedem that's a timeout before the guest transfer completed
15:35:34 openstackgerrit Merged openstack/nova master: block_device: Rollback volumes to in-use on DeviceDetachFailed https://review.openstack.org/590439
15:35:35 mriedem but it still completes http://logs.openstack.org/08/553608/11/check/neutron-tempest-linuxbridge/992de45/logs/screen-n-cpu.txt.gz#_Aug_10_13_46_13_027466
15:35:43 openstackgerrit Merged openstack/nova master: Nix 'new in 1.19' from 1.19 sections for rp aggs https://review.openstack.org/590389
15:35:55 SteelyDan yeah I saw all the comments
15:36:13 mriedem this time was a bit different, more realistic but yeah
15:36:20 mriedem either way it validates what we expected to happen
15:36:27 SteelyDan yup
15:36:28 mriedem lyaaaaaarwood: are you going to push backports for https://review.openstack.org/#/c/590439/ ?
15:36:36 mriedem SteelyDan: you going to touch up that reno?
15:36:44 mriedem or are we waiting for sahid yet? he's on PTO
15:36:46 SteelyDan mriedem: oh yeah, forgot but I can
15:36:57 mriedem lemme -1 stat pad quick
15:37:15 SteelyDan personally I'd rather see this go in so we have soak on the changes to the driver, even though we won't exercise the waiting code
15:37:17 lyaaaaaarwood mriedem: yup will do
15:37:27 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: block_device: Rollback volumes to in-use on DeviceDetachFailed https://review.openstack.org/590801
15:38:26 mriedem melwitt: now that we have a stable/rocky branch you get to create the stein series https://bugs.launchpad.net/nova
15:38:40 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: block_device: Rollback volumes to in-use on DeviceDetachFailed https://review.openstack.org/590803
15:38:41 melwitt ok
15:39:28 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: block_device: Rollback volumes to in-use on DeviceDetachFailed https://review.openstack.org/590804
15:39:44 melwitt mriedem: were you thinking of the DeviceDetachFailed one for rc2? from what I understand, we release rc2 from stable/rocky so we hold non-rc2 things until after the final rocky release deadline
15:40:55 mriedem melwitt: we can, but it's also extremely low risk
15:41:00 mriedem and we'll backport it anyway
15:41:13 melwitt ok, just making sure I understood
15:42:01 SteelyDan that one is a regression so it makes sense anyway right?
15:42:17 melwitt mriedem: I thought we already have a stein series? https://launchpad.net/nova/stein
15:42:38 mriedem SteelyDan: yes it is, and we also backported it to queens and pike
15:42:41 mriedem so it's going back either way

Earlier   Later