OpenStack Developer Mailing List Digest June 18-24

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 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
    • 1 project
  • Full thread

[1] –

[2] –

Leave a Reply

Your email address will not be published. Required fields are marked *