<div dir="ltr">On Fri, Jul 12, 2013 at 2:43 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Really interesting solution, Chris. Thanks for sharing! I had not thought of that, but it certainly makes sense on paper.<br>

<br>
Best,<br>
-jay<br>
<br>
On 07/12/2013 02:22 PM, Chris Behrens wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<br>
It was said that your quota issue is not solved by cells… but I'm not<br>
actually sure that is true.  This is certainly not the normal way I<br>
would configure cells, but I suppose it's possible to do this:<br>
<br>
1) Use the NoopQuotaDriver in your API cell.<br>
2) Use the normal DbQuotaDriver in childs cells.<br>
<br></div>
<snip><br><div>
<br>
Anyway, I only recommend trying this if you want to live slightly<br>
dangerously. :)<br>
<br></div></blockquote></blockquote><div><br></div><div>I can take some danger (cells are still documented as "experimental"), and this is academia over here. <br><br></div>The quotas in the child cells would be invisible to tenants, wouldn't they? This is somewhat less than ideal.<br>
<br></div><div class="gmail_quote">Given what I'm hearing, my current thought is to use host aggregates with aggregate specific flavors and a custom scheduler filter that gets cpu_allocation_ratio and ram_allocation_ratio from aggregate metadata and uses the regular conf values as defaults.  <br>
<br></div><div class="gmail_quote">That gets me most of the way.  Haven't looked at the code for this part but hopefully a similar bit of custom coding can get me compute_fill_first_cost_fn_weight as a aggregate settable value rather than a global value.<br>
<br></div><div class="gmail_quote">Making the huge leap of faith that that all works, it leaves quota.  Everything here feels kludgy, but simplest kludge that comes to mind is forcing different tenants for each "value" or resource, which can then have different quotas and using flavor-access list to restrict high value flavors.  <br>
<br>This is a little bumpy on the user end but perhaps livable, and discourages using the high value systems which is OK given my nonexistent revenue model. Given physical and 1:1 virtualised systems have essentially the same value per resource unit to me, I's only need 2 value levels which I think would work though I don't think it would go much past that.  For example adding baremetal with GPUs as the 3rd value level and set of tenants would probably be too much.<br>
<br></div><div class="gmail_quote">Guess it's time to make some PoC systems and see what catches fire and what doesn't.<br><br></div><div class="gmail_quote">Thanks,<br></div><div class="gmail_quote">-Jon<br></div>
</div></div>