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 <thin...@gmail.com> 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" <amit....@cloudbyte.com> wrote: > > > > > Thanks Duncan. > > > Do you mean hepler methods in the specific driver class? > > > On 19 Dec 2014 14:51, "Duncan Thomas" <duncan.tho...@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....@cloudbyte.com> wrote: > > I've expressed in past reviews that we should have an interface that limits > drivers access to the database , 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  from > previous meetings and start a rediscussion on it in the next meeting . > 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. > >  - https://review.openstack.org/#/c/107693/14 >  - > http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-15-16.00.log.html#l-186 >  - https://wiki.openstack.org/wiki/CinderMeetings > > -- > Mike Perez > > _______________________________________________ > OpenStack-dev mailing list > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev