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 .
- 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
- 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 
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
 – http://bit.ly/2979tQl
 – http://bit.ly/1ZywA8U