SuccessBot Says
mriedem: We’re now running neutron by default in Ocata CI jobs [1].
stevemar: fernet token format is now the default format in keystone! thanks lbragstad samueldmq and dolphm for making this happen!
Ajaegar: developer.openstack.org is now hosted by OpenStack infra.
Tonyb: OpenStack requirements on pypi [2] is now a thing!
All
Registration Open For the Project Teams Gathering
The first OpenStack Project Teams Gathering event geared toward existing upstream team members, providing a venue for those project teams to meet, discuss and organize the development work for the Pike release.
Where: Atlanta, GA
When: The week of February 20, 2017
Register and get more info [3]
Read the FAQ for any questions. If you still have questions, contact Thierry (ttx) over IRC on free node, or email foundation staff at ptg@openstack.org.
Full thread
Follow up on Barcelona Review Cadence Discussions
Summary of concerns were Nova is a complex beast. Very few people know even most of it well.
There are areas in Nova where mistakes are costly and hard to rectify later.
Large amount of code does not merge quickly.
Barrier of entry for Nova core is very high.
Subsystem maintainer model has been pitched [4].
Some believe this is still worth giving a try again in attempt to merge good code quickly.
Nova today uses a list of experts [5] to sign off on various changes today.
Nova PTL Matt Riedemann’s take:
Dislikes the constant comparison of Nova and the Linux kernel. Lets instead say all of OpenStack is the Linux Kernel, and the subsystems are Nova, Cinder, Glance, etc.
The bar for Nova core isn’t as high as some people make it out to be:
Involvement
Maintenance
Willingness to own and fix problems.
Helpful code reviews.
Good code is subjective. A worthwhile and useful change might actually break some other part of the system.
Nova core Jay Pipes is supportive of the proposal of subsystems, but with a commitment to gathering data about total review load, merge velocity, and some kind of metric to assess code quality impact.
Full thread
Embracing New Languages in OpenStack
Technical Committee member Flavio Percoco proposes a list of what the community should know/do before accepting a new language:
Define a way to share code/libraries for projects using the language
A very important piece is feature parity on the operator.
Oslo.config for example, our config files shouldn’t change because of a different implementation language.
Keystone auth to drive more service-service interactions through the catalog to reduce the number of things an operator needs to configure directly.
oslo.log so the logging is routed to the same places and same format as other things.
oslo.messaging and oslo.db as well
Work on a basic set of libraries for OpenStack base services
Define how the deliverables are distributed
Define how stable maintenance will work
Setup the CI pipelines for the new language
Requirements management and caching/mirroring for the gate.
Longer version of this [6].
Previous notes when the Golang discussion was started to work out questions [7].
TC member Thierry Carrez says the most important in introducing the Go should not another way for some of our community to be different, but another way for our community to be one.
TC member Flavio Percoco sees part of the community wide concerns that were raised originated from the lack of an actual process of this evaluation to be done and the lack of up front work, which is something trying to be addressed in this thread.
TC member Doug Hellmann request has been to demonstrate not just that Swift needs Go, but that Swift is willing to help the rest of the community in the adoption.
Signs of that is happening, for example discussion about how oslo.config can be used in the current version of Swift.
Flavio has started a patch that documents his post and the feedback from the thread [8]
Full thread
API Working Group News
Guidelines that have been recently merged:
Clarify why CRUD is not a great descriptor [9]
Add guidelines for complex queries [10]
Specify time intervals based filtering queries [11]
Guidelines currently under review:
Define pagination guidelines [12]
WIP add API capabilities discovery guideline [13]
Add the operator for “not in” to the filter guideline [14]
Full thread
OakTree – A Friendly End-user Oriented API Layer
The OpenStack summit results of the Interop Challenge shown on stage was awesome. 17 different people from 17 different clouds ran the same workload!
One of the reasons it worked is because they all used the Ansible modules we wrote based on the Shade library.
Shade contains business logic needed to hide vendor difference in clouds.
This means that there is a fantastic OpenStack interoperability story &8211; but only if you program in Python.
OakTree is a gRPC-based APO service for OpenStack that is based on the Shade library.
Basing OakTree on Shade gets not only the business logic, Shade understands:
Multi-cloud world
Caching
Batching
Thundering herd protection sorted to handle very high loads efficiently.
The barrier to deployers adding it to their clouds needs to be as low as humanly possible.
Exists in two repositories:
openstack/oaktree [15]
openstack/oaktreemodel [16]
OakTree model contains the Protobuf definitions and build scripts to produce Python, C++ and Go code from them.
OakTree itself depends on python OakTree model and Shade.
It can currently list and search for flavors, images, and floating ips.
A few major things that need good community design listed in the todo.rst [17]
Full thread
Quelle: openstack.org
Published by