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 <vere...@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 <jaypi...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
