Where are we with SLIDER-82: Anti-Affinity? 1. The core algorithms are implemented: instances are asked for one at a time. 2. Tests against a mock RM appear to verify this. 3. There's a minicluster test which verifies that if you ask for >1 instance on a minicluster, you never get more than one. That is, the AA requirements mean that the rest stay outstanding. Not tested 1. Functional tests, especially with clusters size >1, hence whether it really works. 2. How well real clusters generate node update events, so how accurate the node map remains after the initial startup/restart nodemap fetched from a YarnClient query run in the AM. If it doesn't stay accurate, we'll just switch to more repeated full cluster enums. Note: we need to pick up on label changes as well as cluster changes; the two events which currently trigger a cancel & re-issue of outstanding AA events are: (i) node becomes healthy, (ii) label change. 3. resumption on AM restart in a real cluster. 4. reaction to container failure (it should be the same as flex: add one to the pending count if there's any outstanding, trigger a new request if none active) 5. What happens when we turn this on for HBase Not (yet) implemented 1. Using historical placement data before starting the AA ramp-up. I focused on that AA ramping first; history would just complicate things and hide problems. 2. Similarly, "strict" placement + AA for new nodes. 3. Web UI/|REST view to provide details of what's happening. I'm working on #3 first, after which I'll write some basic functional tests designed to scale up to the #of nodes in the test cluster. Once I've done that —assume by wednesday— I'm going to consider the first initial release of the AA code ready for people to test, and will merge it into the develop branch. And on wednesday I'm going to give a quick talk & demo on this in our proposed slider online meetup Wednesday, 19:00 GMT == 11:00 PST webex room: https://hortonworks.webex.com/meet/stevel
