Subru Krishnan commented on YARN-3736:

Thanks [~adhoot] for the patch and [~asuresh] for reviewing/committing the 

[~bikassaha], we did have this discussion. The number of new reservations will 
be bounded by the number of applications as having a reservation per 
application is the worst case scenario. Practically you will have a reservation 
per job pipeline as a production pipeline is rarely composed of one job. 
Similarly Hive/Pig/Tez DAGs which are composed of multiple YARN apps can also 
be represented as a single reservation. Moreover not all new applications will 
use reservations, just those which need SLA and those generally tend to be 
bigger but fewer. Considering all this, our approach is aligned with the design 
of the state store. Makes sense?

> Add RMStateStore apis to store and load accepted reservations for failover
> --------------------------------------------------------------------------
>                 Key: YARN-3736
>                 URL: https://issues.apache.org/jira/browse/YARN-3736
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: capacityscheduler, fairscheduler, resourcemanager
>            Reporter: Subru Krishnan
>            Assignee: Anubhav Dhoot
>             Fix For: 2.8.0
>         Attachments: YARN-3736.001.patch, YARN-3736.001.patch, 
> YARN-3736.002.patch, YARN-3736.003.patch, YARN-3736.004.patch, 
> YARN-3736.005.patch
> We need to persist the current state of the plan, i.e. the accepted 
> ReservationAllocations & corresponding RLESpareseResourceAllocations  to the 
> RMStateStore so that we can recover them on RM failover. This involves making 
> all the reservation system data structures protobuf friendly.

This message was sent by Atlassian JIRA

Reply via email to