> On Sept. 3, 2015, 1:27 a.m., Suman Karumuri wrote:
> > api/src/main/thrift/org/apache/aurora/gen/api.thrift, line 369
> > <https://reviews.apache.org/r/38081/diff/1/?file=1062906#file1062906line369>
> >
> >     I think it will be better if we split this into 
> > nonProdSharedConsumption and nonProdDedicatedConsumption.
> 
> Maxim Khutornenko wrote:
>     This may be an option to consider in future but it does not fit the scope 
> of this change.
> 
> Suman Karumuri wrote:
>     Is there a strong reason, not to split the non prod consumption into 
> shared and dedicated pools since we already do it for prod jobs? I think we 
> should expose this info now when we are making the split between dedicated 
> and shared pool. Delaying it will involve a lot more effort later. If we 
> choose not to expose this infortion separately in the UI, the UI can add up 
> nonProdDedicatedConsumption and nonProdSharedPoolConsumption into the same 
> field. But going the other way around would be a lot more work. 
>     
>     I also feel we should decide on the UI design now and implement the API 
> accordingly.
> 
> Maxim Khutornenko wrote:
>     | Is there a strong reason, not to split the non prod consumption into 
> shared and dedicated pools since we already do it for prod jobs?
>     
>     I just don't want to increase the size of this diff and add changes 
> irrelevant to the subject matter. I am open to consider adding it separately.
>     
>     Also, the approach of adding prod/non-prod dedicated consumption does not 
> scale given our upcoming migration to task tiers. There is a good chance this 
> structure will have to be dropped entirely in favor of something like this 
> (just to illustrate the direction):
>     ```
>     struct TierResources {
>       1: string taskTier
>       2: ResourceAggregate quota
>       3: ResourceAggregate consumption
>     }
>     
>     struct GetQuotaResultNew {
>       1: map<string, TierResources> resourcesByTier
>     }
>     ```
>     
>     In the above example, a "non-prod dedicated" could be a completely 
> separate tier (though does not have to be). This is the reason I was 
> hesistant adding prod/nonprod consumption split in the first place, hence my 
> comment in the description. I wonder what others think?
>     
>     | But going the other way around would be a lot more work. I also feel we 
> should decide on the UI design now and implement the API accordingly.
>     
>     I don't buy this argument. There is nothing preventing us from 
> implementing the UI the way we want and iterate accordingly.
> 
> Zameer Manji wrote:
>     Maxim,
>     
>     Is this possible change tracked apart of the tier work? If not, I really 
> think a ticket for this should be created so we don't forget about this.
> 
> Suman Karumuri wrote:
>     Thanks for the explanation. I like the TieredResources struct approach. 
> As a service owner though, I would like to see non-prod dedicated consumption 
> and prod dedicated consumption. That would clearly tell me the amount of 
> resources I am using for prod and non-prod.
>     
>     +1 for tracking this in a ticket as part of task tiers implementation.

Thought about this a bit more and I think it makes sense to get it in within 
the scope of this ticket. The GetQuotaResult is subject to deprecation anyway 
and we are not gaining much by limiting changes to it.

Also, I will delay comitting this change until the UI part is ready. Otherwise, 
a sudden drop in prod consumption in the UI could be an unexpected surprise.


- Maxim


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


On Sept. 3, 2015, 12:46 a.m., Maxim Khutornenko wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38081/
> -----------------------------------------------------------
> 
> (Updated Sept. 3, 2015, 12:46 a.m.)
> 
> 
> Review request for Aurora, Joshua Cohen, Bill Farner, and Zameer Manji.
> 
> 
> Bugs: AURORA-1460
>     https://issues.apache.org/jira/browse/AURORA-1460
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> This change drops quota enforcement for dedicated jobs and adds dedicated 
> resource consumption into the thrift API. Feel free to pushback on the latter 
> but I think users will find it immediately confusing when we change the "Prod 
> consumption" to something like "Prod shared pool consumption" in the 
> UI/client and not provide the missing dedicated rollup numbers.
> 
> 
> Diffs
> -----
> 
>   api/src/main/thrift/org/apache/aurora/gen/api.thrift 
> 21137bbbdc3010c6b1e2cc0ebb3b99bfa8490563 
>   src/main/java/org/apache/aurora/scheduler/quota/QuotaInfo.java 
> b40ecd0af7c1d1bb9372bd89c741622ce4c9040c 
>   src/main/java/org/apache/aurora/scheduler/quota/QuotaManager.java 
> 8787aeaa6655cfab1e0a6d5719f9e08a89df7631 
>   src/main/java/org/apache/aurora/scheduler/thrift/ReadOnlySchedulerImpl.java 
> 3d89e43659750de63d7588f8574e7a350caea04b 
>   src/main/python/apache/aurora/client/api/quota_check.py 
> 75406ac1d3ec9ba655daf7c6125f208f74290cfb 
>   src/main/python/apache/aurora/client/cli/quota.py 
> e8aa010f5ecce0464a8ad6b072bccba589fe16d7 
>   src/main/resources/scheduler/assets/js/controllers.js 
> 98920196db34f2eb4dcad93429274517e7383efe 
>   src/test/java/org/apache/aurora/scheduler/quota/QuotaManagerImplTest.java 
> db60cd21d06d636505202bac7277a13dc24d46e6 
>   
> src/test/java/org/apache/aurora/scheduler/thrift/ReadOnlySchedulerImplTest.java
>  4d4e752088f7dca99675cc66782ae046bbd516d6 
>   src/test/python/apache/aurora/admin/test_admin.py 
> d793293acc7f77c0081968334c38b984d865fbc8 
>   src/test/python/apache/aurora/client/api/test_quota_check.py 
> 6c9bc373d1868bd6e0cae2f2218261f39fd7ab8f 
>   src/test/python/apache/aurora/client/cli/test_quota.py 
> 3573e4c4575577e2232d2b99ca781b06a03d48d7 
> 
> Diff: https://reviews.apache.org/r/38081/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Maxim Khutornenko
> 
>

Reply via email to