[ 
https://issues.apache.org/jira/browse/MESOS-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14993409#comment-14993409
 ] 

Alexander Rukletsov commented on MESOS-3826:
--------------------------------------------

I will also try to read between the lines : ). Even if there is a single 
instance of a single framework in the role, that framework may want to 
distinguish between reservation it creates according to requests of its 
clients. For example, Marathon can create two reservations for {{app1}} and 
three for {{app3}} and would like to distinguish between them when it gets 
offers from the master. Without ids, Marathon has to do rather complex 
bookkeeping in order to match offered reserved resources to its clients.

Instead of introducing ids, how about adding optional labels for reservations? 
In this case, no mesos code should be changed (except protobufs), while 
meta-frameworks get the ability to track their reservations if the want to.

> Add an optional unique identifier for resource reservations
> -----------------------------------------------------------
>
>                 Key: MESOS-3826
>                 URL: https://issues.apache.org/jira/browse/MESOS-3826
>             Project: Mesos
>          Issue Type: Improvement
>          Components: general
>            Reporter: Sargun Dhillon
>            Assignee: Guangya Liu
>            Priority: Minor
>              Labels: mesosphere
>
> Thanks to the resource reservation primitives, frameworks can reserve 
> resources. These reservations are per role, which means multiple frameworks 
> can share reservations. This can get very hairy, as multiple reservations can 
> occur on each agent. 
> It would be nice to be able to optionally, uniquely identify reservations by 
> ID, much like persistent volumes are today. This could be done by adding a 
> new protobuf field, such as Resource.ReservationInfo.id, that if set upon 
> reservation time, would come back when the reservation is advertised.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to