aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Farner <wfar...@apache.org>
Subject Re: Should we maintain the thermos abstraction?
Date Wed, 24 Jun 2015 22:50:42 GMT
I may not be thinking hard enough about it - but wouldn't consuming it as a
third-party dependency add to the problems?

-=Bill

On Wed, Jun 24, 2015 at 3:44 PM, Maxim Khutornenko <maxim@apache.org> wrote:

> I generally agree on the cognitive overhead point as it's not easy to
> maintain mental picture of all dependencies especially for someone
> without much domain knowledge.
>
> That said, I recognize the value of Thermos that was conceived as a
> standalone system not necessarily constrained by the Aurora. Would it
> make sense to consider forking Thermos out as an independent project
> and consume it as an external versioned dependency? Is Thermos
> independence worth the increased development overhead?
>
> On Wed, Jun 24, 2015 at 3:35 PM, Kevin Sweeney <kevints@apache.org> wrote:
> > I think the abstraction has outlived its value, proven by the fact that
> > there are parts of thermos that are completely untested and broken (see
> gc
> > subcommand) that maintaining them isn't worth the overhead.
> >
> > I think my comment here sums up my feelings on this issue and points out
> > some of the shortcomings of maintaining the abstraction barriers as they
> > exist today
> >
> https://issues.apache.org/jira/browse/AURORA-1338?focusedCommentId=14561777&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14561777
> >
> > On Wed, Jun 24, 2015 at 3:13 PM, Bill Farner <wfarner@apache.org> wrote:
> >
> >> Since there's been a recent uptick in development on the executor,
> there's
> >> a long overdue discussion that i would like to raise.
> >>
> >> Does it make sense to continue maintaining the abstraction between
> >> 'thermos' and the 'default Aurora executor'?  I see this as cognitive
> >> overhead in the code, and it adds non-trivial complexity that is not
> used
> >> in practice in Aurora.
> >>
> >>
> >> -=Bill
> >>
>

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