The content below is taken from the original (OpenStack Developer Mailing List Digest November 5-18), to continue reading please visit the site. Remember to respect the Author & Copyright.

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 – 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