Re: Review Request: Static Allocations 1: Introduce the Dedication abstraction

[Thomas Marshall <tw...@gmail.com>]

> On Feb. 20, 2013, 12:26 a.m., Vinod Kone wrote:
> > src/slave/flags.hpp, line 53
> > <https://reviews.apache.org/r/9480/diff/1/?file=259389#file259389line53>
> >
> >     what does '&' mean? Is that how you separate dedications/allocations? If yes, thats not very clear. Probably an example string in the description makes it more clear.

Yes, that was my plan for separating allocations, though I chose '&' arbitrarily as something that wouldn't conflict with the ':' and ';' in use in the resources part so if you have a better suggestion for a symbol to use I can change it.


> On Feb. 20, 2013, 12:26 a.m., Vinod Kone wrote:
> > include/mesos/mesos.proto, lines 243-246
> > <https://reviews.apache.org/r/9480/diff/1/?file=259385#file259385line243>
> >
> >     What about cases where we want to allocate based on 'framework' but not 'user'? i.e.,, can 'user' be optional too?
> >     
> >     More importantly, do you have any thoughts no how to make this more generic/hierarchical? For example,  what if we want to dedicate resources to all users of a team?

You make a good point that this scheme isn't very flexible, so I was thinking that instead of doing dedications based on users/frameworks, I could create an "allocation group" abstraction that gets passed in through FrameworkInfos, so that any framework can be assigned to any number of groups and any group can be statically allocated any resources on any slave, which gives the highest level of control over how resources are statically assigned while still being simple.


> On Feb. 20, 2013, 12:26 a.m., Vinod Kone wrote:
> > include/mesos/mesos.proto, line 247
> > <https://reviews.apache.org/r/9480/diff/1/?file=259385#file259385line247>
> >
> >     How about calling this Allocation instead of Dedication?
> >     
> >     Dedication seems to be too strict of a notion, compared to Allocation.

While I agree that Dedication may not be the best word, I think that Allocation would be too ambiguous since there's already a concept of "allocation", as in the decision by the allocator to offer some set of resources to some framework, which is clearly different from the concept of a "dedication", as in the specification by the user that the allocator can only offer some set of resources to some specific framework.


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9480/#review16757
-----------------------------------------------------------


On Feb. 16, 2013, 12:52 a.m., Thomas Marshall wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9480/
> -----------------------------------------------------------
> 
> (Updated Feb. 16, 2013, 12:52 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Vinod Kone.
> 
> 
> Description
> -------
> 
> Introduces the Dedication abstraction, a protobuf with C++ wrapper in the style of Attributes or Resources, used to store information about resources on certain slaves being statically dedicated to certain frameworks/users. The patch allows this information to be passed in to the slave as a command line option, then parses it and creates the appropriate Dedication objects to be passed to the allocator.
> 
> This patch does not implement the logic behind static allocations in the allocator because I'm trying to break all of this up to make it easier to review.
> 
> 
> Diffs
> -----
> 
>   include/mesos/mesos.proto 3823515 
>   src/Makefile.am c94736d 
>   src/common/dedications.hpp PRE-CREATION 
>   src/common/dedications.cpp PRE-CREATION 
>   src/slave/flags.hpp 39e57f4 
>   src/slave/slave.hpp e9f7b65 
>   src/slave/slave.cpp 9755b46 
> 
> Diff: https://reviews.apache.org/r/9480/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Thomas Marshall
> 
>