| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-18 | |||
| 12:53:35 | lyarwood | artom / sean-k-mooney ; https://review.opendev.org/c/openstack/nova-specs/+/794799 - would you mind taking another look at this btw? | |
| 12:53:38 | gibi | s/my/by/ | |
| 12:53:52 | bauzas | gibi: if you use mdev_class='vgpu' which is the default, then you will have two inventories with the same RC | |
| 12:54:01 | gibi | bauzas: cool, that works for me | |
| 12:54:08 | sean-k-mooney | lyarwood: sure ill take a look tat this soon after ^ | |
| 12:54:25 | lyarwood | ack thanks :) | |
| 12:54:28 | sean-k-mooney | bauzas: i have one question though | |
| 12:54:29 | bauzas | gibi: if you use other mdev_class value, you will still have two inventories but with different RCs | |
| 12:54:46 | sean-k-mooney | from the generic resouces:request in the flavor | |
| 12:54:53 | gibi | bauzas: and then what I really want is to tell the consumers of the generic mdev feature not to use to specific RC names for different types but uses custom traits instead as that is more flexibly when you request things | |
| 12:54:56 | bauzas | sean-k-mooney: sure, shoot | |
| 12:55:10 | sean-k-mooney | how are you planning to determin that a RC is an request for an MDEV to be passed through | |
| 12:55:11 | bauzas | gibi: agreed | |
| 12:55:12 | gibi | s/to/too/ | |
| 12:55:22 | bauzas | gibi: we should document this | |
| 12:55:29 | gibi | bauzas: agreed | |
| 12:55:30 | sean-k-mooney | are you on the compute node going to look at all the RC in the config for mdevs and then just compare to that list | |
| 12:55:49 | bauzas | gibi: that's why I used the wording "class" and not "type" | |
| 12:56:22 | bauzas | gibi: in theory, that's for apples vs. bananas | |
| 12:56:28 | bauzas | gibi: and not about apple flavors | |
| 12:56:37 | sean-k-mooney | or should we havee a mdev_request:<RC>=<amount>,<RC>=<Amount>,... extra specs | |
| 12:56:54 | bauzas | sean-k-mooney: I was expecting to reuse this method, sec | |
| 12:57:29 | sean-k-mooney | gibi: bauzas would it be clear to use resouce_class instead of mdev_class in the cofnig | |
| 12:57:37 | bauzas | sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7377 | |
| 12:57:58 | bauzas | sean-k-mooney: meh, I'm not opiniated by the option name | |
| 12:58:01 | sean-k-mooney | bauzas: the reason im asking is for the pci in placement spec by the way | |
| 12:58:11 | gibi | sean-k-mooney: I have no hard opinion about naming, if the doc is clear about that different classes results in different resource pools then I'm fine with the naming | |
| 12:58:23 | bauzas | sean-k-mooney: so I was expecting to look at the options to know the custom RCS | |
| 12:58:28 | sean-k-mooney | im not currently planning to support resource: syntax for pci passthough | |
| 12:59:06 | bauzas | sean-k-mooney: sorry, wrong method, this would be done in https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7763 | |
| 12:59:10 | sean-k-mooney | bauzas: ok | |
| 12:59:30 | sean-k-mooney | so for consitency should i include the same capablity in the pci spec? | |
| 12:59:55 | bauzas | sean-k-mooney: within this method, we would look at the known custom RCs besides the VGPU one | |
| 13:00:09 | sean-k-mooney | bauzas: i can determin the classes form pci_whitelist | |
| 13:00:29 | bauzas | sean-k-mooney: correct, I was expecting to look at the options | |
| 13:01:27 | gibi | sean-k-mooney: about PCI, we have an established way to request PCI, I would not extend on that as that can cause confusion. | |
| 13:01:49 | gibi | sure the PCI and the VGPU will be differnet from the flavor point of view | |
| 13:01:53 | gibi | but I think that is fine | |
| 13:02:02 | sean-k-mooney | i dont really like that personally | |
| 13:02:24 | sean-k-mooney | well its more i dont really like using resouce: as the only way to requst vgpus | |
| 13:02:35 | gibi | I see | |
| 13:02:37 | sean-k-mooney | but if we are supporting it for mdev i dont see why we would not support it for pci | |
| 13:02:53 | sean-k-mooney | i kind fo feel like we shoud go one way or the other | |
| 13:03:13 | gibi | I agree that having 'resource:' in the flavor is a shortcut, but it is an established form for VGPU already | |
| 13:03:14 | sean-k-mooney | the resouce class basiclaly will give use the same level of indrection the pci alais has today | |
| 13:03:28 | sean-k-mooney | but without the need to configure pci aliase in the first place | |
| 13:04:33 | sean-k-mooney | gibi: basically im wonderign should look to eventually remove the pci alaise and just use resouce: for pci passthough or mdev passtough in the future | |
| 13:04:44 | gibi | I can accept that ^^ | |
| 13:05:01 | gibi | they feel pretty equal to me regarding expressivity | |
| 13:05:23 | gibi | but I don't think we have to do that now. as you said, in the future :) | |
| 13:05:58 | sean-k-mooney | ill at least mention it in the spec in the alternitive section as possibel future work | |
| 13:06:06 | gibi | that is totally cool with me | |
| 13:07:25 | sean-k-mooney | the spec will already be split into 2 spec 1 basic passtogh 2 neutron integration i can add 3 which is replaceing alsias with resouce: but that wont happen this cycle | |
| 13:07:40 | gibi | sure | |
| 13:07:44 | gibi | sounds like a plan :) | |
| 13:08:07 | sean-k-mooney | bauzas: so just looping back to your discussion | |
| 13:08:27 | sean-k-mooney | i think im ok with useing resouce: and just checking the config on the compute node for the RC classes | |
| 13:09:07 | sean-k-mooney | i would still prefer to use resouce_class as the config option name but thats minor | |
| 13:09:26 | sean-k-mooney | i can also live with mdev_class if we just have good help text | |
| 13:09:42 | sean-k-mooney | gibi: did you have any other open question on bauzas proposal | |
| 13:10:04 | sean-k-mooney | gibi: lyarwood asked first so im going to review his spec shortly but i can look at bauzas next | |
| 13:11:57 | bauzas | I diverted from IRC | |
| 13:12:05 | gibi | sean-k-mooney, bauzas: that settles my last quesiton in the mdev spec, so I going to reply in the spec and approve it | |
| 13:12:08 | bauzas | any thoughts ? | |
| 13:12:15 | bauzas | ack, ok | |
| 13:13:39 | sean-k-mooney | ok ill try and get to https://review.opendev.org/c/openstack/nova-specs/+/794799 and https://review.opendev.org/c/openstack/nova-specs/+/792796/3/specs/xena/approved/generic-mdevs.rst in the next hour or so | |
| 13:27:56 | gibi | bauzas, sean-k-mooney: could you hit this small spec fix: https://review.opendev.org/c/openstack/nova-specs/+/795493 | |
| 13:29:31 | sean-k-mooney | gibi: i just fast approved that | |
| 13:29:46 | sean-k-mooney | oh | |
| 13:29:49 | sean-k-mooney | actully no | |
| 13:29:55 | sean-k-mooney | can you rename the file to match | |
| 13:30:22 | sean-k-mooney | it shoudl be cyborg-admin-user-client.rst | |
| 13:30:36 | gibi | OK, let me fix that quickly | |
| 13:30:41 | sean-k-mooney | the move implemented spec tool use that to find the blueprint | |
| 13:33:47 | opendevreview | Balazs Gibizer proposed openstack/nova-specs master: Fix the bp link in the cyborg admin token spec https://review.opendev.org/c/openstack/nova-specs/+/795493 | |
| 13:34:00 | gibi | sean-k-mooney: ^^ | |
| 13:35:41 | sean-k-mooney | gibi++ | |
| 13:35:53 | sean-k-mooney | we dont have a karma bot here but still | |
| 13:36:19 | gibi | sean-k-mooney: thanks | |
| 13:36:32 | gibi | the happy days of doing the virtual paperwork as a PTL | |
| 13:36:57 | sean-k-mooney | at least you dont have to do it in triplicate | |
| 13:37:48 | sean-k-mooney | not today but i can proably look at adding a small script that will check for this in the ci | |
| 13:38:12 | gibi | good idea | |
| 13:38:20 | gibi | on the CI script | |
| 13:38:40 | artom | lyarwood, done | |
| 13:38:41 | sean-k-mooney | get the added filename, strip the rst, grep and see if there is a url that end with that and curl it to make sure it does not have a 404 | |
| 13:43:49 | lyarwood | thanks | |
| 13:45:48 | stephenfin | an interesting Python problem | |
| 13:45:51 | stephenfin | return json.loads(self._bar) | |
| 13:45:51 | stephenfin | def bar(self): | |
| 13:45:51 | stephenfin | @property | |
| 13:45:51 | stephenfin | class Foo: | |
| 13:45:51 | stephenfin | import json | |
| 13:45:53 | stephenfin | @bar.setter | |
| 13:45:54 | stephenfin | def bar(self, value): | |
| 13:45:56 | stephenfin | self._bar = json.dumps(value) | |
| 13:45:58 | stephenfin | foo = Foo() | |
| 13:46:02 | stephenfin | foo.bar = {} | |
| 13:46:04 | stephenfin | foo.bar['test'] = 'hello' | |
| 13:46:06 | stephenfin | assert foo.bar == {'test': 'hello'} | |