[
https://issues.apache.org/jira/browse/SLIDER-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14266194#comment-14266194
]
Steve Loughran commented on SLIDER-739:
---------------------------------------
Requirements
# In-cluster API for talking to the AM.
# Detailed queries of state of running application (enumerating components &
locations)
# Ability to query topology of YARN cluster/queue itself. e.g. labelled nodes
and capacity, rack topology.
# Ability to request component instances on specific nodes —and with specific
port bindings. Mandating the port bindings can ensure that client applications
can retain existing bindings.
# Ability to blacklist specific nodes and have this forwarded to YARN. (+
query, reset blacklist if in YARN APIs)
# Ability to query/manipulate registry and quicklinks. (This can be done
directly by the YARN registry anyway; it's not clear we need to add above and
beyond a REST binding for the registry).
# Ability to query status of outstanding requests —and to cancel them. Given
that they are cancelled simply by a flex down that can be done with what is
proposed today: YARN aggregates all requests at a specific priority level, and
there are no individual requests to cancel. If there was a notion of retaining
ports on a recreated container, then that would be some state (which wouldn't
matter if lost on AM restart, as all requests are lost then too)
> REST API to support application self-management
> -----------------------------------------------
>
> Key: SLIDER-739
> URL: https://issues.apache.org/jira/browse/SLIDER-739
> Project: Slider
> Issue Type: Sub-task
> Components: appmaster, Web & REST
> Affects Versions: Slider 0.70
> Reporter: Steve Loughran
> Assignee: Steve Loughran
>
> Add the use case "application manipulating its own deployment"
> This allows a YARN-aware app to talk to the AM to manipulate its deployment,
> *without writing its own AM*
> That implies exposing more state for both viewing and manipulating. That
> includes state that is not retained over AM restart.
> We may want to publish some event history purely for the apps too
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
