Open Stack

> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com]
> Sent: Wednesday, March 23, 2016 8:01 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [neutron][nova][stable][sr-iov] Status of
> physical_device_mappings
> 
> +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.
This may have worked in the past if yo did not use the neutron sriovnic agent.
In liberty it was optional and not used with intel nics but in mitaka it is now required.
I do not have a liberty system to hand to test but perhaps that is how it worked(assuming it did work) 
In liberty but not in mitaka?
> 
> > 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.ht
> > ml
> > [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