[
https://issues.apache.org/jira/browse/YARN-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14011820#comment-14011820
]
Vinod Kumar Vavilapalli commented on YARN-1708:
-----------------------------------------------
Thanks for the patch [~subru]! I started looking at this. Few comments:
h4. Misc
- I think we should create a ReservationID or ReservationHandle and use it
instead of strings
- ReservationResponse.message -> errorMesage? Or Errors?
h4. ApplicationClientProtocol
- createReservation -> submitReservation?
- Let's have separate request/response records for submission, update and
deletion of reservations. Deletion of reservations, for e.g only needs to
supplied a reservationID. See submit/kill app for analogy. Similarly,
ReservationRequest.reservationID doesn't need to be part of the request for the
reservation-submission.
h4. ReservationDefinition
- Seems like there is a notion of absolute time. We should make it clear what
the arrival/deadline long's really represent. Particularly given the
possibility of different timezones between the RM and the client.
- It may be also very useful to let users specify time in relative terms -
6hrs from now, etc.
- It let's you specify a list of ResourceRequests. Not sure how we can specify
things like RR1 for the first 5 mins, RR2 for the next 15 etc.
h4. ReservationDefinitionType
- It seems like if we instead have a list of records of type (arrival,
ResourceRequest, deadline), we will cover all the cases in the definition-type
and then some more? Thoughts?
- Also any examples of where R_ANY is useful? Similarly as to how R_ORDER is
not enough and instead we have a need for R_ORDER_NO_GAP? Focusing mainly on
use-cases here.
h4. ResourceRequest
- concurrency is really a request for a gang of containers?
- Meaning of leaseDuration? Is it indicating the scheduler as to how long the
container will run for?
I have suggestions for configuration props renames follow. We follow a
component.sub-component.sub-component.property-name convention. (OT: I wish I
looked at preemption related config names :) ) IAC, I need to see the bigger
picture with the rest of the patches before I can suggest correct naming, let's
drop the YarnConfiguration changes from this patch.
Will look more carefully at the PB impls in the next cycle.
bq. The patch posted here is not submitted, since it depends on many other
patches part of the umbrella JIRA, the separation is designed only for ease of
reviewing.
I see this patch to be fairly independent and committable in isolation. Though
we should wait till we have the entire set to make sure the changes here are
all sufficient and necessary.
> Add a public API to reserve resources (part of YARN-1051)
> ---------------------------------------------------------
>
> Key: YARN-1708
> URL: https://issues.apache.org/jira/browse/YARN-1708
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: resourcemanager
> Reporter: Carlo Curino
> Assignee: Subramaniam Krishnan
> Attachments: YARN-1708.patch
>
>
> This JIRA tracks the definition of a new public API for YARN, which allows
> users to reserve resources (think of time-bounded queues). This is part of
> the admission control enhancement proposed in YARN-1051.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
