Hello Stackers,
I've put together an etherpad [0] for the summary of the nova/neutron
session from the PTG in the Croke Park Hotel breakfast area and included
it as a plain text export on this email. Please feel free to edit or
reply to this thread to add/correct anything I've missed.
Cheers,
-melanie
[0] https://etherpad.openstack.org/p/nova-ptg-rocky-neutron-summary
*Nova/Neutron: Rocky PTG Summary
https://etherpad.openstack.org/p/nova-ptg-rocky L159
*Key topics
* NUMA-aware vSwitches
* Minimum bandwidth-based scheduling
* New port binding API in Neutron
* Filtering instances by floating IP in Nova
* Nova bug around re-attaching network interfaces on nova-compute
restart -- port re-plug and re-create results in loss of some
configuration like VLANs
* https://bugs.launchpad.net/nova/+bug/1670628
* Routed provider networks needs to move to placement aggregates
*Agreements and decisions
* For NUMA-aware vSwitches, we'll go forward with a config-based
solution for Rocky and deprecate it later when we have support in
placement for the necessary inventory reporting bit (which will be
implemented as part of the bandwidth-based scheduling work). We'll use
dynamic attributes like "physnet_mapping_[name] = nodes" to avoid the
JSON blob problem (Cinder and Manila do this) and thusly we'll avoid
having to deprecate any additional YAML config file or JSON blob based
thing when the placement support is available.
* Spec: https://review.openstack.org/#/c/541290/
* On minimum bandwidth-based scheduling:
* Neutron will create the network related RPs under the compute RP
in placement
* It's reasonable to require unique hostnames (across cells, the
internet, the world) and we'll solve the host -- compute uuid issue
separately
* Neutron will report the bandwidth inventory to placement
* On the interaction of Neutron and Nova to communicate the
requested bandwidth per port:
* The requested minimum bandwidth for a neturon port wil be
available in the neutron port API
https://review.openstack.org/#/c/396297/7/specs/pike/strict-minimum-bandwidth-support.rst@68
* The work does not depend on the new neutron port binding API
* We'll need not just resources but traits as well on the neutron
port and neutron should add the physnet to the port as a trait. We'll
assume that the requested resources and traits are from a single
provider per port
* We don't need to block bandwidth-based scheduling support for
doing port creation in conductor (it's not trivial), however, if nova
creates a port on a network with a QoS policy, nova is going to have to
munge the allocations and update placement (from nova-compute) ... so
maybe we should block this on moving port creation to conductor after all
* Nova will merge the requested bandwidth into the
allocation_candidate request by a new request filter
* Nova will create the allocation in placement for bandwidth
resources and the allocation uuid will be the instance uuid. Multiple
ports with different QoS rules will be distinguishable because they will
have allocations from different providers
* As PF/VF modeling in placement has not been done yet we can phase
this feature to support OVS first and add support for SRIOV after the
PF/VF modelling is done
* Nova spec: https://review.openstack.org/#/c/502306/
* Neutron spec: https://review.openstack.org/#/c/508149
* On the new port binding API in Neutron, there is solid progress on
the Neutron side and the Nova skeleton patches are making progress and
depend on the Neutron patch, so some testing will be possible soon
(still need to plumb in the libvirt driver changes)
* Spec:
https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/neutron-new-port-binding-api.html
* Neutron patch: https://review.openstack.org/#/c/414251/
* On the Nova bug about re-attaching network interfaces:
* There was a bug in OVS back in 2014 for which a workaround was
added: https://github.com/openstack/nova/commit/33cc64fb817
* The bug was fixed in OVS in 2015 and is available in OVS 2.6.0
onward:
https://github.com/openvswitch/ovs/commit/e21c6643a02c6b446d2fbdfde366ea303b4c2730
* The old workaround in Nova (now in os-vif) was determined to be
causing the bug, so a fix to os-vif was made which essentially reverted
the workaround: https://review.openstack.org/#/c/546588
* We can close the bug in Nova once we have a os-vif library
release and we depend on its version in our requirements.txt
* On routed provider networks:
* On the Neutron side, this is already done:
https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html
* Summit videos about routed provider networks:
*
https://www.openstack.org/videos/barcelona-2016/scaling-up-openstack-networking-with-routed-networks
*
https://www.openstack.org/videos/sydney-2017/openstack-networking-routed-networks-new-features
__________________________________________________________________________
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
