[manila][glusterfs] on queens error
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
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
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, 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
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
Il giorno Gio 31 Gen 2019 20:56 Goutham Pacha Ravi gouthampravi@gmail.com 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, 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
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 gouthampravi@gmail.com 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, 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
Many Thanks. I will check it [1]. Regards Ignazio
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 <
gouthampravi@gmail.com>
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,
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
On 03/02/19 12:45 +0100, Ignazio Cassano wrote:
Many Thanks. I will check it [1]. Regards Ignazio
And Goutham just gave me a more current doc link:
https://netapp-openstack-dev.github.io/openstack-docs/rocky/manila/examples/...
-- 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 <
gouthampravi@gmail.com>
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,
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
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
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 <
gouthampravi@gmail.com>
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,
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
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 <
gouthampravi@gmail.com>
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,
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
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
Il giorno Mer 6 Feb 2019 16:32 Tom Barron tpb@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@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 <
gouthampravi@gmail.com>
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,
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
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
Il giorno Mer 6 Feb 2019 16:32 Tom Barron tpb@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@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 <
gouthampravi@gmail.com>
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,
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
On Wed, Feb 6, 2019 at 12:16 PM Tom Barron tpb@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@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@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 <
gouthampravi@gmail.com>
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,
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 >
Many thanks. I'll check today. Ignazio
Il giorno Mer 6 Feb 2019 21:26 Goutham Pacha Ravi gouthampravi@gmail.com ha scritto:
On Wed, Feb 6, 2019 at 12:16 PM Tom Barron tpb@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@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@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 < gouthampravi@gmail.com> >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,
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 >>
Hello, the manila replication dr works fine on netapp ontap following your suggestions. :-) Source backends (svm for netapp) must belong to a different destination backends availability zone, but in a single manila.conf I cannot specify more than one availability zone. For doing this I must create more share servers ....one for each availability zone. Svm1 with avz1 Svm1-dr with avz1-dr ......... Are you agree??? Thanks & Regards Ignazio
Il giorno Gio 7 Feb 2019 06:11 Ignazio Cassano ignaziocassano@gmail.com ha scritto:
Many thanks. I'll check today. Ignazio
Il giorno Mer 6 Feb 2019 21:26 Goutham Pacha Ravi gouthampravi@gmail.com ha scritto:
On Wed, Feb 6, 2019 at 12:16 PM Tom Barron tpb@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@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@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 < > gouthampravi@gmail.com> > >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,
> 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 > >> >
On Mon, Feb 11, 2019 at 10:18 AM Ignazio Cassano ignaziocassano@gmail.com wrote:
Hello, the manila replication dr works fine on netapp ontap following your suggestions. :-) Source backends (svm for netapp) must belong to a different destination backends availability zone, but in a single manila.conf I cannot specify more than one availability zone. For doing this I must create more share servers ....one for each availability zone. Svm1 with avz1 Svm1-dr with avz1-dr ......... Are you agree??? Thanks & Regards Ignazio
Yes, until the Stein release, you cannot specify multiple availability zones for a single manila share manager service, even if your deployment has multiple storage backends. However, you can run another manila share manager process with a different "storage_availability_zone" parameter as you described.
Il giorno Gio 7 Feb 2019 06:11 Ignazio Cassano ignaziocassano@gmail.com ha scritto:
Many thanks. I'll check today. Ignazio
Il giorno Mer 6 Feb 2019 21:26 Goutham Pacha Ravi gouthampravi@gmail.com ha scritto:
On Wed, Feb 6, 2019 at 12:16 PM Tom Barron tpb@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@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@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 < >> gouthampravi@gmail.com> >> >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, >> 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 >> >> >>
Many thanks for your help. Ignazio
Il giorno mer 13 feb 2019 alle ore 00:53 Goutham Pacha Ravi < gouthampravi@gmail.com> ha scritto:
On Mon, Feb 11, 2019 at 10:18 AM Ignazio Cassano ignaziocassano@gmail.com wrote:
Hello, the manila replication dr works fine on netapp ontap following
your suggestions. :-)
Source backends (svm for netapp) must belong to a different destination
backends availability zone, but in a single manila.conf I cannot specify more than one availability zone. For doing this I must create more share servers ....one for each availability zone.
Svm1 with avz1 Svm1-dr with avz1-dr ......... Are you agree??? Thanks & Regards Ignazio
Yes, until the Stein release, you cannot specify multiple availability zones for a single manila share manager service, even if your deployment has multiple storage backends. However, you can run another manila share manager process with a different "storage_availability_zone" parameter as you described.
Il giorno Gio 7 Feb 2019 06:11 Ignazio Cassano ignaziocassano@gmail.com
ha scritto:
Many thanks. I'll check today. Ignazio
Il giorno Mer 6 Feb 2019 21:26 Goutham Pacha Ravi <
gouthampravi@gmail.com> ha scritto:
On Wed, Feb 6, 2019 at 12:16 PM Tom Barron tpb@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@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@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 < > >> gouthampravi@gmail.com> > >> >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
> >> >> > 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@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 > >> >> > >> >
participants (3)
-
Goutham Pacha Ravi
-
Ignazio Cassano
-
Tom Barron