aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santhosh Kumar Shanmugham <sshanmug...@twitter.com.INVALID>
Subject Re: Redesign of the Aurora UI
Date Thu, 20 Jul 2017 03:34:23 GMT
This sounds great and seems like the right step forward to gain engagement
for Aurora from both operator as well as their user's perspective. I am
really excited to see how people start customizing the UI to their
particular situation.

On Wed, Jul 19, 2017 at 2:10 PM, David McLaughlin <dmclaughlin@apache.org>
wrote:

> Thanks for the feedback!
>
> Joshua - I haven't tried to drop in Preact yet, but I was also planning to
> throw away the prototype and starting again when it came to upstreaming it,
> so as part of that we can just address incompatibilities as we go. If I was
> to guess, then the only significant impact on my prototype would probably
> be the reactable plugin I was using (replacement for Angular's
> smart-table). But longer term I do have concerns about moving away from
> what is a constantly improving and healthy ecosystem around React. So most
> likely I'll hold off until a decision is made there one way or the other
> (which should be within a week).
>
>
> Kai - I'd be happy to coordinate and collaborate on this with others. Let
> me try and finish up the CSS/UX of the pages in my prototype and from there
> we can sync on who does what. Does that sound good?
>
>
>
>
> On Wed, Jul 19, 2017 at 1:56 PM, Kai Huang <texasred2013@hotmail.com>
> wrote:
>
> > Just a few thoughts as an aurora developer and operator:
> >
> >
> > From my experiences with Aurora users, some persisting complaints are:
> >
> >   1.  The current UI is not very intuitive for the users to understand
> the
> > task lifecycle, resource utilization of their job.
> >   2.  Often times users are unaware of the new features/changes in Aurora
> > Scheduler/Executor, which leads to a lot of misuse of the system.
> >   3.  Users have preferences on the appearance of the scheduler/thermos
> UI
> > due to special use cases, and ask us to customize for them(or start to
> > write their own UI, which is often not recommended).
> >
> >
> > The other major issue I see in the current UI is that it's built on an
> > obsolete tech stack(AngularJS) that has all the binaries and dependencies
> > in the repo. From a developer's perspective, it's a big burden to
> > maintain/test the code, and make fast iterations on it.
> >
> >
> > Currently the scheduler UI is readonly, and mainly designed for debugging
> > purposes. We could have done much better to make the UI more friendly to
> > the end user, empower them to discover, understand and use all the Aurora
> > features, and give them more insights into the their jobs, or even the
> > entire cluster. I love the idea that redesign the UI with a modern stack,
> > and more importantly, every single part of the application is a module
> that
> > you could take your own customization.
> >
> >
> > As for the development strategy, I'm in favor of the incremental approach
> > that posts one page at a time. The main benefit is that we are educating
> > the developers while iterating on it, and this will improve the adoption
> > rate in the long term.
> >
> >
> > Overall I'm very interested in this work, and would like to collaborate
> > with David to redesign and improve the UI.
> >
> >
> > ________________________________
> > From: Joshua Cohen <jcohen@apache.org>
> > Sent: Wednesday, July 19, 2017 11:39
> > To: dev@aurora.apache.org
> > Subject: Re: Redesign of the Aurora UI
> >
> > I think this looks great overall! I'm super excited to see the UI get
> some
> > love (and to set us up for better iteration on the UI going forward). My
> > biggest concern, of course, is the current hubbub vis-a-vis Apache and
> the
> > BSD-3+Patents license[1]. Have you tried running this against Preact to
> > confirm compatibility/performance? Also note that other Facebook
> libraries
> > have the same license problem (e.g. Immutable, Jest), so unless FB
> changes
> > their patent grant clause, I imagine we'd have to find alternatives to
> > those as well. If only we had landed this a week ago, we could've been
> > grandfathered in on the license front :(.
> >
> > As far as the options for landing this, I'll leave that up to more active
> > reviewers, but my gut says that smaller reviews will make this easier to
> > parse, especially for those unfamiliar with React. That said, perhaps we
> > could go with an alternate method for reviewing here, where people review
> > against your fork directly and only when they're comfortable do you post
> > the whole patch to reviewboard for what should, by that point, be a
> rubber
> > stamp review?
> >
> > In general, fantastic work, David!
> >
> > [1] https://issues.apache.org/jira/browse/LEGAL-319
> >
> > On Wed, Jul 19, 2017 at 12:55 AM, David McLaughlin <
> dmclaughlin@apache.org
> > >
> > wrote:
> >
> > > Hey all,
> > >
> > > At Twitter we have had a long-standing desire to be able to put custom
> > > widgets and other UX enhancements into the Aurora UI. Recent prototype
> > work
> > > to do this in a clean way has proved fruitful and I'd like to present
> > this
> > > approach to the community and get feedback on the overall approach.
> > >
> > > The basic approach is simple:
> > >
> > > 1) Use the node plugin for gradle to bootstrap a modern web development
> > > build system using webpack and npm.
> > > 2) Use a modern JS view library like ReactJS (or Preact depending on
> the
> > > Facebook+Patents license issues for Apache projects) to have all UI
> > > components defined as ES6 modules.
> > > 3) Use webpack to set up a custom plugin directory that modules should
> be
> > > loaded from first. This would allow anyone with custom Scheduler builds
> > to
> > > also drop in custom JS files to replace selected OSS UI components.
> > > Example, you could drop a "Navigation.js" into the plugin directory,
> and
> > > the build system will use that module instead whenever it sees a
> > > <Navigation /> used by parent components. Basically: it's a hybrid
> > > plugin/dependency injection (similar to Guice) approach to
> customization
> > of
> > > the UI.
> > >
> > > The nice thing here is that since every single part of the application
> > is a
> > > module you could take your customizations to any level of precision
> that
> > > you need. You could replace (or add) key pages or components, or just
> > keep
> > > it as simple as adding some helper text to one of the pages.
> > >
> > > Some use cases this could enable:
> > >
> > > * A <ConfigurationViewer /> widget that you can replace with
> > configuration
> > > parsing that understands special processes and/or custom executors.
> > > * Integration with your telemetry stacks to add resource utilization
> > > feedback or other performance indicators into the job page.
> > > * Adding custom stats tracking widgets for internal analytics.
> > >
> > >
> > > Some points from my prototype work:
> > >
> > > 1) Switching to npm for JS asset management allows us to delete the
> vast
> > > majority of our 3rdparty assets that we had to copy into the repo. We
> can
> > > most likely extend this to remove all of them, including our CSS
> > frameworks
> > > like Bootstrap.
> > > 2) ReactJS was proposed before (by Joshua Cohen) and ironically I was
> one
> > > of the main voices against. The argument I used at the time was lack of
> > > familiarity with the stack within the community, as well as concerns
> > about
> > > the complexity. So what changed? Almost the entire Aurora team at
> Twitter
> > > has ReactJS experience now - from working on our internal Continuous
> > > Delivery system. I also believe that as a view layer, ReactJS is
> > > conceptually very simple and that most of the complexity in these
> modern
> > JS
> > > applications is in a state layer like Redux. The Aurora UI is currently
> > > read-only and relatively simple, and we can avoid much of the
> complexity
> > by
> > > just using component state instead.
> > > 3) Unit tests are trivial to add as part of this work.
> > > 4) I'd like to move to modern, maintainable CSS tooling - SASS - as
> part
> > of
> > > this.
> > >
> > >
> > > My prototype is (hastily) published here:
> > >
> > > https://github.com/DavidMcLaughlin/aurora/tree/js-build
> > [https://avatars0.githubusercontent.com/u/56563?v=4&s=400]<
> > https://github.com/DavidMcLaughlin/aurora/tree/js-build>
> >
> > DavidMcLaughlin/aurora<https://github.com/DavidMcLaughlin/
> > aurora/tree/js-build>
> > github.com
> > aurora - Mirror of Apache Aurora
> >
> >
> >
> > >
> > >
> > > Some highlighted changes:
> > >
> > > 1) Bootstrapping the modern UI toolchain from gradle:
> > > https://github.com/DavidMcLaughlin/aurora/blob/
> > js-build/build.gradle#L452-
> > [https://avatars0.githubusercontent.com/u/56563?v=4&s=400]<
> > https://github.com/DavidMcLaughlin/aurora/blob/
> js-build/build.gradle#L452-
> > >
> >
> > DavidMcLaughlin/aurora<https://github.com/DavidMcLaughlin/
> > aurora/blob/js-build/build.gradle#L452->
> > github.com
> > aurora - Mirror of Apache Aurora
> >
> >
> >
> > > L459
> > >
> > > 2) The webpack configuration to enable loading from a plugin directory
> > (and
> > > SASS):
> > > https://github.com/DavidMcLaughlin/aurora/blob/
> > js-build/webpack.config.js
> > [https://avatars0.githubusercontent.com/u/56563?v=4&s=400]<
> > https://github.com/DavidMcLaughlin/aurora/blob/
> js-build/webpack.config.js>
> >
> > DavidMcLaughlin/aurora<https://github.com/DavidMcLaughlin/
> > aurora/blob/js-build/webpack.config.js>
> > github.com
> > aurora - Mirror of Apache Aurora
> >
> >
> >
> > >
> > > 3) The Hello, World of the plugin mechanism:
> > >
> > > https://github.com/DavidMcLaughlin/aurora/blob/js-build/src/main/js/
> > [https://avatars0.githubusercontent.com/u/56563?v=4&s=400]<
> > https://github.com/DavidMcLaughlin/aurora/blob/js-build/src/main/js/>
> >
> > DavidMcLaughlin/aurora<https://github.com/DavidMcLaughlin/
> > aurora/blob/js-build/src/main/js/>
> > github.com
> > aurora - Mirror of Apache Aurora
> >
> >
> >
> > > components/Hello.js
> > >
> > > Is replaced by:
> > >
> > > https://github.com/DavidMcLaughlin/aurora/blob/
> > > js-build/plugin/js/components/Hello.js
> > >
> > > 4) Unit test example:
> > > https://github.com/DavidMcLaughlin/aurora/blob/js-build/src/main/js/
> > [https://avatars0.githubusercontent.com/u/56563?v=4&s=400]<
> > https://github.com/DavidMcLaughlin/aurora/blob/js-build/src/main/js/>
> >
> > DavidMcLaughlin/aurora<https://github.com/DavidMcLaughlin/
> > aurora/blob/js-build/src/main/js/>
> > github.com
> > aurora - Mirror of Apache Aurora
> >
> >
> >
> > > components/pages/__tests__/HomePage-test.js
> > >
> > >
> > > My goal now is to take the prototype to completion and upstream to
> Aurora
> > > OSS. If the community is in favor, we should also discuss how to handle
> > the
> > > rollout.
> > >
> > > I would propose two options:
> > >
> > > * a massive code-dump with the entire UI rewritten in ReactJS.
> > > * an incremental approach where I (for example) post one page at a
> time,
> > > allowing those unfamiliar with JS to see the step by step process that
> > can
> > > demystify the tooling. The new UI would not be enabled incrementally
> due
> > to
> > > the issues with "greedy" one-page frameworks.. instead we'd just enable
> > it
> > > at the very end. The major downside here is just maintaining all the
> > weight
> > > of two UI frameworks, etc. in that period of development.
> > >
> > > Please let me know any questions, concerns or feedback.
> > >
> > >
> > > Cheers,
> > > David
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message