Jump to: navigation, search

Meetings/KeystoneMeeting

< Meetings
Revision as of 20:50, 1 January 2015 by Blk-u (talk | contribs) (Review of Keystone Blueprints for No-Spec Requires Status)

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!).

  • Assignments Split henry-nash, 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 My First ABAC. The key file to look at is its 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.
    • Is 'resource' the right name for where the projects and domains are split off to?
      • '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
  • Domain-roles....separate API or overload the existing roles API? Proposed Domain Role API henry-nash

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!).

[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)

Previous meetings

Logs and meeting summaries of previous meetings are located here.