| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-04 | |||
| 13:39:04 | jaypipes | efried: doing so would probably lead to a lot of dup code. | |
| 13:39:17 | efried | Mapping devices to RPs? virt driver. | |
| 13:39:49 | efried | sahid The only "work in progress" is scribbles on etherpads, which we discussed at the PTG. | |
| 13:40:09 | sahid | efried: yes i was not here, if you can give me the link | |
| 13:40:32 | efried | sahid https://etherpad.openstack.org/p/nova-ptg-queens-generic-device-management | |
| 13:40:49 | efried | sahid It has generally been a drive towards understanding how devices are going to be managed once we go full-bore with placement & resource providers | |
| 13:40:59 | efried | sahid The goal being to get rid of the existing PCI manager code. | |
| 13:41:25 | mriedem | gmann_sleep: doesn't it seem odd that we still have this filtering code when listing instances to be able to filter by metadata and system_metadata? https://github.com/openstack/nova/blob/master/nova/compute/api.py#L2328-L2332 | |
| 13:41:32 | mriedem | i thought that was a 400 in the API now | |
| 13:41:56 | mriedem | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L182 | |
| 13:42:14 | efried | jaypipes Potentially duplication among the linuxy hypervisors, I suppose. I would still expect the code to ultimately run under the auspices of the virt driver. | |
| 13:42:15 | sahid | efried: no transition phase as suggested jaypipes by adding a update_from_inventory() method to the PciManager? | |
| 13:43:15 | efried | jaypipes So I could see having some shared class above the ComputeDriver base class that provides linuxy impls for devicey methods. | |
| 13:44:15 | efried | sahid Well, the cores have made their position pretty clear: Investment in the existing PCI manager is going to be very limited. | |
| 13:46:19 | efried | sahid That said, I think it may be possible to get very close to what you want just using NRP with traits and careful modeling, which is happening in Queens. | |
| 13:46:44 | efried | sahid Fancy use cases like (anti)affinity won't work yet. | |
| 13:46:49 | jaypipes | efried: yeah, we're gonna need to have some sort of transitionary plan anyway... | |
| 13:47:33 | efried | jaypipes Oh, like sahid is saying with update_from_inventory() - presumably a RT method that peels dev info out of the virt inventory and flushes it back to the PCI manager? | |
| 13:47:54 | jaypipes | efried: chatting with dansmith and bauzas, I'm cool with trying to get single-inventory VGPU support pushed for Queens if we miss nested resource provider targets. That would means no support for multiple GPU types on a single compute node, but would at least get some rudimentary VGPU support | |
| 13:49:08 | dansmith | jaypipes: multiple gpu types can be handled with aggregates until we have richer support, and at least one customer has told me that's fine, FWIW | |
| 13:49:18 | bauzas | efried: I just wanted to clarify how we would translate a specific {'VPGU:1"} request into something very virt-specific | |
| 13:49:18 | jaypipes | k | |
| 13:49:40 | bauzas | heh VGPUs even | |
| 13:49:41 | sahid | it seems that XenServer provides an abstraction which makes easy what you want to achieve | |
| 13:49:48 | sahid | but that does not look reasonable for libvirt | |
| 13:50:05 | efried | bauzas So the only way we're going to translate an allocation to a specific device is if the RP is modeled as representing that specific device. | |
| 13:50:31 | sahid | XenServer is doing the managmenet ofr the devices, libvirt is using the PciManager | |
| 13:50:56 | bauzas | efried: sahid: dansmith: I just feel we need code so we could chat on the details | |
| 13:51:09 | bauzas | reporting the inventory for those resource classes is easy | |
| 13:51:21 | efried | The virt driver will ultimately be responsible for designing that model, maintaining that mapping, and providing the appropriate RPs and inventory to placement (via get_inventory, or update_provider_tree, or whatever it winds up being) | |
| 13:51:25 | dansmith | bauzas: you're asking how the virt driver knows a thing has been requested? | |
| 13:51:44 | bauzas | dansmith: yup, correct | |
| 13:51:57 | dansmith | bauzas: in the simple case it can just look at extra_specs on instance.flavor | |
| 13:52:00 | bauzas | dansmith: jaypipes told me RT looks up the allocation | |
| 13:52:11 | bauzas | dansmith: yeah that was my initial approach | |
| 13:52:17 | dansmith | bauzas: we have a routine that can parse the flavor and give you a merged resource view | |
| 13:52:27 | bauzas | that would be an easy thing then | |
| 13:52:33 | bauzas | okay, I need coding then | |
| 13:52:34 | dansmith | or look at the allocation, yeah, but plumbing that from rt to virt will take a little work | |
| 13:52:49 | efried | The virt driver will be able to see the allocation, no? | |
| 13:52:51 | bauzas | yeah, for a POC, introspecting the flavor seems the quickiest path | |
| 13:52:55 | dansmith | you will need the allocation once we have n-r-p or traits though | |
| 13:53:02 | bauzas | efried: it requires a new interface which we don't have yet | |
| 13:53:02 | mriedem | these -1s from zuul messing up my dashboard is messing up my life | |
| 13:53:10 | dansmith | efried: it could fetch it itself, yeah, but better if it didn't I think | |
| 13:53:30 | bauzas | dansmith: yeah, I'm not a fan of the virt driver calling placement | |
| 13:53:36 | dansmith | bauzas: yeah, a good first step would be figuring out the best way to tell the virt driver about the allocation | |
| 13:53:45 | dansmith | bauzas: yep | |
| 13:53:52 | efried | Talking like something in the Instance object? | |
| 13:53:55 | bauzas | anyway, /me coding then | |
| 13:53:59 | dansmith | efried: no | |
| 13:54:08 | efried | param to spawn? | |
| 13:54:09 | dansmith | efried: maybe just a param in spawn | |
| 13:54:11 | dansmith | yeah | |
| 13:54:13 | efried | ight | |
| 13:54:30 | efried | btw, virt will at some point be calling placement. | |
| 13:54:33 | efried | Not necessarily in spawn | |
| 13:54:45 | bauzas | dansmith: jaypipes was thinking of a specific interface for nested RPs | |
| 13:54:57 | bauzas | dansmith: something like update_my_provider_tree() | |
| 13:54:59 | dansmith | efried: you're saying that because of virt drivers reporting resource? | |
| 13:55:01 | efried | but in init_host, and/or get_inventory, and/or update_provider_tree, whatever - to set up the RPs and whatnot. | |
| 13:55:27 | efried | Yeah, for example, to know whether a RP has been created yet. | |
| 13:55:31 | dansmith | efried: that should be abstracted by the compute manager, not virt calling placement directly | |
| 13:55:32 | dansmith | IMHO | |
| 13:55:33 | dansmith | bauzas: yep makes sense | |
| 13:55:41 | efried | dansmith Yeah, I suppose it could be. | |
| 13:55:54 | bauzas | I second dansmith on not having placement calls from the driver | |
| 13:56:02 | efried | This means virt is always responsible for producing RP UUIDs. | |
| 13:56:07 | dansmith | efried: I think we should shoot for that goal, and if there's some compelling reason to break that rule, then we can discuss it | |
| 13:56:14 | efried | dansmith Dig. | |
| 13:56:17 | bauzas | mriedem: (Zuul, Jenkins) is now the tuple to care | |
| 13:56:24 | jaypipes | dansmith: right. RT constructs the known ProviderTree. passes it to the virt driver's update_provider_tree() method, virt driver adds, removes, changes inventory and traits for resource providers in the tree, RT then saves any of those changes to placement. | |
| 13:56:36 | dansmith | jaypipes: yes, that | |
| 13:56:38 | efried | bauzas What is it you're going off to code now? | |
| 13:57:26 | bauzas | efried: I'll just update libvirt to pass vGPU resources and lookup the flavor extraspecs for plumbing a mdev | |
| 13:57:48 | efried | bauzas Pass vGPU resources from get_inventory? | |
| 13:57:55 | bauzas | correct | |
| 13:58:02 | efried | bauzas and look up flavor extra specs from spawn? | |
| 13:58:11 | bauzas | efried: yup | |
| 13:58:17 | efried | bauzas Cool. sahid ^ | |
| 14:02:28 | sahid | that seems a bit archaic - get_inventory to retourn ResourceClass.GPU and then ? you are going to hack the virt driver to read a flavor in the spawn phase? add a conditon that a vgpu, (which kind?, what numa?) and then update the XML | |
| 14:03:31 | bauzas | that's basically my intent, yes :) | |
| 14:03:54 | dansmith | 460 uses of instance.flavor in the virt drivers today | |
| 14:03:56 | dansmith | not exactly a hack | |
| 14:05:22 | sahid | It is totally a hack and it's going to provide a very basic support | |
| 14:05:53 | dansmith | yep, it's a first step to get us basic support, as stated above | |
| 14:05:53 | sahid | libvirt have a pci device manager, and it's a bad idea to just ignore it | |
| 14:07:00 | sahid | but it's a hack, no need ot RP or anything to provide that basic support | |
| 14:09:49 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add support for Windows network commands https://review.openstack.org/487405 | |
| 14:13:40 | openstackgerrit | Eric Berglund proposed openstack/nova master: WIP(5): PowerVM driver: ovs vif https://review.openstack.org/422512 | |
| 14:13:51 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add Port Profile info to VIF objects Linux Bridge plugin https://review.openstack.org/490829 | |
| 14:15:08 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add VersionedObjectPrintable mixin https://review.openstack.org/493082 | |
| 14:18:47 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix test_get_volume_config method https://review.openstack.org/489467 | |
| 14:20:39 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test resource allocation during soft delete https://review.openstack.org/495159 | |
| 14:20:39 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: factor out compute service start in ServerMovingTest https://review.openstack.org/503037 | |
| 14:23:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove unused get_all_instance_*metadata methods https://review.openstack.org/508299 | |
| 14:23:11 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Stop joining on system_metadata when listing instances https://review.openstack.org/508335 | |
| 14:23:11 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove old compat code from servers ViewBuilder._get_metadata https://review.openstack.org/508326 | |
| 14:23:12 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove system_metadata loading in Instance._load_flavor https://review.openstack.org/508357 | |
| 14:24:57 | dansmith | jaypipes: bauzas: stephenfin: easy +W on this cleanup: https://review.openstack.org/#/c/508299/2 | |