Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
Reviewed
Description
For legacy reasons, the current allocate protocol expects expanded requests which represent the cumulative request for any change in resource constraints. This is not only very difficult to comprehend but makes it impossible for the scheduler to associate container allocations to the original requests. This problem is amplified by the fact that the expansion is managed by the AMRMClient which makes it cumbersome for non-Java clients as they all have to replicate the non-trivial logic. In this JIRA, we are proposing enhancement to the Allocate Protocol to allow AMs to identify requests explicitly.
Attachments
Attachments
Issue Links
- blocks
-
YARN-5415 Add support for NodeLocal and RackLocal OPPORTUNISTIC requests
- Resolved
- is blocked by
-
YARN-5132 Exclude generated protobuf sources from YARN Javadoc build
- Resolved
- is depended upon by
-
YARN-314 Schedulers should allow resource requests of different sizes at the same priority and location
- Open
-
YARN-2915 Enable YARN RM scale out via federation using multiple RM's
- Resolved
-
REEF-1288 Add a request ID to resource requests / allocated Evaluators
- Open
-
YARN-4485 [Umbrella] Capture per-application and per-queue container allocation latency
- Open
- is related to
-
YARN-1042 add ability to specify affinity/anti-affinity in container requests
- Open
-
YARN-3870 Providing raw container request information for fine scheduling
- Open
-
YARN-110 AM releases too many containers due to the protocol
- Open
-
YARN-5907 [Umbrella] [YARN-1042] add ability to specify affinity/anti-affinity in container requests
- Open
-
YARN-4902 [Umbrella] Generalized and unified scheduling-strategies in YARN
- Resolved
- relates to
-
YARN-2877 Extend YARN to support distributed scheduling
- Resolved