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
__________________________________________________________________________
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
