Re: Review Request 72267: Added docs for UPDATE_FRAMEWORK call.

2020-03-27 Thread Benjamin Mahler


> On March 25, 2020, 7:20 p.m., Benjamin Mahler wrote:
> > docs/scheduler-http-api.md
> > Lines 534-535 (patched)
> > 
> >
> > Huh? Which fields are being referred to here?
> 
> Andrei Sekretenko wrote:
> Everything not named above: all the fileds except for `principal`, 
> `user`, `checkpoint`, `roles`/`role` and, obviously, except of `id`.
> 
> 
> There, actually, is a good question: how well tested is update of other 
> fields and what we can document here?
> 
> I tried to dig into the current state a bit. 
> 
> First, there are basic tests that resubscription/UPDATE_FRAMEWORK can 
> change all other fields in `FrameworkInfo` as reported by Master.
> 
> Then, I would say, there are three categories of fields:
> 1) `name`, `hostname`, `webui_url` and `labels`: these are not really 
> used by Mesos, basic tests seem enough.
> 
> 2) `failover_timeout` and `offer_filters`: don't see where we test the 
> effects of updating them, but those effects look more or less trivial.
> 
> 3) `capabilities` field: changing some of them has non-trivial effects. 
>For example, removing `REVOCABLE_RESOURCES` results in rescinging 
> offered revocable resources; this particular scenario is tested. 
>At this point I'm not really sure that every non-trivial capability 
> change is well-designed and covered by tests.
> 
> Do you have any suggestions how to better document all this stuff? 
> Can we safely say that Mesos supports update of (1)? How about (2)?
> What to state about `capabilities` other than `REVOCABLE_RESOURCES`?...

I would say that if we don't explicitly deny it and we've told the user 200 OK, 
then it should be changed in the master and the updates should be propagated to 
the agents. 

1) should be supported, with the caveat that anything that is looking at these 
needs to be aware that they may change

2) should definitely be supported

3) Capabilities get tricky since we never implemented minimum capabilities for 
schedulers yet (so we can't validate that the removal of capabilities is safe). 
Like [MESOS-8878](https://issues.apache.org/jira/browse/MESOS-8878) but for 
schedulers.

I would suggest spelling these subtleties out, so that users know there are 
some pitfalls here, and there are no safety guarantees for 3).


- Benjamin


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


On March 25, 2020, 2:08 p.m., Andrei Sekretenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/72267/
> ---
> 
> (Updated March 25, 2020, 2:08 p.m.)
> 
> 
> Review request for mesos, Benjamin Mahler and Greg Mann.
> 
> 
> Bugs: MESOS-9979
> https://issues.apache.org/jira/browse/MESOS-9979
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Added docs for UPDATE_FRAMEWORK call.
> 
> 
> Diffs
> -
> 
>   docs/scheduler-http-api.md 9831d527cc1f832a6fb0d0d330ebdc2a0b0f3774 
> 
> 
> Diff: https://reviews.apache.org/r/72267/diff/1/
> 
> 
> Testing
> ---
> 
> Checked rendering in Github: 
> https://github.com/asekretenko/mesos/blob/update_framework_doc/docs/scheduler-http-api.md
> 
> 
> Thanks,
> 
> Andrei Sekretenko
> 
>



Re: Review Request 72275: Added Dong Zhu to contributors list.

2020-03-27 Thread Benjamin Mahler

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


Ship it!




Ship It!

- Benjamin Mahler


On March 27, 2020, 1:33 a.m., Dong Zhu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/72275/
> ---
> 
> (Updated March 27, 2020, 1:33 a.m.)
> 
> 
> Review request for mesos and Benjamin Mahler.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Added Dong Zhu to contributors list.
> 
> 
> Diffs
> -
> 
>   docs/contributors.yaml 038013bb5bdfbbda109a7db630bcd068c2268aaa 
> 
> 
> Diff: https://reviews.apache.org/r/72275/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dong Zhu
> 
>