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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
