For the new UPDATE_QUOTA call, do we allow setting limit lower than role's existing allocation? If yes, does operator have to do it with the 'force' flag?
Regards, Qian Zhang On Sat, Mar 10, 2018 at 10:40 AM, Benjamin Mahler <bmah...@apache.org> wrote: > As discussed during the API working group, we would like to ensure that > upcoming API changes are surfaced more broadly than just in Review Board. > The hope is that if we surface them on the dev@ list, it will raise > awareness and give a chance for more folks to give feedback on things like > naming, consistency, intuitiveness, etc of any API changes. > > One upcoming change is the addition of quota "limits" to the quota API: > https://reviews.apache.org/r/65334/ > > JIRA / Design Doc: > https://issues.apache.org/jira/browse/MESOS-8068 > https://docs.google.com/document/d/1EEpHIlJahYtjqv7zAEkW8U7Bi0CTY > FDqAhU0laM7Rzk/edit?usp=sharing (this is hierarchical, but we're tackling > non-hierarchical first). > > Here's an overview: > > (1) Currently, the default quota is: no guarantee and no limit. This will > remain unchanged. > > (2) v0 /quota and v1 SET_QUOTA currently implicitly set quota limit equal > to quota guarantee. > (2)(a) For backwards compatibility, these APIs will continue to behave > the same. > (2)(b) We will also disallow users from explicitly setting limit in these > old APIs. > > (3) A new UPDATE_QUOTA call will be added which allows users to set a > limit. > (3)(a) This approach is more consistent with UPDATE_WEIGHTS: there is > always a quota, much like there is always a weight. If the quota is updated > to the default, it does not need to be persisted. > (3)(b) Unlike the old APIs, absence of a limit will mean no limit. > (3)(c) We'll validate that the limit does not exceed the cluster size and > the existing 'force' flag in QuotaRequest will bypass this validation. > > Let me know if you have any feedback. > > Ben >
