Role-related configuration in Mesos

[Yongqiao Wang <gr...@foxmail.com>]

Hi guys,


Currently, Mesos uses the following ways to configure role-related objects:
1. For dynamic reserve resources for a role, /reserve endpoint is used to reserve, another /unreserve endpoint is used to unreserve, maybe the third endpoint should be added to show resource reservation of a role later due to someone has issue a requirement of this.


2. For configuring quota for a role, only one endpoint /quota is provided to set/remove/show quota information.


3. For role information, /roles endpoint is only provided to show role information(contains role name, weight and the registered frameworks and their used resources) that master is configured with (specified by --roles when Mesos master startup), and the configured roles do not be changed by this endpoint at runtime(without restart Mesos master). And current there are two proposals in progress to support re-configure roles at runtime:
    - Dynamic Roles(MESOS-3177): roles are stored in the registry and added/deleted/removed/shown via /roles HTTP endpoints with the authorized principles.
    - Implicit Roles(MESOS-3988): any role will be allowed, subject to the ACL/authorization system.


After having a discussion, we all prefer to implement Implicit Roles rather than Dynamic Roles, but dynamic weight is out scope of Implicit Roles, so a new project will need be issued for dynamic weight, and like quota, a new endpoint(such as /weight) will be added to update weight of a role at runtime.


For above design and implementation, they are all different. In order to improve the user experience, some enhancements should be done for the same behaviours between above endpoints. I have two proposals as below:


Proposals 1, using /roles endpoint to centralizely show all roles information and using other endpoints(/weight,/quota,/reservation) to only set the role-related configuration.
- Implement Implicit Roles to support dynamically implicitly add/remove role at runtime. and enhance /roles endpoint to centralizely show all role information which contains role name, weight, resource reservation, quota,etc.
- For reservation, merge /reserve and /unreserve together, end user can use one endpoint /reservation(should better be a noun for a Restful endpoint) to reserve(POST method) and unreserve(PUT method) resource, and does not support to show reservation with this endpoint;
- For setting quota, end user can only use /quota endpoint to set and remove quota, and does not support to show quota with this endpoint;
- For dynamic weight, add a new endpoint /weight, end user can use to update weight of a role, and does not support to show weights with this endpoint.




Proposals 2, keep the old behaviour of /roles endpoint and using other endpoints(/weight,/quota,/reservation) to set and show the role-related configuration.
- Implement Implicit Roles to support dynamic implicitly configure role at runtime. and keep the old behaviour of /roles to only show role information which contains role name, weight and the registered frameworks and their used resources.
- For reservation, merge /reserve and /unreserve together, end user can use one endpoint /reservation to reserve(POST method) resource, unreserve(PUT method) resource, show reserved resources(GET method);
- For setting quota, keep the current behaviour, and end user can use /quota endpoint to set(PUT method), remove(DELETE method) and show(GET method) quota;
- For dynamic weight, add a new endpoint /weight, end user can use to update(PUT method) weight of a role, and show(GET method) weight information.



I prefer the proposal 1, because cluster administrator can use /roles endpoint to show the global resource plan of the cluster. I would like to listen from you guys on the above proposals, and any other comments are welcome.


------------------
Regards!
Grady YQ. Wang（王勇桥）

Re: Role-related configuration in Mesos

[Jeff Schroeder <je...@computer.org>]

Perhaps we could also support HTTP PATCH so you could just update one small
thing vs's PUT's get and set method.

On Thursday, December 17, 2015, Adam Bordelon <ad...@mesosphere.io> wrote:

