hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sunil G (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (YARN-5932) Retrospect moveApplicationToQueue in align with YARN-5611
Date Thu, 01 Dec 2016 10:30:58 GMT

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

Sunil G updated YARN-5932:
    Attachment: YARN-5932.0001.patch

Thanks [~jianhe]

Yes. We are not checking this condition as of now in CS. Ideally we are moving resource from
one queue to another. hence post move, there could be some imbalances. Could such cases be
handled in next allocation / preemption cycle itself.

I had few thoughts here for some more potential validations (app priority etc), but it may
make move more stricter. Could that be a pblm to end user as its an old api to customer.

Addressed other comments and uploading a new patch.

> Retrospect moveApplicationToQueue in align with YARN-5611
> ---------------------------------------------------------
>                 Key: YARN-5932
>                 URL: https://issues.apache.org/jira/browse/YARN-5932
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: capacity scheduler, resourcemanager
>            Reporter: Sunil G
>            Assignee: Sunil G
>         Attachments: YARN-5932.0001.patch, YARN-5932.v0.patch, YARN-5932.v1.patch
> All dynamic api's of an application's state change could follow a general design approach.
Currently priority and app timeouts are following this approach all corner cases.
> *Steps*
> - Do a pre-validate check to ensure that changes are fine.
> - Update this information to state-store
> - Perform real move operation and update in-memory data structures.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org

View raw message