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
