[keystone][oslo] oslo.limt implementation update
Today in keystone's office hours, we went through a group code review of what's currently proposed for the oslo.limit library [0]. This is a summary of the action items that came out of that meeting. * We should implement a basic functional testing framework that exercises keystoneauth connections (used for pulling limit information for keystone). Otherwise, we'll be mocking things left and right in unit tests to get decent test coverage with the current keystoneauth code. * Investigate alternatives to globals for keystoneauth connections [1]. * Investigate adopting a keystoneauth-like way of loading enforcement models (similar to how ksa loads authentication plugins) [2]. * Figure out if we want to use endpoint_id or service name + region name for service configuration [3]. * Build out functional testing for flat enforcement * Implement strict-two-level enforcement model This existing rewrite was mostly stolen from John's patches to his fork oslo.limit [4]. Hopefully the current series moves things in that direction. Feel free to chime in if you have additional notes or comments. Lance [0] https://review.opendev.org/#/q/topic:rewrite+(status:open+OR+status:merged)+... [1] https://bugs.launchpad.net/oslo.limit/+bug/1835103 [2] https://bugs.launchpad.net/oslo.limit/+bug/1835104 [3] https://bugs.launchpad.net/oslo.limit/+bug/1835106 [4] https://github.com/JohnGarbutt/oslo.limit/commit/a5b908046fd904c25b6cd15c652...
I forgot to add that the meeting was held in IRC. Logs are available if you're interested in following along [0]. [0] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-ke... On 7/2/19 2:34 PM, Lance Bragstad wrote:
Today in keystone's office hours, we went through a group code review of what's currently proposed for the oslo.limit library [0]. This is a summary of the action items that came out of that meeting.
* We should implement a basic functional testing framework that exercises keystoneauth connections (used for pulling limit information for keystone). Otherwise, we'll be mocking things left and right in unit tests to get decent test coverage with the current keystoneauth code. * Investigate alternatives to globals for keystoneauth connections [1]. * Investigate adopting a keystoneauth-like way of loading enforcement models (similar to how ksa loads authentication plugins) [2]. * Figure out if we want to use endpoint_id or service name + region name for service configuration [3]. * Build out functional testing for flat enforcement * Implement strict-two-level enforcement model
This existing rewrite was mostly stolen from John's patches to his fork oslo.limit [4]. Hopefully the current series moves things in that direction.
Feel free to chime in if you have additional notes or comments.
Lance
[0] https://review.opendev.org/#/q/topic:rewrite+(status:open+OR+status:merged)+... [1] https://bugs.launchpad.net/oslo.limit/+bug/1835103 [2] https://bugs.launchpad.net/oslo.limit/+bug/1835104 [3] https://bugs.launchpad.net/oslo.limit/+bug/1835106 [4] https://github.com/JohnGarbutt/oslo.limit/commit/a5b908046fd904c25b6cd15c652...
* We should implement a basic functional testing framework that exercises keystoneauth connections (used for pulling limit information for keystone). Otherwise, we'll be mocking things left and right in unit tests to get decent test coverage with the current keystoneauth code.
I would be not at all offended if functional test fixtures for ksa artifacts were made generally available. efried .
participants (2)
-
Eric Fried
-
Lance Bragstad