[
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)
