Hi all,

in Austin we had a session to discuss the future of Neutron
architecture. You can find the etherpad here [1].

The first part was about agents. In the last releases we have been
factoring common code out and allowing pluggability: in Liberty L2 agent
extensions were introduced and in Mitaka a common agent framework. We
were wondering if it could be worth considering to move to a single
agent, where l2, l3, etc. are just roles that can be loaded according to
the configuration. We didn't reach any consensus, many people expressed
doubts regarding this approach so for now nothing will change.

The second part was about upgrades and specifically about the
introduction of Oslo VersionedObject in Neutron. The upgrade subteam is
taking care of this [2]. This work still requires lots of effort but
everybody agreed that it's needed. We decided that new features need to
adopt OVO straight away. The only exception is if a feature uses a
resource that is already in the code base and has not been ported to OVO
yet. As action items we need to figure out which features are in flight
and need to adopt OVO and we need to fill any gap in the documentation.
The upgrades team should make authors of patches in flight aware of the
new requirements and should deliver foundational bits to build features
upon. Some patches may still land without objects right now and it’s
advised to reach upgrades subteam for recommendations if in doubt.

To test upgrades with two Neutron servers we might want to have a
three-node testing. Assaf suggested that we can achieve the same results
modifying the job that currently uses two nodes since we can run compute
services (l2 agent, nova-compute) on the ‘new’ node in addition to the
‘old’ services, and have a connectivity test for instances explicitly
landed on different nodes.

cheers,

Rossella and Ihar


[1]
https://etherpad.openstack.org/p/newton-neutron-future-neutron-architecture
[2] https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam

__________________________________________________________________________
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

Reply via email to