sr-iov: neutron-sriov-agent required for >= mitaka
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Neutron Open vSwitch Charm |
Fix Released
|
Medium
|
James Page | ||
OpenStack Nova Compute Charm |
Fix Released
|
Medium
|
Unassigned | ||
neutron-openvswitch (Juju Charms Collection) |
Invalid
|
Medium
|
James Page | ||
nova-compute (Juju Charms Collection) |
Invalid
|
Medium
|
Unassigned |
Bug Description
Context: xenial/mitaka deploy using 16.07 charms release, sr-iov enabled as per release notes[0].
As per [1] compute node should "Enable neutron sriov-agent" -
without it, nova-compute fails with the infamous:
NovaException: Unexpected vif_type=
Got above fixed after manually installing the pkg and modifying
sriov_agent.ini as:
root@buizel:~# apt-get install neutron-sriov-agent
root@buizel:~# tail -3 /etc/neutron/
[sriov_nic]
physical_
exclude_devices =
[0] https:/
[1] http://
Changed in charm-nova-compute: | |
importance: | Undecided → Medium |
status: | New → Triaged |
Changed in nova-compute (Juju Charms Collection): | |
status: | Triaged → Invalid |
Changed in charm-neutron-openvswitch: | |
assignee: | nobody → James Page (james-page) |
importance: | Undecided → Medium |
status: | New → In Progress |
Changed in neutron-openvswitch (Juju Charms Collection): | |
status: | In Progress → Invalid |
Changed in charm-neutron-openvswitch: | |
milestone: | none → 17.02 |
status: | In Progress → Fix Released |
Changed in charm-nova-compute: | |
status: | Triaged → Fix Released |
milestone: | none → 17.02 |
The SR-IOV support was implemented across the charms against liberty (which did not require use of the neutron- sriov-agent) . As of Mitaka, this agent is required for correct functioning of SR-IOV ports in neutron.
That said, this should not be a feature of the nova-compute charm; I think its probably a new charm (neutron-sriov) *but* it has to co-exist with neutron- openvswitch, so can't assume sole ownership of /etc/neutron/ neutron. conf. As a result, this won't be super trivial to implement, as I suspect we'll need it to operate standalone on a compute node as well as with n-ovs.