Open Stack

On Wed, Feb 6, 2019 at 12:16 PM Tom Barron <tpb at dyncloud.net> wrote:
>
> On 06/02/19 17:48 +0100, Ignazio Cassano wrote:
> >The 2 openstack Installations do not share anything. The manila on each one
> >works on different netapp storage, but the  2 netapp can be synchronized.
> >Site A with an openstack instalkation and netapp A.
> >Site B with an openstack with netapp B.
> >Netapp A and netapp B can be synchronized via network.
> >Ignazio
>
> OK, thanks.
>
> You can likely get the share data and its netapp metadata to show up
> on B via replication and (gouthamr may explain details) but you will
> lose all the Openstack/manila information about the share unless
> Openstack database info (more than just manila tables) is imported.
> That may be OK foryour use case.
>
> -- Tom


Checking if I understand your request correctly, you have setup
manila's "dr" replication in OpenStack A and now want to move your
shares from OpenStack A to OpenStack B's manila. Is this correct?

If yes, you must:
* Promote your replicas
   - this will make the mirrored shares available. This action does
not delete the old "primary" shares though, you need to clean them up
yourself, because manila will attempt to reverse the replication
relationships if the primary shares are still accessible
* Note the export locations and Unmanage your shares from OpenStack A's manila
* Manage your shares in OpenStack B's manila with the export locations
you noted.

