<snip>
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!
That's pretty awesome indeed. But it also moves the user further away
from the actual code running, so in case of an unobvious failure they'll
have to inspect more layers. I guess I am getting at the debugability
point again... At least it's good to know we're getting all the output
visible, that's really great.
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.
So, this multi-node thing. Will it still be as easy as running one
command? I guess we assume that the OS is already provisioned on all
nodes, right?
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/
++ to this
However, it brings a big QE concern. If we say we support deployment
with and without nova, it increases a number of things to test wrt
provisioning twice. I still suspect we'll end up with one "blesses" way,
and the other "probably working" ways. Which might not be so good.
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.
I think I've seen the patches up for removing all of them (except for
puppet-stack-config obviously).
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.
A bit unrelated, but while we're here... I wonder if we could stop after
instances are deployed with Heat returning a set of hieredata files for
nodes... Haven't thought is through, just a quick idea.
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.
Oh, something new :) Thanks! Any particular reason it's not in our
troubleshooting guide and we don't save (or do we?) its output in the CI
runs?
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
__________________________________________________________________________
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
