| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-17 | |||
| 16:06:41 | mriedem | mkoderer: dgonzalez: because that method is called from a few different operations | |
| 16:08:48 | rabel_b1 | mriedem: ok, thank you very much. | |
| 16:09:36 | mriedem | dgonzalez: ah i see your patch now | |
| 16:43:59 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Plumbing for tagged nic attachment https://review.openstack.org/415622 | |
| 16:44:01 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Delete nic metadata when detaching interface https://review.openstack.org/435387 | |
| 16:44:03 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Libvirt support for tagged volume attachment https://review.openstack.org/418100 | |
| 16:44:08 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Delete disk metadata when detaching volume https://review.openstack.org/435082 | |
| 16:44:15 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Plumbing for tagged volume attachment https://review.openstack.org/391941 | |
| 16:44:16 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: API support for tagged device attachment https://review.openstack.org/376021 | |
| 16:44:29 | openstackgerrit | sean mooney proposed openstack/nova master: do not set vcpu_pin elements when virt_type=qemu https://review.openstack.org/465160 | |
| 16:47:15 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Plumbing for tagged nic attachment https://review.openstack.org/415622 | |
| 16:47:17 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Delete nic metadata when detaching interface https://review.openstack.org/435387 | |
| 16:47:19 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Libvirt support for tagged volume attachment https://review.openstack.org/418100 | |
| 16:47:24 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Delete disk metadata when detaching volume https://review.openstack.org/435082 | |
| 16:47:31 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Plumbing for tagged volume attachment https://review.openstack.org/391941 | |
| 16:47:32 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: API support for tagged device attachment https://review.openstack.org/376021 | |
| 16:47:36 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Libvirt support for tagged nic attachment https://review.openstack.org/415520 | |
| 17:04:23 | cfriesen | where does ServerExternalEvents run? is this part of nova-api? | |
| 17:05:43 | cfriesen | bah, never mind, just noticed the full path to the file | |
| 17:11:37 | openstackgerrit | Matthew Booth proposed openstack/nova master: Add a method signature test for all virt drivers https://review.openstack.org/465676 | |
| 17:12:26 | mdbooth | Honestly I was expecting that to find things. Surprised it didn't. | |
| 17:14:15 | mdbooth | lyarwood: Added ^^^ when I noticed your change to swap_volume, also your previous reluctance to change detach_volume. This test should make those things easier. | |
| 17:20:15 | artom | mdbooth, I thought we already tested virt drivers's method signatures... Were some drivers missing from the list? | |
| 17:22:08 | mdbooth | artom: Where do we test it? | |
| 17:22:28 | mdbooth | Although that would explain why they all match :) | |
| 17:22:46 | artom | mdbooth, ah, I think they're individual tests in each driver | |
| 17:23:05 | artom | http://paste.openstack.org/show/609828/ | |
| 17:23:14 | artom | I know I remembered getting method signature errors | |
| 17:25:43 | mdbooth | That's incredibly similar to mine, except not recursive | |
| 17:25:52 | mdbooth | I needed recursive for the volume drivers | |
| 17:26:04 | mdbooth | Although I hadn't noticed that existed already | |
| 17:26:31 | mdbooth | I wonder why it doesn't have to handle wrapped methods | |
| 17:28:41 | artom | mdbooth, I agree your way is better - it doesn't depend on each driver doing their own tests correctly | |
| 17:28:52 | mdbooth | Ah... HyperV munges it. | |
| 17:29:09 | mdbooth | artom: Meh, it's only important that it's checked, tbh. | |
| 17:29:44 | artom | mdbooth, I suppose the only issue with the current tests is if a new virt driver gets added and forgets them | |
| 17:29:48 | artom | But that doesn't seem likely | |
| 17:30:12 | mdbooth | Well powervm.PowerVMDriver already wasn't added to the DriverMethodTestCase | |
| 17:30:13 | artom | Also, you've included PowerVM | |
| 17:30:17 | mdbooth | Although that case is stupid | |
| 17:30:23 | artom | Which isn't in the list I got | |
| 17:32:05 | mdbooth | artom: Can you note on the review that we already do that? I'll probably abandon it, and/or update my recursive test to use the existing method. | |
| 17:32:38 | artom | mdbooth, sure | |
| 17:32:45 | mdbooth | artom: Thanks | |
| 17:35:43 | artom | mdbooth, there. I didn't even -1 it ;) | |
| 17:38:52 | mriedem | cfriesen: did you happen to catch the sriov bug armax was asking about last night? | |
| 17:40:28 | armax | mriedem: btw talking to gyee_ it seems the issue happens in Newton still | |
| 17:43:56 | gyee_ | I am curious why we are using NopClaim if host is specified https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2771 | |
| 17:44:21 | gyee_ | does specifying a host implies force evacuate? | |
| 17:49:07 | gyee_ | meanwhile if SR-IOV is enabled, we are trying to get the PCI mapping via the migration context, which is only populated at rebuild_claim. https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L2462 | |
| 17:51:31 | mriedem | https://github.com/openstack/nova/commit/dc0221d7240326a2d1b467e2a367bebb7e764e61 added that code in the compute manager about the nop claim, which implies resources were already claimed, but i'd have to dig into that | |
| 17:56:36 | mriedem | yikes, that was part of a big series https://review.openstack.org/#/q/topic:bug/1417667 | |
| 17:57:37 | gyee_ | but I don't see where the resource is being claimed, if the host is specified | |
| 17:57:53 | openstackgerrit | Gage Hugo proposed openstack/nova master: Admin API Policy contingent on is_admin_project https://review.openstack.org/384148 | |
| 17:58:00 | mriedem | gyee_: i'm also looking for that | |
| 18:03:50 | gyee_ | mriedem: I don't think that's being done. The migration_context in instance_extra table is empty if host specified, regardless if SR-IOV is enabled or not | |
| 18:06:21 | mriedem | gyee_: as far as i can tell, the only way to get the noop claim is if the user specifies the host and --force | |
| 18:07:01 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4115 | |
| 18:07:20 | mriedem | if the host is specified but force is not, then the api nulls out host when calling conductor | |
| 18:07:39 | gyee_ | I didn't use the --force option. Just merely specifying the host. | |
| 18:07:54 | mriedem | which gets to this else block https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L751 | |
| 18:08:08 | mriedem | node would eventually be set here https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L770 | |
| 18:08:15 | mriedem | and passed to compute as scheduled_node | |
| 18:08:43 | mriedem | which should get the rebuild_claim here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2769 | |
| 18:08:56 | mriedem | dansmith: do you remember anything about not doing a claim if the host is forced during evacuate? | |
| 18:09:41 | dansmith | mriedem: no | |
| 18:10:01 | dansmith | mriedem: I would think you'd get a new claim on the new compute node, and then drop the old one when the dead compute comes up a deletes the old instance | |
| 18:12:01 | mriedem | i'm not sure why we have this then https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2771 | |
| 18:12:31 | dansmith | mriedem: well for a regular rebuild | |
| 18:12:46 | mriedem | oh...yeah | |
| 18:12:47 | dansmith | regular rebuild is in place | |
| 18:13:01 | mriedem | original commit message says "Also - if we called the scheduler, we also know the node of the chosen host, and the limits set, and this information is needed for doing claims." | |
| 18:13:17 | mriedem | but yeah, | |
| 18:13:24 | mriedem | i suppose the noop claim is there for rebuild on the same host | |
| 18:13:25 | mriedem | not evacuate | |
| 18:13:29 | sdague | efried: I'm pushing in your devstack console color fix, thanks again for that | |
| 18:13:29 | mriedem | god | |
| 18:13:58 | mriedem | at some point we should just split the evacuate and rebuild code apart in the compute manager | |
| 18:14:53 | gyee_ | ++ | |
| 18:15:01 | mriedem | i think you can also specify a host for rebuild | |
| 18:15:50 | mriedem | oh no nvm | |
| 18:15:54 | mriedem | i was thinking of another bug, | |
| 18:16:14 | mriedem | where you change the image and the new image meta for the rebuild doesn't work with the original host, but we don't validate that | |
| 18:16:56 | mriedem | gyee_: then i think all you need to do is add an "or recreate" to this conditional https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2767 | |
| 18:17:05 | mriedem | gyee_: do you have a recreate of the bug? | |
| 18:19:01 | gyee_ | mriedem: I haven't file a bug for Nova yet | |
| 18:19:04 | gyee_ | about to do so | |
| 18:19:18 | mriedem | gyee_: oh we have a bug | |
| 18:19:20 | mriedem | well MOS does | |
| 18:19:23 | mriedem | but we can add nova to that | |
| 18:19:49 | cfriesen | question about RPC (with standard rabbitmq/kombu messaging): are incoming messages on nova-compute immediately grabbed by an eventlet? I'm seeing huge lock contention on the 'refresh_cache-%s' lock between the live migration code and external events coming in from neutron | |
| 18:19:57 | gyee_ | do I have perm to do that? Sorry I am still new to Nova. | |
| 18:20:01 | mriedem | gyee_: https://bugs.launchpad.net/mos/+bug/1658070 | |
| 18:20:01 | openstack | Launchpad bug 1658070 in Mirantis OpenStack "Failed SR_IOV evacuation with host" [Medium,Confirmed] | |
| 18:20:32 | gyee_ | oh good :-) | |
| 18:24:43 | cdent | bauzas, dansmith: sorry for beating a dead horse, but I need some help understanding https://review.openstack.org/#/c/465175/ (returning alternatives) | |
| 18:25:08 | cdent | edleafe too | |
| 18:25:12 | gyee_ | mriedem: thanks for the help! | |
| 18:25:34 | dansmith | cdent: what about it? | |
| 18:25:36 | mriedem | gyee_: np, you did the hard debug already, | |