aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Wickman <wick...@apache.org>
Subject Re: Should we maintain the thermos abstraction?
Date Wed, 24 Jun 2015 23:16:15 GMT
I definitely think that we should remove the legacy features that have been
supplanted by Mesos, e.g. resource monitoring and disk quota enforcement
(though the disk quota enforcement is actually an Aurora executor feature
and not provided by Thermos, but I think this illustrates Bill's point.)

On the other hand, some arguably unnecessary features like out-of-process
monitoring would take quite a bit of new development to replace.  For
example, the checkpoint stream that Kevin cites is central to how Thermos
operates and replacing it would be a nontrivial task -- a task that would
serve less the purpose of breaking abstraction barriers and more to address
dislike for a particular implementation detail.  I'm not saying we
shouldn't do it -- in the end the diff would definitely be red -- but it
would be tantamount to a rewrite of the Thermos core and I'm not sure it's
the right thing to prioritize given all the other problems we'd like to
solve.

~brian

On Wed, Jun 24, 2015 at 4:00 PM, Bill Farner <wfarner@apache.org> wrote:

> Gotcha.  From my perspective, the overhead is much greater than avoiding
> commits that span the two folders.  We'll own the complexity no matter
> where it lives.  My point is that there's code and complexity in thermos
> that we could discard if we don't treat thermos like an independent entity
> with the features it has today.
>
> -=Bill
>
> On Wed, Jun 24, 2015 at 3:53 PM, Brian Wickman <wickman@apache.org> wrote:
>
> > I think the observation is that if it were consumed as a third party
> > dependency, the separation of concerns would be more crystal clear than
> > with the code living in a quasi-monorepo.  Right now it's neither
> > documented nor clear that it can operate in isolation from Aurora.
> >
> > On Wed, Jun 24, 2015 at 3:50 PM, Bill Farner <wfarner@apache.org> wrote:
> >
> > > 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