> First off, if we're going to have a /reservations endpoint, we should
> follow the same PUT+DELETE pattern for reserve+unreserve, instead of
> POST+PUT. And we should consider converting /create and /destroy to
> PUT+DELETE verbs on a /volumes endpoint.
>
> Secondly, we're going to have to support the previous endpoints
> through a deprecation cycle (~6mo), so there's no rush to get those
> changes in at the same time as or before dynamic weights.
>
> Finally, it seems like the only real difference between the two
> proposals is whether (1) /roles will be the catch-all "show me
> everything about each role" endpoint that admins/users will request
> when they want to see the current state of their
> reservations/quota/weights(/volumes?), or (2) each endpoint with
> create/update (PUT/POST) and DELETE actions will also have a GET
> action that lists the current state of quotas or weights or whatever,
> and /roles can (continue to) show whatever subset of information it
> wants.
>
> In the long-run, I like the idea of consistency among these types of
> endpoints, but for the near-term scope of dynamic weights, I think you
> can leave the other endpoints alone (including /roles) and just
> implement the PUT/POST+DELETE for /weights to create/update+delete
> weight configurations. Since weights are already displayed in /roles,
> you can leave them there and not worry about creating a GET for
> /weights. That's the least amount of work/disruption you have to do to
> deliver the feature/functionality, includes no wasted work no matter
> whether we go with your proposal 1 or 2 in the long run.
> On that note, we should create a JIRA Epic for defining a proper
> RESTful API for these actions and migrating all relevant endpoints to
> the new model.
>
> Cheers,
> -Adam-
>
> P.S. Seems like RESTful APIs prefer plural nouns over singular, so it
> would be /weights instead of /weight.
>
> On Wed, Dec 16, 2015 at 4:02 AM, Yongqiao Wang <grady.wang@foxmail.com
> <javascript:;>> wrote:
> > Hi guys,
> >
> > Currently, Mesos uses the following ways to configure role-related
> objects:
> > 1. For dynamic reserve resources for a role, /reserve endpoint is used to
> > reserve, another /unreserve endpoint is used to unreserve, maybe the
> third
> > endpoint should be added to show resource reservation of a role later
> due to
> > someone has issue a requirement of this.
> >
> > 2. For configuring quota for a role, only one endpoint /quota is
> provided to
> > set/remove/show quota information.
> >
> > 3. For role information, /roles endpoint is only provided to show role
> > information(contains role name, weight and the registered frameworks and
> > their used resources) that master is configured with (specified by
> --roles
> > when Mesos master startup), and the configured roles do not be changed by
> > this endpoint at runtime(without restart Mesos master). And current there
> > are two proposals in progress to support re-configure roles at runtime:
> >     - Dynamic Roles(MESOS-3177): roles are stored in the registry and
> > added/deleted/removed/shown via /roles HTTP endpoints with the authorized
> > principles.
> >     - Implicit Roles(MESOS-3988): any role will be allowed, subject to
> the
> > ACL/authorization system.
> >
> > After having a discussion, we all prefer to implement Implicit Roles
> rather
> > than Dynamic Roles, but dynamic weight is out scope of Implicit Roles,
> so a
> > new project will need be issued for dynamic weight, and like quota, a new
> > endpoint(such as /weight) will be added to update weight of a role at
> > runtime.
> >
> > For above design and implementation, they are all different. In order to
> > improve the user experience, some enhancements should be done for the
> same
> > behaviours between above endpoints. I have two proposals as below:
> >
> > Proposals 1, using /roles endpoint to centralizely show all roles
> > information and using other endpoints(/weight,/quota,/reservation) to
> only
> > set the role-related configuration.
> > - Implement Implicit Roles to support dynamically implicitly add/remove
> role
> > at runtime. and enhance /roles endpoint to centralizely show all role
> > information which contains role name, weight, resource reservation,
> > quota,etc.
> > - For reservation, merge /reserve and /unreserve together, end user can
> use
> > one endpoint /reservation(should better be a noun for a Restful
> endpoint) to
> > reserve(POST method) and unreserve(PUT method) resource, and does not
> > support to show reservation with this endpoint;
> > - For setting quota, end user can only use /quota endpoint to set and
> remove
> > quota, and does not support to show quota with this endpoint;
> > - For dynamic weight, add a new endpoint /weight, end user can use to
> update
> > weight of a role, and does not support to show weights with this
> endpoint.
> >
> >
> > Proposals 2, keep the old behaviour of /roles endpoint and using other
> > endpoints(/weight,/quota,/reservation) to set and show the role-related
> > configuration.
> > - Implement Implicit Roles to support dynamic implicitly configure role
> at
> > runtime. and keep the old behaviour of /roles to only show role
> information
> > which contains role name, weight and the registered frameworks and their
> > used resources.
> > - For reservation, merge /reserve and /unreserve together, end user can
> use
> > one endpoint /reservation to reserve(POST method) resource, unreserve(PUT
> > method) resource, show reserved resources(GET method);
> > - For setting quota, keep the current behaviour, and end user can use
> /quota
> > endpoint to set(PUT method), remove(DELETE method) and show(GET method)
> > quota;
> > - For dynamic weight, add a new endpoint /weight, end user can use to
> > update(PUT method) weight of a role, and show(GET method) weight
> > information.
> >
> > I prefer the proposal 1, because cluster administrator can use /roles
> > endpoint to show the global resource plan of the cluster. I would like to
> > listen from you guys on the above proposals, and any other comments are
> > welcome.
> >
> > ------------------
> > Regards!
> > Grady YQ. Wang（王勇桥）
> >
>


