[openstack-dev] [tripleo][manila] Moving forward with landing manila in tripleo
rodrigo.barbieri2010 at gmail.com
Fri May 27 19:46:37 UTC 2016
The Data Service is needed for Share Migration feature in manila since the
There has not been any work done yet towards adding it to puppet. Since its
introduction in Mitaka, it has been made compatible only with devstack so
I have not invested time thinking about how it should fit in a HA
environment at this stage, this is a service that currently sports a single
instance, but we have plans to make it more scallable in the future.
What I have briefly thought about is the idea where there would be a
scheduler that decides whether to send the data job to m-dat1, m-dat2 or
m-dat3 and so on, based on information that indicates how busy each Data
Service instance is.
For this moment, active/passive makes sense in the context that manila
expects only a single instance of m-dat. But active/active would allow the
service to be load balanced through HAProxy and could partially accomplish
what we have plans to achieve in the future.
I hope I have addressed your question. The absence of m-dat implies in the
Share Migration feature not working.
On Fri, May 27, 2016 at 10:10 AM, Marios Andreou <marios at redhat.com> wrote:
> Hi all, I explicitly cc'd a few folks I thought might be interested for
> visibility, sorry for spam if you're not. This email is about getting
> manila landed into tripleo asap, and the current obstacles to that (at
> least those visible to me):
> The current review  isn't going to land as is, regardless of the
> outcome/discussion of any of the following points because all the
> services are going to "composable controller services". How do people
> feel about me merging my review at  into its parent review (which is
> the current manilla review at ). My review just takes what is in 
> (caveats below) and makes it 'composable', and includes a dependency on
>  which is the puppet-tripleo side for the 'composable manila'.
> ---> Proposal merge the 'composable manila' tripleo-heat-templates
> review @  into the parent review @ . The review at  will be
> abandoned. We will continue to try and land  in its new 'composable
> manila' form.
> WRT the 'caveats' mentioned above and why I haven't just just ported
> what is in the current manila review @  into the composable one @
> ... there are two main things I've changed, both of which on
> guidance/discussion on the reviews.
> The first is addition of manila-data (wasn't in the original/current
> review at ). The second a change to the pacemaker constraints, which
> I've corrected to make manila-data and manila-share pacemaker a/p but
> everything else systemd managed, based on ongoing discussion at .
> So IMO to move forward I need clarity on both those points. For
> manila-data my concerns are is it already available where we need it. I
> looked at puppet-manila  and couldn't quickly find much (any) mention
> of manila-data. We need it there if we are to configure anything for it
> via puppet. The other unkown/concern here is does manila-data get
> delivered with the manila package (I recall manila-share possibly, at
> least one of them, had a stand-alone package) otherwise we'll need to
> add it to the image. But mainly my question here is, can we live without
> it? I mean can we deploy sans manila-data or does it just not make sense
> (sorry for silly question). The motivation is if we can let's land and
> iterate to add it.
> Q. Can we live w/out manila-data so we can land and iterate (esp. if
> we need to land things into puppet-manila or anywhere else it is yet to
> be landed)
> For the pacemaker constraints I'm mainly just waiting for confirmation
> of our current understanding.. manila-share and manila-data are a/p
> pacemaker managed, everything else systemd.
> thanks for any info, I will follow up and update the reviews accordingly
> based on any comments,
>  "Enable Manila integration" https://review.openstack.org/#/c/188137/
>  "Composable manila tripleo-heat-templates side"
>  "Adds the puppet-tripleo manifests for manila"
>  "openstack/puppet-manila" https://github.com/openstack/puppet-manila
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
OpenStack Manila Contributor
Federal University of São Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev