Open Stack

Hi Andrey

On Wed, 3 Aug 2016 at 14:35 Andrey Pavlov <andrey.mp at gmail.com> wrote:

> Instead of adding one more relation to glance, I can relate my charm to
> new relation 'cinder-volume-service'
>

almost


>
> 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*
>

Almost - the interface type should be something like 'glance-backend'
matching the type of the container scoped interface we'd need to add to the
glance charm.

provides:
  image-backend:
    interface: glance-backend
    scope: container

The glance charm needs to interrogate the data presented by the subordinate
charm - I'd suggest one of the data items is 'cinder-backend=True|False' in
which case the glance charm can then set the required configuration option
in the glance-api.conf file (instead of doing that via a relation to cinder
as you proposed in your original changes to glance).


> 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 think the experience would be something like:

  *juju add-relation glance:image-backend  scaleio-openstack:image-backend*

based on my feedback above.  A relation to cinder might not be required
at-all if all glance needs to know is 'use cinder' rather than any other
additional data such as the location of the cinder-api services etc..

As you state - the scaleio-openstack charm can install the required filters
to /etc/glance/rootwrap.d - which is great as it moves the scaleio specific
bits into a specific charm for scaleio (which I like), rather than
overloading and increasing the complexity of the core glance charm.


> I've made additional review - https://review.openstack.org/#/c/350565/
>

Looking today -  I think we can refine things via the review if the overall
design intent is agreed here.

Thanks for your work on this feature!

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160804/89b6aedc/attachment.html>