[
https://issues.apache.org/jira/browse/MESOS-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jie Yu updated MESOS-1974:
--------------------------
Description:
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.
was:
WeThe 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.
> Update 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
>
> 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)
