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
