[openstack-dev] [TripleO] a new Undercloud install driven by Heat
dtantsur at redhat.com
Fri Aug 5 13:55:40 UTC 2016
>> 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
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
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
>>> 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:
++ 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
>> 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
I think I've seen the patches up for removing all of them (except for
>>> 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
>>> 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
> 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
>> 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
>>> 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).
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev