| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-29 | |||
| 15:30:30 | leakypipes | sean-k-mooney: I think everyone's in agreement that we should enable multiple device management APIs, not tie us to one or another. | |
| 15:30:53 | andreykurilin | mriedem: also, the reason of making rally job voting in neutron was an ability to check the concurrency issues | |
| 15:31:03 | sean-k-mooney | leakypipes: yes | |
| 15:31:05 | sahid | sean-k-mooney: yes really, since the beginning the point was that, vgpus can be exposed with sriov or mdev | |
| 15:31:40 | cdent | sean-k-mooney: while you’re around, can you have a look at https://review.openstack.org/#/c/504540/ you were one of the people who had some ideas on how to do allocation candidate limiting, and there now lots of ideas on that spec, but some confusion on what things we are trying to optimize | |
| 15:31:55 | sean-k-mooney | cdent: sure opening it now | |
| 15:32:00 | cdent | thanks | |
| 15:32:07 | bauzas | leakypipes: sean-k-mooney: that's one of the reasons why the vGPU spec is saying we will only pass GPU resource classes | |
| 15:32:17 | bauzas | if libvirt uses mdev, then meh | |
| 15:32:27 | bauzas | if xen is using anything else, then meh | |
| 15:32:39 | sean-k-mooney | bauzas: its nto a libvirt vs xen thing | |
| 15:32:41 | bauzas | we shouldn't just leak out the technical details | |
| 15:32:42 | sahid | it's not libvirt who is using mdev, it's the hardware driver... | |
| 15:33:04 | sean-k-mooney | at the hardware level amd uses hardware based partitioning of the gpu via sriov | |
| 15:33:12 | bauzas | whatever the solution is, the interface with the compute manager is just a resource class | |
| 15:33:17 | sean-k-mooney | intel and nvidia do it via the diriver with mdevs | |
| 15:33:48 | bauzas | for the moment, libvirt supports virtual GPUs by mdevs but that's just a temporary thing AFAICU | |
| 15:33:51 | andreykurilin | mriedem: I agree that it is difficult to compare the results from different hardware(which we have in infra), but it is not a good time for openstack and I do not know the company who are ready to give reserved hardware for a performance ci | |
| 15:34:15 | bauzas | sean-k-mooney: yeah that's the driver which provides mdev types, libvirt just gets them | |
| 15:34:17 | sean-k-mooney | bauzas: the hypervisror did nto need modifcation to work with vgpus with sriov | |
| 15:34:51 | bauzas | sean-k-mooney: not sure I get your point :) | |
| 15:35:11 | sean-k-mooney | my point is that libvirt works with amd vgpus also | |
| 15:35:27 | sean-k-mooney | you just to a pci passthough of the sriov vf | |
| 15:35:47 | bauzas | ah okay, and amd driver uses SR-IOV for that? | |
| 15:35:57 | bauzas | the AMD driver isn't using mdevs ? | |
| 15:36:05 | sean-k-mooney | yes they do the virtualisation in hardware | |
| 15:36:09 | bauzas | I see | |
| 15:36:11 | bauzas | so, the thing is | |
| 15:36:11 | sean-k-mooney | they do not use mdevs | |
| 15:36:20 | bauzas | I see baby steps here | |
| 15:36:38 | bauzas | step 1/ make sure we have something workable without adding more tech deby | |
| 15:37:07 | bauzas | step 2/ work on the generic thingy from efried and "do the work" (c) | |
| 15:37:37 | bauzas | step 3/ migrate how we track PCI devices from the old world to the new world | |
| 15:38:02 | fried_rice | ++ | |
| 15:38:12 | bauzas | hah, Friday! | |
| 15:38:28 | bauzas | holy shit, I said many times I need a ZNC bot for me | |
| 15:38:40 | mriedem | andreykurilin: http://forumtopics.openstack.org/cfp/details/55 | |
| 15:38:43 | mriedem | superdan: melwitt: ^ | |
| 15:39:23 | melwitt | cool | |
| 15:40:27 | sean-k-mooney | bauwser: makes sense, my concern is coming for interop side in that i would hope at the api level we will not need to expose if it is an mdev or sriov based vgpu | |
| 15:40:51 | bauwser | sean-k-mooney: that's where I'm pretty firm in my mind | |
| 15:41:02 | bauwser | sean-k-mooney: outside the virt driver, we shouldn't leak out the details | |
| 15:41:23 | sean-k-mooney | bauwser: we may need to expose a vender in some form for guest driver reasons but other then that how we virtualise should be internal to nova | |
| 15:41:26 | bauwser | the virt driver will just report inventories | |
| 15:41:46 | bauwser | how those inventories will be populated will be different based on the driver | |
| 15:41:59 | bauwser | but that will be consistent | |
| 15:42:17 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Use ksa adapter for cinder client https://review.openstack.org/508345 | |
| 15:42:41 | sean-k-mooney | sure and i think we can use traits on the provider to hanel the "i only have a nvida driver in my vm image" problem | |
| 15:42:44 | fried_rice | mordred ^ would you mind checking that I did my version discovery sanely here? | |
| 15:43:03 | bauwser | so that a flavor asking for an amount of 2 of the VGPU resource class and a trait of 'K800' will get 2 K800 vGPUs | |
| 15:43:21 | bauwser | that's where the API is | |
| 15:43:46 | bauwser | actually a good call for trying to fit the fried_rice's model with vGPUs | |
| 15:44:19 | sean-k-mooney | bauwser: perhaps yes or as image metadata where i say i can support x,y,z and the and flavor say i want y and we compare to make sure its compatible | |
| 15:45:10 | bauwser | sean-k-mooney: mmm | |
| 15:45:26 | bauwser | sean-k-mooney: I wonder if that wouldn't be just a filter for the image metadata | |
| 15:45:47 | bauwser | like, I can find all the hosts that can support y (if y is asked by the flavor) | |
| 15:45:48 | sean-k-mooney | im thinking we can add traits to the image metadata | |
| 15:45:52 | bauwser | that is a placement thing | |
| 15:46:14 | bauwser | well | |
| 15:46:25 | bauwser | honestly that's a thought | |
| 15:47:22 | mordred | fried_rice: looks good on quick glance - but I haven't ooked deeply yet | |
| 15:47:37 | fried_rice | mordred Cool, thanks. | |
| 15:48:22 | bauwser | well, I need to call it a day, actually | |
| 15:48:48 | mriedem | fried_rice: let's let mordred deal with the infra fire that's raging | |
| 15:48:52 | mriedem | :) | |
| 15:49:19 | fried_rice | mriedem mordred Sorry, didn't smell the smoke. | |
| 15:49:27 | mriedem | #openstack-infra | |
| 15:49:42 | sean-k-mooney | leakypipes: am qq. is there a way we can retrive the compute node resocue provide by the hostid? and if not would you be against adding one. it could just be a trait | |
| 15:50:33 | leakypipes | sean-k-mooney: each resource provider has a name attribute. | |
| 15:50:41 | leakypipes | sean-k-mooney: that is set to hypervisor_hostname value | |
| 15:50:49 | leakypipes | sean-k-mooney: so yeah, you can already do that. | |
| 15:50:55 | leakypipes | sean-k-mooney: and that name is unique BTW | |
| 15:51:24 | sean-k-mooney | leakypipes: yes i know we require that all hostnames be unique in the openstack cloud | |
| 15:51:47 | sean-k-mooney | leakypipes: the issue is the get resouce provider api to day i think need you to pass the uuid | |
| 15:51:50 | mriedem | sean-k-mooney: you can find the compute node by hostname, and from the compute node uuid look up the RP | |
| 15:51:53 | mriedem | that's what our functional tests do | |
| 15:51:58 | sean-k-mooney | i dont know if we have a rest api call to get it by name | |
| 15:52:06 | leakypipes | sean-k-mooney: no, I mean when resource providers are added by the compute node, the resource provider's name attribute is set to the hypervisor_hostname | |
| 15:52:32 | sean-k-mooney | fried_rice: cool if GET /resource_providers?name={hostname} works that perferct | |
| 15:52:34 | leakypipes | sean-k-mooney: GET /resource_providers?name=$hypervisor_hostname | |
| 15:52:43 | leakypipes | sean-k-mooney: sorry, yeah, fried_rice beat me to it. | |
| 15:52:59 | leakypipes | he's a wily coyote, that fried_rice | |
| 15:52:59 | fried_rice | Yeah, to be technically correct, in case $hypervisor_hostname isn't the same as `hostname` | |
| 15:53:16 | leakypipes | fried_rice: which is the case for Ironic nodes :) | |
| 15:53:27 | fried_rice | right | |
| 15:53:39 | sean-k-mooney | the reason i was asking is for the neutron placement work. when nested provider are added we will need to find the computenode provider for the current host hence question | |
| 15:54:17 | fried_rice | So as long as you know how virt is reporting the hypervisor hostname, you're golden. | |
| 15:54:54 | sean-k-mooney | in neutron i belive we have the host id in a config that must be set to match the one used by nova | |
| 15:55:23 | leakypipes | right | |
| 15:55:32 | fried_rice | #host = example.domain | |
| 15:55:32 | fried_rice | # the same host value. (unknown value) | |
| 15:55:32 | fried_rice | # this machine. All the agents and services running on this machine must use | |
| 15:55:32 | fried_rice | # Hostname to be used by the Neutron server, agents and services running on | |
| 15:55:35 | fried_rice | in neutron.conf ? | |
| 15:55:39 | leakypipes | device_id == hostname, right? | |
| 15:55:42 | leakypipes | sean-k-mooney: ^\ | |
| 15:55:59 | sean-k-mooney | device_id? | |
| 15:56:41 | leakypipes | sean-k-mooney: in neutron port response... | |
| 15:57:35 | leakypipes | sean-k-mooney: never mind. | |
| 15:57:36 | sean-k-mooney | oh binding:host_id is | |