> On Jan. 19, 2016, 2:18 p.m., Joseph Wu wrote:
> > src/common/resources.cpp, lines 874-877
> > <https://reviews.apache.org/r/41772/diff/6/?file=1199181#file1199181line874>
> >
> > This is pretty much a copy of `Resources::reserved` now. You can
> > remove it.
>
> Guangya Liu wrote:
> The reason that I keep this is because the current `Resources::reserved`
> returns a hashmap but what I need here is a flatten string for resources in
> different roles. e.g. cpus(r1):100;cpus(r2):200
>
> I updated the comments here to clarify why this is needed.
>
> Klaus Ma wrote:
> I think it's more general to add a `Resources` constructor to accept
> hashmap, so it'll be `Resources(res.reserved()).flatten()`.
It doesn't look like `reserved()` is used very heavily. And the places that do
use it could easily use a normal `Resources` object. I'd recommend changing
`reserved()` or just using `reserved("*")`.
> On Jan. 19, 2016, 2:18 p.m., Joseph Wu wrote:
> > src/common/resources.cpp, line 880
> > <https://reviews.apache.org/r/41772/diff/6/?file=1199181#file1199181line880>
> >
> > It should be fine to just name this `flatten`.
> >
> > You should also consider changing the parameter type from
> > `RevocableInfo::Type` to just `RevocableInfo`. Supplying the whole
> > `RevocableInfo` will save us another tweak to the helpers if we change the
> > revocable protobufs again.
>
> Guangya Liu wrote:
> I think that we cannot rename it to `flatten` as the compiler will not
> know what does `flatten()` mean.
>
> Klaus Ma wrote:
> Regarding from `RevocableInfo::Type` to `RevocableInfo`, do you mean
> change `RevocableInfo` from `message` to `enum`? I think it's better to
> define const in `Resources` instead of changing `RevocableInfo`'s type, e.g.
> `static const Resource::RevocableInfo::Type Resources::ALLOCATION_SLACK =
> Resource::RevocableInfo::Type::ALLOCATION_SLACK`.
>
> Regarding `flatten`, there're two options to me:
>
> * Option 1: add `RevocableInfo::Type` to as 3rd parameter in current
> `flatten` with `None()` as default vaule, and a new helper function to accept
> `RevocableInfo::Type` only without default value. The sample code is:
>
> ```
> Resources flatten(string role = "*", Option<ReservationInfo>
> resveration = None(), Option<RevocableInfo::Type> revocable = None()) {
> ...
> if (revocable.isSome()) {
> flatten(revocable.get());
> } else {
> // clear revocable info.
> }
> }
>
> Resources flatten(RevocableInfo::Type revocable) {
> foreach resources {
> resource.mutable_revocable()->set_type(revocable);
> }
> }
> ```
>
> * Option 2: add new `flatten` functions but did not provide default
> value; `None()` means clear the `RevocableInfo::Type`.
>
> I perfer to Option 1 :). Any comments?
>
> Guangya Liu wrote:
> option 1 will cause all caller who want to flatten allocation slack need
> to input all of the four parameter, it is really not convenient for the
> caller.
> Option 2 need to add a new `flatten` with a `requested` but not `option`
> parameter, I think that maybe 2 is better.
>
> Klaus Ma wrote:
> regarding 1, if want to clear the flags (role, reservation and
> revocable), call `flatten()`; if want to set `ALLOCATION_SLACK`, call
> `flatten(Resources::ALLOCATION_SLACK)`.
>
> Guangya Liu wrote:
> Just clarify 1) here, I have some mis-understanding for it.
>
> Option 1) has involved two APIs, one is update current `Resources
> flatten(string role = "*", Option<ReservationInfo> resveration = None(), ,
> Option<RevocableInfo::Type> revocable = None() )`, the other is add a new
> `flatten(RevocableInfo::Type revocable)`. The `first flatten` is used to
> clear `allocation slack` and the `second flatten` is used to set `allocation
> slack` flag.
>
> Seems 1) is better as it faciliates the caller.
Given how you're using `flatten`, it would be better to have two calls:
`Resources flatten(string role = "*", Option<ReservationInfo> resveration =
None())`
and
`Resources flatten(Option<RevocableInfo> revocable)` // No default so there's
no ambiguity.
---
Note: If you wanted a single `flatten`, you'd need to have
`Option<Option<ReservationInfo>>` so that you have the option of setting,
un-setting, or not-changing each field.
- Joseph
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41772/#review115249
-----------------------------------------------------------
On Jan. 19, 2016, 7:40 p.m., Guangya Liu wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41772/
> -----------------------------------------------------------
>
> (Updated Jan. 19, 2016, 7:40 p.m.)
>
>
> Review request for mesos, Ben Mahler, Artem Harutyunyan, Joris Van
> Remoortere, Joseph Wu, and Klaus Ma.
>
>
> Bugs: MESOS-4267
> https://issues.apache.org/jira/browse/MESOS-4267
>
>
> Repository: mesos
>
>
> Description
> -------
>
> Added helper function to flatten resources.
>
>
> Diffs
> -----
>
> include/mesos/resources.hpp cc8fef9470d779078aa408ed03e747e5a492deaa
> include/mesos/v1/resources.hpp f4892977f8d7b0439db6e9cf7921334f606a496c
> src/common/resources.cpp 575d6651185d8431f01d589f4afc255cb751181a
> src/tests/resources_tests.cpp b42610f1bf8eacfd7bf388d351f8745f1d96f666
> src/v1/resources.cpp 8de6672ba9b34947db81c74b8e03e8965e8af5fc
>
> Diff: https://reviews.apache.org/r/41772/diff/
>
>
> Testing
> -------
>
> make
> make check
>
> GLOG_v=2 ./bin/mesos-tests.sh --gtest_filter="ResourcesOperationTest.*"
> --verbose
>
>
> Thanks,
>
> Guangya Liu
>
>
