Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for consul EnableTagOverride #2057

Closed
brunomacf opened this issue Dec 4, 2016 · 4 comments · Fixed by #7106
Closed

Add support for consul EnableTagOverride #2057

brunomacf opened this issue Dec 4, 2016 · 4 comments · Fixed by #7106

Comments

@brunomacf
Copy link

It would be great to have this consul option in service stanza to enable dynamic tagging. My use case is with mongo replica set.... i have 3 instances, one with "primary" tag and the other with "secondary" tag, but when the primary goes away a new primary is elected and i would like to see this election reflected on (updated) service tags.

@brunomacf brunomacf changed the title Add support for Consul EnableTagOverride Add support for consul EnableTagOverride Dec 4, 2016
@dadgar dadgar added this to the v0.6.0 milestone Dec 5, 2016
@schmichael schmichael removed this from the v0.6.0 milestone Jul 31, 2017
@nickwales
Copy link
Contributor

This would be a very nice to have. We rely on this on our platform currently and Nomad would need to support this before we could migrate.

@nickwales
Copy link
Contributor

nickwales commented Mar 21, 2018

Realized I can update consul tags via running the job again with the required updates to the service section. Our requirement is slightly different from @brunomacf in that we want to tag a version or versions of an app to receive traffic, which means an entire task group can be re-tagged rather than a single instance of a task group.

  • Initial testing suggests the entire service gets re-registered so health checks go critical temporarily which is probably not ideal.
  • I haven't seen instances get restarted but are there any instances where that could happen?

To confirm, my testing so far has been changing the contents of the tags array in the service section and re-running the job: https://www.nomadproject.io/docs/job-specification/service.html#tags

bogdanalbei added a commit to bogdanalbei/nomad that referenced this issue May 31, 2019
bogdanalbei added a commit to bogdanalbei/nomad that referenced this issue Jun 3, 2019
bogdanalbei added a commit to bogdanalbei/nomad that referenced this issue Jun 4, 2019
bogdanalbei added a commit to bogdanalbei/nomad that referenced this issue Jun 4, 2019
@dcarbone
Copy link

This functionality would be awesome to have. Should be an entirely non-breaking change. Simply pass up the EnableTagOverride opt as true, or allow it to be settable in the service block.

@shoenig shoenig self-assigned this Feb 6, 2020
shoenig added a commit that referenced this issue Feb 10, 2020
Consul provides a feature of Service Definitions where the tags
associated with a service can be modified through the Catalog API,
overriding the value(s) configured in the agent's service configuration.

To enable this feature, the flag enable_tag_override must be configured
in the service definition.

Previously, Nomad did not allow configuring this flag, and thus the default
value of false was used. Now, it is configurable.

Because Nomad itself acts as a state machine around the the service definitions
of the tasks it manages, it's worth describing what happens when this feature
is enabled and why.

Consider the basic case where there is no Nomad, and your service is provided
to consul as a boring JSON file. The ultimate source of truth for the definition
of that service is the file, and is stored in the agent. Later, Consul performs
"anti-entropy" which synchronizes the Catalog (stored only the leaders). Then
with enable_tag_override=true, the tags field is available for "external"
modification through the Catalog API (rather than directly configuring the
service definition file, or using the Agent API). The important observation
is that if the service definition ever changes (i.e. the file is changed &
config reloaded OR the Agent API is used to modify the service), those
"external" tag values are thrown away, and the new service definition is
once again the source of truth.

In the Nomad case, Nomad itself is the source of truth over the Agent in
the same way the JSON file was the source of truth in the example above.
That means any time Nomad sets a new service definition, any externally
configured tags are going to be replaced. When does this happen? Only on
major lifecycle events, for example when a task is modified because of an
updated job spec from the 'nomad job run <existing>' command. Otherwise,
Nomad's periodic re-sync's with Consul will now no longer try to restore
the externally modified tag values (as long as enable_tag_override=true).

Fixes #2057
@shoenig shoenig reopened this Feb 13, 2020
@shoenig shoenig added this to the 0.11.0 milestone Feb 13, 2020
@shoenig shoenig closed this as completed Feb 13, 2020
@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 13, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants