Difference between revisions of "Oslo"
|Line 53:||Line 53:|
== Principles ==
== Principles ==
Revision as of 09:33, 4 July 2013
The Oslo program produces a set of python libraries containing infrastructure code shared by OpenStack projects. The APIs provided by these libraries should be high quality, stable, consistent and generally useful.
- 1 The Oslo Team
- 2 Libraries
- 3 Principles
- 4 Incubation
- 5 Resources
The Oslo Team
The Oslo program brings together generalist code reviewers and specialist API maintainers. They share a common interest in tackling copy-and-paste technical debt across the OpenStack project.
Generalist Code Reviewers
Oslo's core reviewers take on a generalist role on the project. They are folks with good taste in Python code, provide constructive input in their reviews and make time to review any patches submitted to the project, irrespective of the area which a given patch targets.
Specialist API Maintainers
Each library or incubating API has one or more specialist maintainers who have responsibility for evolving the API in question. They work to ensure the API meets the needs of all OpenStack projects and helps to ensure the APIs are widely adopted across the project, wherever the APIs can reduce duplication of functionality.
Getting in Touch
We use the email@example.com mailing list for discussions and we all hang out on #openstack-dev.
The following libraries are currently published by the Oslo program. Where we felt that a library had real potential for widespread use outside OpenStack, we chose not to include them in the oslo namespace.
oslo.config is a library for parsing configuration files and command line arguments. It is maintained by Mark McLoughlin.
Please file bugs in the oslo project in launchpad.
See this historical blueprint describing the initial requirements for the API.
pbr (or Python Build Reasonableness) is a set of sensible default setuptools behaviours. It is maintained by Monty Taylor.
Please file bugs in the pbr project in launchpad.
hacking is a set of tools for enforcing coding style guidelines. It is maintained by Joe Gordon and Sean Dague.
Please file bugs in the hacking project in launchpad.
The oslo.messaging will provide a messaging API supports RPC and notifications over a number of different messaging transports. It is not yet ready for use. It is maintained by Mark McLoughlin.
This etherpad captures the latest status and background to this project.
oslo.sphinx provides theme and extension support for Sphinx documentation from the OpenStack project. It is maintained by Doug Hellmann.
Please file bugs in the oslo project in launchpad.
APIs included in Oslo should reflect a rough consensus across the project on the requirements and design for that use case. New OpenStack projects should be able to use an Oslo API safe in the knowledge that, by doing so, the project is being a good OpenStack citizen and building upon established best practice.
To that end, we keep a number of principles in mind when designing and evolving Oslo APIs:
- The API should be generally useful and a "good fit" - e.g. it shouldn't encode any assumptions specific to the project it originated from, it should follow a style consistent with other Oslo APIs and should fit generally in a theme like error handling, configuration options, time and date, notifications, WSGI, etc.
- The API should already be in use by a number of OpenStack projects
- There should be a commitment to adopt the API in all other OpenStack projects (where appropriate) and there should be no known major blockers to that adoption
- The API should represents the "rough consensus" across OpenStack projects
- There should be no other API in OpenStack competing for this "rough consensus"
- It should be possible for the API to evolve while continuing to maintain backwards compatibility with older versions for a reasonable period - e.g. compatibility with an API deprecated in release N may only be removed in release N+2
The process of developing a new Oslo API usually begins by taking code which is common to some OpenStack projects and moving it into the oslo-incubator repository. New APIs live in the incubator until they have matured to meet the criteria described above.
While incubating, all APIs should have a specialist API maintainer. The responsibility of these maintainers and the list of maintainers for each incubating API is documented in the MAINTAINERS file in oslo-incubator.
Developers making major changes to incubating APIs in oslo-incubator must be prepared to update the copies in the projects which have previously imported the code.
Incubation shouldn't be seen as a long term option for any API - it is merely a stepping stone to inclusion into a published Oslo library.
Please file bugs for incubating APIs in the oslo project in launchpad.
Syncing Code from Incubator
APIs which are incubating can be copied into individual openstack projects from oslo-incubator using the
update.py script provided. An
openstack-common.conf configuration file in the project describes which modules to copy and where they should be copied to.
Usually the API maintainer or those making significant changes to an API take responsibility for syncing that specific module into the projects which use it by doing e.g.:
$> cd ../ $> git clone .../oslo-incubator $> cd oslo-incubator $> python update.py --nodeps --base nova --dest-dir ../nova --modules jsonutils,gettextutils
Alternatively, it can make sense for someone to batch sync more minor changes into a project by doing e.g.: To sync all code for a specific project, you can do:
$> python update.py ../nova Copying the config,exception,extensions,utils,wsgi modules under the nova module in ../nova
in this latter case, the
update.py script uses the
openstack-common.conf config file to determine which modules to copy. The format of that file is e.g.
$> cd ../nova $> cat openstack-common.conf [DEFAULT] # The list of modules to copy from oslo-incubator modules=cfg,iniparser # The base module to hold the copy of openstack.common base=nova
Projects which are using such incubating APIs must avoid ever modifying their copies of the code. All changes should be made in oslo-incubator itself and copied into the project.
We use launchpad blueprints to track design proposals.
The havana blueprints detail the work currently underway.
Messaging Related Work in Havana
See this etherpad for yet more details.
Etherpads from sessions at the Havana Design summit.
- Oslo Status and Plans
- Pecan/WSME Status
- No-downtime DB migrations
- Rootwrap improvements for the Havana cycle
- Common packaging support and code analysis tools
- RPC API review
- ZeroMQ RPC for Ceilometer and Quantum
- Message queue access control
- RPC Message Signing and Encryption
- Zipkin tracing in OpenStack
- i18n strategy for OpenStack services
- Common XenAPI libary
Etherpads from sessions at the Grizzly Design summit.
- Oslo status and plans
- Unified CLI, take 2
- Adding optional security to RPC
- Services framework for command and control
- Using the message bus for messaging
- Choosing a WSGI framework for API services
- XML request/response processing
- Entrypoints based plugins
- Unified rootwrap & password management
- A common database
- Instrumentation monitoring
Etherpads from sessions at the Folsom Design summit.