-- 
Text by Jeff, typos by iPhone

Re: Role-related configuration in Mesos

[Adam Bordelon <ad...@mesosphere.io>]

First off, if we're going to have a /reservations endpoint, we should
follow the same PUT+DELETE pattern for reserve+unreserve, instead of
POST+PUT. And we should consider converting /create and /destroy to
PUT+DELETE verbs on a /volumes endpoint.

Secondly, we're going to have to support the previous endpoints
through a deprecation cycle (~6mo), so there's no rush to get those
changes in at the same time as or before dynamic weights.

Finally, it seems like the only real difference between the two
proposals is whether (1) /roles will be the catch-all "show me
everything about each role" endpoint that admins/users will request
when they want to see the current state of their
reservations/quota/weights(/volumes?), or (2) each endpoint with
create/update (PUT/POST) and DELETE actions will also have a GET
action that lists the current state of quotas or weights or whatever,
and /roles can (continue to) show whatever subset of information it
wants.

In the long-run, I like the idea of consistency among these types of
endpoints, but for the near-term scope of dynamic weights, I think you
can leave the other endpoints alone (including /roles) and just
implement the PUT/POST+DELETE for /weights to create/update+delete
weight configurations. Since weights are already displayed in /roles,
you can leave them there and not worry about creating a GET for
/weights. That's the least amount of work/disruption you have to do to
deliver the feature/functionality, includes no wasted work no matter
whether we go with your proposal 1 or 2 in the long run.
On that note, we should create a JIRA Epic for defining a proper
RESTful API for these actions and migrating all relevant endpoints to
the new model.

Cheers,
-Adam-

P.S. Seems like RESTful APIs prefer plural nouns over singular, so it
would be /weights instead of /weight.

