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