aurora-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Mahler (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AURORA-715) Retire GC Executor
Date Wed, 17 Sep 2014 22:33:34 GMT

    [ https://issues.apache.org/jira/browse/AURORA-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14138129#comment-14138129
] 

Benjamin Mahler commented on AURORA-715:
----------------------------------------

{quote}
Isn't a selling point of mesos that we don't have to do out-of-band communication like this?
{quote}
You're right, we want to avoid out-of-band communication and having an out-of-band observer
shouldn't be something that's necessary. It's just a way to retire the GC Executor in the
interim of a better story.

Avoiding the need for the out-of-band observer UI means ensuring that we provide all the information
you need in your UI through the slave's http endpoints:
* {{/state.json}}: We'll need to improve the history, the GC process on the slave should drive
removal of historical state.
* {{/files/(browse.json|read.json)}}: We'll need to ensure that we keep sandboxes accessible
until GCed.

With these, the JSONP requests are done against the slave. And the observer / sandbox browser
could live within Aurora's UI (leveraging /state.json + /files to read any thermos checkpoint
data as necessary).

{quote}
What's the downside of best-effort delivery of this information by mesos?
{quote}
The downside of introducing a sandbox deletion event in the system is that it doesn't eliminate
the need for an out-of-band UI. It solves only the "sandbox deletion" problem, and only in
a best-effort way. It's also more complexity within Mesos vs. leveraging the http endpoints
of the slave.

{quote}
There's also a likely future where we support running without an executor, which brings us
back to square one.
{quote}
What's the story around running without an executor, as far as the observer is concerned?
Wouldn't you need a way to show the sandbox of the command-based task, orthogonally to whether
you're using the GC Executor vs. Observer to detect sandbox deletion?

> Retire GC Executor
> ------------------
>
>                 Key: AURORA-715
>                 URL: https://issues.apache.org/jira/browse/AURORA-715
>             Project: Aurora
>          Issue Type: Epic
>            Reporter: Chris Lambert
>
> Mesos plans to provide a task reconciliation API and sandbox history so that we can retire
the GC Executor.  This Epic captures the work necessary to complete this process.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message