On Wed, Dec 16, 2015 at 4:02 AM, Yongqiao Wang <gr...@foxmail.com> wrote:
> Hi guys,
>
> Currently, Mesos uses the following ways to configure role-related objects:
> 1. For dynamic reserve resources for a role, /reserve endpoint is used to
> reserve, another /unreserve endpoint is used to unreserve, maybe the third
> endpoint should be added to show resource reservation of a role later due to
> someone has issue a requirement of this.
>
> 2. For configuring quota for a role, only one endpoint /quota is provided to
> set/remove/show quota information.
>
> 3. For role information, /roles endpoint is only provided to show role
> information(contains role name, weight and the registered frameworks and
> their used resources) that master is configured with (specified by --roles
> when Mesos master startup), and the configured roles do not be changed by
> this endpoint at runtime(without restart Mesos master). And current there
> are two proposals in progress to support re-configure roles at runtime:
>     - Dynamic Roles(MESOS-3177): roles are stored in the registry and
> added/deleted/removed/shown via /roles HTTP endpoints with the authorized
> principles.
>     - Implicit Roles(MESOS-3988): any role will be allowed, subject to the
> ACL/authorization system.
>
> After having a discussion, we all prefer to implement Implicit Roles rather
> than Dynamic Roles, but dynamic weight is out scope of Implicit Roles, so a
> new project will need be issued for dynamic weight, and like quota, a new
> endpoint(such as /weight) will be added to update weight of a role at
> runtime.
>
> For above design and implementation, they are all different. In order to
> improve the user experience, some enhancements should be done for the same
> behaviours between above endpoints. I have two proposals as below:
>
> Proposals 1, using /roles endpoint to centralizely show all roles
> information and using other endpoints(/weight,/quota,/reservation) to only
> set the role-related configuration.
> - Implement Implicit Roles to support dynamically implicitly add/remove role
> at runtime. and enhance /roles endpoint to centralizely show all role
> information which contains role name, weight, resource reservation,
> quota,etc.
> - For reservation, merge /reserve and /unreserve together, end user can use
> one endpoint /reservation(should better be a noun for a Restful endpoint) to
> reserve(POST method) and unreserve(PUT method) resource, and does not
> support to show reservation with this endpoint;
> - For setting quota, end user can only use /quota endpoint to set and remove
> quota, and does not support to show quota with this endpoint;
> - For dynamic weight, add a new endpoint /weight, end user can use to update
> weight of a role, and does not support to show weights with this endpoint.
>
>
> Proposals 2, keep the old behaviour of /roles endpoint and using other
> endpoints(/weight,/quota,/reservation) to set and show the role-related
> configuration.
> - Implement Implicit Roles to support dynamic implicitly configure role at
> runtime. and keep the old behaviour of /roles to only show role information
> which contains role name, weight and the registered frameworks and their
> used resources.
> - For reservation, merge /reserve and /unreserve together, end user can use
> one endpoint /reservation to reserve(POST method) resource, unreserve(PUT
> method) resource, show reserved resources(GET method);
> - For setting quota, keep the current behaviour, and end user can use /quota
> endpoint to set(PUT method), remove(DELETE method) and show(GET method)
> quota;
> - For dynamic weight, add a new endpoint /weight, end user can use to
> update(PUT method) weight of a role, and show(GET method) weight
> information.
>
> I prefer the proposal 1, because cluster administrator can use /roles
> endpoint to show the global resource plan of the cluster. I would like to
> listen from you guys on the above proposals, and any other comments are
> welcome.
>
> ------------------
> Regards!
> Grady YQ. Wang（王勇桥）
>

Re: Role-related configuration in Mesos

[Adam Bordelon <ad...@mesosphere.io>]

First off, if we're going to have a /reservations endpoint, we should
follow the same PUT+DELETE pattern for reserve+unreserve, instead of
POST+PUT. And we should consider converting /create and /destroy to
PUT+DELETE verbs on a /volumes endpoint.

Secondly, we're going to have to support the previous endpoints
through a deprecation cycle (~6mo), so there's no rush to get those
changes in at the same time as or before dynamic weights.

Finally, it seems like the only real difference between the two
proposals is whether (1) /roles will be the catch-all "show me
everything about each role" endpoint that admins/users will request
when they want to see the current state of their
reservations/quota/weights(/volumes?), or (2) each endpoint with
create/update (PUT/POST) and DELETE actions will also have a GET
action that lists the current state of quotas or weights or whatever,
and /roles can (continue to) show whatever subset of information it
wants.

In the long-run, I like the idea of consistency among these types of
endpoints, but for the near-term scope of dynamic weights, I think you
can leave the other endpoints alone (including /roles) and just
implement the PUT/POST+DELETE for /weights to create/update+delete
weight configurations. Since weights are already displayed in /roles,
you can leave them there and not worry about creating a GET for
/weights. That's the least amount of work/disruption you have to do to
deliver the feature/functionality, includes no wasted work no matter
whether we go with your proposal 1 or 2 in the long run.
On that note, we should create a JIRA Epic for defining a proper
RESTful API for these actions and migrating all relevant endpoints to
the new model.

Cheers,
-Adam-

P.S. Seems like RESTful APIs prefer plural nouns over singular, so it
would be /weights instead of /weight.

