[ 
https://issues.apache.org/jira/browse/SLIDER-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gour Saha updated SLIDER-868:
-----------------------------
    Description: 
You create a Slider application package, deploy it to a YARN cluster and manage 
it. From the management perspective it is primarily flexing. Based on needs 
(and the architecture of the application) you grow or shrink specific 
components of your long running application from time to time. Of course you 
can set some constraints like affinity, anti-affinity, and strict placement 
(for data locality or other reasons). Some of these are handled very well by 
Slider, others are best efforts.

However long running applications have an inherent need to be auto (or even 
self) managed. This can be achieved by a custom management tool, interacting 
with Slider client based on constant feedback on the health of the application 
(metrics, alerts, etc.). This is primarily reactive management. 

There is also proactive management, where the application owner is aware of the 
usage pattern of the application over time. For example, a financial 
application usage peaks between 8am to 4pm Mon to Sat (local time), and slows 
down at other times. A tax application usage peaks for a few months prior to 
April 15 and then slows down for several months. Certain healthcare 
applications peak during flu season. You get the point!

It should be possible to declaratively define such an application usage 
skyline, which can be fed to Slider and put an application on cruise control. 
The specification can be modified dynamically and Slider should honor the 
modified version for (reasonably acceptable) future state of the application.

This kind of feature would need support from YARN. There should be a way for 
Slider to provide details to YARN for guaranteed future capacity planning. 


  was:
You create a Slider application package, deploy it to a YARN cluster and manage 
it. From the management perspective it is primarily flexing. Based on needs 
(and the architecture of the application) you grow or shrink specific 
components of your long running application from time to time. Of course you 
can set some constraints like affinity, anti-affinity, and strict placement 
(for data locality or other reasons). Some of these are handled very well by 
Slider, others are best efforts.

However long running applications have an inherent need to be auto (or even 
self) managed. This can be achieved by a custom management tool, interacting 
with Slider client based on constant feedback on the health of the application 
(metrics, alerts, etc.). This is primarily reactive management. 

There is also proactive management, where the application owner is aware of the 
usage pattern of the application over time. For example, a financial 
application usage peaks between 8am to 4pm Mon to Sat (local time), and slows 
down at other times. A tax application usage peaks for a few months prior to 
April 15 and then slows down for several months. Certain healthcare 
applications peak during flu season. You get the point!

It should be possible to declaratively define such an application usage 
skyline, which can be fed to Slider and put an application on cruise control. 
The specification can be modified and Slider should honor the modified version 
for (reasonably acceptable) future state of the application.

This kind of feature would need support from YARN. There should be a way for 
Slider to provide details to YARN for guaranteed future capacity planning. 



> Ability to put a Slider application on cruise control
> -----------------------------------------------------
>
>                 Key: SLIDER-868
>                 URL: https://issues.apache.org/jira/browse/SLIDER-868
>             Project: Slider
>          Issue Type: New Feature
>          Components: agent, app-package, appmaster
>    Affects Versions: Slider 0.70
>            Reporter: Gour Saha
>
> You create a Slider application package, deploy it to a YARN cluster and 
> manage it. From the management perspective it is primarily flexing. Based on 
> needs (and the architecture of the application) you grow or shrink specific 
> components of your long running application from time to time. Of course you 
> can set some constraints like affinity, anti-affinity, and strict placement 
> (for data locality or other reasons). Some of these are handled very well by 
> Slider, others are best efforts.
> However long running applications have an inherent need to be auto (or even 
> self) managed. This can be achieved by a custom management tool, interacting 
> with Slider client based on constant feedback on the health of the 
> application (metrics, alerts, etc.). This is primarily reactive management. 
> There is also proactive management, where the application owner is aware of 
> the usage pattern of the application over time. For example, a financial 
> application usage peaks between 8am to 4pm Mon to Sat (local time), and slows 
> down at other times. A tax application usage peaks for a few months prior to 
> April 15 and then slows down for several months. Certain healthcare 
> applications peak during flu season. You get the point!
> It should be possible to declaratively define such an application usage 
> skyline, which can be fed to Slider and put an application on cruise control. 
> The specification can be modified dynamically and Slider should honor the 
> modified version for (reasonably acceptable) future state of the application.
> This kind of feature would need support from YARN. There should be a way for 
> Slider to provide details to YARN for guaranteed future capacity planning. 



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

Reply via email to