I think it makes sense to merge the triplo heat templates without m-dat
support, as including m-dat will require a bunch of dependent patches
and slow everything down. The lack of the m-dat service won't cause any
issues other than that the experimental share-migration APIs won't work.
We should of course start work on all of those other patches
immediately, and add a follow-on patch to add m-dat support to tripleo.
One other thing -- the design of the m-dat service currently doesn't
lend it to HA or scale-out configurations, but the whole point of
creating this separate service is to provide for HA and scale out of
data-oriented operations, so I expect that by the end of Newton any
issues related to active/active m-dat will have been addressed.
-Ben
On 05/30/2016 04:48 AM, Marios Andreou wrote:
On 27/05/16 22:46, Rodrigo Barbieri wrote:
Hello Marios,
Hi Rodrigo, thanks very much for taking the time, indeed that clarifies
quite a lot:
The Data Service is needed for Share Migration feature in manila since the
Mitaka release.
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
far.
I see so at least that confirms I didn't just miss it at puppet-manila
... so that is a prerequisite really to us being able to configure and
enable manila-data in tripleo and someone will have to look at doing that.
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.
OK thanks, so we can proceed with a/p for manila-share and manila-data
(one thought below) for now and revisit once you've worked out the
details there.
I hope I have addressed your question. The absence of m-dat implies in the
Share Migration feature not working.
thanks for the clarification. So then I wonder if this is a feature we
can live w/out for now, especially if this is an obstacle to landing
manila-anything in tripleo. I mean, if we can live w/out the Share
Migration Feature, until we get proper support for configuring
manila-data landed, then lets land w/out manila data and just be really
clear about what is going on, manila-data pending etc.
thanks again, marios
Regards,
On Fri, May 27, 2016 at 10:10 AM, Marios Andreou <mar...@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 [1] 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 [2] into its parent review (which is
the current manilla review at [1]). My review just takes what is in [1]
(caveats below) and makes it 'composable', and includes a dependency on
[3] which is the puppet-tripleo side for the 'composable manila'.
---> Proposal merge the 'composable manila' tripleo-heat-templates
review @ [2] into the parent review @ [1]. The review at [2] will be
abandoned. We will continue to try and land [1] 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 @ [1] into the composable one @
[2]... 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 [1]). 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 [3].
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 [4] 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,
marios
[1] "Enable Manila integration" https://review.openstack.org/#/c/188137/
[2] "Composable manila tripleo-heat-templates side"
https://review.openstack.org/#/c/315658/
[3] "Adds the puppet-tripleo manifests for manila"
https://review.openstack.org/#/c/313527/
[4] "openstack/puppet-manila" https://github.com/openstack/puppet-manila
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
