> 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. > > Joseph Wu wrote: > 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. > > Guangya Liu wrote: > I think that adding a new `flatten` without default value might be better > and clear. > > Guangya Liu wrote: > But the problem is that even with > > `Resources flatten(string role = "*", Option<ReservationInfo> resveration > = None())` > and > `Resources flatten(Option<RevocableInfo> revocable)` > > There are still ambiguity when calling `flatten(role)`, comments? > > Guangya Liu wrote: > In file included from ../../src/tests/fault_tolerance_tests.cpp:56: > ../../src/tests/mesos.hpp:665:39: error: call to member function > 'flatten' is ambiguous > remaining.find(TASK_RESOURCES.flatten(role)); > ~~~~~~~~~^ > What about still use `flattenSlack`? > > Klaus Ma wrote: > Sorry, just checked this error; it seems we `make` passed but `make > check` failed, right? > > Guangya Liu wrote: > Yes, the `make tests/check` failed, any idea for this?
It's possible to fix the ambiguity (thanks MPark!), although I'm not sure if we want to... We can disambiguate by changing one of `Option` 's constructors to: ``` template < typename U, typename = typename std::enable_if< std::is_constructible<T, const U&>::value>::type> Option(const U& u); ``` - Joseph ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41772/#review115249 ----------------------------------------------------------- On Jan. 22, 2016, 6:59 p.m., Guangya Liu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/41772/ > ----------------------------------------------------------- > > (Updated Jan. 22, 2016, 6:59 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 allocation slack 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 > >