| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-04 | |||
| 20:23:24 | mriedem | and raise BuildAbortException | |
| 20:23:50 | artom | Ah, right, hopefully rescheduling to a virt driver that supports it | |
| 20:23:57 | mriedem | no, we don't reschedule | |
| 20:24:09 | mriedem | BuildAbortException means abort, don't reschedule | |
| 20:24:14 | artom | Ah, ok | |
| 20:24:28 | artom | Yeah, that's not awesome, but no other way of doing it I guess | |
| 20:24:31 | mriedem | BuildRescheduledException means kick edleafe in the head a few times | |
| 20:24:43 | artom | And then for tagged attach... | |
| 20:25:05 | artom | I think they were all RPC calls down to the compute | |
| 20:25:13 | artom | So virt driver support was straightforward | |
| 20:25:25 | artom | Except for shelved offloaded, which was a cast | |
| 20:25:28 | artom | (Obviously) | |
| 20:25:28 | mriedem | yeah that one is easy | |
| 20:25:35 | mriedem | unless the server is shelved offloaded | |
| 20:25:42 | artom | So that one we decided to just fail in the API | |
| 20:25:52 | mriedem | in the case of shelved offloaded, we don't do anything with the compute b/c there is no compute | |
| 20:25:58 | artom | Instead of having the unshelve fail like, 3 years later | |
| 20:26:13 | mriedem | yeah, i'm saying, i think at a minimum we could do the same for shelved offloaded as we do for tagged boot which is check the service version | |
| 20:26:39 | mriedem | we don't reschedule on an unshelve failure, but we don't reschedule on a tagged boot failure either | |
| 20:26:43 | mriedem | so it's basically the same | |
| 20:26:57 | artom | One is definitely more immediate than the other | |
| 20:27:22 | artom | Though I guess we if we relay the exception properly, it's not a massive deal | |
| 20:27:22 | edleafe | mriedem: so it seems that the bug I found was the result of a race | |
| 20:27:32 | edleafe | The call to retry on https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4087 runs the retry before the 'finally:' clause reight below it gets hit. | |
| 20:27:44 | edleafe | If I add the call the self._revert_allocation() before L4087, the test I wrote passes. | |
| 20:27:53 | artom | Like, if nova show unshelved-instance has 'you unshelved on a virt that doesn't support tagging' somewhere in there (but more cloudy) it can work | |
| 20:28:14 | mriedem | edleafe: ah just like the thing we hit in the other patch | |
| 20:28:23 | mriedem | need to cleanup the allocation before casting to conductor | |
| 20:28:56 | mriedem | artom: we'd record a fault | |
| 20:28:58 | mriedem | that's about it | |
| 20:29:00 | edleafe | mriedem: do you have a fix for the caching scheduler? Or should I do that? | |
| 20:29:16 | artom | mriedem, is that obvious to the user? | |
| 20:29:18 | mriedem | edleafe: https://review.openstack.org/#/c/531220/ | |
| 20:29:31 | mdbooth | mriedem: My patch series removes it from swap_volume, btw, but not surprised by the others. | |
| 20:29:32 | mriedem | artom: not really, the fault's traceback is only available to admins | |
| 20:29:55 | mriedem | mdbooth: swap_volume is the one case where i don't think this matters because we don't rely on the conf.shareable attribute | |
| 20:29:55 | artom | mriedem, so give this lack of feedback to the user, it's probably better to fail fast in the API, no? | |
| 20:30:23 | mriedem | artom: maybe | |
| 20:30:29 | mriedem | i can see the argument for being consistent | |
| 20:30:34 | mdbooth | mriedem: Ok, so how can we flag this as a second connection_info wart? | |
| 20:30:47 | mriedem | mdbooth: 2nd as in device_path is #1? | |
| 20:30:52 | artom | mriedem, what's the issue we see with multiattach though? | |
| 20:31:03 | mdbooth | I mean there's this and also device_path | |
| 20:31:13 | edleafe | mriedem: ah, I just saw the test patch | |
| 20:31:19 | mdbooth | mriedem: Right, yeah. What you said :) | |
| 20:31:21 | artom | I haven't followed closely, so it may or may not be worth it to dump all the context on me for whatever my opinion is worth ;) | |
| 20:31:35 | mriedem | artom: nothing - i'm just weighing options since we don't have the api plumbed in for all of the multiattach stuff | |
| 20:31:41 | mriedem | so i'm thinking through how to handle this, | |
| 20:31:50 | mriedem | because the backend capabilty checking is the same as with tagged attach | |
| 20:32:19 | mriedem | and i need to get out of my head sometimes | |
| 20:32:37 | mriedem | mdbooth: i'm not sure how to flag this | |
| 20:32:41 | artom | Are we talking about attaching to a shelved offloaded instance? And we don't know whether the eventual compute would support it? | |
| 20:32:51 | mriedem | artom: correct | |
| 20:33:11 | mdbooth | mriedem: I don't think there's a good central focal point for connection_info cruft. Which is another problem, tbh. | |
| 20:33:39 | jackie-truong | sdague: The nova-queens-blueprint-status etherpad mentioned that you needed Johns Hopkins to sync up with you on the certificate validation feature | |
| 20:34:20 | artom | mriedem, so exactly the same problem? 1. check that compute manager is new enough 2. check that virt driver supports it | |
| 20:34:28 | artom | Or is multi-attach virt-agnostic? | |
| 20:35:18 | jackie-truong | sdague: We created an etherpad (https://etherpad.openstack.org/p/queens-nova-certificate-validation) to walk through usage and testing. Let me know if you need more information or have any questions. | |
| 20:35:45 | mriedem | artom: it's the same problem | |
| 20:36:04 | mriedem | in queens, assuming we ship this code, only the libvirt driver will support multiattach | |
| 20:37:03 | artom | mriedem, one thing we talked about was scheduling with compute driver capabilities taken into account, probably through placement/resource providers | |
| 20:37:20 | artom | I don't think that work is ready yet, though | |
| 20:37:56 | artom | Then again, by the time multiattach lands, there might be talks of replacing placement with a new quantum-powered scheduler | |
| 20:37:58 | artom | ;) | |
| 20:39:10 | mriedem | sure, the ambiguity goes away if we had the CapabilitiesFilter aware of this and handling it | |
| 20:39:22 | mriedem | "request says it wants multiattach, find a host that supports multiattach" | |
| 20:39:23 | mriedem | done | |
| 20:40:02 | mriedem | anywho, i'll work on what i know we need to support for now, and get testing going, and then bikeshed on the rest | |
| 20:42:58 | openstackgerrit | Jay Pipes proposed openstack/nova master: allow compute nodes to be associated with host agg https://review.openstack.org/526753 | |
| 20:42:59 | openstackgerrit | Jay Pipes proposed openstack/nova master: Remove server group sched filter support caching https://review.openstack.org/529200 | |
| 20:42:59 | openstackgerrit | Jay Pipes proposed openstack/nova master: WIP Support aggregate affinity filters https://review.openstack.org/529201 | |
| 20:43:00 | openstackgerrit | Jay Pipes proposed openstack/nova master: get instance group's aggregate associations https://review.openstack.org/531243 | |
| 20:47:27 | mgagne | answering myself, legacy v2 code is still used in mitaka: https://docs.openstack.org/nova/latest/reference/stable-api.html | |
| 20:52:11 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use volume shared_targets to lock during attach/detach https://review.openstack.org/529695 | |
| 20:52:11 | openstackgerrit | Matt Riedemann proposed openstack/nova master: [libvirt] Allow multiple volume attachments https://review.openstack.org/267587 | |
| 20:52:12 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: [api] Allow multi-attach in compute api https://review.openstack.org/271047 | |
| 20:52:12 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Pass multiattach flag to reserve_block_device_name https://review.openstack.org/531244 | |
| 20:52:14 | mriedem | ildikov: here is the reserve_block_device_name change ^ | |
| 20:52:44 | ildikov | mriedem: cool, thanks! | |
| 20:58:43 | mriedem | nova meeting in 1 minute | |
| 21:20:32 | openstackgerrit | Merged openstack/os-traits master: Add NIC Switchdev feature https://review.openstack.org/508817 | |
| 21:39:03 | jaypipes | ab2434_: ok, so a couple questions for you... | |
| 21:39:13 | ab2434_ | sure | |
| 21:39:50 | jaypipes | ab2434_: question #1: if a VM consumes a VF, why should the VF's PF information be made available to it? | |
| 21:40:36 | ab2434_ | its being used for Active & Available Inventory | |
| 21:40:47 | jaypipes | ab2434_: and? | |
| 21:41:03 | ab2434_ | mainly thats it | |
| 21:41:24 | jaypipes | ab2434_: what purpose does having the PF's PCI address serve? | |
| 21:42:10 | ab2434_ | mainly for inventory | |
| 21:42:16 | ab2434_ | in this case | |
| 21:45:36 | jaypipes | ab2434_: I still don't see what purpose having the PF's PCI address serves. I mean, I can kind of see an inventory management system taking inventory of all hardware on compute hosts, but that's not what the Neutron port binding profile is for. Why doesn't AAI just, you know... inventory the systems itself? | |
| 21:45:37 | ab2434_ | one other thing is SDN-F application can configure switch port interfaces based on the mapping | |
| 21:46:38 | jaypipes | ab2434_: that particular VNF should have the *PF* assigned to the VM, then, so that it can inventory the VFs on the PF itself (and control them accordingly). no? | |
| 21:47:08 | ab2434_ | true. but there is a corresponding swith port that needs to be configured | |
| 21:47:50 | jaypipes | ab2434_: and you need the PF's PCI address in order to figure out which switch port the PF is associated with? | |
| 21:48:13 | jaypipes | ab2434_: why is the switch port or tag decorating the Neutron port binding? | |
| 21:48:22 | jaypipes | why *isn't*... | |
| 21:48:24 | jaypipes | sorry | |
| 21:48:53 | ab2434_ | i dont think thats what's happening today | |
| 21:49:22 | ab2434_ | as a side note there could be multiple switches | |