[openstack-dev] [oslo] PTG wrapup

Ben Nemec openstack at nemebean.com
Fri Sep 28 22:05:48 UTC 2018


A bit belated, but here goes:

Monday:
Had a good discussion in the Keystone room about oslo.limit with some 
Nova developers. There was quite a bit of discussion around how the 
callbacks should work for resource usage and cleanup, and the Nova 
developers took an action to do some prototyping. Also, there was 
general consensus in the room that user quotas were probably a thing 
that should go away and we didn't want to spend a lot of time trying to 
accommodate them. If you have a different viewpoint on that please let 
someone involved with this know ASAP.

In addition, for the first time the topic of how to migrate from 
project-specific quota code to oslo.limit got some serious discussion. 
The current proposal is to have projects support both methods for a 
cycle to allow migration of the data. A Nova spec is planned to detail 
how that will work.

https://etherpad.openstack.org/p/keystone-stein-unified-limits

In the afternoon there was also a productive discussion in the API sig 
room about the healthcheck middleware. Initially it was a lot of "we 
want this, but no one has time to work on it", but after some more 
digging into the existing oslo.middleware code it was determined that we 
might be able to reuse parts of that to reduce the amount of work needed 
to implement it. This also makes it an easier sell to projects since 
many already include the old healthcheck middleware and this would be an 
extension of it. Graham was going to hack on the implementation in his 
PTG downtime.

https://etherpad.openstack.org/p/api-sig-stein-ptg

Tuesday:
Our scheduled session day. The main points of the discussion were 
(hopefully) captured in 
https://etherpad.openstack.org/p/oslo-stein-ptg-planning

Highlights:
-The oslo.config driver work is continuing. One outcome of the 
discussion was that we decided to continue to defer the question of how 
to handle mutable config with drivers. If somebody asks for it then we 
can revisit.

-There was general agreement to proceed with the simple config 
validator: https://review.openstack.org/#/c/567950/ There is a 
significantly more complex version of that review out there as well, but 
it's so large that nobody has had time to review it. The plan is that 
the added features from that can be added to this simple version in 
easier-to-digest pieces once the base functionality is there.

-The config migration tool is awaiting reviews (I see Doug reviewed it 
today, thanks!), and then will proceed with phase 2 in which it will try 
to handle more complex migrations.

-oslo.upgradecheck is now a thing. If you don't know what that is, see 
Matt Riedemann's email updates on the upgrade checkers goal.

-There was some extensive discussion around how to add parallel 
processing to oslo.privsep. The main outcomes were that we needed to get 
rid of the eventlet dependency from the initial implementation, but we 
think the rest of the code should already deal with concurrent execution 
as expected. However, as we are still lacking deep expertise in 
oslo.privsep since Gus left (help wanted!), it is TBD whether we are 
right. :-)

-A pluggable policy spec and some initial patches are proposed and need 
reviews. One of these days I will have time to do that.

Wednesday:
Had a good discussion about migrating Oslo to Storyboard. As you may 
have noticed, that discussion has continued on the mailing list so check 
out the [storyboard] tagged threads for details on where that stands. If 
you want to kick the tires of the test import you can do so here: 
https://storyboard-dev.openstack.org/#!/story/list?project_group_id=74

Thursday:
Discussion in the TripleO room about integrating the config drivers 
work. It sounded like they had a plan to implement support for them when 
they are available, so \o/.

Friday:
Mostly continued work on oslo.upgradecheck in between some non-Oslo 
discussions.

I think that's it. If I missed anything or you have questions/comments 
feel free to reply.

Thanks.

-Ben



More information about the OpenStack-dev mailing list