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).
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
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
You might like to watch Dan's demo again.
It goes something like:
yum install python-tripleoclient
openstack undercloud deploy
The problems this would solve are several:
- 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
- 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
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.
Get container integration "for free" when we land it in the overcloud
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.
- We remove dependencies on a bunch of legacy scripts which run outside of
If you mean instack-undercloud element, we're getting rid of them anyway,
Quite a few still remain, but yeah there are less than there was, which is
- 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
- 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
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
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
These are some strong but unqualified assertions, so it's hard to really
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).