Jump to: navigation, search


< Meetings
Revision as of 13:45, 8 September 2015 by Blk-u (talk | contribs) (Main Agenda)

Weekly Keystone team meeting

If you're interested in identity, authentication, authorization, and/or policy 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:

ajayaa, amakarov, ayoung, breton, browne, davechen, david8hu, dolphm, dstanek, ericksonsantos, geoffarnold, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, lbragstad, lhcheng, marekd, morganfainberg, nkinder, raildo, rharwood, rodrigods, roxanaghe, samueldmq, stevemar, tsymanczyk, topol, vivekd, wanghong, claudiub

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

  • 2015-09-08
    • Keystoneclient v2 branch
      • keystoneclient has the keystoneauth_integration branch. This was for testing having our current (1.x) keystoneclient consuming keystoneauth. Later it was decided that keystoneclient 1.x would never consume keystoneauth and we would make a big break for keystoneclient 2. We never renamed the branch because there were Zuul exemptions based on the branch name to get around keystoneauth not being in global-requirements.
      • Propose we delete the keystoneauth_integration branch. Everything that has merged so far was trying to maintain an API we won't keep in v2 or trying to keep the patches in sync from master: https://review.openstack.org/#/q/status:merged+project:openstack/python-keystoneclient+branch:feature/keystoneauth_integration,n,z
      • Create new v2 branch of keystoneclient from master. Won't need the zuul exemption because keystoneauth is in global requirements.
    • Changing driver version numbers....looking for guidance on how this should work? henrynash
      • I have a bug fix that I want to land between now and release of Liberty that requires a driver change for domain_config. First off, is this allowed?
      • Irrespective of when we do this, it's not really clear how I hook my new driver into the rest of Keystone...I'm assuming we rename the driver in the backend (e.g. in this case resource.config_backend.sql.DomainConfigV9) and then make this the default driver to load? Here's my first attempt: https://review.openstack.org/#/c/191976/. But I'm not sure this is stevedore friendly - since we have both v8 and v9 entry points in the driver. Are we meant to version the file itself? i.e. have sql9.py? I am assuming the whole point is that an external developer can substitute their driver with simply a config change directing it to be loaded?
      • I then also added a naive implementation to the old V8 driver (as per the instructions in developing_drivers.rst) - is this what we envisaged?
      • What happens about the manage legacy loading statement in reasource/core.py? Does this just stay as is (not quite sure how this gets used)?
      • I assume I need to add testing with the old (v8) driver to make sure they naive implementation does something sensible?
    • keystonemiddleware tests broken by keystoneclient release (bknudson)
    • python-keystoneclient uses socket attributes that do not exist in Windows (claudiub)
    • Policies (samueldmq)
      • Implementation status
      • FFE vs Postpone
        • The former implies in the need of core-team members to signup for review
    • Reseller (htruta, henrynash)
      • FFE vs Postpone
        • Maybe cut at nth patch

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

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.