Add ability to update tags and to persist them upon restart

[XavM]

Something similar to "serf tags" and "-tags-file" to be able to update tags via rpc, consul and HTTP, and persist them upon consul restart would be useful

[armon]

Could you clarify a bit one this one? Serf tags are a bit more dynamic than Consul tags. Or are you using the HTTP API to register services/checks and want to persist those?

[hunter]

We'd like to see persistence of services/checks via the API. Something on the cards?

[XavM]

@armon : Imagine we have a same service running on multiple servers, but that we segregate different pool of users to a specific subset of those hosts for whatever reason (performance, multitenancy, etc ...)

We can use service tags to automate reverse proxy's upstream lists, but when we switch one server from one pool to an other, we have to deploy a new service.json file on each host and then SIGHUP consul

It would come in handy to allow this tag update thru HTTP and RPC, but we would then need to persist this change upon the next server restart/failure to make sure it gets back to the desired upstream pool and not to the one that it was first deployed with

EDIT: Of course it should work with node tags as well #154

[armon]

@XavM Got it. Makes sense to me.
@hunter Not yet, but it seems like something we need to address.

[chrisDeFouRire]

Here's another use case:
I'd love to update master/slave status for services (redis, mongodb) in Consul. I could have checks to update the tags when needed (when master/slave status is changed), so I could query the DNS for a readonly redis, or a redis master with a lookup for readonly.redis.service.consul or master.redis.service.consul

Note that readonly.redis.service.consul would then nicely load balance among redis slaves :)

[benagricola]

Yeah - to detect redis master / slave at the moment I have 2 different services with checks, redis-master and redis-slave and they're essentially running a ROLE command against redis and checking for master or slave.

It works well, but means that hosts which could be master or slave all have 2 services and 1 of them is always failing depending on its' role. Some way to update the tag on the service would be grand.

I was thinking maybe it would be possible to update the tags based on the output of the check command but I have no idea how that would work, and it interferes with the notes field handling at the moment.

[chrisDeFouRire]

Many tools (mongodb, redis sentinel, elasticsearch) have a notion of a master/slave, and I think a dedicated api would be appropriate... Tags are cool, but the semantics of master/slave are very specific and could add a lot to consul... That's probably why tags were not expected to change, while master/slave status IS expected to change over time

[balexx]

Another use cases would be to add a tag based on mysql slave lag - if lag is below 5s, add the "uptodate" tag. When a client needs up-to-date data, it can connect to uptodate.mysql.service.consul and read from a relatively fresh replica. "Yes, please!" on API to update service tags.

[xla]

While I don't believe master/slave semantics should be part of consuls interface the story around service definition persistence is interesting. Is there an update on it? Is agent state persistence planned? If not where would be a good place to start discussing the design (user-group thread, PR, etc.)?

[armon]

There is no ongoing discussion as of yet. Mostly still at the thought stage. There a few complicating factors with this. One is that clients are generally stateless currently, which this changes. The other is clients are considered "authoritative" for definition of services and states. In practice, this means anti-entropy is simple, the client state wins. Changing this to support a server-side update of a client state introduces lots of subtle complexity. Anyways, food for thought.

[armon]

API based changes are now persistent! Closing.

[XavM]

@armon: Thank you so much !!

[darron]

Yes thanks @armon !