Open Stack

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
>