> >
> >
> >Il giorno Mer 6 Feb 2019 16:32 Tom Barron <tpb at dyncloud.net> ha scritto:
> >
> >> On 06/02/19 15:34 +0100, Ignazio Cassano wrote:
> >> >Hello Tom, I think cases you suggested do not meet my needs.
> >> >I have an openstack installation A with a fas netapp A.
> >> >I have another openstack installation B with fas netapp B.
> >> >I would like to use manila replication dr.
> >> >If I replicate manila volumes  from A to B the manila db on B does not
> >> >knows anything about the replicated volume but only the backends  on
> >> netapp
> >> >B. Can I discover replicated volumes on openstack B?
> >> >Or I must modify the manila db on B?
> >> >Regards
> >> >Ignazio
> >>
> >> I guess I don't understand your use case.  Do Openstack installation A
> >> and Openstack installation B know *anything* about one another?  For
> >> example, are their keystone and neutron databases somehow synced?  Are
> >> they going to be operative for the same set of manila shares at the
> >> same time, or are you contemplating a migration of the shares from
> >> installation A to installation B?
> >>
> >> Probably it would be helpful to have a statement of the problem that
> >> you intend to solve before we consider the potential mechanisms for
> >> solving it.
> >>
> >> Cheers,
> >>
> >> -- Tom
> >>
> >> >
> >> >
> >> >Il giorno Dom 3 Feb 2019 11:05 Tom Barron <tpb at dyncloud.net> ha scritto:
> >> >
> >> >> On 01/02/19 07:28 +0100, Ignazio Cassano wrote:
> >> >> >Thanks Goutham.
> >> >> >If there are not mantainers for this driver I will switch on ceph and
> >> or
> >> >> >netapp.
> >> >> >I am already using netapp but I would like to export shares from an
> >> >> >openstack installation to another.
> >> >> >Since these 2 installations do non share any openstack component and
> >> have
> >> >> >different openstack database, I would like to know it is possible .
> >> >> >Regards
> >> >> >Ignazio
> >> >>
> >> >> Hi Ignazio,
> >> >>
> >> >> If by "export shares from an openstack installation to another" you
> >> >> mean removing them from management by manila in installation A and
> >> >> instead managing them by manila in installation B then you can do that
> >> >> while leaving them in place on your Net App back end using the manila
> >> >> "manage-unmanage" administrative commands. Here's some documentation
> >> >> [1] that should be helpful.
> >> >>
> >> >> If on the other hand by "export shares ... to another" you mean to
> >> >> leave the shares under management of manila in installation A but
> >> >> consume them from compute instances in installation B it's all about
> >> >> the networking.  One can use manila to "allow-access" to consumers of
> >> >> shares anywhere but the consumers must be able to reach the "export
> >> >> locations" for those shares and mount them.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> -- Tom Barron
> >> >>
> >> >> [1]
> >> >>
> >> https://netapp.github.io/openstack-deploy-ops-guide/ocata/content/manila.examples.manila_cli.single_svm.html#d6e5806
> >> >> >
> >> >> >Il giorno Gio 31 Gen 2019 20:56 Goutham Pacha Ravi <
> >> >> gouthampravi at gmail.com>
> >> >> >ha scritto:
> >> >> >
> >> >> >> Hi Ignazio,
> >> >> >>
> >> >> >> On Thu, Jan 31, 2019 at 7:31 AM Ignazio Cassano
> >> >> >> <ignaziocassano at gmail.com> wrote:
> >> >> >> >
> >> >> >> > Hello All,
> >> >> >> > I installed manila on my queens openstack based on centos 7.
> >> >> >> > I configured two servers with glusterfs replocation and ganesha
> >> nfs.
> >> >> >> > I configured my controllers octavia,conf but when I try to create a
> >> >> share
> >> >> >> > the manila scheduler logs reports:
> >> >> >> >
> >> >> >> > Failed to schedule create_share: No valid host was found. Failed to
> >> >> find
> >> >> >> a weighted host, the last executed filter was CapabilitiesFilter.:
> >> >> >> NoValidHost: No valid host was found. Failed to find a weighted host,
> >> >> the
> >> >> >> last executed filter was CapabilitiesFilter.
> >> >> >> > 2019-01-31 16:07:32.614 159380 INFO manila.message.api
> >> >> >> [req-241d66b3-8004-410b-b000-c6d2d3536e4a
> >> >> 89f76bc5de5545f381da2c10c7df7f15
> >> >> >> 59f1f232ce28409593d66d8f6495e434 - - -] Creating message record for
> >> >> >> request_id = req-241d66b3-8004-410b-b000-c6d2d3536e4a
> >> >> >>
> >> >> >>
> >> >> >> The scheduler failure points out that you have a mismatch in
> >> >> >> expectations (backend capabilities vs share type extra-specs) and
> >> >> >> there was no host to schedule your share to. So a few things to check
> >> >> >> here:
> >> >> >>
> >> >> >> - What is the share type you're using? Can you list the share type
> >> >> >> extra-specs and confirm that the backend (your GlusterFS storage)
> >> >> >> capabilities are appropriate with whatever you've set up as
> >> >> >> extra-specs ($ manila pool-list --detail)?
> >> >> >> - Is your backend operating correctly? You can list the manila
> >> >> >> services ($ manila service-list) and see if the backend is both
> >> >> >> 'enabled' and 'up'. If it isn't, there's a good chance there was a
> >> >> >> problem with the driver initialization, please enable debug logging,
> >> >> >> and look at the log file for the manila-share service, you might see
> >> >> >> why and be able to fix it.
> >> >> >>
> >> >> >>
> >> >> >> Please be aware that we're on a look out for a maintainer for the
> >> >> >> GlusterFS driver for the past few releases. We're open to bug fixes
> >> >> >> and maintenance patches, but there is currently no active maintainer
> >> >> >> for this driver.
> >> >> >>
> >> >> >>
> >> >> >> > I did not understand if controllers node must be connected to the
> >> >> >> network where shares must be exported for virtual machines, so my
> >> >> glusterfs
> >> >> >> are connected on the management network where openstack controllers
> >> are
> >> >> >> conencted and to the network where virtual machine are connected.
> >> >> >> >
> >> >> >> > My manila.conf section for glusterfs section is the following
> >> >> >> >
> >> >> >> > [gluster-manila565]
> >> >> >> > driver_handles_share_servers = False
> >> >> >> > share_driver = manila.share.drivers.glusterfs.GlusterfsShareDriver
> >> >> >> > glusterfs_target = root at 10.102.184.229:/manila565
> >> >> >> > glusterfs_path_to_private_key = /etc/manila/id_rsa
> >> >> >> > glusterfs_ganesha_server_username = root
> >> >> >> > glusterfs_nfs_server_type = Ganesha
> >> >> >> > glusterfs_ganesha_server_ip = 10.102.184.229
> >> >> >> > #glusterfs_servers = root at 10.102.185.19
> >> >> >> > ganesha_config_dir = /etc/ganesha
> >> >> >> >
> >> >> >> >
> >> >> >> > PS
> >> >> >> > 10.102.184.0/24 is the network where controlelrs expose endpoint
> >> >> >> >
> >> >> >> > 10.102.189.0/24 is the shared network inside openstack where
> >> virtual
> >> >> >> machines are connected.
> >> >> >> >
> >> >> >> > The gluster servers are connected on both.
> >> >> >> >
> >> >> >> >
> >> >> >> > Any help, please ?
> >> >> >> >
> >> >> >> > Ignazio
> >> >> >>
> >> >>
> >>