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

Jeff Darcy jdarcy at redhat.com
Thu Jan 29 17:22:08 UTC 2015


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


More information about the Gluster-devel mailing list