[Gluster-devel] GlusterFS SSL behaviour change breaks openstack Manila GlusterFS Native driver

[Deepak Shetty]

Jeff,
  'Guess i misunderstood your Q then, i took your Q on "isn't Manila
already involved in the creation of every other CN  "  as you saying that
manila should manage the trust setup! Hence my reply... Nevermind.

I very well understand and agree that the only way (given the absence of
auth reject for ssl) for Manila driver is to manage the list of CNs and
assume whatever is left after removing client CN is the server CNs and
preserve it. For a moment i do was confused but it's clear now. Not rocket
science for you but can't be sure of others ( incl. Me) :)

Thanks,
Deepak

On Jan 30, 2015 7:27 PM, "Jeff Darcy" <jdarcy at redhat.com> wrote:
>
> > Cert, Keys and CN management is out of band of Manila. The manila
community
> > didn't wanted to get into the lifecycle management as its not in the
scope of
> > Manila
> > project of openstack. Thus cert and trust setup is deployer's
responsibility
> > and needs to be done out of band of Manila.
>
> So this code isn't part of Manila?
>
> https://github.com/openstack/manila/tree/master/manila/share/drivers
>
> As far as I can tell, that code *is* managing tenants, volumes, certs,
> and so on - including actions on them and interactions between them.  It
> has its own config variables, and even a database.  As far as I can
> tell, it only has to handle adding access to a single CN at a time
> (adding a second will overwrite the ssl-allow value from adding the
> first).  Thus there are only two values for ssl-allow.
>
>         allow_access: internal CN + tenant CN (in access['access_to'])
>
>         deny_access: internal CN
>
> Why can't the internal CN be a configuration value, like the volume list
> or private-key location we already have?  Is there some strange quirk of
> how Manila (or OpenStack more generally) works that makes any of this
> seem like rocket science
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150130/de4bf6c6/attachment.html>