Thanks Mike for getting me these useful reviews & design discussions. So as it stands now, I am trying '*provider_id*' to map OpenStack/Cinder with the driver's backend storage.
I got some useful review comments from @xing-yang to try out '*provider_id'* feature enabled by below commit: https://review.openstack.org/#/c/143205/ Do let me know if '*provider_id'* approach seems reasonable ? Regards, Amit *CloudByte Inc.* <http://www.cloudbyte.com/> On Thu, Dec 25, 2014 at 1:46 AM, Mike Perez <[email protected]> wrote: > 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" <[email protected]> wrote: > > > > > Thanks Duncan. > > > Do you mean hepler methods in the specific driver class? > > > On 19 Dec 2014 14:51, "Duncan Thomas" <[email protected]> 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" <[email protected]> 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 > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
