Open Stack

Seems like the explanation below indeed suggests that’s a regression for  
Mitaka. We’ll track the bug for a backport. I don’t think that we can block  
the initial Mitaka release for that though. So let’s work on the master fix  
right now, and target the fix for Mitaka for one of the first minor updates  
for the branch.

Ihar

Vladimir Eremin <veremin at mirantis.com> wrote:

> Hi jay,
>
> There was no ability to setup this configuration WITH Neutron SR-IOV ML2  
> agent in Liberty. That what you pointed out and you’re totally correct.
>
> But in Liberty, you’re not required to use Neutron SR-IOV ML2 agent to  
> get this functionality works. And if you configure only nova-compute and  
> neutron-server (WITHOUT Neutron SR-IOV ML2 agent), you could achieve  
> desired configuration.
>
> Basically:
> * Liberty: you can use agent and you will be limited in physnets, or you  
> can use it without agent.
> * Mitaka: you should use agent and you will be limited in physnets.
>
> So, regression is introduced by making Neutron SR-IOV ML2 agent required.  
> And this easy-fix removes the problem.
>
> -- 
> With best regards,
> Vladimir Eremin,
> Fuel Deployment Engineer,
> Mirantis, Inc.
>
>
>
>> On Mar 23, 2016, at 11:01 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>>
>> +tags for stable and nova
>>
>> Hi Vladimir, comments inline. :)
>>
>> On 03/21/2016 05:16 AM, Vladimir Eremin wrote:
>>> Hey OpenStackers,
>>>
>>> I’ve recently found out, that changing of use neutron sriov-agent in  
>>> Mitaka from optional to required[1] makes a kind of regression.
>>
>> While I understand that it is important for you to be able to associate  
>> more than one NIC to a physical network, I see no evidence that there  
>> was a *regression* in Mitaka. I don't see any ability to specify more  
>> than one NIC for a physical network in the Liberty Neutron SR-IOV ML2  
>> agent:
>>
>> https://github.com/openstack/neutron/blob/stable/liberty/neutron/common/utils.py#L223-L225
>>
>>> Before Mitaka, there was possible to use any number of NICs with one  
>>> Neutron physnet just by specifying pci_passthrough_whitelist in nova:
>>>
>>>     [default]
>>>     pci_passthrough_whitelist = { "devname": "eth3", "physical_network": "physnet2”},{ "devname": "eth4", "physical_network": "physnet2”},
>>>
>>> which means, that eth3 and eth4 will be used for physnet2 in some manner.
>>
>> Yes, *in Nova*, however from what I can tell, this functionality never  
>> existed in the parse_mappings() function in neutron.common.utils module.
>>
>>> In Mitaka, there also required to setup neutron sriov-agent as well:
>>>
>>>     [sriov_nic]
>>>     physical_device_mappings = physnet2:eth3
>>>
>>> The problem actually is to unable to specify this mapping as  
>>> "physnet2:eth3,physnet2:eth4” due to implementation details, so it is  
>>> clearly a regression.
>>
>> A regression means that a change broke some previously-working  
>> functionality. This is not a regression, since there apparently was  
>> never such functionality in Neutron.
>>
>>> I’ve filed bug[2] for it and proposed a patch[3]. Originally  
>>> physical_device_mappings is converted to dict, where physnet name goes  
>>> to key, and interface name to value:
>>>
>>>>>> parse_mappings('physnet2:eth3’)
>>>    {‘physnet2’: 'eth3’}
>>>>>> parse_mappings('physnet2:eth3,physnet2:eth4’)
>>>    ValueError: Key physnet2 in mapping: 'physnet2:eth4' not unique
>>>
>>> I’ve changed it a bit, so interface name is stored in list, so now this  
>>> case is working:
>>>
>>>>>> parse_mappings_multi('physnet2:eth3,physnet2:eth4’)
>>>    {‘physnet2’: [‘eth3’, 'eth4’]}
>>>
>>> I’d like to see this fix[3] in master and Mitaka branch.
>>
>> I understand you really want this functionality in Mitaka. And I will  
>> leave it up to the stable team to determine whether this code should be  
>> backported to stable/mitaka. However, I will point out that this is a  
>> new feature, not a bug fix for a regression. There is no regression  
>> because the ability for Neutron to use more than one NIC with a physnet  
>> was never supported as far as I can tell.
>>
>> Best,
>> -jay
>>
>>> Moshe Levi also proposed to refactor this part of code to remove  
>>> physical_device_mappings and reuse data that nova provides somehow.  
>>> I’ll file the RFE as soon as I figure out how it should work.
>>>
>>> [1]:  
>>> http://docs.openstack.org/liberty/networking-guide/adv_config_sriov.html
>>> [2]: https://bugs.launchpad.net/neutron/+bug/1558626
>>> [3]: https://review.openstack.org/294188
>>>
>>> --
>>> With best regards,
>>> Vladimir Eremin,
>>> Fuel Deployment Engineer,
>>> Mirantis, Inc.
>>>
>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:  
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev