[openstack-dev] [neutron][upgrades] Bi-weekly upgrades work status. 6/2/2016

Ihar Hrachyshka ihrachys at redhat.com
Thu Jun 9 13:42:16 UTC 2016

> On 09 Jun 2016, at 02:45, Carl Baldwin <carl at ecbaldwin.net> wrote:
> On Thu, Jun 2, 2016 at 2:29 PM, Korzeniewski, Artur
> <artur.korzeniewski at intel.com> wrote:
>> I would like to remind that agreed approach at Design Summit in Austin was,
>> that every new resource added to neutron should have OVO implemented. Please
>> comply, and core reviewers please take care of this requirements in patches
>> you review.
> How about the networksegments table?  It was already a part of the ML2
> model but was moved out of ML2 to make it available for the OVN
> plugin.  Just days after the summit, it was made in to a first class
> resource [2] with its own CRUD operations.  Is this part of the model
> on your radar?  What needs to be done?
> Since then, a relationship has been added between segment and subnet
> [3].  Also, a mapping to hosts has been added [4].  What needs to be
> done for OVO for these?  I'm sorry if these are slipping through the
> cracks but we're still learning.  There are a couple of other model
> tweaks in play on this topic too [5][6].  I'd like to begin doing
> these the correct way.

First, thanks a lot Carl for stepping in on segments.

Previously, we had a blocker that did not allow us to proceed with segments OVO, due to missing sorting/pagination support in objects API. As of [1], it’s supported.

I think we should start from segment object itself and see where it leads us. As for relations to other resources, like subnet, we don’t implement them right away since e.g. subnet is not available at all. For the start, an object would for the most part reflect what’s already in database model (plus code sugar to make objects easier to use).

So the proper order to get this bit converted to using objects would be:
- model a new object class for segments (there are lots of examples under neutron/objects/);
- cover segments with sorting/pagination tests to avoid potential regressions; example at [2];
- switch existing places where segment models are accessed to using the object; example at [3].

In the end, you won’t have any references to NetworkSegment model except in the object itself.

ATM I see the following places to convert:
- neutron/db/ipam_backend_mixin.py
- neutron/db/segments_db.py
- neutron/services/segments/db.py

Once we are there, we can see whether more segment related models can be considered for conversion.

Please ping me if lost.

[1]: https://review.openstack.org/#/c/300055/
[2]: https://review.openstack.org/#/c/327081/
[3]: https://review.openstack.org/#/c/300056/


More information about the OpenStack-dev mailing list