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@xxxxxxxxxx> 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
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