On Wed, Dec 16, 2015 at 4:02 AM, Yongqiao Wang <gr...@foxmail.com> wrote:
> Hi guys,
>
> Currently, Mesos uses the following ways to configure role-related objects:
> 1. For dynamic reserve resources for a role, /reserve endpoint is used to
> reserve, another /unreserve endpoint is used to unreserve, maybe the third
> endpoint should be added to show resource reservation of a role later due to
> someone has issue a requirement of this.
>
> 2. For configuring quota for a role, only one endpoint /quota is provided to
> set/remove/show quota information.
>
> 3. For role information, /roles endpoint is only provided to show role
> information(contains role name, weight and the registered frameworks and
> their used resources) that master is configured with (specified by --roles
> when Mesos master startup), and the configured roles do not be changed by
> this endpoint at runtime(without restart Mesos master). And current there
> are two proposals in progress to support re-configure roles at runtime:
>     - Dynamic Roles(MESOS-3177): roles are stored in the registry and
> added/deleted/removed/shown via /roles HTTP endpoints with the authorized
> principles.
>     - Implicit Roles(MESOS-3988): any role will be allowed, subject to the
> ACL/authorization system.
>
> After having a discussion, we all prefer to implement Implicit Roles rather
> than Dynamic Roles, but dynamic weight is out scope of Implicit Roles, so a
> new project will need be issued for dynamic weight, and like quota, a new
> endpoint(such as /weight) will be added to update weight of a role at
> runtime.
>
> For above design and implementation, they are all different. In order to
> improve the user experience, some enhancements should be done for the same
> behaviours between above endpoints. I have two proposals as below:
>
> Proposals 1, using /roles endpoint to centralizely show all roles
> information and using other endpoints(/weight,/quota,/reservation) to only
> set the role-related configuration.
> - Implement Implicit Roles to support dynamically implicitly add/remove role
> at runtime. and enhance /roles endpoint to centralizely show all role
> information which contains role name, weight, resource reservation,
> quota,etc.
> - For reservation, merge /reserve and /unreserve together, end user can use
> one endpoint /reservation(should better be a noun for a Restful endpoint) to
> reserve(POST method) and unreserve(PUT method) resource, and does not
> support to show reservation with this endpoint;
> - For setting quota, end user can only use /quota endpoint to set and remove
> quota, and does not support to show quota with this endpoint;
> - For dynamic weight, add a new endpoint /weight, end user can use to update
> weight of a role, and does not support to show weights with this endpoint.
>
>
> Proposals 2, keep the old behaviour of /roles endpoint and using other
> endpoints(/weight,/quota,/reservation) to set and show the role-related
> configuration.
> - Implement Implicit Roles to support dynamic implicitly configure role at
> runtime. and keep the old behaviour of /roles to only show role information
> which contains role name, weight and the registered frameworks and their
> used resources.
> - For reservation, merge /reserve and /unreserve together, end user can use
> one endpoint /reservation to reserve(POST method) resource, unreserve(PUT
> method) resource, show reserved resources(GET method);
> - For setting quota, keep the current behaviour, and end user can use /quota
> endpoint to set(PUT method), remove(DELETE method) and show(GET method)
> quota;
> - For dynamic weight, add a new endpoint /weight, end user can use to
> update(PUT method) weight of a role, and show(GET method) weight
> information.
>
> I prefer the proposal 1, because cluster administrator can use /roles
> endpoint to show the global resource plan of the cluster. I would like to
> listen from you guys on the above proposals, and any other comments are
> welcome.
>
> ------------------
> Regards!
> Grady YQ. Wang（王勇桥）
>

Re: Role-related configuration in Mesos

[Alex Rukletsov <al...@mesosphere.com>]

An example that clarifies Benjamin's point: quota is set per role indeed,
but it may change in the future (I can envision quotas for individual
frameworks as well).

I think:
  * It would be great to merge relevant actions into one endpoint and
express the difference via http verbs ("/reservation" and "/volumes").
  * All services that are not strictly related to roles, should have their
own endpoints.
  * All services somehow related to roles should be somehow "linked" in
"/roles". For example, if quota is set for role "A" as an operator I should
be able to see it when I hit "/roles". Otherwise it's very tedious to track
all "visible" roles.
  * All services strictly related to roles (role weight) do not necessarily
need their own endpoints and can be managed via "/roles".


