[openstack-dev] [cinder] [driver] DB operations

Mike Perez thingee at gmail.com
Wed Dec 24 20:16:19 UTC 2014

On 06:05 Sat 20 Dec     , Duncan Thomas wrote:
> No, I mean that if drivers are going to access database, then they should
> do it via a defined interface that limits what they can do to a sane set of
> operations. I'd still prefer that they didn't need extra access beyond the
> model update, but I don't know if that is possible.
> Duncan Thomas
> On Dec 19, 2014 6:43 PM, "Amit Das" <amit.das at cloudbyte.com> wrote:
> > Thanks Duncan.
> > Do you mean hepler methods in the specific driver class?
> > On 19 Dec 2014 14:51, "Duncan Thomas" <duncan.thomas at gmail.com> wrote:
> >
> >> So our general advice has historical been 'drivers should not be
> >> accessing the db directly'. I haven't had chance to look at your driver
> >> code yet, I've been on vacation, but my suggestion is that if you
> >> absolutely must store something in the admin metadata rather than somewhere
> >> that is covered by the model update (generally provider location and
> >> provider auth) then writing some helper methods that wrap the context bump
> >> and db call would be better than accessing it directly from the driver.
> >>
> >> Duncan Thomas
> >> On Dec 18, 2014 11:41 PM, "Amit Das" <amit.das at cloudbyte.com> wrote:

I've expressed in past reviews that we should have an interface that limits
drivers access to the database [1], but received quite a bit of push
back in Cinder. I recommend we stick to what has been decided, otherwise, Amit
you should spend some time on reading the history of this issue [2] from
previous meetings and start a rediscussion on it in the next meeting [3]. Not
discouraging it, but this has been something brought up at least a couple of
times now and it ends up with the same answer from the community.

[1] - https://review.openstack.org/#/c/107693/14
[2] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-15-16.00.log.html#l-186
[3] - https://wiki.openstack.org/wiki/CinderMeetings

Mike Perez

More information about the OpenStack-dev mailing list