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