Yan Xu created MESOS-6222:
-----------------------------
Summary: Improve organization of methods related to Resources
Key: MESOS-6222
URL: https://issues.apache.org/jira/browse/MESOS-6222
Project: Mesos
Issue Type: Improvement
Components: c++ api
Reporter: Yan Xu
Currently the {{Resources}} class is used to dump everything loosely related to
the protobuf {{Resource}} as member methods.
As a result {{Resources}} has a large amount of utility methods that are not
related to the {{Resources}} abstraction.
Examples:
{code:title=This returns a protobuf Resource and not Resources.}
static Try<Resource> parse(
const std::string& name,
const std::string& value,
const std::string& role);
{code}
{code:title=This only looks at the protobuf too.}
static bool isPersistentVolume(const Resource& resource);
{code}
This makes it hard to name and distinguish similar methods which work at
different abstraction levels (see the {{parse(text, role)}} function below).
It would be way simpler to have them as namespaced free-standing functions.
{code:title=}
namespace mesos {
// Methods for the protobuf `Resource`.
namespace resource {
Try<Resource> parse(
const std::string& name,
const std::string& value,
const std::string& role);
bool isPersistentVolume(const Resource& resource);
// Now I can add a `parse` method for multiple resources but at the
`Resource` level.
Try<vector<Resource>> parse(
const std::string& text,
const std::string& defaultRole = "*");
}
// Methods for the `Resources` abstraction.
namespace resources {
...
}
}
{code}
Static member methods of Resources are still fine if they directly pertain to
the {{Resources}} abstraction itself and we can use the private members/methods
when useful.
{code:title=e.g., Resources::flatten() uses the internal validation-free `add`
method as opposed to `+=` to accumulate resource objects}
Try<Resources> flatten(
const std::string& role,
const Option<Resource::ReservationInfo>& reservation = None()) const;
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
