Open Stack

On Fri, Aug 05, 2016 at 12:27:40PM +0200, Dmitry Tantsur wrote:
> On 08/04/2016 11:48 PM, Dan Prince wrote:
> > Last week I started some prototype work on what could be a new way to
> > install the Undercloud. The driving force behind this was some of the
> > recent "composable services" work we've done in TripleO so initially I
> > called in composable undercloud. There is an etherpad here with links
> > to some of the patches already posted upstream (many of which stand as
> > general imporovements on their own outside the scope of what I'm
> > talking about here).
> > 
> > https://etherpad.openstack.org/p/tripleo-composable-undercloud
> > 
> > The idea in short is that we could spin up a small single process all-
> > in-one heat-all (engine and API) and thereby avoid things like Rabbit,
> > and MySQL. Then we can use Heat templates to drive the Undercloud
> > deployment just like we do in the Overcloud.
> 
> I don't want to sound rude, but please no. The fact that you have a hammer
> does not mean everything around is nails :( What problem are you trying to
> solve by doing it?

I think Dan explains it pretty well in his video, and your comment
indicates a fundamental misunderstanding around the entire TripleO vision,
which is about symmetry and reuse between deployment tooling and the
deployed cloud.

The problems this would solve are several:

1. Remove divergence between undercloud and overcloud puppet implementation
(instead of having an undercloud specific manifest, we reuse the *exact*
same stuff we use for overcloud deployments)

2. Better modularity, far easier to enable/disable services

3. Get container integration "for free" when we land it in the overcloud

4. Any introspection and debugging workflow becomes identical between the
undercloud and overcloud

5. We remove dependencies on a bunch of legacy scripts which run outside of
puppet

6. Whenever someone lands support for a new service in the overcloud, we
automatically get undercloud support for it, completely for free.

7. Potential for much easier implementation of a multi-node undercloud

> Undercloud installation is already sometimes fragile, but it's probably the
> least fragile part right now (at least from my experience) And at the very
> least it's pretty obviously debuggable in most cases. THT is hard to
> understand and often impossible to debug. I'd prefer we move away from THT
> completely rather than trying to fix it in one more place where heat does
> not fit..

These are some strong but unqualified assertions, so it's hard to really
respond.  Yes, there is complexity, but it's a set of abstractions which
actually work pretty well for us, so there is value in having just one set
of abstractions used everywhere vs special-casing the undercloud.

Re moving away from THT completely, this is not a useful statement -
yes, there are alternative tools, but if you were to remove THT and just
use some other tool with Ironic, the result would simply not be TripleO.
There would be zero migration/upgrade path for existing users and all
third-party integrations (and our API/UI) would break.

FWIW I think this prototyping work is very interesting, and I'm certainly
keen to get wider (more constructive) feedback and see where it leads.

Thanks,

Steve