| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-04 | |||
| 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 | |
| 21:49:29 | jaypipes | ab2434_: but why should Nova twist and turn to satisfy the needs of one particular VNF? :) | |
| 21:50:09 | jaypipes | ab2434_: especially when said VNF isn't *really* a VM but instead just hardware masquerading as software ;) | |
| 21:50:18 | jaypipes | but I digress... | |
| 21:50:22 | ab2434_ | well. it boils down to the mapping, having nova provide a way to map the ports | |
| 21:50:55 | ab2434_ | for the sdn-f to configure the correct switch /port for the vm | |
| 21:52:04 | mriedem | do vif tags not work here? | |
| 21:52:06 | jaypipes | ab2434_: my point is this: if the Neutron port binding can be decorated with the switch group or port tag, then that information can be passed down to Nova (in the instance PCI request) and used to identify the physical function that should be selected for the VM. what is being proposed here is the opposite of that design. the proposal here is to essentially inventory the topology and hardware for the entire deployment ahead of time and | |
| 21:52:07 | jaypipes | pre-schedule/place VMs that consume specific PCI devices on specific hardware all at once. | |
| 21:52:17 | jaypipes | it's the opposite of cloud... the opposite of on-demand. | |
| 21:52:43 | ab2434_ | ok | |
| 21:55:12 | jaypipes | ab2434_: the world that we (Nova/OpenStack, whatever) is trying to get to is a world where the VNFs/applications *describe to Nova the resources and traits that it needs* and Nova goes and finds an appropriate place for that workload to land and devices to consume. What the world that NFV is trying to force on Nova is the opposite of that: a world where a VNF says to Nova "hey, put me on node X and PF Y and use VF foo. Oh, and also pin me to | |
| 21:55:12 | jaypipes | CPUs 1-12, 18-24 and NUMA cell 0." | |
| 21:56:07 | ab2434_ | yes i see your point | |
| 21:56:09 | jaypipes | ab2434_: it's this incongruence of worldviews that is at the root of the issue I think. | |
| 21:56:58 | jaypipes | ab2434_: and yes, I understand I work for Verizon (used to be AT&T) and that certain groups at Verizon think that OpenStack should just get on with the business of being an NFVI and nothing more ;) | |
| 21:58:43 | tonyb | kashyap, mriedem: we had the beginings of one but it bitrotted. We could look at reviving it after the PTG. | |
| 21:59:24 | mriedem | tonyb: i don't think that job is useful anymore now that we're using the pike UCA by default in devstack | |
| 22:00:04 | tonyb | mriedem: Yeah the UCA stuff was always s'posed to be a POC the real plan was to have a tandem repo where we built tagged snapshots and use that | |
| 22:03:04 | tonyb | mriedem: At times there is a reasonable Fedora$current image, if ianw_pto has that working we can use the std. virt repo for Fedora also (again that was part of the plan) | |
| 22:03:48 | tonyb | mriedem, kashyap: I'm really happy to help revive that work QA, Neuton and infra all want somethign like that I just can't really be the driver | |
| 22:05:54 | jaypipes | efried: still around? | |
| 22:06:59 | jaypipes | efried: so... this will fail a functional test: https://review.openstack.org/#/c/531243/ and I'm not entirely sure why. perhaps if you're around later you could pull that patch and have a looksie? it looks like the instance creation ain't actually working. | |
| 22:07:12 | mriedem | mdbooth: so, long-term we should probably store the multiattach value on the bdm record... | |
| 22:07:15 | mriedem | the more i think about it | |
| 22:07:19 | mriedem | just like a tag | |
| 22:07:20 | jaypipes | efried: in any case, meh, will hit it later and tomorrow but if you have any time, could use your eyeballs. | |