+1 on *Request -> *Info :). ---- Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer Platform OpenSource Technology, STG, IBM GCG +86-10-8245 4084 | [email protected] | http://k82.me
On Mon, Jan 18, 2016 at 7:38 PM, Alex Rukletsov <[email protected]> wrote: > I agree that the borderline between being related to the request and being > related to the way the request is processed is vague. I think having > *Request objects is a good idea, both for documenting the JSON request > schema and differentiating between the request and storage data. > > However, I'm a bit reluctant to nest QuotaInfo in QuotaRequest. Since > QuotaInfo is what we persist in the master (and the registry), it may have > fields that are not relevant to the request (e.g., "principal"), hence we > should validate these fields are not set and document that. I would suggest > to untie *Request and *Info protos and perform conversions *Request -> > *Info. > > On Fri, Jan 15, 2016 at 10:09 PM, Benjamin Mahler <[email protected]> > wrote: > > > 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 > > equivalent: > > > > /quota?force=true > > { > > "quota_info": { ...} > > } > > > > /quota > > { > > "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 <[email protected]> > > wrote: > > > > > 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] https://issues.apache.org/jira/browse/MESOS-3914 > > > > > >
