To me, the fundamental issue is just what a quota is. Is a quota a
primitive basic object which has the role/cluster/environment as an
attribute? Or is the role the basic object, and the quota is an attribute
of the role? I think that the quota as attribute of a user makes much more
Even in the case of things like the quota for a specific environment. I
think that the question "What is roleA's quota on cluster west in the prod
environment?" is more natural than "What is the quota in the test
environment of cluster west for roleA?" And so asking "aurora role
get_quota smf1/mchucarroll/test" makes sense, because it's asking about the
quota for a user in a particular place.
I'm willing to give in if the consensus is against me, but I really think
that the role-based quota command makes much more sense.
Can others please chip in with their opinions?
On Fri, Jan 31, 2014 at 7:49 PM, Kevin Sweeney <kevi...@apache.org> wrote:
> This is an automatically generated e-mail. To reply, visit:
> On January 24th, 2014, 2:35 p.m. PST, *Kevin Sweeney* wrote:
> Why is this happening on a role noun and not a quota noun.
> aurora quota get west/ksweeney
> aurora role get_quota west/ksweeney
> The second looks inconsistent with the noun-verb model to me and if we ever
> decide that a quota could be set at a lower level the first is more extensible
> aurora quota get west/ksweeney/prod
> aurora quota get west/ksweeney/prod/appserver
> On January 31st, 2014, 7:37 a.m. PST, *Mark Chu-Carroll* wrote:
> I've been thinking about this, debating it in my own head, and I just can't
> "Quota" isn't a standalone entity; A quota is an attribute of a role. It
> doesn't make sense to me to have it be a standalone noun.
> In terms of syntax, in noun/verb commands, the first parameter is almost
> always a value of the noun type. (For example, inn "job create", the first
> parameter is a job identifier.) For quota, there is no such thing as a quota
> identifier or a quota object. You specify the role who's quota you're
> interested in.
> Even in the extended scenarios you're talking about, I don't think it makes
> sense. The quota for "west/ksweeney/prod" is ksweeney's quota in the prod
> So it seems better to add:
> aurora role get_quota smf1/ksweeney
> aurora environment get_quota smf1/ksweeney/prod
> aurora job get_quota smf1/ksweeney/prod/app
> I'm not quite convinced, but I recognize I could be wrong. Anybody else want
> to chime in here?
> - Kevin
> On January 24th, 2014, 2:07 p.m. PST, Mark Chu-Carroll wrote:
> Review request for Aurora, Kevin Sweeney and Brian Wickman.
> By Mark Chu-Carroll.
> *Updated Jan. 24, 2014, 2:07 p.m.*
> *Bugs: * aurora-107 <https://issues.apache.org/jira/browse/aurora-107>
> *Repository: * aurora
> Add a "role" noun.
> Currently, the only operation on roles is getting the quota associated with a
> but there are definitely others that can be added later: what packages has a
> role created?
> How many jobs is a role running? What privileges are associated with a role?
> How much
> system storage is being used by a role? Etc.
> [sun-wukong incubator-aurora (user)]$ ./pants
> Build operating on targets:
> ==================================== test session starts
> platform darwin -- Python 2.7.2 -- pytest-2.5.1
> collected 20 items
> src/test/python/apache/aurora/client/cli/test_create.py ....
> src/test/python/apache/aurora/client/cli/test_status.py .....
> src/test/python/apache/aurora/client/cli/test_diff.py ...
> src/test/python/apache/aurora/client/cli/test_kill.py .....
> src/test/python/apache/aurora/client/cli/test_get_quota.py ...
> ================================= 20 passed in 0.71 seconds
> ..... SUCCESS
> - src/main/python/apache/aurora/client/cli/BUILD
> - src/main/python/apache/aurora/client/cli/__init__.py
> - src/main/python/apache/aurora/client/cli/options.py
> - src/main/python/apache/aurora/client/cli/role.py (PRE-CREATION)
> - src/test/python/apache/aurora/client/cli/BUILD
> - src/test/python/apache/aurora/client/cli/test_get_quota.py
> - src/test/python/apache/aurora/client/cli/util.py
> View Diff <https://reviews.apache.org/r/17332/diff/>