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

Status of the OpenStack Port to Python 3

• The only projects not ported to Python 3 yet:
  • Nova (76%)
  • Trove (42%)
  • Swift (0%)
• Number of projects already ported:
  • 19 Oslo Libraries
  • 4 development tools
  • 22 OpenStack Clients
  • 6 OpenStack Libraries (os-brick, taskflow, etc)
  • 12 OpenStack services approved by the TC
  • 17 OpenStack services (not approved by the TC)
• Raw total: 80 projects
• Technical Committee member Doug Hellmann would like the community to set a goal for Ocata to have Python 3 functional tests running for all projects.
• Dropping support for Python 2 would be nice, but is a big step and shouldn’t distract from the goals of getting the remaining things to support Python 3.
  • Keep in mind OpenStack on PyPy which is using Python 2.7.
• Full thread

Proposal: Architecture Working Group

• OpenStack is a big system that we have debated what it actually is [1].
• We want to be able to point to something and proud tell people “this is what we designed and implemented.”
  • For individual projects this is possible. Neutron can talk about their agents and drivers. Nova can talk about conductors that handle communication with compute nodes.
  • When we talk about how they interact with each other, it’s a coincidental mash of de-facto standards and specs. They don’t help someone make decisions when refactoring or adding on to the system.
• Oslo and cross-project initiatives have brought some peace and order to implementation, but not the design process.
  • New ideas start largely in the project where they are needed most, and often conflict with similar decisions and ideas in other projects.
  • When things do come to a head these things get done in a piecemeal fashion, where it’s half done here, 1/3 over there, ¼ there, ¾ over there.
  • Maybe nova-compute should be isolated from Nova with an API Nova, Cinder and Neutron can talk to.
  • Maybe we should make the scheduler cross-project aware and capable of scheduling more than just Nova.
  • Maybe experimental groups should look at how some of this functionality could perhaps be delegated to non-OpenStack projects.
• Clint Byrum would like to propose the creation of an Architecture Working Group.
  • A place for architects to share their designs and gain support across projects to move forward and ratify architectural decisions.
  • The group being largely seniors at companies involved and if done correctly can help prioritize this work by advocating for people/fellow engineers to actually make it ‘real’.
• How to get inovlved:
  • Bi-weekly IRC meeting at a time convenient for the most interested individuals.
  • #openstack-architecture channel
  • Collaborate on the openstack-specs repo.
  • Clint is working on a first draft to submit for review next week.
• Full thread

Release Countdown for Week R-15, Jun 20-24

• Focus:
  • Teams should be working on new feature development and bug fixes.
• General Notes:
  • Members of the release team will be traveling next week. This will result in delays in releases. Plan accordingly.
• Release Actions:
  • Official independent projects should file information about historical releases using the openstack/releases repository so the team pages on release.openstack.org are up to date.
  • Review stable/liberity and stable/mitaka branches for needed releases.
• Important Dates:
  • Newton 2 milestone, July 14

  • Newton release schedule [2]

• Full thread

Placement API WSGI Code – Let’s Just Use Flask

• Maybe it’s better to use one of the WSGI frameworks used by the other OpenStack projects, instead of going in a completely new direction.
  • It will easier for other OpenStack contributors to become familiar with the new API placement API endpoint code if it uses Flask.
  • Flask has a very strong community and does stuff well that the OpenStack community could stop worrying about.
• The amount of WSGI glue above Routes/Paste is pretty minimal in comparison to using a full web framework.
  • Template and session handling are things we don’t need. We’re a REST service, not web application.
• Which frameworks are in use in Mitaka:
  • Falcon: 4 projects
  • Custom + routes: 12 projects
  • Pecan: 12 projects
  • Flask: 2 projects
  • web.py: 1 project
• Full thread

[1] – http://bit.ly/2979tQl

[2] – http://bit.ly/1ZywA8U