| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-06 | |||
| 16:39:17 | cfriesen | sean-k-mooney: just curious, why is numa support in dpdk off by default? seems like that'd be a good thing. | |
| 16:41:11 | mriedem | melwitt: comments in https://review.openstack.org/#/c/515008/ since sahid asked for review and left | |
| 16:42:08 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 16:46:28 | stephenfin | cfriesen: I'm not sean-k-mooney, but I'm guessing it's the need for an extra dependency? | |
| 16:49:23 | bauzas | mriedem: I have a noob question, how can you know that vol.volume_id is set in https://review.openstack.org/#/c/539739/4/nova/virt/libvirt/driver.py@7430 . | |
| 16:49:24 | bauzas | ? | |
| 16:51:39 | mriedem | bauzas: because when we attach a volume to an instance, we save the volume_id on the bdm record, | |
| 16:51:50 | mriedem | see nova.virt.block_device.DriverVolumeBlockDevice.attach | |
| 16:52:05 | mriedem | DriverVolumeBlockDevice wraps an proxies a BlockDeviceMapping object, | |
| 16:52:22 | mriedem | and the @update_db decorator on attach() updates the wrapped bdm object | |
| 16:53:34 | mriedem | i should say that is the case for bfv with source type blank/image/snapshot where nova creates the volume and then attaches it, | |
| 16:53:53 | mriedem | for normal volume attach to an existing instance, the bdm is created in compute here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5220 | |
| 16:53:54 | bauzas | ok, looking at the code | |
| 16:53:56 | mriedem | with the volume_id | |
| 16:56:11 | hrw | zuul forgot about me ;( 7h since patch upload and no results | |
| 16:56:33 | bauzas | hrw: you probably haven't see the gate status | |
| 16:56:46 | bauzas | they had problems in the morning with very slow processing | |
| 16:56:51 | hrw | bauzas: probably | |
| 16:57:35 | kashyap | dansmith: Okay, after talking to libvirt and QEMU migration maintainers, you're right in pointing out here: https://review.openstack.org/#/c/497457/18/nova/virt/libvirt/driver.py | |
| 16:57:39 | kashyap | That... | |
| 16:57:40 | hrw | ok I see | |
| 16:57:45 | kashyap | dansmith: It is an absolutely horrible hack | |
| 16:58:10 | kashyap | dansmith: ...to slow down migration via by limiting the speed to 1 MiB/s | |
| 16:58:11 | dansmith | kashyap: Well, I know it's a hack, but wasn't sure if there was another option :) | |
| 16:58:25 | hrw | bauzas: will see. in worst case 'recheck' in the morning tomorrow | |
| 16:58:56 | bauzas | hrw: you know the status page or not ? | |
| 16:59:00 | kashyap | dansmith: Discussing the design aspects w/ them. I have a half-comment in draft, will complete it in a bit :-) | |
| 16:59:07 | dansmith | kashyap: excellent, thanks! | |
| 16:59:08 | kashyap | dansmith: Just wanted to confirm your instinct :P | |
| 16:59:14 | hrw | bauzas: https://wiki.openstack.org/wiki/Infrastructure_Status one? | |
| 16:59:14 | dansmith | kashyap: awesome :P | |
| 17:00:14 | stephenfin | (I looked at the underlying bug and also assumed there wasn't an alternative) | |
| 17:00:41 | bauzas | hrw: http://zuul.openstack.org/ and http://status.openstack.org/openstack-health/#/ | |
| 17:01:07 | hrw | thx | |
| 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:28 | openstackgerrit | Dan Smith proposed openstack/nova master: Compute RPC client bump to 5.0 https://review.openstack.org/541035 | |
| 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 | |