Allow nomad to declare canary instances and non canary instances in different consul services

[mildred]

Nomad version

Nomad v0.8.4 (dbee1d7d051619e90a809c23cf7e55750900742a)

Operating system and Environment details

CoreOS

core@ip-10-0-9-185 ~ $ cat /etc/os-release 
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1800.7.0
VERSION_ID=1800.7.0
BUILD_ID=2018-08-15-2254
PRETTY_NAME="Container Linux by CoreOS 1800.7.0 (Rhyolite)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"

Feature Request

Nomad allows canary deployment, but the only way to load balance or select between the promoted instances and the canary instances using Consul is via canary_tags. This means that a single service in the Consul catalog will contain both canaries and promoted instances. Some Consul clients such as Traefik are not able to make the difference between the different instances under a single Consul service, see traefik/traefik#3882.

For the sake of those clients, it should be possible to declare in a service stanza that it should only contain promoted instances, or to the contrary, that it should only contain canary instances.

[dadgar]

@mildred I am a little confused by the request. The title and your ask seems to be different. Are you asking to have a canary_name such that canaries are registered separately?

[mildred]

I'm asking something like the service stanza could gain an attribute:

• instances (string, default: all): determines which instances are registered for that consul service. This field can contain:
  • all: all instances should be registered with consul
  • promoted: only promoted instances should be registered with consul
  • canary: only canary instances should be registered with consul

[mildred]

Reading other issues, what i'm suggesting is basically what is suggested in #2920 (comment):

One idea would be to have a CanaryServiceName config within the service declaration that would be used during the canary transition period instead of the normal service name.

However, this suggestion should be weighted in regard to the following issue: #4566 Promoting a canary causes its service check to immediately become critical where updating the consul catalog during canary promotion causes the newly promoted alloc to become unhealthy.

[stale]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem 👍

[github-actions]

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.