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 <[email protected]> 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 <[email protected]> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > Date: Tuesday, November 15, 2016 at 3:06 AM > To: OpenStack List <[email protected]> > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
