<div dir="ltr">Hello Marios,<div><br></div><div>The Data Service is needed for Share Migration feature in manila since the Mitaka release. </div><div><br></div><div>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.</div><div><br></div><div>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. </div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I hope I have addressed your question. The absence of m-dat implies in the Share Migration feature not working.</div><div><br></div><div><br></div><div>Regards,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 27, 2016 at 10:10 AM, Marios Andreou <span dir="ltr"><<a href="mailto:marios@redhat.com" target="_blank">marios@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Rodrigo Barbieri<div>Computer Scientist</div><div>OpenStack Manila Contributor</div><div>Federal University of São Carlos</div><div><br></div></div></div></div>
</div>