[rdo-list] Packstack refactor and future ideas

[James Slagle]

On Thu, Jun 09, 2016 at 12:40:39AM +0200, Hugh Brock wrote:
> Here's a possibly stupid question, indulge me....
> 
> Seems like we're always going to need a simple (ish) tool that just
> installs the openstack services on a single machine, without any need for
> VMs.
> 
> In fact, the tripleo installer - instack - is one such tool. Packstack is
> another, more flexible such tool. Should we consider merging or adapting
> them to be the same tool?

The point of instack has always been to reuse the same tooling that is used for
the overcloud to do the undercloud install.

Given:
  - the composability that is coming in tripleo-heat-templates
  - driving SoftwareDeployment via Heat without a full stack
  - applying those SoftwareDeployments to servers that don't even have to
    be known to Heat

I actually think we'd move more in the direction of using
tripleo-heat-templates in some fashion to install the undercloud.

Also given the requirements around undercloud HA, TripleO doesnt want to
reinvent the wheel coming up with a new multinode HA installer. Users are
likely to want compsability, network isolation, ipv6, etc, for their HA
underclouds too. Reusing what we're already doing for the overcloud makes the
most sense to me.

That would be the next iteration of instack IMO, using Heat and
tripleo-heat-templates. As long as those are our tools for the overcloud, I'd
want to reuse them for the undercloud as well, especially as the requirements
grow to require more complexity.

That solution might result in a nice and simple AIO installer as well, but
I don't hear a lot of requests for that outside the context of "how can we get
rid of packstack". Which doesn't seem like all that valid of a reason tbh given
that packstack is already really good at doing AIO.

Approaching it from the other angle, what if packstack were really good at
multinode HA, and we used that for undercloud HA? That could definitely work,
but you don't have any code reuse between the undercloud and overcloud other
than the puppet modules.

Further, there would be a fair amount of churn in the install experience unless
we developed a compatibility layer as well, would we really want to deprecate
every undercloud.conf already out there, and require rewriting it as answers
file? I think there's a fair amount of complexity and trade-offs to consider in
going this route as well.

I think the last time we had this discussion, it more or less inspired/moved us
along the lines of creating tripleo-quickstart. It's just not clear to me if
the current discussion is about making AIO better or making multinode easier
via packstack.

It might be useful to define who we're actually targetting with this effort,
and what the requirements are. IME, the effort to get to a simple and working
multinode installer if actually pretty easy. But then you're staring at a huge
amount of complexity to move it to the next level of even being usable for
POC's.

We're spending a lot of time trying to make TripleO easier for POC's as well. I
think what we're finding though is that there are no "simple" POC's either,
every one is different.  You still need a fair amount of customization, which
results in complexity, even for POC's.

--
-- James Slagle
--