<div dir="ltr">On Fri, Jul 12, 2013 at 11:19 AM, 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"><div class="im">On 07/12/2013 10:36 AM, Jonathan Proulx wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I need one set of nodes to schedule with a 1:1 physical:virtual ratio,<br>
an other using an over committed ratio (I'm thinking 8:1 in my<br>
environment) and in a perfect world a third that does bare metal<br>
provisioning both for TripleO purposes and for providing other baremetal<br>
systems directly to my user base.  Each would need it's own set of quotas.<br>
</blockquote>
<br></div>
It is that last requirement -- having separate quotas -- that makes both cells and host aggregates inappropriate here. Neither cells nor host aggregates allow you to manage quotas separate from the tenant's compute quotas.</blockquote>
<div><br></div><div>Ouch, I really though I was going to get that one.  <br><br></div><div>This deployment is in a research lab and we don't have any internal billing mechanisms for compute resources.  In a more commercial use case I could just bill more for the more valuable resources, and likely not worry so much about quotas, hmmm...<br>
</div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think host aggregates is the way to go here, not cells, unless you are trying to solve scaling issues (doesn't sound like that's the case). But in either case, you will need to give up on the separate quota requirement -- either that, or create an entirely separate deployment zone for each of your "types" of nodes. That will give you per-type quotas (because each deployment zone would have a separate nova database and associated quota data set. But at that point, I'll welcome you to the wonderful world of shared identity and image databases :)<br>
</blockquote><div><br></div><div>No I'm not trying to solve scaling, I have one rack with 768 cores (double that virtually with HT) I'd like multiply that by 3 or 5 in the near (12months?) future but even at that I don't think I'm pushing any current scaling boundaries. <br>
<br></div><div>I've looked at host aggregates and I like their simplicity, but there doesn't seem to be a direct way to have a different cpu_allocation_ratio per node or compute_fill_first_cost_fn_weight (for 1:1 nodes I want to fill depth first so big chunks are available for big flavors, but for 8:1 nodes I wand to fill breadth first to reduce likely contention).<br>
<br></div><div>If I can't get my pony without making a bunch of independent deployments then using magic to glue them back together, I can probably solve at least the cpu_allocation_ratio by replacing the scheduler CoreFilter presumably I could also hack  nova.scheduler.least_cost.compute_fill_first_cost_fn <br>
<br></div><div>-Jon<br></div></div></div></div>