Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-04
20:22:03 artom mriedem, so there's this 2 x 2 matrix of stuff
20:22:10 artom we have tagged boot / tagged attach
20:22:11 mriedem that's basically what i was saying we'd do in those two cases for multiattach too - check the min compute service version and fail if computes aren't upgraded yet
20:22:20 artom And compute manager supports it / virt driver supports it
20:22:57 artom For tagged boot, we used the service level check to see if compute manager supports it
20:23:12 artom For tagged boot/virt driver... I forget how we handled it
20:23:21 mriedem we just fail in the compute
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 mriedem yeah that one is easy
20:25:28 artom (Obviously)
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 edleafe mriedem: so it seems that the bug I found was the result of a race
20:27:22 artom Though I guess we if we relay the exception properly, it's not a massive deal
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 artom mriedem, so give this lack of feedback to the user, it's probably better to fail fast in the API, no?
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: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: WIP Support aggregate affinity filters https://review.openstack.org/529201
20:42:59 openstackgerrit Jay Pipes proposed openstack/nova master: Remove server group sched filter support caching https://review.openstack.org/529200
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: [libvirt] Allow multiple volume attachments https://review.openstack.org/267587
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:12 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Pass multiattach flag to reserve_block_device_name https://review.openstack.org/531244
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: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?

Earlier   Later