Open Stack

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