There are no simple answers here other than to understand the effect of the
command.
The resource limit/control command always addresses an object. But giving
control of that command to the object owner, just because the command
addresses an object, will break all controls about resource utilizat
I haven't gone through the details of the new proposal yet.
But based on the comments in the email thread, it seems to me that one of
the major concerns is around the ownership and permissions of "resources".
The actual resources (cpu, memory, and storage) is shared between multiple
tenants within
I’m not diving in but thinking about the logical implication of this dichotomy.
For any object’s attributes some ought to be controlled by object level
permissions and others by sysadmin permissions. How can developers tell?
Best Regards,
Dave
Sent from my iPhone
> On Nov 7, 2019, at 8:02 PM,
This proposal has the same issues as the previous one . In general it is
not correct to think of commands as being controlled by owner of the
object on which the command operates. Eg: It will be an error to assing
control of all namespace commands to the namespace owner
For eg: set subscription
I can't speak to if these are all the correct level of access (thought it
looks sane to me) but I am very excited about more granular permissions.
I would also say that I I think even an initial simpler implementation of
this with just the "namespace admin" would go a long way to improving it if
f
2019-11-06 22:02:31 UTC - Peter Dimitrios: @Peter Dimitrios has joined the
channel
