aurora-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Mahler (JIRA)" <>
Subject [jira] [Commented] (AURORA-715) Retire GC Executor
Date Wed, 24 Sep 2014 22:35:35 GMT


Benjamin Mahler commented on AURORA-715:

We could communicate that information through Offers. Sorry to leave you hanging here, [~vinodkone],
[~wickman] and I got together to chat about the broader desire to eliminate the out-of-band
per-machine Observer UI since it's related to this. No perfect solutions:

# Run UI in sandbox. Issue: no UI after executor terminates.
# Run UI in sandbox but leave executor/UI running after task terminates. Issue: consumes a
lot of resources.
# Include pure HTML/javascript UI assets in sandbox, the slave serves up the assets and the
UI runs in the end user's browser. Issue: Python based UI not supported, hard to implement
everything needed in javascript (recordIO deserialization, etc).
# Run centralized UI alongside Aurora (separate since Aurora knows nothing about Thermos).
This UI is responsible for obtaining all needed information from the slave's endpoints (sandbox
contents for the most part).

Still thinking over some ideas to deal with the more immediate sandbox deletion problem, will
update this ticket with more details.

> Retire GC Executor
> ------------------
>                 Key: AURORA-715
>                 URL:
>             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

View raw message