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

Jie Yu updated MESOS-1974:
--------------------------
    Summary: Refactor the C++ Resources abstraction for DiskInfo  (was: Update 
the C++ Resources abstraction for DiskInfo)

> Refactor the C++ Resources abstraction for DiskInfo
> ---------------------------------------------------
>
>                 Key: MESOS-1974
>                 URL: https://issues.apache.org/jira/browse/MESOS-1974
>             Project: Mesos
>          Issue Type: Improvement
>            Reporter: Jie Yu
>            Assignee: Jie Yu
>             Fix For: 0.22.0
>
>
> As we introduce DiskInfo and reservation for Resource. We need to change the 
> C++ Resources abstraction to properly deal with merge/split of resources with 
> those additional fields.
> Also, the existing C++ 'Resources' interfaces are poorly designed. Some of 
> them are confusing and unintuitive. Some of them are overloaded with too many 
> functionalities. For instance,
> {noformat}
> bool operator <= (const Resource& left, const Resource& right);
> {noformat}
> This interface in non-intuitive because A <= B doesn't imply !(B <= A).
> {noformat}
> Resource operator + (const Resource& left, const Resource& right);
> {noformat}
> This one is also non-intuitive because if 'left' is not compatible with 
> 'right', the result is 'left' (why not right???). Similar for operator '-'.
> {noformat}
> Option<Resource> Resources::get(const Resource& r) const;
> {noformat}
> This one assume Resources is flattened, but it might not be.
> As we start to introduce persistent disk resources (MESOS-1554), things will 
> get more complicated. For example, one may want to get two types of 'disk()' 
> functions: one returns the ephemeral disk bytes (with no disk info), one 
> returns the total disk bytes (including ones that have disk info). We may 
> wanna introduce a concept about Resource that indicates that a resource 
> cannot be merged or split (e.g., atomic?).
> Since we need to change this class anyway. I wanna take this chance to 
> refactor it.



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

Reply via email to