Open Stack

Howday all,

Since I know not everyone from the oslo community was able to attend the 
austin summit I just wanted to send out *my* version of the oslo 
sessions notes and next steps (others are free/encouraged to respond 
with there own) so that those folks can catch up and/or get up to speed.

Some of the todos were gathered @ 
https://etherpad.openstack.org/p/oslo-newton-things-to-achieve (people 
are encouraged to update this with others if they want).

Monday
------

Live from oslo @ https://www.youtube.com/watch?v=3W-qGnYrpfg

Thanks to all the oslo folks for doing this one, it was a great recap as 
to what we are working on and the improvements done in mitaka.

Tuesday
-------

N/A wasn't any oslo sessions on this day but there was a bunch of 
cross-project sessions which were/can be deemed relevant (especially the 
ones around rootwrap and privsep, oslo.policy, secure messaging, quota 
library and backwards compat).

https://wiki.openstack.org/wiki/Design_Summit/Newton/Etherpads#Cross-Project_workshops 


Wednesday
---------

Mutable config progress + mutable logging + mutable
***************************************************

Etherpad @ https://etherpad.openstack.org/p/newton-oslo-mutables

Notes/todos:

- Desire to create a simple logging config like 'json' that will when 
set apply the various related settings so that it becomes much easier to 
use the json formatter. This also should allow for setting 'fluent' or 
'color' (with integration into devstack that uses this, so that devstack 
can remove a bunch of its color customizations).

- Docs needed that explain how mutable logging will be used, and 
examples of how to use it with a existing project (for operators)

- Review needed @ https://review.openstack.org/#/c/263312/ so that the 
mutable options will be reloaded, please help as able!

- Agreement was made that we should highly avoid any kind of 
`log_config_append` mutation due to complexity of doing this correctly 
(unless this can be proven to be a safe and simple change).

Oslo.policy so that it reads default policies embedded in project code
**********************************************************************

Etherpad @ 
https://etherpad.openstack.org/p/newton-oslo-policy-default-embedded

Notes: this mostly overlapped with the cross project sessions and alaski 
was unable to show up with-in this session (I was also doing a speaker 
presentation), so looking over the above etherpad for details (others 
who were in attendance might have recorded others details).

Change oslo.policy to support YAML
**********************************

Etherpad @ https://etherpad.openstack.org/p/newton-oslo-policy-yaml-support

Notes: since this code has merged (and is on its way to being released) 
this was more of session regarding how we make sure that the docs team 
knows about the change, and small tweaks we need to make in the 
oslo.policy code to make this process easier for operators to move to.

Things to do:

- We as a group need to make sure we engage the docs team, and engage 
projects to actively convert them to yaml
- Also we as a group agreed that this change should block (part of?) the 
change for policy generation in code so that the policy generation in 
code does not create json files which we then must convert back to yaml.

Thursday
--------

Updates on oslo.messaging drivers
*********************************

Etherpad @ https://etherpad.openstack.org/p/newton-oslo-messaging-drivers

Notes: a good overview of all the drivers, there current state and where 
to go next (see etherpad); no additional notes created (besides whats in 
the etherpad). Thanks for those involved (since it was really a bunch of 
smaller updates on each driver).

Things to do:

- Redesign interfaces work (spec needed!)

Finish our python 3 work
************************

Etherpad @ https://etherpad.openstack.org/p/newton-oslo-python-three

Also since michael still brought it up a smaller etherpad @ 
https://etherpad.openstack.org/p/newton-oslo-python-log

Notes: nothing in particular, this has been a reoccurring discussion at 
the prior summits and it seems like we have been doing a pretty good job 
of actually making the work move forward.

Things to do:

- Update needed to 
https://wiki.openstack.org/wiki/Python3#Common_Libraries_.28Oslo_Projects.29 
since it is not 100% accurate
- As a group we need to do better at explaining to folks what is py3 
compat and how they can help (it didn't seem well known that eventlet is 
py3 compat).
- Work on (as a group) getting keystone py3 issues resolved (ldap, 
memcache) so that it can be made to run in py3 without problem (it's an 
important one, being the project called 'keystone')

New libraries
*************

Etherpad @ https://etherpad.openstack.org/p/newton-oslo-maybe-new-libraries

Notes: this mainly turned into a policy adjustment dicussion since there 
wasn't any strong advocate for new libraries (if there are folks that 
want new libraries and they feel it needs to be in oslo, please reach out).

Things to do:

- Formalize the 'new library' template in the etherpad so that folks 
can easily use it to gather feedback on a new library.
- Create through a project retirement policy (something more official 
than tribal knowledge) for things like pylockfile which were adopted but 
are really no longer maintained by the oslo team (the other option is to 
just let the project, like pylockfile, continue to rot on the vine).
- Create a easily useable doc/how-to so that folks with external 
libraries on github can easily have travis-ci test that there library 
continues to work correctly with parts of openstack (this would ensure 
to some degree that new library commits don't break openstack)
- Possibly try out taskflow being a independently released/managed 
library (so that it can move quicker).

Improve oslo libraries adoption
*******************************

Etherpad @ https://etherpad.openstack.org/p/newton-oslo-improve-adoption

Notes: a big thanks to ronald for leading a-lot of this work and 
tracking down the many moving parts to removing pieces of the incubator 
that are still left in various places!

Things to do:

- Work through having a larger team effort to try to piece by piece help 
out ronald in the quest for removing and cleaning up some of the tech 
debt leftover (a sprint or two perhaps?)
- Consistency around oslo configuration generation; it was noted (using 
glance as an example) that at least glance has some configuration files 
in its repo, some are not and there is very little consistency around 
those files (what is generated, what is old/stale, what is not...); 
perhaps a cross-project spec that helps fix this is needed.
- Some way to make oslo configuration show the diffs of config, via some 
programatic interface so that something akin to an errata can be easily 
created (for devs and operators)
- Outreach in general (blogging and such)

Backwards compat. testing strategies
************************************

Etherpad @ 
https://etherpad.openstack.org/p/newton-oslo-backwards-compat-testing

Notes: this was a lively discussion that is being tackled on a different 
thread in the ML, so leaving most of the notes out of here and linking 
to that thread (thanks robert for helping drive this through!) @ 
http://lists.openstack.org/pipermail/openstack-dev/2016-April/093403.html