aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Farner <wfar...@apache.org>
Subject Re: [proposal] Deprecate the Thermos CLI
Date Wed, 18 Feb 2015 22:07:20 GMT
Several times it's come up that Aurora should support alternative
executors, which i support.  Between that and additional frameworks running
alongside Aurora, i think we're back to square one for that use case.

-=Bill

On Wed, Feb 18, 2015 at 12:56 PM, Maxim Khutornenko <maxim@apache.org>
wrote:

> Running "thermos status --verbosity=3" gives full thermos task history
> including the sandbox path and process table contents. This really
> saves time when trying to get to the failed task details or see what
> else is running on a host.
>
> On Wed, Feb 18, 2015 at 12:04 PM, Bill Farner <wfarner@apache.org> wrote:
> > Can either of you elaborate on the type of debugging you currently
> > accomplish with this tool?
> >
> > On Wednesday, February 18, 2015, Brian Wickman <wickman@apache.org>
> wrote:
> >
> >> I agree it is a valuable component.  However, I think that until it has
> >> test coverage we should consider it an unsupported tool.  Filed
> AURORA-1131
> >> <https://issues.apache.org/jira/browse/AURORA-1131>.  This is already
> on
> >> my
> >> radar as part of AURORA-1027
> >> <https://issues.apache.org/jira/browse/AURORA-1027>.
> >>
> >> On Wed, Feb 18, 2015 at 9:19 AM, Maxim Khutornenko <maxim@apache.org
> >> <javascript:;>> wrote:
> >>
> >> > > Moving parts should either provide value or be obliterated from our
> >> > source tree.
> >> >
> >> > I generally agree. In this particular case it's still unclear to me -
> >> > in the absence of Thermos CLI and Observer, how do we conduct live
> >> > site executor/thermos troubleshooting?
> >> >
> >> > On Tue, Feb 17, 2015 at 7:45 PM, Bill Farner <wfarner@apache.org
> >> <javascript:;>> wrote:
> >> > >>
> >> > >>  I think we would be better served by advertising it as an
> >> > >> optional component that provides operators and users with debugging
> >> > >> ability.
> >> > >
> >> > >
> >> > > Slightly tangential discussion, but i think we should be very
> skeptical
> >> > of
> >> > > fringe components.  Moving parts should either provide value or be
> >> > > obliterated from our source tree.
> >> > >
> >> > > -=Bill
> >> > >
> >> > > On Tue, Feb 17, 2015 at 6:51 PM, Zameer Manji <zmanji@apache.org
> >> <javascript:;>> wrote:
> >> > >
> >> > >> One thing I would like to point out is the thermos CLI is not
> required
> >> > for
> >> > >> Aurora operation. I think we would be better served by advertising
> it
> >> > as an
> >> > >> optional component that provides operators and users with debugging
> >> > >> ability.
> >> > >>
> >> > >> On Tue, Feb 17, 2015 at 6:38 PM, Joseph Smith <yasumoto7@gmail.com
> >> <javascript:;>>
> >> > wrote:
> >> > >>
> >> > >> > I believe it absolutely is- ideally as we deprecate the
> Observer, we
> >> > can
> >> > >> > then lean on the Mesos Slave for this information instead.
This
> will
> >> > >> > further decrease the number of moving pieces, simplifying
the
> >> > operation
> >> > >> of
> >> > >> > an Aurora/Mesos cluster.
> >> > >> >
> >> > >> > > On Feb 17, 2015, at 6:33 PM, Zameer Manji <zmanji@apache.org
> >> <javascript:;>>
> >> > wrote:
> >> > >> > >
> >> > >> > > Joe,
> >> > >> > >
> >> > >> > > If I understand Brian's proposal correctly <
> >> > >> > >
> >> > >> >
> >> > >>
> >> >
> >>
> http://mail-archives.apache.org/mod_mbox/aurora-dev/201501.mbox/%3CCAFTdr0DZvH21tR=NLK0qP-Y9-oL9SyULy6GLah=CApuW0SVvnw@mail.gmail.com%3E
> >> > >> > >,
> >> > >> > > we are going to depreciate the Observer. This combined
with
> your
> >> > >> proposal
> >> > >> > > will make the executor the only component that can read
the
> >> thermos
> >> > >> > > checkpoints and produce some output that is human readable.
Is
> >> that
> >> > >> > > something we want to do?
> >> > >> > >
> >> > >> > > On Tue, Feb 17, 2015 at 6:26 PM, Joseph Smith <
> >> yasumoto7@gmail.com <javascript:;>>
> >> > >> > wrote:
> >> > >> > >
> >> > >> > >> Hi everyone,
> >> > >> > >>
> >> > >> > >> After reviewing the functionality offered by the
Thermos
> >> > Commandline
> >> > >> > tool
> >> > >> > >> vs. what’s exported via the Thermos Observer,
I was hoping to
> >> bring
> >> > >> up a
> >> > >> > >> question I had:
> >> > >> > >>
> >> > >> > >> Can we deprecate the Thermos CLI?
> >> > >> > >>
> >> > >> > >> Removing this would decrease the number of components
required
> >> for
> >> > a
> >> > >> > >> functional Aurora installation (a huge victory,
in my opinion)
> >> and
> >> > >> also
> >> > >> > >> enable the Observer to fully take over the duty
of providing
> >> > >> visibility
> >> > >> > >> into what’s running on a most. In addition, maintenance
is
> >> > performed
> >> > >> via
> >> > >> > >> the HostMaintenance API <
> >> > >> > >>
> >> > >> >
> >> > >>
> >> >
> >>
> https://github.com/apache/incubator-aurora/blob/master/src/main/python/apache/aurora/admin/host_maintenance.py#L26
> >> > >> > >
> >> > >> > >> and should not be done using thermos kill, which
would cause
> LOST
> >> > >> tasks.
> >> > >> > >>
> >> > >> > >> That said, removing this tool makes it much more
difficult for
> >> > Thermos
> >> > >> > to
> >> > >> > >> be used as a monit <http://mmonit.com/monit/>
replacement,
> which
> >> > is
> >> > >> > >> actually rather feasible now. In addition, it also
forces
> people
> >> to
> >> > >> > >> remember + learn the port the Observer is running
on in order
> to
> >> > get
> >> > >> > >> information about tasks.
> >> > >> > >>
> >> > >> > >> Any thoughts and opinions would be much appreciated!
> >> > >> > >>
> >> > >> > >> Thanks!
> >> > >> > >> Joe
> >> > >> > >>
> >> > >> > >> --
> >> > >> > >> Zameer Manji
> >> > >> > >>
> >> > >> > >>
> >> > >> >
> >> > >> > --
> >> > >> > Zameer Manji
> >> > >> >
> >> > >> >
> >> > >>
> >> >
> >>
> >
> >
> > --
> > -=Bill
>

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