Open Stack

We won't be able to take a hard and fast rule on this just because of the
way Neutron currently works and the semantics we offer the mechanism
drivers and extensions in ML2.

Right now when a port is created in ML2, we allow extensions and mechanism
drivers to make changes as part of the same transaction. If we completely
defer transaction handling to the OVO framework, it will break these
semantics.

We can certainly work to move as much of the handling for simpler cases
(e.g. security group rule creation) into the OVO framework, but there are
others like the one above where we will need to start a transaction first
and leave it open across multiple operations.

On Tue, Nov 15, 2016 at 6:15 AM, Morales, Victor <victor.morales at intel.com>
wrote:

> My two cents on this.
>
> OVO is going to be the new layer to access to DB model classes, therefore
> all the calls to the database(ensuring that there is an opened session) and
> the process to receive(validating fields) and/or return data(determining if
> a specific column exists) should be managed by OVO classes internally, so
> that’s also my understanding.
>
> Regards,
> Victor Morales
>
> From:  Gary Kotton <gkotton at vmware.com>
> Reply-To:  "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date:  Tuesday, November 15, 2016 at 3:06 AM
> To:  OpenStack List <openstack-dev at lists.openstack.org>
> Subject:  [openstack-dev] [neutron] OVO support
>
>
> Hi,
> It seems like a lot of the object work is being done under database
> transactions. My understanding is that the objects should take care of this
> internally.
> Any thoughts?
> Thanks
> Gary
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161115/c27da63e/attachment.html>