Hi, Maybe I understood this option -
Instead of adding one more relation to glance, I can relate my charm to new relation 'cinder-volume-service' So there is no more changes in the glance charm. And additional in my charm will be - metadata.yaml - *subordinate: trueprovides: image-backend: interface: cinder scope: container* and then I can relate my charm to glance (and my charm will be installed in the same container as glance, so I can configure OS) *juju add-relation glance:cinder-volume-service scaleio-openstack:image-backend* This option works for me - I don't need to add something to glance config. I'm only need to add files to /etc/glance/rootwrap.d/ and this option allows to do it. I've made additional review - https://review.openstack.org/#/c/350565/ But I don't need it :) Should I abandon it or not? On Tue, Aug 2, 2016 at 6:15 PM, James Page <james.p...@ubuntu.com> wrote: > Hi Andrey > > On Tue, 2 Aug 2016 at 15:59 Andrey Pavlov <andrey...@gmail.com> wrote: > >> I need to add glance support via storing images in cinder instead of >> local files. >> (This works only from Mitaka version due to glance-store package) >> > > OK > > >> First step I've made here - >> https://review.openstack.org/#/c/348336/ >> This patchset adds ability to relate glance-charm to cinder-charm >> (it's similar to ceph/swift relations) >> > > Looks like a good start, I'll comment directly on the review with any > specific comments. > > >> And also it configures glance's rootwrap - original glance package >> doesn't have such code >> ( >> I think that this is a bug in glance-common package - cinder and >> nova can do it themselves. >> And if someone point me to bugtracker - I will file the bug there. >> ) >> > > Sounds like this should be in the glance package: > > https://bugs.launchpad.net/ubuntu/+source/glance/+filebug > > or use: > > ubuntu-bug glance-common > > on an installed system. > > >> But main question is about additional configurations' steps - >> Some cinder backends need to store additional files in >> /etc/glance/rootwrap.d/ folder. >> I have two options to implement this - >> 1) relate my charm to glance:juju-info (it will be run on the same >> machine as glance) >> and do all work in this hook in my charm. >> 2) add one more relation to glance - like >> 'storage-backend:cinder-backend' in cinder. >> And write code in a same way - with ability to pass config options. >> > >> I prefer option 2. It's more logical and more general. It will allow >> to configure any cinder's backend. >> > > +1 the subordinate approach in cinder (and nova) works well; lets ensure > the semantics on the relation data mean its easy to restart the glance > services from the subordinate service if need be. > > Taking this a step further, it might also make sense to have the relation > to cinder on the subordinate charm and pass up the data item to configure > glance to use cinder from the sub - does that make sense in this context? > > Cheers > > James > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kind regards, Andrey Pavlov.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
