Re: Temporarily remove a host from service discovery

[Joe Littlejohn <jo...@gmail.com>]

I've added a new PR here: https://github.com/apache/curator/pull/116

Hope this fits the standards and conventions of the project. Feedback
welcome of course.

Cheers

On 29 October 2015 at 20:49, Joe Littlejohn <jo...@gmail.com> wrote:

> Oh yes, sorry, I didn't mean to imply that someone else should implement
> this. I'm more than happy to submit a PR for this.
>
> I just wanted to run this by the core team first really, to see if anyone
> had strong opinions about either the feature or the best method of
> implementing it.
>
> So my plan for this would be:
>
> - Include an 'enabled' boolean value to ServiceInstance
> - Add an EnabledInstanceFilter to localFilters in the ServiceProviderImpl
> constructor, this filter will remove disabled instances
>
> For now, removing an instance would be a manual update via e.g. Exhibitor.
> I can imagine creating some tooling to do this though.
>
>
> On 29 October 2015 at 02:31, Jordan Zimmerman <jo...@jordanzimmerman.com>
> wrote:
>
>> We’re always open to PRs - in fact they are encouraged! No guarantees,
>> but this is a community project. So, please help.
>>
>> -Jordan
>>
>> > On Oct 28, 2015, at 6:44 PM, Joe Littlejohn <jo...@gmail.com>
>> wrote:
>> >
>> > Thanks for commenting!
>> >
>> > It would be good to be able to implement this without having to
>> maintain a parallel structure of nodes. I was thinking a flag included as
>> part of the instance node data ("enabled":false) however this would require
>> a Curator change since this flag would not be accessible via the
>> ServiceInstance object (unless it was included in the payload).
>> >
>> > The ability to deactivate a node when using the service discovery
>> recipe seems like a very useful and core feature. I'm wondering - would the
>> maintainers be amenable to adding such a feature? It would be quite easy to
>> implement some tooling outside of Curator to set/reset this flag, but at
>> least having the core Curator library support the flag itself as part of
>> the node data would mean that this wouldn't require many client-side
>> customisations.
>> >
>> > I see this as very similar to the DownInstanceManager but offering
>> explicit, central control.
>> >
>>
>>
>