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.
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
Please add agenda items to the bottom of this section's list (be sure to include your
- 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?
- I have a bug fix that I want to land between now and release of Liberty (see: https://review.openstack.org/#/c/191976/), 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.DomainConfigV9) and then make this the default driver to load? I then also add a naive implementation to the old V8 driver (as per the instructions in developing_drivers.rst)
- What happens about the manage legacy loading statement in reasource/core.py? Do I update this like I have done?
- 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 (
- Proposed change to ksc: https://review.openstack.org/#/c/220736/
- backwards-incompatible change somewhere?
- Gate keystoneclient on keystonemiddleware unit tests?
- python-keystoneclient uses socket attributes that do not exist in Windows (
- socket.TCP_KEEPCNT and socket.KEEPINTVL do not exist in windows.
- because of this, the nova-compute service running on Hyper-V is not able to create instances.
- issue has been hiting Hyper-V CI: http://188.8.131.52/128940/76/Hyper-V_logs/hv-compute1/nova-compute.log.gz
- proposed partial fix: https://review.openstack.org/#/c/211686/
- creating instances on Hyper-V is possible using the proposed fix.
- Keystoneclient v2 branch
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
Keystone Weekly Bug Reports
Bugs for the various Keystone repositories are collects and published to the following links. (
Logs and meeting summaries of previous meetings are located here.