Thanks for the update Allen, appreciate your continued help reviewing this feature.
Looking at the calendar, we have three weeks from when we want to have GA RC0 out for vote. We're already dipping into code freeze time landing HDFS router-based federation and API-based scheduler configuration next week. If we want to get any more features in, it means slipping the GA date. So, my current thinking is that we should draw a line after these pending branches merge. Like before, I'm willing to bend on this if there are strong arguments, but the quality bar is even higher than it was for beta1, and we've still got plenty of other blockers/criticals to work on for GA. If you feel differently, please reach out, I can make myself very available next week for a call. Best, Andrew On Fri, Oct 6, 2017 at 3:12 PM, Allen Wittenauer <a...@effectivemachines.com> wrote: > > > On Oct 6, 2017, at 1:31 PM, Andrew Wang <andrew.w...@cloudera.com> > wrote: > > > > - Still waiting on Allen to review YARN native services feature. > > Fake news. > > I’m still -1 on it, at least prior to a patch that posted late > yesterday. I’ll probably have a chance to play with it early next week. > > > Key problems: > > * still haven’t been able to bring up dns daemon due to lacking > documentation > > * it really needs better naming and command structures. When put > into the larger YARN context, it’s very problematic: > > $ yarn —daemon start resourcemanager > > vs. > > $ yarn —daemon start apiserver > > if you awoke from a deep sleep from inside a cave, which > one would you expect to “start YARN”? Made worse that the feature is > called “YARN services” all over the place. > > $ yarn service foo > > … what does this even mean? > > It would be great if other outsiders really looked hard at this > branch to give the team feedback. Once it gets released, it’s gonna be > too late to change it…. > > As a sidenote: > > It’d be great if the folks working on YARN spent some time > consolidating daemons. With this branch, it now feels like we’re > approaching the double digit area of daemons to turn on all the features. > It’s well past ridiculous, especially considering we still haven’t replaced > the MRJHS’s feature set to the point we can turn it off. > >
