glusterfs_native: manila host TLS identity forced to be unintuitive

[Ramana Raja]

With the change https://review.openstack.org/#/c/215173/, glusterfs_native driver mounts the GlusterFS volume on the Manila host without disabling TLS authentication. This sets the requirement for Manila host to have TLS credentials to be setup to access the GlusterFS volume.

In the create_share_from_snapshot call, the share, a GlusterFS volume, that is created from snapshot needs to retain the the TLS identities (Common Names) of the GlusterFS servers an the Manila host to allow the volume to be used by the glusterfs_native driver. Presently, this is done by retaining identities that are prefixed by 'glusterfs-server'. So the Manila host is forced to be setup with a TLS certificate having a CN prefixed by 'glusterfs-server' to allow glusterfs_native driver to create a share from snapshot. It's not OK to set such an unintuitive constraint for the CN of the TLS certificate in the Manila host.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/224846

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/224846
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=69d06d7c5f1e398a7c0a508ea08afb38c057bc94
Submitter: Jenkins
Branch: master

commit 69d06d7c5f1e398a7c0a508ea08afb38c057bc94
Author: Ramana Raja <email address hidden>
Date: Thu Sep 17 23:04:41 2015 +0530

    glusterfs_native: Hardwire Manila Host CN pattern

    Currently, the glusterfs_native driver can support
    create_share_from_snapshot API only if the Manila host's TLS
    certificate's common name(CN) is prefixed by 'glusterfs-server'. This
    constraint on the CN of the host is not acceptable. So fix this by
    hardwiring a Manila host CN pattern that allows the Manila host CN
    to have a more intuitive prefix, 'manila-host'.

    Change-Id: Ibab27da4f9b28c6e7d2ef9c175d5decf5fa67ce4
    Closes-Bug: #1496833