<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 31, 2018 at 12:22 PM, Dmitry Tantsur <span dir="ltr"><<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 01/31/2018 06:15 PM, Matt Riedemann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 1/30/2018 9:33 AM, Colleen Murphy wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At the last PTG we had some time on Monday and Tuesday for<br>
cross-project discussions related to baremetal and VM management. We<br>
don't currently have that on the schedule for this PTG. There is still<br>
some free time available that we can ask for[1]. Should we try to<br>
schedule some time for this?<br>
<br>
 From a keystone perspective, some things we'd like to talk about with<br>
the BM/VM teams are:<br>
<br>
- Unified limits[2]: we now have a basic REST API for registering<br>
limits in keystone. Next steps are building out libraries that can<br>
consume this API and calculate quota usage and limit allocation, and<br>
developing models for quotas in project hierarchies. Input from other<br>
projects is essential here.<br>
- RBAC: we've introduced "system scope"[3] to fix the admin-ness<br>
problem, and we'd like to guide other projects through the migration.<br>
- Application credentials[4]: this main part of this work is largely<br>
done, next steps are implementing better access control for it, which<br>
is largely just a keystone team problem but we could also use this<br>
time for feedback on the implementation so far<br>
<br>
There's likely some non-keystone-related things that might be at home<br>
in a dedicated BM/VM room too. Do we want to have a dedicated day or<br>
two for these projects? Or perhaps not dedicated days, but<br>
planned-in-advance meeting time? Or should we wait and schedule it<br>
ad-hoc if we feel like we need it?<br>
<br>
Colleen<br>
<br>
[1] <a href="https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true" rel="noreferrer" target="_blank">https://docs.google.com/spread<wbr>sheets/d/e/2PACX-1vRmqAAQZA1rI<wbr>zlNJpVp-X60-z6jMn_<wbr>95BKWtf0csGT9LkDharY-mppI25Kji<wbr>uRasmK413MxXcoSU7ki/pubhtml?<wbr>gid=1374855307&single=true</a> <br>
[2] <a href="http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html" rel="noreferrer" target="_blank">http://specs.openstack.org/ope<wbr>nstack/keystone-specs/specs/<wbr>keystone/queens/limits-api.<wbr>html</a> <br>
[3] <a href="http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html" rel="noreferrer" target="_blank">http://specs.openstack.org/ope<wbr>nstack/keystone-specs/specs/<wbr>keystone/queens/system-scope.<wbr>html</a> <br>
[4] <a href="http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.html" rel="noreferrer" target="_blank">http://specs.openstack.org/ope<wbr>nstack/keystone-specs/specs/<wbr>keystone/queens/application-<wbr>credentials.html</a> <br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</blockquote>
<br>
These all seem like good topics for big cross-project issues.<br>
<br>
I've never liked the "BM/VM" platform naming thing, it seems to imply that the only things one needs to care about for these discussions is if they work on or use nova and ironic, and that's generally not the case.<br>
</blockquote>
<br></div></div>
++ can we please rename it? I think people (myself included) will expect specifically something related to bare metal instances co-existing with virtual ones (e.g. scheduling or networking concerns). Which is also a great topic, but it does not seem to be present on the list.</blockquote><div><br></div><div>Fair point. When the "VM/baremetal workgroup" was originally formed,</div><div>the goal was more about building clouds with both types of resources,</div><div>making them behave similarly from a user perspective, etc. Somehow</div><div>we got into talking applications and these other topics came up, which</div><div>seemed more interesting/pressing to fix. :)</div><div><br></div><div>Maybe "cross-project identity integration" or something is a better name?</div><div><br></div><div>// jim</div></div></div></div>