> 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
