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.