[
https://issues.apache.org/jira/browse/YARN-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15410209#comment-15410209
]
Konstantinos Karanasos commented on YARN-4902:
----------------------------------------------
Thanks for checking the design doc and the patch, and for the feedback,
[~leftnoteasy].
Please find below some thoughts regarding the points your raised and some
additional information.
bq. From the requirement's perspective, I didn't see new things, please remind
me if I missed anything
Agreed that our basic requirements are similar, which is good because it means
we are aligned. Some of the notions we are using might coincide with yours but
have a different name (e.g., dynamic vs. allocation tags, although the scope of
our dynamic tags is global and not application specific like yours), by virtue
of the fact that we were designing things at the same time. We can agree on a
common naming, not a problem.
What I would like to stretch as being different is mainly the LRA planning,
some extensions to the constraints (along with a more succinct way of
expressing them), as well as the ease of expressing inter-application
constraints -- more details below.
*Constraints*
bq. The cardinality constraints is placement_set with maximum_concurrency
constraint: see (4.3.3) Placement Strategy in my design doc.
If I am not wrong, the maxiumum_concurrency in your document corresponds to a
single allocation/resource-request. Our min and max cardinality is across
applications. For instance, in order to say "don't put more than 5 hbase
servers (from any possible application) in a rack".
In general, as we showed in our design doc, you can use max and min
cardinalities to also express affinity and anti-affinity constraints. This way
we can have only a single type of constraints. What do you think?
bq. Will this patch support anti-affinity / affinity between apps? I uploaded
my latest POC patch to YARN-1042, it supports affinity/anti-affinity for
inter/intra apps. We can easily extend it to support intra/inter resource
request within the app.
Yes, this is a major use case for us. The current patch can already support it.
And this is why we want to make more use of the tags and of planning, since
they would allow us to specify inter-app constraints without needing to know
the app ID of the other job.
bq. Major logic of this patch depends on node label manager dynamic tag
changes. First of all, I'm not sure if NLM works efficiently when node label
changes rapidly (we could update label on node when allocate / release every
container). And I'm not sure how you plan to avoid malicious application add
labels. For example if a distributed shell application claims it is a "hbase
master" just for fun, how to enforce cardinality logics like "only put 10 HBase
masters in the rack"?
Good points.
For the scalability we have not seen any problems so far (we update tags at
allocate/release), but we have not run very large-scale experiments -- I will
update you on that.
For the malicious AM, I am not sure if the application would benefit from
lying. But even if it does, we can use cluster-wide constraints to limit such
AMs. Still, I agree more thought has to be given on this matter -- it's good
you brought it up.
*Scheduling*
bq. It might be better to implement complex scheduling logics like
affinity-between-apps and cardinality in a global scheduling way. (YARN-5139)
We will be more than happy to use any advancement in the scheduler that is
available!
I totally believe that global scheduling (i.e., have an application-centric
rather than node-centric scheduling) is much more appropriate and will give
better results. We did not use it in our first patch, as it was not available,
but we are happy to try it out.
*Planning*
bq. I'm not sure how LRA planner will look like, should it be a separate
scheduler running in parallel? I didn't see your patch uses that approach.
The idea here is to be able to do more holistic placement decisions across
applications. What if you place your HBase service in a way that does not let a
subsequent Heron app be placed in the cluster at all?
We envision it to be outside of the scheduler, similar to the reservation
system (YARN-1051).
Applications will also be able to submit multiple applications at once, and
specify constraints among them.
It is not in the initial version of the patch.
*Suggestions*
bq. Could you take a look at global scheduling patch which I attached to
YARN-5139 to see if it is possible to build new features added in your patch on
top of the global scheduling framework? And also please share your thoughts
about what's your overall feedbacks to the global scheduling framework like
efficiency, extensibility, etc.
I will check the global scheduler, and as I said above, I'd be happy to use it.
bq. It will be better to design Java API for this ticket, both of our poc
patches (this one and the one I attached to YARN-1042) don't have a solid API
definition. It is very important to define API first, could you help with API
definition works?
Agreed, we should do that.
> [Umbrella] Generalized and unified scheduling-strategies in YARN
> ----------------------------------------------------------------
>
> Key: YARN-4902
> URL: https://issues.apache.org/jira/browse/YARN-4902
> Project: Hadoop YARN
> Issue Type: New Feature
> Reporter: Vinod Kumar Vavilapalli
> Assignee: Wangda Tan
> Attachments: Generalized and unified scheduling-strategies in YARN
> -v0.pdf, LRA-scheduling-design.v0.pdf, YARN-5468.prototype.patch
>
>
> Apache Hadoop YARN's ResourceRequest mechanism is the core part of the YARN's
> scheduling API for applications to use. The ResourceRequest mechanism is a
> powerful API for applications (specifically ApplicationMasters) to indicate
> to YARN what size of containers are needed, and where in the cluster etc.
> However a host of new feature requirements are making the API increasingly
> more and more complex and difficult to understand by users and making it very
> complicated to implement within the code-base.
> This JIRA aims to generalize and unify all such scheduling-strategies in YARN.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
