Github user joelittlejohn commented on the pull request:
https://github.com/apache/curator/pull/116#issuecomment-154554250
It's a very good point @serranom.
There's nothing stopping someone from doing this via the API (I don't
think) since you can simply create a new ServiceInstance (based on the field
values of the instance you want to disable) but pass `false` as the enabled
value, then use
[ServiceDiscovery#updateService(ServiceInstance)](https://github.com/joelittlejohn/curator/blob/4776a2daacb3a776e9dd0bdc214ed4987fef96c9/curator-x-discovery/src/main/java/org/apache/curator/x/discovery/ServiceDiscovery.java#L48)
to apply the change. This is the kind of thing a dashboard/tool (that has no
knowledge of the znode layout) could do. So in this way, all ServiceInstance
fields are always updatable via the API.
I saw this as an administrative task that (as the least worst option)
allows an update to the znode to disable an instance. I thought of this as a
useful administrative hook but not necessarily an operation that needs to part
of the core API. If we did want _improved_ support for this in the API it would
be easy to add this e.g.
`ServiceDiscovery#enable(ServiceInstance)` and
`ServiceDiscovery#disable(ServiceInstance)`
or
`ServiceInstance#enable()` and `ServiceInstance#disable()`
(followed by `ServiceDiscovery#updateService(ServiceInstance)`)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
