Open Stack

Hi neutrinos,

The idea of this email is to summarize the effort that we're making during the implemetation of Rolling upgrades in Neutron, as well as 
sharing the upcoming changes.

Announcements
============

Neutron Newton RC1 has been created and this contains the following changes related to OVO:
https://review.openstack.org/#/dashboard/?foreach=%28project%3Aopenstack%2Fneutron%29%0Astatus%3Amerged+after%3A2016%2D04%2D04+before%3A2016%2D09%2D19&title=Neutron+Upgrades+%2D+Newton&Oslo%2DVersioned+Object+Creation+and+Integration=%28topic%3Abp%2Fadopt%2Doslo%2Dversioned%2Dobjects%2Dfor%2Ddb+OR+topic%3Aovo%29&Relocate+DB+model+classes=topic%3Abug%2F1597913

Here, let's just outline general plan:
    - Move DB model classes to avoid cyclic imports. https://review.openstack.org/#/q/status:open+topic:bug/1597913
    - Land Oslo-Versioned Objects
    - Adopt them in plugin code, this means the replacement of the exisiting calls for corresponding OVO functions. 
    
Ocata release will last 4.5 months only. Though the cycle is short, the plan is to make it the first release that supports partial upgrade
for neutron-servers. It means we will need to forbid contract alembic scripts during this cycle.

Model Relocation 
=============

SubnetServiceType, FlatAllocation, GreAllocation and GreEndpoints models have been already moved into neutron/db/models folder.  The 
plan is to move the DB model classes that share file with mixin class ( https://review.openstack.org/#/q/status:open+topic:bug/1597913 )

OVO Neutron Framework
===================

There are some cases where the API receives filters which are not defined in the model.( e. g. for the query to filter Subnet model class 
is using 'admin_state_up' as filter).  This behaviour is not allowed in the strict OVO implementation, so it was required to make optional
this restriction. https://review.openstack.org/#/c/365659/

Subnet OVO has been created but its integration is in progress, so any feedback is welcome
https://review.openstack.org/#/c/321001/ 
 https://review.openstack.org/#/c/351740/

Regarding the way to replace inner and outer joins on the current way that models have been implemented is something that has not 
been defined yet.  The initial approach to follow is trying to create a new classmethod in the most relevant OVO class and move that logic
into the OVO class.  Obviously, this varies case by case.

It has been identified some cases where methods passes DB session as an argument instead of a Application Context.  This has a direct impact on the way to
replace code with OVO classes because they use context for doing DB changes internally.  It was decided to consider changes on method signature whenever
it's possible with the only exception to don't modify the any method that afects the API.

OVO Implementation Dashboard  ->  https://docs.google.com/spreadsheets/d/1FeeQlQITsZSj_wpOXiLbS36dirb_arX0XEWBdFVPMB8

http://eavesdrop.openstack.org/meetings/neutron_upgrades/2016/neutron_upgrades.2016-09-12-15.01.log.html
http://eavesdrop.openstack.org/meetings/neutron_upgrades/2016/neutron_upgrades.2016-09-19-15.00.log.html