On Fri, Dec 18, 2015 at 3:05 PM, Benjamin Bannier <
benjamin.bannier@mesosphere.io> wrote:

> Hi,
>
> like you write we use roles for a number of pretty loosely coupled
> concerns (allocation, quota, reservations).
>
> While denormalizing the endpoints like you suggest in Proposal (1)
> simplifies querying information, it limits how that coupling can be evolved
> in the future (at least if we’d like to avoid breaking the interface). That
> would be much less a problem for lightweight endpoints dealing with single
> services each.
>
>
> Cheers,
>
> Benjamin
>
>
> > On Dec 16, 2015, at 1:02 PM, Yongqiao Wang <gr...@foxmail.com>
> wrote:
> >
> > Hi guys,
> >
> > Currently, Mesos uses the following ways to configure role-related
> objects:
> > 1. For dynamic reserve resources for a role, /reserve endpoint is used
> to reserve, another /unreserve endpoint is used to unreserve, maybe the
> third endpoint should be added to show resource reservation of a role later
> due to someone has issue a requirement of this.
> >
> > 2. For configuring quota for a role, only one endpoint /quota is
> provided to set/remove/show quota information.
> >
> > 3. For role information, /roles endpoint is only provided to show role
> information(contains role name, weight and the registered frameworks and
> their used resources) that master is configured with (specified by --roles
> when Mesos master startup), and the configured roles do not be changed by
> this endpoint at runtime(without restart Mesos master). And current there
> are two proposals in progress to support re-configure roles at runtime:
> >     - Dynamic Roles(MESOS-3177): roles are stored in the registry and
> added/deleted/removed/shown via /roles HTTP endpoints with the authorized
> principles.
> >     - Implicit Roles(MESOS-3988): any role will be allowed, subject to
> the ACL/authorization system.
> >
> > After having a discussion, we all prefer to implement Implicit Roles
> rather than Dynamic Roles, but dynamic weight is out scope of Implicit
> Roles, so a new project will need be issued for dynamic weight, and like
> quota, a new endpoint(such as /weight) will be added to update weight of a
> role at runtime.
> >
> > For above design and implementation, they are all different. In order to
> improve the user experience, some enhancements should be done for the same
> behaviours between above endpoints. I have two proposals as below:
> >
> > Proposals 1, using /roles endpoint to centralizely show all roles
> information and using other endpoints(/weight,/quota,/reservation) to only
> set the role-related configuration.
> > - Implement Implicit Roles to support dynamically implicitly add/remove
> role at runtime. and enhance /roles endpoint to centralizely show all role
> information which contains role name, weight, resource reservation,
> quota,etc.
> > - For reservation, merge /reserve and /unreserve together, end user can
> use one endpoint /reservation(should better be a noun for a Restful
> endpoint) to reserve(POST method) and unreserve(PUT method) resource, and
> does not support to show reservation with this endpoint;
> > - For setting quota, end user can only use /quota endpoint to set and
> remove quota, and does not support to show quota with this endpoint;
> > - For dynamic weight, add a new endpoint /weight, end user can use to
> update weight of a role, and does not support to show weights with this
> endpoint.
> >
> >
> > Proposals 2, keep the old behaviour of /roles endpoint and using other
> endpoints(/weight,/quota,/reservation) to set and show the role-related
> configuration.
> > - Implement Implicit Roles to support dynamic implicitly configure role
> at runtime. and keep the old behaviour of /roles to only show role
> information which contains role name, weight and the registered frameworks
> and their used resources.
> > - For reservation, merge /reserve and /unreserve together, end user can
> use one endpoint /reservation to reserve(POST method) resource,
> unreserve(PUT method) resource, show reserved resources(GET method);
> > - For setting quota, keep the current behaviour, and end user can use
> /quota endpoint to set(PUT method), remove(DELETE method) and show(GET
> method) quota;
> > - For dynamic weight, add a new endpoint /weight, end user can use to
> update(PUT method) weight of a role, and show(GET method) weight
> information.
> >
> > I prefer the proposal 1, because cluster administrator can use /roles
> endpoint to show the global resource plan of the cluster. I would like to
> listen from you guys on the above proposals, and any other comments are
> welcome.
> >
> > ------------------
> > Regards!
> > Grady YQ. Wang（王勇桥）
> >
>
>

