Open Stack

On Tue, 2018-12-18 at 14:47 +0100, Cédric Jeanneret wrote:
> Hello folks,
> 
> While working on the service flattening in t-h-t, I have some
> question
> regarding the pacemaker things.
> 
> If we take rabbitmq:
> - we have rabbitmq things in docker/services
> - we have rabbitmq things in puppet/services
> - we have rabbitmq things in docker/services/pacemaker
> - we have rabbitmq things in puppet/services/pacemaker
> 
> If the plain services are easy to flatten, the pacemaker part is more
> annoying, at least on the naming/location.
> 
> I see the following possibilities:
> - create a deployment/pacemaker and move all pacemaker-related things
> in
> there

This was the old way. A directory for all the 'docker' stuff. A
directory for all the 'puppet' stuff. It doesn't seem like people
prefered this so we are re-organizing it by service now. There are pros
and cons to both approaches I think. It largely comes down to
preference.

> 
> - name files something like rabbitmq-pacemaker-foo.yaml and push them
> in deployment/rabbitmq

I think this options seems reasonable and would seem to follow the
convention are moving to in the deployments directory to split things
out by service.

You might call it rabbitmq-pacemaker-puppet.yaml for example. The
convention is <service name> - <engine> - <config tool>. Or something
like that.

> 
> Both look valid. And both might have their downsides.
> Any advice, idea, feeling on that?
> 
> Also, regarding the workflow: do we do that flattening in one, or two
> passes?

Flattening and moving files in the same patch leads to larger reviews.
But it also saves CI reasources. For smaller services perhaps do them
together. For services with multiple files perhaps consider splitting
up the patchset somehow to make it smaller.

Dan

> i.e. we can move all rabbitmq related code at once, or only the plain
> service, and do a second patch for the pacemaker things.
> 
> Here again, both look valid, but I'm more in the "2 passes" idea.
> 
> So... yeah, I'd like to get some feedback on that in order to do
> things
> right, and avoid monkey-patching because paths/naming aren't good ;).
> 
> Thanks!
> 
> Cheers,
> 
> C.
> 
> 
> 
>