Open Stack

On Fri, Aug 05, 2016 at 01:56:32PM +0200, Dmitry Tantsur wrote:
> On 08/05/2016 01:21 PM, Steven Hardy wrote:
> > 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.
> 
> Well, except for you need some non-openstack starting point, because unlike
> with e.g. ansible installing any openstack service(s) does not end at "dnf
> install <package-name>".

You might like to watch Dan's demo again.

It goes something like:

yum install python-tripleoclient
openstack undercloud deploy

Done!

> > 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)
> 
> I'm not against reusing puppet bits, I'm against building the same heavy
> abstraction layer with heat around it.

Sure, this is a valid concern to raise, and analternative to what Dan has
prototyped would be to refactor the undercloud puppet manifest to use the
puppet-tripleo profiles, somebody still has to do this work and it still
doesn't help at all with either container integration or multi-node
underclouds.

> > 2. Better modularity, far easier to enable/disable services
> 
> Why? Do you expect enabling/disabling Nova, for example? In this regard
> undercloud is fundamentally different from overcloud: for the former we have
> a list of required services and a pretty light list of optional services.

Actually, yes!  I'd love to be able to disable Nova and instead deploy
nodes directly via a mistral workflow that drives Ironic.  That's why I
started this:

https://review.openstack.org/#/c/313048/

There are reasons such as static IPs for everything where you might want to
be able to make Neutron optional, and there are already a bunch of optional
services (such as all the telemetry services).

Ok, every time I want to disable or add a new service I can hack on the
manifest, but it's just extra work compared to reusing the exact same
method we already support for overcloud deployments.

> > 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
> 
> I would love a defined debugging workflow for the overcloud first..

Sure, and it's something we have to improve regardless.

> > 5. We remove dependencies on a bunch of legacy scripts which run outside of
> > puppet
> 
> If you mean instack-undercloud element, we're getting rid of them anyway,
> no?

Quite a few still remain, but yeah there are less than there was, which is
good.

> > 6. Whenever someone lands support for a new service in the overcloud, we
> > automatically get undercloud support for it, completely for free.
> 
> Again, why? A service won't integrate itself into the deployment. And to be
> honest, the amount of options TripleO has already cases real world problems.
> I would rather see a well defined set of functionality for it..

It means it's easy to enable any service which is one less barrier to
integration, I'm not really sure how that could be construed as a bad
thing.

> > 7. Potential for much easier implementation of a multi-node undercloud
> 
> Ideally, I would love to see:
> 
>  for node in nodes:
>    ssh $node puppet apply blah-blah

Haha, this is a delightful over-simplification, but it completely ignores
all of the logic to create the per-node manifests and hieradata.  This is
what the Heat templates already do for us, over multiple nodes by default.

> Maybe we're not there, but it only means we have to improve our puppet
> modules.

There is a layer of orchestration outside of the per-service modules which
is needed here.  We do that simply in the current undercloud implementation
by having a hard-coded manifest, which works OK.  We do that in the
overcloud by orchestrating puppet via Heat over multiple nodes, which also
works OK.

> > > 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.
> 
> We'll talk about "unqualified" assertions the next time I'll try to get
> answers on #tripleo after seeing error messages like "controller_step42
> failed with code 1" ;)

Next time that happens, try typing "openstack stack failures list
overcloud" - it's a first step to improving the way we surface errors.

> > 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.
> 
> There should be a point where we stop. What entity is going to install heat
> to install undercloud (did I just say "seed")? What will provide HA for it?
> Authentication, templates storage and versioning? How do you reuse the same
> abstractions (that's the whole point after all)?

Watch the demo.  Tripleoclient runs a heat process, which drives
applying puppet.  There is no seed, but I guess it could be a disposable
container (as Dan said in his demo).

Thanks,

Steve