Open Stack

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.
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.

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.

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.

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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160321/45e13584/attachment.pgp>