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@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.exa...
Il giorno Gio 31 Gen 2019 20:56 Goutham Pacha Ravi <
ha scritto:
Hi Ignazio,
On Thu, Jan 31, 2019 at 7:31 AM Ignazio Cassano <ignaziocassano@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,
gouthampravi@gmail.com> 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@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@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