Open Stack

Many thanks for your help.
Ignazio

Il giorno mer 13 feb 2019 alle ore 00:53 Goutham Pacha Ravi <
gouthampravi at gmail.com> ha scritto:

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