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