Re: Role-related configuration in Mesos

[Benjamin Bannier <be...@mesosphere.io>]

Hi,

like you write we use roles for a number of pretty loosely coupled concerns (allocation, quota, reservations).

While denormalizing the endpoints like you suggest in Proposal (1) simplifies querying information, it limits how that coupling can be evolved in the future (at least if we’d like to avoid breaking the interface). That would be much less a problem for lightweight endpoints dealing with single services each.


Cheers,

Benjamin


> On Dec 16, 2015, at 1:02 PM, Yongqiao Wang <gr...@foxmail.com> wrote:
> 
> Hi guys,
> 
> Currently, Mesos uses the following ways to configure role-related objects:
> 1. For dynamic reserve resources for a role, /reserve endpoint is used to reserve, another /unreserve endpoint is used to unreserve, maybe the third endpoint should be added to show resource reservation of a role later due to someone has issue a requirement of this.
> 
> 2. For configuring quota for a role, only one endpoint /quota is provided to set/remove/show quota information.
> 
> 3. For role information, /roles endpoint is only provided to show role information(contains role name, weight and the registered frameworks and their used resources) that master is configured with (specified by --roles when Mesos master startup), and the configured roles do not be changed by this endpoint at runtime(without restart Mesos master). And current there are two proposals in progress to support re-configure roles at runtime:
>     - Dynamic Roles(MESOS-3177): roles are stored in the registry and added/deleted/removed/shown via /roles HTTP endpoints with the authorized principles.
>     - Implicit Roles(MESOS-3988): any role will be allowed, subject to the ACL/authorization system.
> 
> After having a discussion, we all prefer to implement Implicit Roles rather than Dynamic Roles, but dynamic weight is out scope of Implicit Roles, so a new project will need be issued for dynamic weight, and like quota, a new endpoint(such as /weight) will be added to update weight of a role at runtime.
> 
> For above design and implementation, they are all different. In order to improve the user experience, some enhancements should be done for the same behaviours between above endpoints. I have two proposals as below:
> 
> Proposals 1, using /roles endpoint to centralizely show all roles information and using other endpoints(/weight,/quota,/reservation) to only set the role-related configuration.
> - Implement Implicit Roles to support dynamically implicitly add/remove role at runtime. and enhance /roles endpoint to centralizely show all role information which contains role name, weight, resource reservation, quota,etc.
> - For reservation, merge /reserve and /unreserve together, end user can use one endpoint /reservation(should better be a noun for a Restful endpoint) to reserve(POST method) and unreserve(PUT method) resource, and does not support to show reservation with this endpoint;
> - For setting quota, end user can only use /quota endpoint to set and remove quota, and does not support to show quota with this endpoint;
> - For dynamic weight, add a new endpoint /weight, end user can use to update weight of a role, and does not support to show weights with this endpoint.
> 
> 
> Proposals 2, keep the old behaviour of /roles endpoint and using other endpoints(/weight,/quota,/reservation) to set and show the role-related configuration.
> - Implement Implicit Roles to support dynamic implicitly configure role at runtime. and keep the old behaviour of /roles to only show role information which contains role name, weight and the registered frameworks and their used resources.
> - For reservation, merge /reserve and /unreserve together, end user can use one endpoint /reservation to reserve(POST method) resource, unreserve(PUT method) resource, show reserved resources(GET method);
> - For setting quota, keep the current behaviour, and end user can use /quota endpoint to set(PUT method), remove(DELETE method) and show(GET method) quota;
> - For dynamic weight, add a new endpoint /weight, end user can use to update(PUT method) weight of a role, and show(GET method) weight information.
> 
> I prefer the proposal 1, because cluster administrator can use /roles endpoint to show the global resource plan of the cluster. I would like to listen from you guys on the above proposals, and any other comments are welcome.
> 
> ------------------
> Regards!
> Grady YQ. Wang（王勇桥）
>