[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 <
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
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 <
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
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 <
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
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
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 <
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
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 <
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
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 <
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 >
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
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
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
>> GlusterFS driver for the past few releases. We're open to bug fixes >> and maintenance patches, but there is currently no active
>> for this driver. >> >> >> > I did not understand if controllers node must be connected to
not that the maintainer 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
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
> >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
> 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
> >> GlusterFS driver for the past few releases. We're open to bug fixes > >> and maintenance patches, but there is currently no active
not possible . that the 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>
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
> 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
> 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
> >> >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
> >> >> 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
> >> >> 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
ha scritto: the that possible . 7. things to check there was a 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