| melwitt | sean-k-mooney: thanks for the review on my specs :) I have replied and updated the NIC support in generic PCI driver one | 15:24 |
|---|---|---|
| sean-k-mooney | cool ill try and take a look later in the week | 15:25 |
| sean-k-mooney | did the expectaion aound the nova cybrog neutron interactions make sense to you wehn you read them | 15:25 |
| sean-k-mooney | i know that is a bit complex but the spec were at least somehwat clear on what each service should be doing | 15:26 |
| sean-k-mooney | i looked at the neutron code but didnt look at teh nova side | 15:26 |
| melwitt | sean-k-mooney: yes I think I understood the basics of what you said about nova/cyborg/neutron | 16:08 |
| melwitt | on the nova side it appears you are right about accessing 'physical_network' is _currently_ pointless bc it's not used for anything | 16:09 |
| melwitt | it accesses the key but then does nothing with it | 16:10 |
| sean-k-mooney | ack | 16:11 |
| melwitt | the question is then, should nova be using that key to report a trait to placement (per the https://specs.openstack.org/openstack/nova-specs/specs/xena/implemented/sriov-smartnic-support.html spec) | 16:11 |
| sean-k-mooney | that shoudl be an easy fix so | 16:11 |
| sean-k-mooney | no it should not | 16:11 |
| sean-k-mooney | the placement reporting is doen by cyborg | 16:12 |
| sean-k-mooney | nova shuld be using the phsyical network form the neturon port/network to request the phsynet when quering placement | 16:12 |
| melwitt | yeah, in my testing I commented out that key access and then was able to create the server successfully with the sriov port | 16:12 |
| melwitt | ack | 16:12 |
| sean-k-mooney | basiclly we shoudd more or less do this like we would for neutron sriov ports | 16:13 |
| sean-k-mooney | currenly we do that filtering after the placement call | 16:13 |
| sean-k-mooney | but ideally we woudl do it before hand | 16:13 |
| sean-k-mooney | i.e. we do it via the pci filter today for neutron | 16:13 |
| sean-k-mooney | in nova our vifi object have a type filed and a network field https://github.com/openstack/nova/blob/master/nova/network/model.py#L427-L428 | 16:15 |
| sean-k-mooney | but im not sure we currently recored the phsynet in the network | 16:16 |
| sean-k-mooney | so we may have to look that up directly form neutron | 16:16 |
| sean-k-mooney | or plumb that inf though the modeles | 16:16 |
| sean-k-mooney | this is the bit i didnt want to look up on firday :) | 16:16 |
| sean-k-mooney | we have some exsting code we can draw form like https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2183-L2224 | 16:18 |
| sean-k-mooney | for example in create_resouces_requsts https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2356 | 16:18 |
| sean-k-mooney | infact that is also wehre we are creating the cyborg requests | 16:19 |
| sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2356-L2373 | 16:19 |
| melwitt | hm ok, so nova should be using the key to request a trait rather | 16:20 |
| sean-k-mooney | unless im missing somehting we are looking up the phsynet and nerver actully passing it | 16:21 |
| sean-k-mooney | melwitt: yes | 16:21 |
| melwitt | that is what I saw as well, looking it up but then doing nothing with it | 16:21 |
| sean-k-mooney | because the device profile is the same regardless fo the network | 16:21 |
| sean-k-mooney | but hte phsynet depend on the network and or l2 segment | 16:21 |
| melwitt | ok I will update the nova bug with this info | 16:22 |
| sean-k-mooney | ah... https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2417-L2422 | 16:27 |
| melwitt | ok yeah I see now, I had misread the spec | 16:27 |
| sean-k-mooney | so right now stpehens piror chagnes are findign a host aht has the requried phnets | 16:27 |
| sean-k-mooney | but when they added the cybrog feature the didnt do it on a per nic basis | 16:27 |
| sean-k-mooney | i.e. then never enriched the requried traits for the cyborg request group | 16:28 |
| sean-k-mooney | so if your host only has 1 phsynet this will owrk but if it has 2 then you might get a device on the wrong one form placement | 16:28 |
| melwitt | does that mean anything needst o change about the code you linked with the physnets? or would the cyborg change be an additive change | 16:28 |
| sean-k-mooney | that will then fail at the port bidning stage in neutron | 16:28 |
| sean-k-mooney | no the code shoudl still be changed | 16:28 |
| melwitt | I mean, does _that_ code need to change? with cyborg, is it bad to add the physnet to the set the way it is currently? | 16:29 |
| sean-k-mooney | those are 2 diffent api responces | 16:29 |
| sean-k-mooney | it is correct to add it to the attachment handel | 16:29 |
| sean-k-mooney | but https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2367-L2376 is the imporant part we need to check | 16:30 |
| sean-k-mooney | we are gettign the reqeust form the device profile | 16:30 |
| sean-k-mooney | the device profile shoudl not have the phsynet | 16:30 |
| melwitt | oh ok, so the if physnet: physnets.add(physnet) can stay as-is even when we fix the cyborg part | 16:30 |
| sean-k-mooney | right | 16:30 |
| melwitt | ok that's good | 16:30 |
| sean-k-mooney | that for neutron sriov port | 16:30 |
| sean-k-mooney | so that bit is fine | 16:30 |
| sean-k-mooney | sorry was distracted with nova irc meeting as you probaly saw | 17:02 |
| melwitt | yes np | 18:13 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!