<p dir="ltr">Hi Marios,</p>
<p dir="ltr">I am ok with landing manila in tripleo with manila-data pending as you are suggesting. Manila-data can be added later, thus not blocking your current efforts.</p>
<p dir="ltr">Regards,<br>
--<br>
Rodrigo Barbieri<br>
Computer Scientist<br>
OpenStack Manila Contributor<br>
Federal University of São Carlos</p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 27/05/16 22:46, Rodrigo Barbieri wrote:<br>
> Hello Marios,<br>
><br>
<br>
Hi Rodrigo, thanks very much for taking the time, indeed that clarifies<br>
quite a lot:<br>
<br>
> The Data Service is needed for Share Migration feature in manila since the<br>
> Mitaka release.<br>
><br>
> There has not been any work done yet towards adding it to puppet. Since its<br>
> introduction in Mitaka, it has been made compatible only with devstack so<br>
> far.<br>
<br>
I see so at least that confirms I didn't just miss it at puppet-manila<br>
... so that is a prerequisite really to us being able to configure and<br>
enable manila-data in tripleo and someone will have to look at doing that.<br>
<br>
><br>
> I have not invested time thinking about how it should fit in a HA<br>
> environment at this stage, this is a service that currently sports a single<br>
> instance, but we have plans to make it more scallable in the future.<br>
> What I have briefly thought about is the idea where there would be a<br>
> scheduler that decides whether to send the data job to m-dat1, m-dat2 or<br>
> m-dat3 and so on, based on information that indicates how busy each Data<br>
> Service instance is.<br>
><br>
> For this moment, active/passive makes sense in the context that manila<br>
> expects only a single instance of m-dat. But active/active would allow the<br>
> service to be load balanced through HAProxy and could partially accomplish<br>
> what we have plans to achieve in the future.<br>
<br>
OK thanks, so we can proceed with a/p for manila-share and manila-data<br>
(one thought below) for now and revisit once you've worked out the<br>
details there.<br>
<br>
><br>
> I hope I have addressed your question. The absence of m-dat implies in the<br>
> Share Migration feature not working.<br>
><br>
<br>
thanks for the clarification. So then I wonder if this is a feature we<br>
can live w/out for now, especially if this is an obstacle to landing<br>
manila-anything in tripleo. I mean, if we can live w/out the Share<br>
Migration Feature, until we get proper support for configuring<br>
manila-data landed, then lets land w/out manila data and just be really<br>
clear about what is going on, manila-data pending etc.<br>
<br>
thanks again, marios<br>
<br>
<br>
<br>
><br>
> Regards,<br>
><br>
> On Fri, May 27, 2016 at 10:10 AM, Marios Andreou <<a href="mailto:marios@redhat.com">marios@redhat.com</a>> wrote:<br>
><br>
>> Hi all, I explicitly cc'd a few folks I thought might be interested for<br>
>> visibility, sorry for spam if you're not. This email is about getting<br>
>> manila landed into tripleo asap, and the current obstacles to that (at<br>
>> least those visible to me):<br>
>><br>
>> The current review [1] isn't going to land as is, regardless of the<br>
>> outcome/discussion of any of the following points because all the<br>
>> services are going to "composable controller services". How do people<br>
>> feel about me merging my review at [2] into its parent review (which is<br>
>> the current manilla review at [1]). My review just takes what is in  [1]<br>
>> (caveats below) and makes it 'composable', and includes a dependency on<br>
>> [3] which is the puppet-tripleo side for the 'composable manila'.<br>
>><br>
>>    ---> Proposal merge the 'composable manila' tripleo-heat-templates<br>
>> review @ [2] into the parent review @ [1]. The review at [2] will be<br>
>> abandoned. We will continue to try and land [1] in its new 'composable<br>
>> manila' form.<br>
>><br>
>> WRT the 'caveats' mentioned above and why I haven't just just ported<br>
>> what is in the current manila review @ [1] into the composable one @<br>
>> [2]... there are two main things I've changed, both of which on<br>
>> guidance/discussion on the reviews.<br>
>><br>
>> The first is addition of manila-data (wasn't in the original/current<br>
>> review at [1]). The second a change to the pacemaker constraints, which<br>
>> I've corrected to make manila-data and manila-share pacemaker a/p but<br>
>> everything else systemd managed, based on ongoing discussion at [3].<br>
>><br>
>> So IMO to move forward I need clarity on both those points. For<br>
>> manila-data my concerns are is it already available where we need it. I<br>
>> looked at puppet-manila [4] and couldn't quickly find much (any) mention<br>
>> of manila-data. We need it there if we are to configure anything for it<br>
>> via puppet. The other unkown/concern here is does manila-data get<br>
>> delivered with the manila package (I recall manila-share possibly, at<br>
>> least one of them, had a stand-alone package) otherwise we'll need to<br>
>> add it to the image. But mainly my question here is, can we live without<br>
>> it? I mean can we deploy sans manila-data or does it just not make sense<br>
>> (sorry for silly question). The motivation is if we can let's land and<br>
>> iterate to add it.<br>
>><br>
>>    Q. Can we live w/out manila-data so we can land and iterate (esp. if<br>
>> we need to land things into puppet-manila or anywhere else it is yet to<br>
>> be landed)<br>
>><br>
>> For the pacemaker constraints I'm mainly just waiting for confirmation<br>
>> of our current understanding.. manila-share and manila-data are a/p<br>
>> pacemaker managed, everything else systemd.<br>
>><br>
>> thanks for any info, I will follow up and update the reviews accordingly<br>
>> based on any comments,<br>
>><br>
>> marios<br>
>><br>
>> [1] "Enable Manila integration" <a href="https://review.openstack.org/#/c/188137/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/188137/</a><br>
>> [2] "Composable manila tripleo-heat-templates side"<br>
>> <a href="https://review.openstack.org/#/c/315658/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/315658/</a><br>
>> [3] "Adds the puppet-tripleo manifests for manila"<br>
>> <a href="https://review.openstack.org/#/c/313527/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/313527/</a><br>
>> [4] "openstack/puppet-manila" <a href="https://github.com/openstack/puppet-manila" rel="noreferrer" target="_blank">https://github.com/openstack/puppet-manila</a><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>