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

Deepak Shetty dpkshetty at gmail.com
Fri Jan 30 05:04:14 UTC 2015


On Thu, Jan 29, 2015 at 10:52 PM, Jeff Darcy <jdarcy at redhat.com> wrote:

> > As i think more, maintaining list of CNs as part of ssl.auth-allow isn't
> > going to be easy from Manila side, unless Manila assumes that the first
> CN
> > in the list is the server, hence it should never touch that. What if the
> > admin pre-set the list of CNs, then Manila won't have a way to know which
> > one is the server CN and which are the client CNs. Even if we assume the
> > first CN as server CN, Manila (being python) works with the xml formatted
> > output of volume get, and I hope the CNs listed in the XML output are in
> the
> > same order as the allow list, otherwise we are in for more trouble!
>
> Isn't Manila already involved in the creation of every other CN but the
> server's, on the volumes it cares about?  Then it *does* know every client
> CN.  The server CN(s) can be a Manila configuration parameter, or else it
> can just assume that any CN it doesn't recognize as one of its own must be
> a server's and should be preserved.  Either way, that seems like a small
> fraction of the complexity that alternatives would impose on others.
>

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.

thanx,
deepak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150130/fe5101a2/attachment.html>


More information about the Gluster-devel mailing list