mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Mahler <>
Subject Re: Operator HTTP endpoints
Date Fri, 15 Jan 2016 21:09:23 GMT
The distinction between being related to the request vs. how the request
should be processed seems arguable, do you feel that we'll be able to make
the distinction easily?

One thought.. if there are top-level Request objects:

message QuotaRequest {
  optional bool force;
  required QuotaInfo quota_info;

Then we could map query parameters to fields, so the following are

  "quota_info": { ...}

  "force": true,
  "quota_info": { ...}

The user can choose between query parameters vs json body as they please,
and we still have a single specification of the request.

On Thu, Jan 14, 2016 at 10:09 AM, Alex Rukletsov <>

> Folks,
> I would like to gather your opinions about a concern related to operator
> HTTP endpoints. From one side we agreed that for simplicity and consistency
> we should bake all request data in a single JSON. From the other side, some
> parameters, like a force flag, do not really belong to request JSON (as
> pointed out by some SRE guys in comment to MESOS-3914 [1]). The force flag
> is not really related to the request itself, but more to the way the
> request should be processed.
> To my knowledge, currently we use the force flag in two places:
>   * Subscribe call in framework API.
>   * Quota set request.
> Currently we have the 'force' field in JSON both cases.
> I would like us to agree on the way we write endpoints and clean-up
> existing ones *before* we release Mesos 1.0. Looking forward to your
> feedback.
> AlexR
> [1]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message