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
