Consistent topology per service_group

[bodymindarts]

Currently the topology of a service is not being gossiped. It will need to be gossiped in order to implement #2003.

However first we need to address some inconsistent/undefined behaviour. Currently topology is scoped to a service and not a service_group this means it is possible for some services in a group to execute logic as if they were in standalone topology while another part of the group
executes code relevant to leader topology (eg. here).

How should this be dealt with?
I suggest prohibiting services to join a group that are started with a different --topology setting as the rest of the group.

[mwrock]

I think a common scenario might be a simple web application where you want a leader topology for the web tier but a standalone database. Granted its just a demo, but in https://github.com/habitat-sh/habitat-aspnet-sample, I have such a scenario. I want rolling updates to the web app but don't want the complexity of a multi node db cluster.

[bodymindarts]

@mwrock Right but it is possible to start some parts of your web app with --topoplogy leader and others without (so implicitly --topology standalone). This could cause some of the web app instances to behaviour differently than others even though they are part of the same service_group.

[mwrock]

yes that would be undesirable. I see now that I have mixed group with "service group" here. So my comment really does not apply.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.