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