| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-23 | |||
| 15:16:25 | stephenfin | bauzas: I've it done | |
| 15:16:40 | bauzas | stephenfin: where ? I could do the same | |
| 15:16:41 | stephenfin | :) | |
| 15:16:45 | stephenfin | sec | |
| 15:16:58 | bauzas | or make it generic | |
| 15:16:58 | stephenfin | bauzas: https://github.com/stephenfin/nova/commit/58b53e888feb146123087f2e3f54f677f1fdccdc | |
| 15:17:33 | stephenfin | (I haven't pushed it to Gerrit yet because it's not end-to-end tested and I don't want to swamp the CI as I iterate) | |
| 15:17:34 | dansmith | sahid: yep, cool | |
| 15:18:20 | bauzas | stephenfin: I'm not sure we should dynamicall add the groups in nova/config | |
| 15:18:43 | bauzas | stephenfin: rather closer to the caller | |
| 15:19:20 | bauzas | stephenfin: my thoughts was to use devices.enabled_vgpu_types as the ListOpt value for knowing which opt groups to check | |
| 15:19:21 | stephenfin | bauzas: I wanted it to be done at startup so I could quickly fail. However, that's really good feedback for when it's on Gerrit :) | |
| 15:19:40 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove vestigial system_metadata param from info_from_instance() https://review.openstack.org/561724 | |
| 15:19:51 | bauzas | stephenfin: or use MultiStrOpt for that | |
| 15:19:53 | stephenfin | bauzas: Aye, I used 'CONF.neutron.physnets' for that | |
| 15:20:02 | stephenfin | https://github.com/stephenfin/nova/commit/58b53e888feb146123087f2e3f54f677f1fdccdc#diff-bf484fde349b127980f9341543ce3c9aR38 | |
| 15:20:27 | stephenfin | so '[neutron] physnets = foo, bar' | |
| 15:20:37 | bauzas | right | |
| 15:20:50 | bauzas | stephenfin: see the context in https://review.openstack.org/#/c/557065/2/specs/rocky/approved/vgpu-rocky.rst@86 | |
| 15:20:57 | bauzas | stephenfin: for MultiStrOpt | |
| 15:21:11 | stephenfin | I guess I could use prefixed attribute names but someone (jaypipes or dansmith, I think) thought that was eewy | |
| 15:21:35 | dansmith | jaypipes: we've validated this with the nfv ci, if you want to have another look at it and the one below: https://review.openstack.org/#/c/484997/ | |
| 15:22:16 | jaypipes | dansmith: ack, will do. | |
| 15:23:01 | jaypipes | ah, this is the one I'd asked sahid to combine the first two patches. yeah... one minute. | |
| 15:23:21 | sahid | dansmith: it was a really nice idea your DNM patch, i'm going to reuse it a lot :) | |
| 15:24:07 | dansmith | jaypipes: yep | |
| 15:24:11 | dansmith | sahid: :) | |
| 15:25:46 | bauzas | stephenfin: you're better than me on oslo.config, do you know if we can have a MultiStrOpt where two lines would have the same key but different values ? | |
| 15:26:34 | stephenfin | bauzas: Got an example? | |
| 15:26:39 | bauzas | sec | |
| 15:26:40 | stephenfin | They have the same key by definition | |
| 15:28:41 | jaypipes | dansmith: off to the test pits it goes. | |
| 15:28:45 | efried | gibi: Ready for you: https://review.openstack.org/#/c/561724/ self.NotificationEmail().AndRemove(bug_1764390) | |
| 15:29:13 | dansmith | jaypipes: the test pits ahead won't really test it, but it came back from other test pits that did recently, so.. thanks :) | |
| 15:29:17 | bauzas | stephenfin: actually, what I want is a MultiDictOpt | |
| 15:30:10 | jaypipes | bauzas: you do *not* want a MultiDictOpt. | |
| 15:30:18 | bauzas | I don't know | |
| 15:30:20 | jaypipes | bauzas: dansmith might kill you if you used that. | |
| 15:30:23 | bauzas | what I want is a pony | |
| 15:30:26 | jaypipes | heh | |
| 15:30:47 | jaypipes | bauzas: your dog is as big as a pony. | |
| 15:30:54 | stephenfin | kashyap: One question before I send that on it's way: how come you didn't use the "NEXT" libvirt/qemu values already specified by berrange? | |
| 15:30:55 | bauzas | I just want a fucking easy way to describe a transitive relationship between a thing and a list of other things | |
| 15:31:32 | bauzas | jaypipes: not as big as a pony, I saw taller yesterday when I was in a dog show | |
| 15:31:38 | jaypipes | bauzas: relational DBs are pretty good at storing relations :P | |
| 15:31:46 | bauzas | jaypipes: I know | |
| 15:32:06 | bauzas | jaypipes: I have a crazy idea to just add a new nova-manage helper if you want my own thoughhts | |
| 15:32:19 | bauzas | just for something super specific like that | |
| 15:32:20 | stephenfin | bauzas: s/in a dog show/at a dog show/ ;) | |
| 15:32:27 | bauzas | because libvirtd doesn't help me with that | |
| 15:32:48 | bauzas | so, things are, we know we're doomed with defining that relationship elsewhere but nova | |
| 15:32:51 | jaypipes | stephenfin: an important clarification :) | |
| 15:32:52 | jroll | stephenfin: "in" was correct, bauzas was a contestant :P | |
| 15:32:56 | bauzas | but I want to make it the less painful | |
| 15:33:46 | sean-k-mooney | bauzas: whay are the entities you are trying to define the relationship of? | |
| 15:34:12 | bauzas | x8kAufXHD_RF1-sfVGt6FEMv2MOY7Y2WH5d4MhvFQT3WF37ZLRJxAxXXmhloPjqF6qh374jvsopMPVaKykwW9zuTiZ87CNcQbfXeGze46RC_CAPmccFyYeA84_y7t0TIJOzStqFXA5LvLivtFfxJtGq06ZRD_P0ZSHcw_cdigRN84R-jDPXGRxnbuAkm5f16HfyLzxARcz1OPfVdUBFliYvHR4h8vZ9VI2ajmprFcxZp2mxIhuvD8FC6lzAwyRLayjnfn4ElfZSPVcm8zVJ9VBFnSwBL5xSq6ZaayKfdL1KEPAYgpQYIj0bdLk6w=w1689-h950-no | |
| 15:34:12 | bauzas | jaypipes: stephenfin: jroll: if you care https://lh3.googleusercontent.com/fFHAwwIKjuW9uKAYkPrsTjsw_bOO6gQgA7xw-B0d2-gmC24J8Z1DUpSzKHwkIJesK_aTGeKGQ8ts1P67SZhmsxUiVEEABuFv7Hg4CvQ-ROw8TNcOgKOgw7HjUqL6ZMsLPYgLee8mDkyj0PpCTRUiD936luaHuThLkW__s1Ym9UAXmMPqXo7J1cBv1GkYjyunJfWbJTUBklcJHd6zwTz51M1DhIMRd0zYpr9xm8kCG3Qbn0NnzVK6jt7ppA00jqUbl-NfReOZyCirPZvrMLJyrtm9nza7AwwOuCm0NGYrVBMZlpnGKQ8VmmlG3r8wz9uPKvUjREitqqN4WgTjhDgRrIomD6Oe9bCMRnRX2 | |
| 15:34:16 | sean-k-mooney | bauzas: you can use somthing like ovo in somecases also | |
| 15:34:40 | bauzas | sean-k-mooney: I just want to say "that GPU type is for those PCI devices" | |
| 15:34:45 | bauzas | period | |
| 15:35:15 | bauzas | but oslo.config doesn't give me a good way to express that except something dumb like we merged for pci whitelist, and which I dislike at most | |
| 15:35:47 | bauzas | so, I'm out of ideas | |
| 15:35:53 | sean-k-mooney | bauzas: ah ok ya so like the pci alais with out all the other symantics that is layered on that | |
| 15:35:58 | bauzas | except sealing in the nova codebase something I don't want | |
| 15:36:23 | bauzas | because that's just libvirtd isn't mature enough on that feature to provide CLIs for that | |
| 15:36:55 | bauzas | so a config option is just a 'mid-term' solution until, I hope, something comes up that allows to specify that outside of nova | |
| 15:37:24 | sean-k-mooney | bauzas: you can find the vgpu types in virsh capablitites or virsh nodedev-list though right? | |
| 15:37:57 | bauzas | sean-k-mooney: sure, but then I need to say which type is for which pGPU | |
| 15:37:59 | sean-k-mooney | bauzas: one of those should expose the mdev types that correstpond the the different vgpus | |
| 15:38:07 | bauzas | sean-k-mooney: context is https://review.openstack.org/#/c/557065/2/specs/rocky/approved/vgpu-rocky.rst | |
| 15:38:27 | bauzas | sean-k-mooney: sure, but each pGPU supports multiple types | |
| 15:38:54 | bauzas | Xen doesn't have that problem, because the xen CLI allows to provide such tool out of nova | |
| 15:39:04 | bauzas | I don't have that in my bucket, so I'm doomed | |
| 15:39:32 | sean-k-mooney | bauzas: yes but form a config type we need to seperate things. a whitelist to declare what pGPUs can be used and a mapping that allows you to name the types and use that in the flavor | |
| 15:39:43 | bauzas | sean-k-mooney: we already have the former | |
| 15:39:50 | bauzas | sean-k-mooney: what we miss is the latter | |
| 15:40:16 | bauzas | again, we can technically have a StrOpt and do some magical JSON import | |
| 15:40:27 | bauzas | just because oslo.config misses that | |
| 15:40:27 | sean-k-mooney | bauzas: the pci whitelist is the former right. and your looking for a clean way to lable the diferent types so we dont leak the host implemtaiton details via the api | |
| 15:40:30 | bauzas | no | |
| 15:40:55 | bauzas | sean-k-mooney: we currently have enabled_vgpu_types that lists all the supported types accepted by that compute | |
| 15:41:26 | bauzas | sean-k-mooney: what I miss is a way to say for each of those types, which pGPU(s) is/are associated with | |
| 15:41:53 | sean-k-mooney | bauzas: ah ok. | |
| 15:42:47 | bauzas | jaypipes: if we say here that a dict opt isn't the best match, it only allows us some kind of dynamic import, or some external file that'd be out of oslo.config | |
| 15:43:11 | bauzas | jaypipes: I'm not super happy with the second option that carries a lot of misunderstandings | |
| 15:44:16 | sean-k-mooney | bauzas: i belive stephenfin is looking at reusing how cindier does dynmaic config for the numa aware vswitch spec | |
| 15:44:26 | sean-k-mooney | bauzas: could we use the same approch here or is that overkill | |
| 15:44:50 | bauzas | I think that's the only option I have tbh, if we still care about nova.conf | |
| 15:46:32 | sean-k-mooney | bauzas: well if you have a config var that listed all the phyciscal gpus and then had a dynmic section for each that listed the allowed types i think that would be resonably clean | |
| 15:47:25 | jaypipes | bauzas: I'm not sure if you're asking me a question. I think dansmith would like to see you use a strategy similar to stephenfin's code that adds a config section to nova.conf for each physical device? So, something like [gpu_<some identifier>] and then have CONF options inside that group? | |
| 15:47:38 | bauzas | ok, I can try then | |
| 15:49:36 | dansmith | jaypipes: yeah | |
| 15:49:50 | openstackgerrit | Margarita Shakhova proposed openstack/nova master: Do not skip migrations in _destroy_evacuated_instances() https://review.openstack.org/563623 | |
| 16:05:26 | openstackgerrit | sahid proposed openstack/nova master: add mtu to libvirt xml for ethernet and bridge types https://review.openstack.org/553072 | |
| 16:06:19 | sahid | sean-k-mooney: I updated you patch ^ based on matt comments and i also have updated a point with the mtu function to update libvirt configure xml I hope that was ok for you | |
| 16:08:03 | sean-k-mooney | sahid: ya no worries sorry i had ment to get back to that patch sooner | |
| 16:11:13 | sean-k-mooney | sahid: the real answer to matts question is when os-vif actully plug the interface it does set teh mtu but there are still a few code paths where libvirt plugs the interfaces and then nothing set the mtu which is what that patch fixes | |
| 16:11:45 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove explicit instance.info_cache.delete() https://review.openstack.org/563689 | |
| 16:12:55 | openstack | Launchpad bug 1747496 in OpenStack Compute (nova) "MTUs are not set for VIFs if using kernel ovs + hybrid plug = false" [Medium,In progress] | |
| 16:12:55 | sahid | sean-k-mooney: launchpad updated the bug report to assign myself, i'm not able to re-assign you, so when you have a moment, please do https://bugs.launchpad.net/nova/+bug/1747496 | |