| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-06 | |||
| 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... | |
| 18:05:43 | sean-k-mooney | dansmith: actully vif-plugged has different menanings | |
| 18:06:13 | sean-k-mooney | vif-plugged in the nova-compute agent log means os-vif finisshed plugging the interface | |
| 18:06:33 | sean-k-mooney | vif-plugged event form neutron means neutron finished wireing it up | |
| 18:06:54 | dansmith | sean-k-mooney: we're talking about when neutron does a POST of the event to nova's external event interface | |
| 18:07:27 | dansmith | and it better (still) mean that the wiring is done, else we have a problem :) | |
| 18:07:32 | mriedem | stvnoyes: do you have these set in devstack? https://github.com/openstack/nova/blob/master/playbooks/legacy/nova-multiattach/run.yaml#L31 | |
| 18:07:46 | sean-k-mooney | dansmith: ah then yes that is sent when neutron finishes wiring up the port that was plugged by nova/os-vif/libvirt into the network backend so your correct in what you said | |
| 18:08:17 | mriedem | stvnoyes: also, is tempest running against master nova so the 2.60 microversion is available? | |
| 18:08:37 | dansmith | sean-k-mooney: thanks :) | |
| 18:09:16 | kashyap | sean-k-mooney: Hey, I'm about to write some questions on this change: https://review.openstack.org/#/c/497457/18 | |
| 18:09:26 | kashyap | sean-k-mooney: Post some design discussion w/ QEMU & libvirt folks | |
| 18:09:39 | kashyap | Would appreciate if you also look at it | |
| 18:10:24 | sean-k-mooney | kashyap: am i am behind in some internal paper work but ill try and take a look tomorow | |
| 18:10:37 | kashyap | sean-k-mooney: Sure, tomm is fine; I'm already late for dinner by an hour | |
| 18:10:55 | kashyap | Just want to 'commit this to paper' before my "cache gets flushed" | |