<div dir="ltr">
<p class="MsoNormal">Hi Jesse,</p><p class="MsoNormal">I would say that is a documentation bug for the “AggregateMultiTenancyIsolation” filter.</p><p class="MsoNormal"><br></p><p class="MsoNormal">When this was implemented the objective was to schedule only instances from specific tenants for those aggregates but not make them exclusive.</p>
<p class="MsoNormal"><br></p><p class="MsoNormal">That’s why the work on <a href="https://blueprints.launchpad.net/nova/+spec/multi-tenancy-isolation-only-aggregates">https://blueprints.launchpad.net/nova/+spec/multi-tenancy-isolation-only-aggregates</a> started but was left on hold because it was believed <a href="https://blueprints.launchpad.net/nova/+spec/whole-host-allocation">https://blueprints.launchpad.net/nova/+spec/whole-host-allocation</a> had some similarities and eventually could solve the problem in a more generic way.</p>
<p class="MsoNormal"><br></p><p class="MsoNormal">However p-clouds implementation is marked as “slow progress” and I believe there is no active work at the moment.</p><p class="MsoNormal"><br></p><p class="MsoNormal">Probably is a good time to review the "ProjectsToAggregateFilter" filter again. The implementation and reviews are available at <a href="https://review.openstack.org/#/c/28635/">https://review.openstack.org/#/c/28635/</a></p>
<p class="MsoNormal"><br></p><p class="MsoNormal">One of the problems raised was performance concerns considering the number of DB queries required. However this can be documented if people intend to enable the filter.</p>
<p class="MsoNormal">In the review there was also the discussion about a config option for the old filter.</p><p class="MsoNormal"><br></p><p class="MsoNormal">cheers,</p><p class="MsoNormal">Belmiro</p><p class="MsoNormal">
<br></p><p class="MsoNormal">----------------------------------</p><p class="MsoNormal">Belmiro Moreira</p><p class="MsoNormal">CERN</p><p class="MsoNormal">Email: <a href="mailto:belmiro.moreira@cern.ch">belmiro.moreira@cern.ch</a></p>
<p class="MsoNormal">IRC: belmoreira</p><div><br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 9, 2014 at 1:12 PM, Jesse Pretorius <span dir="ltr"><<a href="mailto:jesse.pretorius@gmail.com" target="_blank">jesse.pretorius@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi everyone,</div><div><br></div><div>We have a need to be able to dedicate a specific host aggregate to a list of tenants/projects. If the aggregate is marked as such, the aggregate may only be used by that specified list of tenants and those tenants may only be scheduled to that aggregate.</div>
<div><br></div><div>The AggregateMultiTenancyIsolation filter almost does what we need - it pushes all new instances created by a specified tenant to the designated aggregate. However, it also seems to still see that aggregate as available for other tenants.</div>
<div><br></div><div>The description in the documentation [1] states: "If a host is in an aggregate that has the metadata key filter_tenant_id it only creates instances from that tenant (or list of tenants)."</div>
<div><br></div><div>This would seem to us either as a code bug, or a documentation bug?</div><div><br></div><div>If the filter is working as intended, then I'd like to propose working on a patch to the filter which has an additional metadata field (something like 'filter_tenant_exclusive') which - when 'true' - will consider the filter_tenant_id list to be the only projects/tenants which may be scheduled onto the host aggregate, and the only host aggregate which the list of projects/tenants which may be scheduled onto.</div>
<div><br></div><div>Note that there has been some similar work done with [2] and [3]. [2] actually works as we expect, but as is noted in the gerrit comments it seems rather wasteful to add a new filter when we could use the existing filter as a base. [3] is a much larger framework to facilitate end-users being able to request a whole host allocation - while this could be a nice addition, it's overkill for what we're looking for. We're happy to facilitate this with a simple admin-only allocation.</div>
<div><br></div><div>So - should I work on a nova-specs proposal for a change, or should I just log a bug against either nova or docs? :) Guidance would be appreciated.</div><div><br></div><div>[1] <a href="http://docs.openstack.org/trunk/config-reference/content/section_compute-scheduler.html" target="_blank">http://docs.openstack.org/trunk/config-reference/content/section_compute-scheduler.html</a><br>
</div><div>[2] <a href="https://blueprints.launchpad.net/nova/+spec/multi-tenancy-isolation-only-aggregates" target="_blank">https://blueprints.launchpad.net/nova/+spec/multi-tenancy-isolation-only-aggregates</a></div><div>
[3] <a href="https://blueprints.launchpad.net/nova/+spec/whole-host-allocation" target="_blank">https://blueprints.launchpad.net/nova/+spec/whole-host-allocation</a></div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>