Open Stack

<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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>