Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-06
17:01:28 openstackgerrit Dan Smith proposed openstack/nova master: Bump compute RPC API to version 5.0 https://review.openstack.org/541005
17:01:48 kashyap dansmith: At least, QEMU migratoin upstream said: "If Nova can define a need, we can add a tunable that libvirt can use"
17:02:08 dansmith ++
17:03:08 stephenfin dansmith: <3 I've been waiting for RPC version bumps for aaaaages
17:03:41 stephenfin Mostly thanks to lots of comments from ndipanov saying we can cruft in virt/hardware when that happens
17:03:44 dansmith stephenfin: don't review it yet.. still working out the bugs. I think this iteration is close, but need tempest tests
17:04:04 dansmith stephenfin: well, then you need to look at those notes and make sure I've got the bits that need to be removed
17:04:16 stephenfin I can do that
17:04:23 dansmith stephenfin: I've deprecated the things I know about, but if there are others, now's the time...
17:06:32 gibi bauzas: could you look at https://review.openstack.org/#/c/525242 again? (and the one below)
17:06:45 gibi bauzas: mriedem is already +2 on both
17:06:48 bauzas fortunately I have https://docs.openstack.org/nova/latest/user/block-device-mapping.html for help
17:07:00 bauzas gibi: only if that's super quick
17:07:22 gibi bauzas: you already reviewed it :)
17:07:32 gibi bauzas: so I hope it is a quick one
17:07:33 bauzas gibi: I'm reviewing mriedem's change https://review.openstack.org/#/c/539739/4 that requires some BDM knowledge
17:07:49 bauzas ^ RC1 blocker, your call, core
17:08:05 mriedem did you lay down a guantlet just now?
17:08:18 mriedem *gauntlet even
17:08:23 gibi bauzas: sure, the LUKS patch has priority
17:09:12 bauzas hah, no
17:09:53 bauzas for the first time of my poor life, I have the opportunity to understand the BDM mess^H^H implementation
17:10:52 dansmith only 341 things in check.. I look forward to my CI results later in the week
17:12:17 bauzas dansmith: yeah like I said to hrw, that GMT morning was awful
17:21:14 kashyap stephenfin: Quickly, for your point on that live migration issue -- yeah, for the immediate term, we may have to go with the ugly hack of slowing the n/w bandwidth. Until we figure out a way to stop migration much earlier in Nova.
17:22:20 bauzas mriedem: nit on https://review.openstack.org/#/c/539739/4/nova/tests/unit/virt/libvirt/test_driver.py@10523 that prevents me to +2 except if you add it in a follow-up (given the gate delays)
17:23:28 bauzas mriedem: do you agree with me on the fact that serial and volume_id should have the same values ?
17:31:04 dansmith hmm
17:31:09 dansmith looks like we just had a zuul reset?
17:31:58 mriedem bauzas: replied
17:32:03 mriedem i specifically wanted those to be different
17:32:10 mriedem so that we take volume_id over serial if both are in connection_info
17:33:17 bauzas okay, I don't want to overthink on that
17:33:22 bauzas +2ing
17:33:58 mriedem the DriverVolumeBlockDevice.attach code only sets the serial to the volume_id iff 'serial' isn't already in the connection_info,
17:34:08 mriedem so once again, some cinder volume driver could theoretically be returning a 'serial' value
17:34:20 bauzas yeah I saw the conditional
17:34:33 mriedem so if volume_id, use it, else hope that serial is correct
17:34:35 bauzas I love those conditions actually
17:35:14 bauzas tbh, the best would be to tell the cinder storage drivers "please, don't give us information, we'll find out by ourselves, it's better ;) '
17:35:47 mriedem a couple of years ago i talked about adding a versioned object for the connection_info dict to cinder,
17:35:48 bauzas since we set the right value in serial if that's not already in there
17:35:52 mriedem to try and normalize a lot of that stuff
17:36:08 mriedem but, i didn't pursue it
17:36:15 bauzas your fault, then
17:36:17 bauzas boooo
17:36:23 mriedem sort of like the MigrateData thing that dansmith did for live migration
17:36:33 bauzas yup
17:36:39 mriedem yes it's my fault, sadly enough,
17:36:48 mriedem it would have also meant converting like 80 volume drivers over to that new model...
17:37:48 bauzas :)
17:38:43 ildikov yeah, this comes up every half year and we note that harmonize the drivers is just not likely to happen
17:39:11 ildikov or you end up with a free-form part where most of the info sits anyway...
17:43:53 bauzas mriedem: I haven't seen https://etherpad.openstack.org/p/nova-aggregate-filter-allocation-ratio-snafu somehow planned for the PTG in the PTG etherpad
17:44:02 bauzas mriedem: ack if I'm adding it?
17:45:55 mriedem jaypipes had a thing in the ptg etherpad for this issue,
17:45:57 mriedem i'll link it in
17:46:25 mriedem starts at L34 in https://etherpad.openstack.org/p/nova-ptg-rocky
17:48:44 bauzas cool
17:50:00 mriedem it's enchilada time!
17:53:38 dansmith mriedem: remind me what the legacy-tempest job is?
17:53:53 dansmith it's failing my service version patches for seemingly related reasons, but the regular job is fine
17:54:51 mriedem hmm, legacy-tempest shouldn't be running on our stuff
17:54:54 mriedem i don't think
17:55:17 mriedem that was replaced by tempest-full
17:55:30 dansmith legacy-tempest-dsvm-py35FAILURE in 1h 14m 39s
17:55:33 dansmith on one of my patches
17:55:39 dansmith https://review.openstack.org/#/c/539590/
17:55:43 mriedem oh that's different
17:55:56 mriedem it's just tempest with devstack on py35
17:56:15 dansmith tbachman: no
17:56:19 dansmith mriedem: hmm, wonder why it failed
17:56:27 tbachman dansmith: thx
17:56:29 mriedem dansmith: http://logs.openstack.org/90/539590/2/check/legacy-tempest-dsvm-py35/79137ee/job-output.txt.gz#_2018-01-31_19_33_29_779861
17:56:40 mriedem likely something in the reserve_block_device_name rpc call?
17:56:49 dansmith mriedem: right, hence my "seemingly related reason"
17:57:00 dansmith no, it's because we check for service version before allowing tags
17:57:06 dansmith which is what that patch is doing
17:57:17 dansmith s/doing/changing/
17:57:21 dansmith s/changing/touching/
17:57:43 bauzas mriedem: mgagne: just added a thought on a possible workaround for https://review.openstack.org/#/c/541018/
17:58:04 bauzas mriedem: mgagne: tl;dr just set allocation ratios on every compute to be 99999.0
17:58:17 sean-k-mooney cfriesen: stephenfin yes numa support is off by default in dpdk so that libnuma can remain an optional dependecy not a required depency of dpdk
17:58:26 mriedem dansmith: maybe "if result is" is different in py35
17:58:33 mriedem i don't see much "foo is bar"
17:58:50 bauzas mriedem: mgagne: that will allow Placement to accept all the hosts, and just keep the filtering logic in the appropriate AggregateRAMFilter and so on
18:00:25 dansmith mriedem: um, which thing are you talking about?
18:00:26 kashyap I'm Neutron-challenged, can anyone tell at _which_ of these points is Nova waiting (by pausing) on Neutron to let it complete things? http://git.openstack.org/cgit/openstack/neutron/commit/?h=master&id=b7c303e ("Notify nova with network-vif-plugged in case of live migration")
18:00:29 dansmith the sentinel check has to be "is"
18:01:21 kashyap "during live migration on pre migration" is terribly unclear
18:02:52 dansmith kashyap: nova waits when it uses the virtapi wait_for_events context manager
18:02:53 dansmith it waits to exit the context until timeout or the event arrives
18:03:22 kashyap I see.
18:03:44 kashyap Is this what the Neutron events telling Nova:
18:04:00 kashyap "Hey, I've done with doing all the stuff I need to do, so I'm signalling that by sending out this event (from the above Neutron commit). Over to you now."
18:04:22 kashyap I.e. the destination Neutron has completed virtual interface plugging.
18:04:40 dansmith yes
18:04:54 dansmith I mean, that's what vif-plugged means
18:05:24 kashyap Noted.
18:05:31 stvnoyes mriedem: matt, I added a change to enable multiattach on the zfssa array, but when tempest runs during the zfssa ci, it's not running with multiattach enabled (in tempest.conf). Where would I make a change to have this enabled when running the Oracle ZFSSA CI? thanks...

Earlier   Later