[
https://issues.apache.org/jira/browse/MESOS-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14181132#comment-14181132
]
Adam B commented on MESOS-1860:
-------------------------------
Two points:
1) A constraint system would definitely be a valuable part of a generic
framework library/service, and I believe Netflix's soon-to-be-open-sourced
Fenzo will provide some of that.
2) I believe [~ChrisHeller]'s use case can be solved with resource reservations
and ACLs. Use the ACLs (master/admin-defined) to specify which framework
principals can register with which roles, and then set up resource reservations
on your special (master) nodes so that all resources are reserved for the
"marathon" role, and none for the default (*) role. This is also specified by
the admin starting the mesos-slave process on those special nodes. Since the
Spark framework will be unable to register with the "marathon" role, and the
mesos master will never offer marathon-reserved resources to a non-marathon
framework, only marathon tasks will run on the special nodes, and Spark will
instead get resource offers from the rest of the cluster. You could still use
attributes to ensure that marathon only launches its tasks (or just the special
applications' tasks) on the special (master) nodes.
> Give more control to the Mesos Administrator
> --------------------------------------------
>
> Key: MESOS-1860
> URL: https://issues.apache.org/jira/browse/MESOS-1860
> Project: Mesos
> Issue Type: Story
> Components: framework, master, slave
> Reporter: Chris Heller
> Labels: design, features
>
> Mesos currently relies on a framework to:
> - discard offers which don't match attributes that the framework finds
> desirable
> - specify which role a given resource request will belong to.
> This creates a scenario where to restrict a framework to a certain subset of
> slaves within a cluster one must unfortunately modify the framework.
> This story is meant to open a discussion on how Mesos could be modified so
> that:
> - an administrator could define attribute constraints which would apply to a
> given framework, without requiring framework support (i.e. an administrator
> could specify that the spark framework only accept offers with an attribute
> of 'appclass=spark' or any other predicate).
> - an administrator could classify framework requests into a given role, again
> without framework support (i.e. an administrator could specify that the spark
> framework requests for 'cpu(*)' become requests for 'cpu(spark)')
> Taking things a step further, how might it be possible that attribute
> constraints and request classifications could be setup for a single instance
> of a framework (i.e. a user fires up spark-shell with a given attribute
> constraint -- without needing to modify spark-shell to support attribute
> constraints)?
> This functionality could apply even deeper: an administrator should be able
> to specify the containerizer of a given framework, without the framework
> needing to explicitly allow for such a parameter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
