Open Stack

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.
>
> 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)

this; to reuse the service templates and puppet classes as they are 
sounds good

> 2. Better modularity, far easier to enable/disable services
>
> 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
>
> 5. We remove dependencies on a bunch of legacy scripts which run outside of
> puppet
>
> 6. Whenever someone lands support for a new service in the overcloud, we
> automatically get undercloud support for it, completely for free.
>
> 7. Potential for much easier implementation of a multi-node undercloud
>
>> 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..

I *do* see your point about the undercloud installation being the less 
problematic but I part of that is because we didn't need to plug into 
the undercloud the same level of flexibility we demand for overcloud

Now, maybe we also shouldn't make things complicated where they don't 
need to (see points 2 and 3) but in addition to reusing tht/puppet code, 
I think it would be interesting to have undercloud/ha (point 7)

fwiw, I'd like to try this out myself before the summit to get a better 
picture.
-- 
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente