Additionally, this would apply to Stram as well i.e. the master should also
not be deployed on these nodes. Not sure if anti-affinity goes beyond
operators.

On Fri, Dec 2, 2016 at 12:47 PM, Milind Barve <mili...@gmail.com> wrote:

> My previous mail explains it, but just forgot to add : -1 to cover this
> under anti affinity.
>
> On Fri, Dec 2, 2016 at 12:46 PM, Milind Barve <mili...@gmail.com> wrote:
>
>> While it is possible to extend anti-affinity to take care of this, I feel
>> it will cause confusion from a user perspective. As a user, when I think
>> about anti-affinity, what comes to mind right away is a relative relation
>> between operators.
>>
>> On the other hand, the current ask is not that, but a relation at an
>> application level w.r.t. a node. (Further, we might even think of extending
>> this at an operator level - which would mean do not deploy an operator on a
>> particular node)
>>
>> We would be better off clearly articulating and allowing users to
>> configure it seperately as against using anti-affinity.
>>
>> On Fri, Dec 2, 2016 at 10:03 AM, Bhupesh Chawda <bhup...@datatorrent.com>
>> wrote:
>>
>>> Okay, I think that serves an alternate purpose of detecting any newly
>>> gone
>>> bad node and excluding it.
>>>
>>> +1 for covering the original scenario under anti-affinity.
>>>
>>> ~ Bhupesh
>>>
>>> On Fri, Dec 2, 2016 at 9:14 AM, Munagala Ramanath <r...@datatorrent.com>
>>> wrote:
>>>
>>> > It only takes effect after failures -- no way to exclude from the
>>> get-go.
>>> >
>>> > Ram
>>> >
>>> > On Dec 1, 2016 7:15 PM, "Bhupesh Chawda" <bhup...@datatorrent.com>
>>> wrote:
>>> >
>>> > > As suggested by Sandesh, the parameter
>>> > > MAX_CONSECUTIVE_CONTAINER_FAILURES_FOR_BLACKLIST seems to do exactly
>>> > what
>>> > > is needed.
>>> > > Why would this not work?
>>> > >
>>> > > ~ Bhupesh
>>> > >
>>> >
>>>
>>
>>
>>
>> --
>> ~Milind bee at gee mail dot com
>>
>
>
>
> --
> ~Milind bee at gee mail dot com
>



-- 
~Milind bee at gee mail dot com

Reply via email to