Revision as of 16:19, 6 January 2015

Weekly Keystone team meeting

If you're interested in identity for OpenStack, we hold public meetings weekly on IRC in #openstack-meeting, on Tuesdays at 18:00 UTC. Please feel free to add items to the agenda below with your name and we'll cover them.

Regular attendees

Add yourself to this list to be pinged prior to each meeting:

dolphm, ayoung, bknudson, dstanek, jamielennox, morganfainberg, stevemar, gyee, henrynash, topol, marekd, lbragstad, joesavak, shardy, fabiog, nkinder, lloydm, shrekuma, ksavich, hrybacki, rharwood, grantbow, vdreamarkitex, raildo, rodrigods, amakarov, ajayaa, hogepodge, breton, lhcheng, nonameentername, samuelms, htruta, amolock

Agenda for next meeting

Main Agenda

Please add agenda items to the bottom of this section's list (be sure to include your irc_handle!).

(for info only) Assignments Split henry-nash, two items:
- As requested, the patch has been split up into multiple simpler changes, starting at: https://review.openstack.org/#/c/144239/
- No new alternatives to 'resource' have been suggested (with 'projects' remaining the only other suggestion, on the basis that one day domains will not be separate entities pr moved elsewhere. The issue for me with is that until that actually happens "self.project_api.list_domains()" seems odd! Maybe once the future of domains is settled we can rename resources->projects)
Migration path for R/W LDAP spec jorge_munoz

Review of Keystone Blueprints for No-Spec Requires Status

Please add BPs to the bottom of this sections list that should be reviewed as not requiring a spec (include your irc_handle!).

refactor keystone-all and http/keystone - https://review.openstack.org/#/c/62275/ - bknudson
refactoring keystonemiddleware to extract classes - https://review.openstack.org/#/c/102403/ , etc. - bknudson
Avoid multiple instances for a provider - https://review.openstack.org/#/c/124599/ - bknudson
Prefer internal notifications - https://review.openstack.org/#/c/125521/ - bknudson
Move eventlet server options to a config section - https://review.openstack.org/#/c/130962/ - bknudson
Change keystone's keystoneclient tests to use venv-installed rather than git - https://review.openstack.org/#/c/136636/ - bknudson
auth-token-use-client - https://review.openstack.org/#/q/status:open+branch:master+topic:bp/auth-token-use-client,n,z - bknudson
Use RequestBodySizeLimiter from oslo.middleware - https://review.openstack.org/#/c/144697/ - bknudson

[Pending details on what constitutes a typical "no-spec BP"' go here']

Keystone Weekly Bug Reports

Bugs for the various Keystone repositories are collects and published to the following links. (lbragstad)

Keystone Weekly Bug Report

Previous meetings

Logs and meeting summaries of previous meetings are located here.

@@ Line 13: / Line 13: @@
 ==== Main Agenda ====
 Please add agenda items to the bottom of this section's list (be sure to include your <code>irc_handle</code>!).
-* [https://review.openstack.org/#/c/130954/ Assignments Split] <code>henry-nash</code>, two items:
+* (for info only) [https://review.openstack.org/#/c/130954/ Assignments Split] <code>henry-nash</code>, two items:
-** Are we OK with role management being placed in its own backend (within the assignments umbrella) as per the current patch? To aid this discussion, a simple alternate assignments engine has been provided that shows these of the new split [https://review.openstack.org/143557 My First ABAC]. The key file to look at is its [https://review.openstack.org/#/c/143557/2/keystone/contrib/myfirstabac/backends/sql.py new assignment driver], which replaces the existing one. Note how the new split allows this to happen easily, and how the fact that role management is in its own backend makes this simpler.
+** As requested, the patch has been split up into multiple simpler changes, starting at: https://review.openstack.org/#/c/144239/
-** Is 'resource' the right name for where the projects and domains are split off to?
+** No new alternatives to 'resource' have been suggested (with 'projects' remaining the only other suggestion, on the basis that one day domains will not be separate entities pr moved elsewhere.  The issue for me with is that until that actually happens "self.project_api.list_domains()" seems odd! Maybe once the future of domains is settled we can rename resources->projects)
-*** 'Resource' was the least-worst we could come up with in the spec and was approved (it borrows the term from federation protocols where "resource" is the object you get access to)
-*** An alternative might be simply "projects", even though domains are included in the same backend...on the basis that domains are going to become just a special attribute of a project
-* [https://review.openstack.org/#/c/133855 Domain-roles]....separate API or overload the existing roles API? [https://review.openstack.org/#/c/139531 Proposed Domain Role API] <code>henry-nash</code>
 * Migration path for [https://review.openstack.org/#/c/140175/ R/W LDAP spec] <code>jorge_munoz</code>

Difference between revisions of "Meetings/KeystoneMeeting"