Open Stack

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 <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 [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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>