[openstack-dev] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

Jim Rollenhagen jim at jimrollenhagen.com
Wed Jan 31 20:00:26 UTC 2018


On Wed, Jan 31, 2018 at 12:22 PM, Dmitry Tantsur <dtantsur at redhat.com>
wrote:

> On 01/31/2018 06:15 PM, Matt Riedemann wrote:
>
>> On 1/30/2018 9:33 AM, Colleen Murphy wrote:
>>
>>> At the last PTG we had some time on Monday and Tuesday for
>>> cross-project discussions related to baremetal and VM management. We
>>> don't currently have that on the schedule for this PTG. There is still
>>> some free time available that we can ask for[1]. Should we try to
>>> schedule some time for this?
>>>
>>>  From a keystone perspective, some things we'd like to talk about with
>>> the BM/VM teams are:
>>>
>>> - Unified limits[2]: we now have a basic REST API for registering
>>> limits in keystone. Next steps are building out libraries that can
>>> consume this API and calculate quota usage and limit allocation, and
>>> developing models for quotas in project hierarchies. Input from other
>>> projects is essential here.
>>> - RBAC: we've introduced "system scope"[3] to fix the admin-ness
>>> problem, and we'd like to guide other projects through the migration.
>>> - Application credentials[4]: this main part of this work is largely
>>> done, next steps are implementing better access control for it, which
>>> is largely just a keystone team problem but we could also use this
>>> time for feedback on the implementation so far
>>>
>>> There's likely some non-keystone-related things that might be at home
>>> in a dedicated BM/VM room too. Do we want to have a dedicated day or
>>> two for these projects? Or perhaps not dedicated days, but
>>> planned-in-advance meeting time? Or should we wait and schedule it
>>> ad-hoc if we feel like we need it?
>>>
>>> Colleen
>>>
>>> [1] https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rI
>>> zlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25Kji
>>> uRasmK413MxXcoSU7ki/pubhtml?gid=1374855307&single=true
>>> [2] http://specs.openstack.org/openstack/keystone-specs/specs/
>>> keystone/queens/limits-api.html
>>> [3] http://specs.openstack.org/openstack/keystone-specs/specs/
>>> keystone/queens/system-scope.html
>>> [4] http://specs.openstack.org/openstack/keystone-specs/specs/
>>> keystone/queens/application-credentials.html
>>>
>>> ____________________________________________________________
>>> ______________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> These all seem like good topics for big cross-project issues.
>>
>> 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.
>>
>
> ++ 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.


Fair point. When the "VM/baremetal workgroup" was originally formed,
the goal was more about building clouds with both types of resources,
making them behave similarly from a user perspective, etc. Somehow
we got into talking applications and these other topics came up, which
seemed more interesting/pressing to fix. :)

Maybe "cross-project identity integration" or something is a better name?

// jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180131/7c1396d4/attachment.html>


More information about the OpenStack-dev mailing list