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.bann...@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 <grady.w...@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（王勇桥）
> >
>
>
