[
https://issues.apache.org/jira/browse/MESOS-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14908523#comment-14908523
]
Greg Mann commented on MESOS-3401:
----------------------------------
[~qianzhang], it should be possible to accomplish this using Resource/Attribute
arguments as-is, but adding labels may improve the comprehensibility of these
structures in cases where there is a lot of fine-grained differentiation
between resource-types. i.e. if I have a fairly heterogenous cluster with CPUs
of many different speeds, is it desireable to have many different cpu resource
names? "cpus2000", "cpus2100", "cpus3000", etc... would require framework
authors to parse these resource names in order to distinguish them and
recognize them as all members of a particular "class" of resource. Allowing the
resource to just be "cpus" improves the user experience from the perspective of
the framework author, I think. It also allows the use of the default "cpus"
resource name, which may have other benefits? Thoughts?
> Add labels to Resources
> -----------------------
>
> Key: MESOS-3401
> URL: https://issues.apache.org/jira/browse/MESOS-3401
> Project: Mesos
> Issue Type: Improvement
> Components: slave
> Reporter: Adam B
> Assignee: Greg Mann
> Labels: mesosphere, resources
>
> Similar to how we have added labels to tasks/executors (MESOS-2120), and even
> FrameworkInfo (MESOS-2841), we should extend Resource to allow arbitrary
> key/value pairs.
> This could be used to specify that a cpu resource has a certain speed, that a
> disk resource is SSD, or express any other metadata about a built-in or
> custom resource type. Only the scalar quantity will be used for determining
> fair share in the Mesos allocator. The rest will be passed onto frameworks as
> info they can use for scheduling decisions.
> This would require changes to how the slave specifies its `--resources`
> (probably as json), how the slave/master reports resources in its web/json
> API, and how resources are offered to frameworks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
