[[Category:Summit]]
[[Category:Newton]]
[[Category:Etherpad]]

The grand list of all the Newton Design Summit sessions. Please include Date, Time, and links to etherpads when adding new content.

<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3">
__TOC__
</div>
== Event intro/closure ==
* Tue 11:15: Design Summit 101 - https://etherpad.openstack.org/p/newton-design-summit-101

==App Catalog==
?

== Barbican ==
Design Summit Topics: https://etherpad.openstack.org/p/newton-barbican-design-sessions

== Cinder ==
Official Schedule: https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Cinder%3A

Planning/Topic Etherpad: https://etherpad.openstack.org/p/newton-cinder-summit-ideas

'''Wednesday 27th'''
* '''9:00am-9:40am'''
** Replication Next Steps: https://etherpad.openstack.org/p/cinder-newton-replication
* '''9:50am-10:30am'''
** Active/Active HA: https://etherpad.openstack.org/p/cinder-newton-activeactiveha
* '''11:00am-11:40am'''
** Mitaka Recap, Part 1: https://etherpad.openstack.org/p/cinder-newton-mitakarecap
* '''11:50am-12:30pm'''
** Mitaka Recap, Part 2: https://etherpad.openstack.org/p/cinder-newton-mitakarecap
* '''1:50pm-2:30pm'''
** Rolling Upgrades: https://etherpad.openstack.org/p/cinder-newton-rollingupgrades
* '''2:40pm-3:20pm'''
** Scalable Backup: https://etherpad.openstack.org/p/cinder-newton-scalablebackup
* '''3:30pm-4:10pm'''
** Testing Process: https://etherpad.openstack.org/p/cinder-newton-testingprocess
'''Thursday 28th'''
* '''9:00am-9:40am'''
** CinderClient and OpenStackClient: https://etherpad.openstack.org/p/cinder-newton-cinderclienttoosc
* '''9:50am-10:30am'''
** Unconference: https://etherpad.openstack.org/p/cinder-newton-unconference
* '''11:00am-11:40am'''
** Nova Cross Project
** Details and notes: https://etherpad.openstack.org/p/cinder-nova-api-changes
** Session etherpad: https://etherpad.openstack.org/p/newton-nova-cinder
'''Friday 29th'''
* '''9:00am-12:30pm'''
* '''2:00pm-5:30pm'''
** Contributors Meetup: https://etherpad.openstack.org/p/cinder-newton-contributorsmeetup

== CloudKitty ==
?

== Congress ==
All sessions are Wed April 27. Full Congress-related schedule: https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=congress

* 11:00-11:40: Integrations with other OpenStack projects - https://etherpad.openstack.org/p/newton-congress-integrations
* 11:50-12:30: Distributed Architecture - https://etherpad.openstack.org/p/newton-congress-architecture
* 1:50-2:30p: High Availability and Throughput - https://etherpad.openstack.org/p/newton-congress-availability
* 2:40-3:20p: Other Features for Newton - https://etherpad.openstack.org/p/newton-congress-features

== Cross-Project workshops ==

All sessions are on Tuesday 2016-04-26

https://www.openstack.org/summit/austin-2016/summit-schedule/#day=2016-04-26&summit_types=2&tags=3601

* '''11:15 - 11:55'''
** Deployment tools discussion - https://etherpad.openstack.org/p/newton-deployment-tools-discussion
** Getting API Docs off of WADL and into RST - https://etherpad.openstack.org/p/newton-api-docs-rst
** How do we get a single CLI? - https://etherpad.openstack.org/p/newton-single-cli
* '''12:05 - 12:45'''
** Alternatives to polling - https://etherpad.openstack.org/p/newton-alternatives-to-polling
** Co-installability Requirements Are Holding Us Back - https://etherpad.openstack.org/p/newton-global-requirements
* '''''Lunch'''''
* '''14:00 - 14:40'''
** Improve oslo.policy to be used more like configuration - https://etherpad.openstack.org/p/newton-policy-in-code
** Moving towards a Identity v3 API only devstack - https://etherpad.openstack.org/p/newton-keystone-v3-devstack
** Stable Branch End of Life Policy - https://etherpad.openstack.org/p/stable-branch-eol-policy-newton
* '''14:50 - 15:30'''
** Backwards compatibility for Libraries - https://etherpad.openstack.org/p/newton-backwards-compat-libs
** Common service deployment in devstack - https://etherpad.openstack.org/p/newton-devstack-wsgi-patterns
** Conventional roles for default policy files - https://etherpad.openstack.org/p/newton-default-policy-roles
* '''15:40 - 16:20'''
** Discovery: Everybody's doing it. Can we all do it the same way? - https://etherpad.openstack.org/p/newton-discovery
** Moving from oslo.rootwrap to oslo.privsep - https://etherpad.openstack.org/p/newton-privsep
** Scaling the OSSA/VMT via Threat Analysis - https://etherpad.openstack.org/p/newton-thread-analysis
* '''''Coffee Break'''''
* '''16:40 - 17:20'''
** (In)secure messaging - https://etherpad.openstack.org/p/newton-secure-messaging
** Brainstorm format for design summit split event - https://etherpad.openstack.org/p/newton-design-summit-format
** The future of baremetal networking - https://etherpad.openstack.org/p/newton-baremetal-networking
* '''17:30 - 18:10'''
** Defining scope of cross projects specs, tracking methods, and approach for providing user/operator feedback as user & design summits separate. - https://etherpad.openstack.org/p/newton-cross-project-spec-scope
** Instance Users - https://etherpad.openstack.org/p/newton-instance-users
** Quota 'delimiter' service and/or library - https://etherpad.openstack.org/p/newton-quota-library

== Ceilometer ==

?

== Cue ==

?

== Designate ==

?

== Documentation ==

https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Documentation%3A

'''Wednesday'''

* '''09:00-09:40'''
** API Guides workgroup: https://etherpad.openstack.org/p/austin-docs-workgroup-api
* '''11:00-11:40'''
** Mitaka Retrospective: https://etherpad.openstack.org/p/austin-docs-mitakaretro
* '''11:50-12:30'''
** Install Guide workgroup: https://etherpad.openstack.org/p/austin-docs-workgroup-install
* '''16:30-17:10'''
** Docs Toolchain/Infra Session: https://etherpad.openstack.org/p/austin-docs-toolsinfra

'''Thursday'''

* '''09:50-10:30'''
** Contributor Guide: https://etherpad.openstack.org/p/austin-docs-contributorguide
* '''11:00-11:40'''
** Security Guide workgroup: https://etherpad.openstack.org/p/austin-docs-workgroup-security
* '''11:50-12:30'''
** Networking Guide workgroup: https://etherpad.openstack.org/p/austin-docs-workgroup-networking
* '''13:30-14:10'''
** Newton planning: https://etherpad.openstack.org/p/austin-docs-newtonplan

'''Friday'''

* '''14:00-17:30'''
** Contributor Meetup

== Dragonflow ==

https://etherpad.openstack.org/p/dragonflow-design-summit

== Glance ==

?

== Group Based Policy ==

?

== Heat ==

The everything etherpad: https://etherpad.openstack.org/p/newton-heat-sessions

'''Wednesday April 27'''
* 3:30pm-4:10pm - [https://etherpad.openstack.org/p/heat-newton-tempest (W) Functional and integration tests, tempest plugin and defcore]
* 4:30pm-5:10pm - [https://etherpad.openstack.org/p/heat-newton-hot-parser (W) HOT parser]
* 5:20pm-6:00pm - [https://etherpad.openstack.org/p/heat-newton-release-model (W) Release model and versioning]

'''Thursday April 28'''
* 9:00am-9:40am - [https://etherpad.openstack.org/p/heat-newton-client-commands (F) New heatclient commands]
* 9:50am-10:30am - [https://etherpad.openstack.org/p/heat-newton-sd-refinents (F) Software deployment refinements]
* 11:00am-11:40am - [https://etherpad.openstack.org/p/heat-newton-observer (F) Continous observer]
* 11:50am-12:30pm - [https://etherpad.openstack.org/p/heat-newton-large-stacks (F) Issues with very large stacks]
* 1:30pm-2:10pm - [https://etherpad.openstack.org/p/heat-newton-dlm (W) Implement DLM to bring HA into Heat]
* 2:20pm-3:00pm - [https://etherpad.openstack.org/p/heat-newton-convergence-switchover (W) Convergence Phase 1 Switchover]
* 3:10pm-3:50pm - [https://etherpad.openstack.org/p/heat-newton-convergence-tidy-up (W) Convergence Phase 1 tidy-up]
* 4:10pm-4:50pm - [https://etherpad.openstack.org/p/heat-newton-performance-improvements (W) Performance improvements]
* 5:00pm-5:40pm - [https://etherpad.openstack.org/p/heat-newton-validation-improvements (W) Validation improvements]

'''Friday April 29'''
* 2:00pm-5:30pm - [https://etherpad.openstack.org/p/heat-newton-meetup Contributors meetup]

== Horizon ==

?

== I18n ==
* '''Thursday 2016-04-28 13:30 - 15:00''' [https://www.openstack.org/summit/austin-2016/summit-schedule/events/7707 I18n workshop: translation processes and tools]: https://etherpad.openstack.org/p/austin-i18n-workshop
* '''Friday 2016-04-29 9:00 -12:30''' [https://www.openstack.org/summit/austin-2016/summit-schedule/events/9418 I18n Contributors meetup]: https://etherpad.openstack.org/p/austin-i18n-meetup

== Infrastructure ==
'''Schedule:''' https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Infrastructure%3A

'''Wednesday:'''
* 09:00-09:40 CDT / 14:00-14:40 UTC fishbowl [https://etherpad.openstack.org/p/newton-infra-community-task-tracking ''Community Task-Tracking''] (MR 400)
** https://etherpad.openstack.org/p/newton-infra-community-task-tracking
* 11:50-12:30 CDT / 16:50-17:30 UTC work session [https://etherpad.openstack.org/p/newton-infra-landing-page-for-contributors ''Landing Page for Contributors''] (MR 416A)
** https://etherpad.openstack.org/p/newton-infra-landing-page-for-contributors
* 13:50-14:30 CDT / 18:50-19:30 UTC work session [https://etherpad.openstack.org/p/newton-infra-launch-node-ansible-and-puppet ''Launch-Node, Ansible and Puppet''] (MR 416A)
** https://etherpad.openstack.org/p/newton-infra-launch-node-ansible-and-puppet
* 15:30-16:10 CDT / 20:30-21:10 UTC fishbowl [https://etherpad.openstack.org/p/newton-infra-wiki-upgrades ''Wiki Upgrades''] (MR 400)
** https://etherpad.openstack.org/p/newton-infra-wiki-upgrades

'''Thursday:'''
* 09:00-09:40 CDT / 14:00-14:40 UTC work session [https://etherpad.openstack.org/p/newton-infra-proposal-jobs ''Proposal Jobs''] (MR 416A)
** https://etherpad.openstack.org/p/newton-infra-proposal-jobs
* 09:50-10:30 CDT / 14:50-15:30 UTC work session [https://etherpad.openstack.org/p/newton-infra-robustify-ansible-puppet ''Robustify Ansible-Puppet''] (MR 416A)
** https://etherpad.openstack.org/p/newton-infra-robustify-ansible-puppet
* 11:00-11:40 CDT / 16:00-16:50 UTC fishbowl [https://etherpad.openstack.org/p/newton-infra-openid-sso-for-community-systems ''OpenID/SSO for Community Systems''] (MR 400)
** https://etherpad.openstack.org/p/newton-infra-openid-sso-for-community-systems
* 16:10-16:50 CDT / 21:10-21:50 UTC fishbowl [https://etherpad.openstack.org/p/newton-infra-distro-upgrade-plans ''Distro Upgrade Plans''] (MR 400)
** https://etherpad.openstack.org/p/newton-infra-distro-upgrade-plans

'''Friday:'''
* Infra/QA sprints (MR 404 and elsewhere)

== Ironic ==

'''Wednesday April 27'''
* 9:00 - 9:40 - Nova-compatible VNC console - https://etherpad.openstack.org/p/ironic-newton-summit-console
* 9:50 - 10:30 - Status and future of our gate - https://etherpad.openstack.org/p/ironic-newton-summit-gate
* 11:00 - 11:40 - Hardware pool management - https://etherpad.openstack.org/p/ironic-newton-summit-hardware-pools
* 11:50 - 12:30 - Work session (driver composition) - https://etherpad.openstack.org/p/ironic-newton-summit-driver-composition
* 1:50 - 2:30 - Making ops less worse - https://etherpad.openstack.org/p/ironic-newton-summit-ops
* 2:40 - 3:20 - Anomaly detection and resolution - https://etherpad.openstack.org/p/ironic-newton-summit-anomaly-detection
* 4:30 - 5:10 - Work session (Ansible deploy driver) - https://etherpad.openstack.org/p/ironic-newton-summit-ansible-deploy
* 5:20 - 6:00 - Work session (Live upgrades) - https://etherpad.openstack.org/p/ironic-newton-summit-live-upgrades

'''Thursday April 28'''
* 11:00 - 11:40 - Work session (Inspector) - https://etherpad.openstack.org/p/ironic-newton-summit-inspector
* 11:50 - 12:30 - Work session (Newton priorities and planning) - https://etherpad.openstack.org/p/ironic-newton-summit-priorities

== Kolla ==

https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Kolla%3A

'''Wed April 27'''

* 09:00 - 09:40 - Adding plugins for compute kit services - https://etherpad.openstack.org/p/kolla-newton-summit-plugin-planning
* 09:50-10:30 - Operational Pain Points - https://etherpad.openstack.org/p/kolla-newton-summit-pain-points
* 11:00 - 11:40 - Improving documentation for Operators - https://etherpad.openstack.org/p/kolla-newton-summit-documentation-planning
* 11:50 - 12:30 - Operator Focused Roadmap - https://etherpad.openstack.org/p/kolla-newton-summit-operator-roadmap
* 13:50 - 14:30 - Security - https://etherpad.openstack.org/p/kolla-newton-summit-security
* 14:40 - 15:20 - Functional Gating - https://etherpad.openstack.org/p/kolla-newton-summit-kolla-functional-gating
* 15:30 - 16:10 - Diagnostics - https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-diagnostics
* 16:30 - 17:10 - kolla-ansible repo split - https://etherpad.openstack.org/p/kolla-newton-summit-kolla-ansible-repo-split
* 17:20 - 18:00 - kolla-kubernetes - https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kubernetes-underlay

'''Thu April 28'''

* 09:00 - 09:40 - Registry Post Job - https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-reg-post-job
* 09:50 - 10:30 - plugins extras - https://etherpad.openstack.org/p/kolla-newton-summit-kolla-plugins-extras
* 11:00 - 11:40 - kolla-host repository - https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo
* 11:50 - 12:30 - Threat Analysis with the Security Team - https://etherpad.openstack.org/p/kolla-newton-summit-threat-analysis
* 13:50 - 14:30 - Cross Project Workshop - https://etherpad.openstack.org/p/kolla-newton-summit-kolla-cross-project-workshop

'''Fri April 29'''

Morning Contributor Meetup Agenda - https://etherpad.openstack.org/p/kolla-newton-summit-kolla-contrib-part-one
Afternoon Contributor Meetup Agenda - https://etherpad.openstack.org/p/kolla-newton-summit-kolla-contrib-part-two
* 09:00 - 10:30 - code walkthrough of gating and how to add gate jobs - https://etherpad.openstack.org/p/kolla-newton-summit-kolla-gate-walkthru
* 11:00 - 12:30 - threat analysis continued - https://etherpad.openstack.org/p/kolla-newton-summit-threat-analysis
* 14:00 - 14:40 - Reboot Survival - https://etherpad.openstack.org/p/kolla-newton-summit-kolla-reboot-survival
* 15:00 - 15:40 - Deploying the Big Tent - https://etherpad.openstack.org/p/kolla-newton-summit-kolla-deploy-big-tent

== Keystone ==

https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Keystone%3A

'''Wed April 27'''
* 11:00 - 11:40 - New Features - https://etherpad.openstack.org/p/newton-keystone-new-features
* 11:50 - 12:30 - Integration - https://etherpad.openstack.org/p/newton-keystone-integration
* '''Lunch'''
* 13:50 - 14:30 - Work session - https://etherpad.openstack.org/p/newton-keystone-work-session
* 14:40 - 15:00 - Stabilization - https://etherpad.openstack.org/p/newton-keystone-stabilization
* 15:10 - 15:50 - Clients and Libraries - https://etherpad.openstack.org/p/newton-keystone-clients-and-libraries
* '''Coffee Break'''
* 16:30 - 17:10 - Work session - https://etherpad.openstack.org/p/newton-keystone-work-session
* 17:20 - 18:00 - Work session - https://etherpad.openstack.org/p/newton-keystone-work-session

'''Thu April 28'''
* 09:50 - 10:30 - Testing - https://etherpad.openstack.org/p/newton-keystone-testing
* '''Coffee Break'''
* 11:00 - 11:40 - Work session - https://etherpad.openstack.org/p/newton-keystone-work-session
* 11:50 - 12:30 - Work session - https://etherpad.openstack.org/p/newton-keystone-work-session
* '''Lunch'''
* 13:50 - 14:30 - Work session - https://etherpad.openstack.org/p/newton-keystone-work-session
* 14:40 - 15:00 - Work session - https://etherpad.openstack.org/p/newton-keystone-work-session
* 15:10 - 15:50 - Work session - https://etherpad.openstack.org/p/newton-keystone-work-session

'''Fri April 29'''
* 09:00 - 12:30 - Contributors Meetup
* '''Lunch'''
* 14:00 - 17:30 - Contributors Meetup

== Kuryr ==
'''Wednesday 2016-04-27'''

13:50-14:30 Work session: Kubernetes Integration

https://etherpad.openstack.org/p/newton-kuryr-k8s-integration

14:40-15:20 Magnum and Nested containers integration

15:30-16:10 Generic architecture of Kuryr

16:30-17:10 Misc.

'''Thursday 2016-04-28'''

11:50 – 12:30 Shared Magnum-Kuryr Session (Magnum Fishbowl Session)

16:10-16:50 Fishbowl: Roadmap and Users priorities

17:00-17:40 Kuryr Mesos and Kuryr Storage

https://etherpad.openstack.org/p/kuryr-design-summit

== Magnum ==

'''Wednesday 2016-04-27'''

9:00 - 9:40 Work session: the bay driver design

https://etherpad.openstack.org/p/newton-magnum-bay-driver

9:50 - 10:30 Work session: lifecycle operations for long running bays

https://etherpad.openstack.org/p/newton-magnum-bays-lifecycle-operations

11:00 - 11:40 Work session: magnum scalability

https://etherpad.openstack.org/p/newton-magnum-scalability

'''Thursday 2016-04-28'''

11:00 - 11:40 Fishbowl: container storage

https://etherpad.openstack.org/p/newton-magnum-container-storage

11:50 - 12:30 Fishbowl: container network

https://etherpad.openstack.org/p/newton-magnum-container-network

13:30 - 14:10 Fishbowl: ironic integration

https://etherpad.openstack.org/p/newton-magnum-ironic-integration

14:20 - 15:00 Fishbowl: challenges in adoption

https://etherpad.openstack.org/p/newton-magnum-adoption-challenges

15:10 - 15:50 Fishbowl: unified container abstraction

https://etherpad.openstack.org/p/newton-magnum-unified-abstraction

16:10 - 16:50 Work session: heat template versioning

https://etherpad.openstack.org/p/newton-magnum-heat-template-versioning

17:00 - 17:40 Work session: bays and containers monitoring

https://etherpad.openstack.org/p/newton-magnum-monitoring

== Manila ==
* Wed 17:20 - 18:00: (WS) Concurrency Issues https://etherpad.openstack.org/p/newton-manila-concurrency
* Thu 11:00 - 11:40: (FB) Share Groups https://etherpad.openstack.org/p/newton-manila-share-groups
* Thu 11:50 - 12:30: (FB) Data Service and Migration https://etherpad.openstack.org/p/newton-manila-data-service-migration
* Thu 13:30 - 14:10: (WS) Update Access https://etherpad.openstack.org/p/newton-manila-update-access
* Thu 14:20 - 15:00: (WS) Quotas https://etherpad.openstack.org/p/newton-manila-quotas
* Thu 15:10 - 15:50: (WS) Snapshot Semantics https://etherpad.openstack.org/p/newton-manila-snapshot-semantics
* Fri 14:00 - 17:30: (CM) Contributor Meetup https://etherpad.openstack.org/p/newton-manila-contributor-meetup

==Mistral==

'''Wednesday 2016-04-27'''

5:20pm-6:00pm Fishbowl: Stories from advanced users

https://etherpad.openstack.org/p/mistral-austin-summit-fishbowl-2106

'''Thursday 2016-04-28'''

9:00am-9:40am Work session

https://etherpad.openstack.org/p/mistral-austin-summit-topics-2106

9:50am-10:30am Work session

https://etherpad.openstack.org/p/mistral-austin-summit-topics-2106

11:00am-11:40am Work session

https://etherpad.openstack.org/p/mistral-austin-summit-topics-2106

==Murano==
?

== Neutron ==

Wednesday 2016-04-27

Wed 13:50 - 14:30 Development track: future of *-aas projects https://etherpad.openstack.org/p/newton-neutron-future-adv-services

Wed 14:40 - 15:20 Development track: neutron-lib next steps https://etherpad.openstack.org/p/newton-neutron-lib-next-steps

Wed 15:30 - 16:10 User feedback track: health checking and troubleshooting https://etherpad.openstack.org/p/newton-neutron-troubleshooting

Wed 16:30 - 17:10 Development track: future of Neutron API https://etherpad.openstack.org/p/newton-neutron-future-neutron-api

Wed 17:20 - 18:00 Development track: future of Neutron architecture https://etherpad.openstack.org/p/newton-neutron-future-neutron-architecture

Thursday 2016-04-28

Thu 09:00 - 09:40 Development track: future of Neutron client https://etherpad.openstack.org/p/newton-neutron-future-neutron-client

Thu 09:50 - 10:30 Community track: stadium evolution https://etherpad.openstack.org/p/newton-neutron-community-stadium-evolution

Thu 16:10 - 16:50 User feedback track: end user and operator pain points https://etherpad.openstack.org/p/newton-neutron-pain-points

Thu 17:00 - 17:40 Development track: completing the Mitaka backlog https://etherpad.openstack.org/p/newton-neutron-core-mitaka-backlog

Friday 2016-04-29

Fri 09:00 - 12:30 Neutron: Contributors meetup https://etherpad.openstack.org/p/newton-neutron-unplugged-track

Fri 14:00 - 17:30 Neutron: Contributors meetup https://etherpad.openstack.org/p/newton-neutron-unplugged-track

== Nova ==

https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Nova%3A

'''Wed April 27'''

* 09:00 - 09:40 - Scheduler and resource tracking evolution - https://etherpad.openstack.org/p/newton-nova-scheduler
* 09:50 - 10:30 - Scheduler and resource tracking evolution (continued)
* '''Coffee Break'''
* 11:00 - 11:40 - Neutron cross-project - https://etherpad.openstack.org/p/newton-nova-neutron
* 11:50 - 12:30 - Performance VMs CI and technical debt - https://etherpad.openstack.org/p/newton-nova-performance-vms
* '''Lunch'''
* 13:50 - 14:30 - Nova: Unconference #1 - https://etherpad.openstack.org/p/newton-nova-summit-unconference
* 14:40 - 15:20 - Cells v2 - https://etherpad.openstack.org/p/newton-nova-cells
* 15:30 - 16:10 - Cells v2 (continued)
* '''Coffee Break'''
* 16:30 - 17:10 -Low-hanging fruit / getting started in Nova - https://etherpad.openstack.org/p/newton-nova-getting-started
* 17:20 - 18:00 - Live Migration - https://etherpad.openstack.org/p/newton-nova-live-migration

'''Thu April 28'''

* 09:00 - 09:40 - API discoverability and policy - https://etherpad.openstack.org/p/newton-nova-api
* 09:50 - 10:30 - API (continued)
* '''Coffee Break'''
* 11:00 - 11:40 - Cross-project with Cinder - https://etherpad.openstack.org/p/newton-nova-cinder
* 11:50 - 12:30 - Feature classification and testing - https://etherpad.openstack.org/p/newton-nova-feature-classification
* '''Lunch'''
* 13:50 - 14:30 - Nova: Unconference #2 - https://etherpad.openstack.org/p/newton-nova-summit-unconference
* 14:40 - 15:20 - Glance v2 integration - https://etherpad.openstack.org/p/newton-nova-glance
* 15:30 - 16:10 - Ironic cross-project session - https://etherpad.openstack.org/p/newton-nova-ironic
* '''Coffee Break'''
* 16:30 - 17:10 - Project ID validation with Keystone - https://etherpad.openstack.org/p/newton-nova-keystone
* 17:20 - 18:00 - Priorities and schedule for Newton - https://etherpad.openstack.org/p/newton-nova-summit-priorities

'''Fri April 29'''
* 09:00 - 12:30 - Contributors Meetup - https://etherpad.openstack.org/p/newton-nova-meetup
* '''Lunch'''
* 14:00 - 17:30 - Contributors Meetup - https://etherpad.openstack.org/p/newton-nova-meetup

== OpenStack-Ansible ==
https://etherpad.openstack.org/p/openstack-ansible-newton-summit

== OpenStack Chef ==
?

== OpenStackClient ==
28 Apr 2016 15:10 - 15:50
https://etherpad.openstack.org/p/newton-openstackclient

== Ops ==
Operators sessions are on Monday 2016-04-25

https://www.openstack.org/summit/austin-2016/summit-schedule/#day=2016-04-25&summit_types=2&tags=976,1419

Etherpads @ https://etherpad.openstack.org/p/AUS-ops-meetup

== Oslo ==

'''Wednesday 2016-04-27'''

13:50 - 14:30 Fishbowl: future plans for mutable config progress + mutable logging + mutable ?

https://etherpad.openstack.org/p/newton-oslo-mutables

14:40 - 15:20 Work session: modify oslo.policy so that it reads default policies embedded in project code

https://etherpad.openstack.org/p/newton-oslo-policy-default-embedded

15:30 - 16:10 Work session: oslo.policy changes for YAML support

https://etherpad.openstack.org/p/newton-oslo-policy-yaml-support

'''Thursday 2016-04-28'''

09:00 - 09:40 Fishbowl: updates on oslo.messaging drivers - pika, zmq, kombu, amqp1

https://etherpad.openstack.org/p/newton-oslo-messaging-drivers

11:00 - 11:40 Workroom: finish our python 3 work

https://etherpad.openstack.org/p/newton-oslo-python-three

11:50 - 12:30 Workroom: new libraries (ideas, thoughts, bring your friends).

https://etherpad.openstack.org/p/newton-oslo-maybe-new-libraries

14:20 - 15:00 Workroom: improve oslo libraries adoption

https://etherpad.openstack.org/p/newton-oslo-improve-adoption

16:10 - 16:50 Fishbowl: backwards compat. testing strategies

https://etherpad.openstack.org/p/newton-oslo-backwards-compat-testing

== Packaging OpenStack ==

* '''2016-04-28: 11:50 - 12:30'''
** Cross-distro (Deb & RPM) packaging discussion - https://etherpad.openstack.org/p/newton-cross-distro-packaging-discussion
* '''2016-04-28: 14:20 - 15:00'''
** RPM Packaging: Work session (Board room 401)

== Product Team ==

?

== Puppet OpenStack ==
https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Puppet
https://etherpad.openstack.org/p/newton-design-puppet

'''Wed April 27'''

Project Statusː https://etherpad.openstack.org/p/newton-puppet-project-status
* 1:50 - 2:30 - Project Update - Mitaka retrospective and Newton Plans 1/2
* '''Coffee Break'''
* 2:40 - 3:20 - Project Update - Mitaka retrospective and Newton Plans 2/2

Work sessionsː
* 4.30 - 5.10 - Work session
* '''Coffee Break'''
* 5.20 - 6.00 - Work session

'''Thu April 28'''
* 11.50 - 12.30 - Work session

'''Fri April 29'''
* 9.00 - 12.30 - Contributors meetup
https://etherpad.openstack.org/p/newton-community-puppet

== QA ==

Wednesday 2016-04-27

09:50 - 10:30 Development track: Devstack Roadmap: https://etherpad.openstack.org/p/newton-qa-devstack-roadmap

11:00 - 11:40 Development track: tempest.lib and tempest plugin: https://etherpad.openstack.org/p/newton-qa-tempest-lib-and-tempest-plugin

14:40 - 15:20 Development track: OpenStack Health The Next Generation: https://etherpad.openstack.org/p/newton-qa-openstack-health

16:30 - 17:10 Development track: Negative testing: https://etherpad.openstack.org/p/newton-qa-negative-testing

17:20 - 18:00 Development track: Cruft-busters: https://etherpad.openstack.org/p/newton-qa-cruft-busters

Thursday 2016-04-28

11:50 - 12:30 Development track: Defcore and interoperability testing: https://etherpad.openstack.org/p/newton-qa-defcore-and-interoperability

14:20 - 15:00 Development track: Newton Priorities: https://etherpad.openstack.org/p/newton-qa-newton-priorities

15:10 - 15:50 Development track: Temepst CLI: https://etherpad.openstack.org/p/newton-qa-tempest-cli

== Release management ==

Thursday 2016-04-28

5:00 pm - 5:40 pm Release Management: Retrospective and Planning Session - https://etherpad.openstack.org/p/newton-release-fishbowl

Friday 2016-04-29

2:00 pm - 5:30 pm Release Management: Contributors meetup - https://etherpad.openstack.org/p/newton-relmgt-plan

== Searchlight ==
?

== Sahara ==

'''Wednesday 2016-04-27'''

09:00 - 09:40 (MR 417A) Work session: Future plans of EDP

https://etherpad.openstack.org/p/sahara-newton-edp

Work session: API v2

https://etherpad.openstack.org/p/sahara-newton-api-v2

Fishbowl: Future of Data Processing UI

https://etherpad.openstack.org/p/sahara-newton-ui

Fishbowl: Deprecation Rodeo

https://etherpad.openstack.org/p/sahara-newton-deprecation-policy

Workroom: Security in Sahara

https://etherpad.openstack.org/p/sahara-newton-security

Workroom: Image generation

https://etherpad.openstack.org/p/sahara-newton-images

Workroom: Release model / Detaching plugins

https://etherpad.openstack.org/p/sahara-newton-release-model

'''Thursday 2016-04-28'''

Workroom: Sahara testing

https://etherpad.openstack.org/p/sahara-newton-tests

All links to all documents are located in here:

https://etherpad.openstack.org/p/sahara-newton-summit

== Senlin ==

* [09:00-09:40 Boardroom 403] Profile/Policy validation - https://etherpad.openstack.org/p/newton-senlin-validation
* [09:50-10:30 Boardroom 403] Distributed lock management/Scalability - https://etherpad.openstack.org/p/newton-senlin-dlm
* [13:50-14:30 MR 406] Container clustering - https://etherpad.openstack.org/p/newton-senlin-container
* [15:30-16:10 Boardroom 401] Advanced autoscaling - https://etherpad.openstack.org/p/newton-senlin-as
* [16:30-17:10 Boardroom 401] Task abstraction and scheduling - https://etherpad.openstack.org/p/newton-senlin-sched
* [17:20-18:00 Boardroom 401] Desired capacity and health management - https://etherpad.openstack.org/p/newton-senlin-ha

== Stable Branch Maintenance ==
* Thursday: 13:30pm-2:10pm: Salon E - https://etherpad.openstack.org/p/newton-stable-summit

== Swift ==
* Wednesday: 9:00am, Salon E - https://etherpad.openstack.org/p/swift-newton-ops-feedback
* Wednesday: 9:50am, Salon E - https://etherpad.openstack.org/p/swift-newton-community-feedback
* Wednesday: 2:40pm-6:00pm, MR417A - https://etherpad.openstack.org/p/swift-newton-work-session-1
* Thursday: 9:00am-12:30pm, MR417A - https://etherpad.openstack.org/p/swift-newton-work-session-2
* Thursday: 2:30pm-5:40pm, MR417A - https://etherpad.openstack.org/p/swift-newton-work-session-3

== Tacker ==

Thursday 2016-04-28

Thu 14:20 - 17:40 Development track: https://etherpad.openstack.org/p/tacker-newton-summit

== Tricircle ==
?

== TripleO ==

'''Thursday April 28'''
* 1:30pm-2:10pm - Upgrades - current status and roadmap - https://etherpad.openstack.org/p/tripleo-newton-upgrades
* 2:20pm-3:00pm - Containerization status/roadmap - current status and roadmap - https://etherpad.openstack.org/p/tripleo-newton-containers
* 3:10pm-3:50pm - Work session (Composable Services and beyond) - https://etherpad.openstack.org/p/tripleo-newton-composable-services
* 4:10pm-4:50pm - Work session (API and TripleO UI) - https://etherpad.openstack.org/p/tripleo-newton-api-ui
* 5:00pm-5:40pm - Work session (Reducing the CI pain) - https://etherpad.openstack.org/p/tripleo-newton-ci
'''Friday April 29'''
* 2:00pm-5:30pm - Contributors meetup - https://etherpad.openstack.org/p/tripleo-newton-meetup

== Trove ==
''' Wednesday (2016-04-27), Session MR412, 0950 to 1030 '''
* Planning for Python3 support [TBD]:
** https://etherpad.openstack.org/p/trove-newton-summit-python3
* Deploying multiple datastores with the same manager [amrith]:
** https://etherpad.openstack.org/p/trove-newton-summit-multiple-datastores

''' Wednesday (2016-04-27), Session MR417A, 1350 to 1430 '''
* Management Client for Trove [nikhil/amrith/doug]:
** https://etherpad.openstack.org/p/trove-newton-summit-management-client
* Migrating to the OpenStack Client [nikhil/amrith/doug]:
** https://etherpad.openstack.org/p/trove-newton-summit-openstack-client

''' Wednesday (2016-04-27), Session MR415B, 1530 to 1610 '''
* Trove Upgrades [doug/morgan]:
** https://etherpad.openstack.org/p/trove-newton-summit-trove-upgrades

''' Wednesday (2016-04-27), Session MR406, 1720 to 1800 '''
* Extending back-end (persistent) storage options [amrith]:
** https://etherpad.openstack.org/p/trove-newton-summit-extensible-backend-storage

''' Thursday (2016-04-28), Session MR406, 0950 to 1030 '''
* Trove Container Support [flavio]:
** https://etherpad.openstack.org/p/trove-newton-summit-container
* Snapshots as a backup strategy [telles]:
** https://etherpad.openstack.org/p/trove-newton-summit-snapshot-as-a-backup-strategy

''' Thursday (2016-04-28), Session MR406, 1100 to 1140 '''
* Making it easier to build guest images [pete]:
** https://etherpad.openstack.org/p/trove-newton-summit-easier-to-build-images

''' Thursday (2016-04-28), Session MR414, 1150 to 1230 '''
* Trove API v2 [doug/morgan]:
** https://etherpad.openstack.org/p/trove-newton-summit-v2-api

''' Thursday (2016-04-28), Session MR415B, 1330 to 1410 '''
* Improving code modularity betweek guests and images [amrith]:
** https://etherpad.openstack.org/p/trove-newton-summit-modularity-guest-image
* Improving Trove support for self-signed certificates [amrith]
** https://etherpad.openstack.org/p/trove-newton-summit-ssl-self-signed-certificates

''' Thursday (2016-04-28), Session MR415A, 1420 to 1500 '''
* Trove Superconductor [nikhil/pete/amrith]:
** https://etherpad.openstack.org/p/trove-newton-summit-superconductor

''' Friday (2016-04-29), Session MR415B, 0900 to 1230 '''
* Contributor meetup:
** https://etherpad.openstack.org/p/trove-newton-summit-contributor-meetup

== UX ==
?

== Watcher ==

Tuesday 2016-04-26

2:00pm-6:00pm Work session

https://etherpad.openstack.org/p/watcher-newton-design-session

Wednesday 2016-04-27

9:00am-12:00am Work session

https://etherpad.openstack.org/p/watcher-newton-design-session

Thursday 2016-04-28

9:00am-12:00am Work session

https://etherpad.openstack.org/p/watcher-newton-design-session

2:20pm-3:00 Watcher, a Resource Manager for OpenStack: Plans for the N-release and Beyond

https://www.openstack.org/summit/austin-2016/summit-schedule/events/7108

== Zaqar ==
?

Design Summit/Newton/Etherpads

2016-04-14T21:47:12Z

Harlowja: /* Oslo */

Design Summit/Newton/Etherpads

2016-04-14T21:46:43Z

Harlowja: /* Oslo */

2016-03-21T18:05:25Z

Harlowja:

[[Category:Commonlibraries]]
[[File:Oslo-moose-color.svg|200px|thumbnail|right|OpenStack Oslo Logo]]

'''Official Title:''' OpenStack Common Libraries 

'''PTL:''' Davanum Srinivas <davanum@gmail.com> 

'''Mission Statement:''' <blockquote>To produce a set of python libraries containing code shared by OpenStack projects. The APIs provided by these libraries should be high quality, stable, consistent, documented and generally applicable.</blockquote>

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

[https://review.openstack.org/#/admin/groups/106,members 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 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 once the API is stable they help graduate the code to a library so it can be adopted by projects needing the functionality.

Each library has its own core team, which can include specialists in the area of the library who are not general Oslo cores. Because the scope of the Oslo project has grown so large, these library-specific cores are critical to the long-term health of the projects and anyone with an interest in a library is encouraged to get involved.

=== Project Meetings ===

See [[Meetings/Oslo]].

=== Getting in Touch ===

We use the [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev openstack-dev@lists.openstack.org] mailing list for discussions and we all hang out in #openstack-oslo and #openstack-dev on freenode.

Each project also designates a liaison for handling integration issues. See [[Oslo/ProjectLiaisons]].

== Libraries ==

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 (aka prefix them with oslo).

New libraries need to be careful to avoid introducing circular dependencies. See [[Oslo/Dependencies]].

Specialized libraries have their own core-review team with members who may not be part of the main Oslo core team. Unless otherwise indicated below, an Oslo library is maintained by [https://review.openstack.org/#/admin/groups/106 oslo-core].

=== automaton ===

[https://review.openstack.org/#/c/141961/ Proposal]

[http://git.openstack.org/cgit/openstack/automaton automaton] is a framework for building state machines.

Please file bugs in the [https://bugs.launchpad.net/automaton automaton project in launchpad].

=== cliff ===

[http://git.openstack.org/cgit/openstack/cliff cliff] is a framework for building command line programs.

Core review team: [https://review.openstack.org/#/admin/groups/258,members cliff-core]

Documentation: [http://docs.openstack.org/developer/cliff/]

Please file bugs in the [https://bugs.launchpad.net/python-cliff python-cliff project in launchpad].

=== cookiecutter ===

[https://review.openstack.org/#/c/42530/ Proposal]

[https://github.com/openstack-dev/cookiecutter cookiecutter] Cookiecutter is a project that creates a skeleton OpenStack project from a set of templates.

Please file bugs in the [https://bugs.launchpad.net/oslo oslo project in launchpad].

=== debtcollector ===

[https://review.openstack.org/#/c/141220/ Proposal]

[https://github.com/openstack/debtcollector debtcollector] A collection of python patterns that help you collect your technical debt in a non-destructive manner (following deprecation patterns and strategies and so-on).

Please file bugs in the [https://bugs.launchpad.net/debtcollector debtcollector project in launchpad].

=== futurist ===

[https://review.openstack.org/#/c/179890/ Proposal]

[https://github.com/openstack/futurist futurist] A collection of async functionality and additions from the future.

Please file bugs in the [https://bugs.launchpad.net/futurist futurist project in launchpad].

=== osprofiler ===

[https://review.openstack.org/#/c/103825/ Proposal]

[https://github.com/openstack/osprofiler OsProfiler] is an OpenStack cross-project profiling library.

Please file bugs in the [https://bugs.launchpad.net/osprofiler osprofiler project in launchpad].

=== oslo.cache ===

A library for caching based on [https://pypi.python.org/pypi/dogpile.cache dogpile].

Please file bugs in the [https://bugs.launchpad.net/oslo.cache oslo.cache project in launchpad].

=== oslo.concurrency ===

A library for managing external processes and task synchronization.

Please file bugs in the [https://bugs.launchpad.net/oslo.concurrency oslo.concurrency project in launchpad].

=== oslo.context ===

[http://pypi.python.org/pypi/oslo.context oslo.context] has helpers to maintain useful information
about a request context.

Please file bugs in the [https://bugs.launchpad.net/oslo.context oslo.context project in launchpad].

See [https://wiki.openstack.org/wiki/Oslo/Context this historical blueprint] describing the initial requirements for the API.

=== oslo.config ===

[http://pypi.python.org/pypi/oslo.config oslo.config] is a library for parsing configuration files and command line arguments.

Please file bugs in the [https://bugs.launchpad.net/oslo.config oslo.config project in launchpad].

See [https://wiki.openstack.org/wiki/Oslo/Config this historical blueprint] describing the initial requirements for the API.

=== oslo-cookiecutter ===

[https://github.com/openstack-dev/oslo-cookiecutter cookiecutter] oslo-cookiecutter creates a skeleton Oslo library from a set of templates.

Please file bugs in the [https://bugs.launchpad.net/oslo-cookiecutter oslo-cookiecutter project in launchpad].

=== oslo.db ===

[https://github.com/openstack/oslo.db oslo.db] is an Oslo database handling library.

Core review team: [https://review.openstack.org/#/admin/groups/331,members oslo-db-core]

Please file bugs in the [https://bugs.launchpad.net/oslo.db oslo.db project in launchpad].

=== oslo.i18n ===

oslo.i18n is a wrapper around Python's gettext module for string translation and other internationalization features.

Please file bugs in the [https://bugs.launchpad.net/oslo.i18n oslo.i18n project in launchpad]

=== oslo.log ===

[http://git.openstack.org/cgit/openstack/oslo.log/ oslo.log] is a logging configuration library.

Please file bugs and blueprints in the [https://bugs.launchpad.net/oslo.log oslo.log project in launchpad].

=== oslo.messaging ===

The [https://github.com/openstack/oslo.messaging oslo.messaging] provides a messaging API which supports RPC and notifications over a number of different messaging transports.

Bugs and blueprints should be filed using the [https://launchpad.net/oslo.messaging oslo.messaging launchpad project].

Core review team: [https://review.openstack.org/#/admin/groups/318 oslo-messaging-core]

[https://etherpad.openstack.org/HavanaOsloMessaging This etherpad] captures the latest status and background to this project.

=== oslo.middleware ===

A collection of WSGI middleware for web service development

Please file bugs in the [https://bugs.launchpad.net/oslo.middleware oslo.middleware project in launchpad].

=== oslo.policy ===

Rules engine for enforcing policy

Please file bugs in the [https://bugs.launchpad.net/oslo.policy oslo.policy project in launchpad].

=== oslo.privsep ===

[http://git.openstack.org/cgit/openstack/oslo.privsep oslo.privsep] is a mechanism for running selected python code with elevated privileges

Please file bugs in the [https://bugs.launchpad.net/oslo.privsep oslo.privsep project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/1135 oslo-privsep-core]

=== oslo.reports ===

[http://git.openstack.org/cgit/openstack/oslo.reports oslo.reports] allows projects to generate Guru Meditation Reports for debugging the current state of OpenStack processes. It can also be used to generating general reports on the fly that are serializable as plain text, JSON, or XML.

Please file bugs in the [https://bugs.launchpad.net/oslo.reports oslo.reports project in launchpad].

=== oslo.rootwrap ===

[http://git.openstack.org/cgit/openstack/oslo.rootwrap oslo.rootwrap] Rootwrap allows fine filtering of shell commands to run as root from OpenStack services.

Please file bugs in the [https://bugs.launchpad.net/oslo.rootwrap oslo.rootwrap project in launchpad]

Core review team: [https://review.openstack.org/#/admin/groups/293 oslo-rootwrap-core]

=== oslo.serialization ===

[http://git.openstack.org/cgit/openstack/oslo.serialization oslo.serialization] provides serialization functionality with special handling for some common types used in OpenStack.

Please file bugs in the [https://bugs.launchpad.net/oslo.serialization oslo.serialization project in launchpad].

=== oslo.service ===

[http://git.openstack.org/cgit/openstack/oslo.service oslo.service] provides functionality for running OpenStack services.

Please file bugs in the [https://bugs.launchpad.net/oslo.service oslo.service project in launchpad].

=== oslosphinx ===

[https://github.com/openstack/oslosphinx oslosphinx] provides theme and extension support for Sphinx documentation from the OpenStack project. It is maintained by Doug Hellmann.

Please file bugs in the [https://bugs.launchpad.net/oslosphinx oslosphinx project in launchpad].

=== oslotest ===

[http://git.openstack.org/cgit/openstack/oslotest oslotest] provide base classes and fixtures for creating unit and functional tests.

Please file bugs in the [https://bugs.launchpad.net/oslotest oslotest project in launchpad].

=== oslo.utils ===

A library of various low-level utility modules.

Please file bugs in the [https://bugs.launchpad.net/oslo.utils oslo.utils project in launchpad].

=== oslo.versionedobjects ===

[https://github.com/openstack/oslo.versionedobjects oslo.versionedobjects] deals with DB schema being at different versions than the code expects, allowing services to be operated safely during upgrades.

Please file bugs in the [https://bugs.launchpad.net/oslo.versionedobjects oslo.versionedobjects project in launchpad].

=== oslo.version ===

[https://review.openstack.org/#/c/40498/ Proposal]

[https://github.com/openstack/oslo.version oslo.version] handles getting the version for an installed piece of software from the python metadata that already exists. It is maintained by Monty Taylor.

Please file bugs in the [https://bugs.launchpad.net/oslo oslo project in launchpad].

=== oslo.vmware ===

Code common to the VMware drivers in several projects.

Please file bugs in the [https://bugs.launchpad.net/oslo.vmware oslo.vmware project in launchpad].

=== pylockfile ===

**Depreciated**

Inter-process lock management library.

Please file bugs in the [https://bugs.launchpad.net/pylockfile pylockfile project in launchpad].

=== hacking ===

[https://pypi.python.org/pypi/hacking 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 [https://bugs.launchpad.net/hacking hacking project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/153 hacking-core]

=== pbr ===

[https://pypi.python.org/pypi/pbr pbr] (or Python Build Reasonableness) is a set of sensible default setuptools behaviours.

Please file bugs in the [https://bugs.launchpad.net/pbr pbr project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/154 pbr-core]

=== pyCADF ===

[http://git.openstack.org/cgit/openstack/pycadf pyCADF] is a python implementation of the DMTF Cloud Audit (CADF) data model.

Please file bugs in the [https://bugs.launchpad.net/pycadf pycadf project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/192 pycadf-core]

=== stevedore ===

[http://git.openstack.org/cgit/openstack/stevedore stevedore] is a library for managing plugins for Python applications.

Please file bugs in the [https://bugs.launchpad.net/python-stevedore python-stevedore project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/247 stevedore-core]

=== taskflow ===

[https://pypi.python.org/pypi/taskflow taskflow] is a library that helps create applications that handle state/failures... in a reasonable manner. It is maintained by [https://launchpad.net/~taskflow-dev taskflow-dev]

More details can be found at: https://wiki.openstack.org/TaskFlow

Please file bugs in the [https://bugs.launchpad.net/taskflow taskflow project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/173 taskflow-core]

=== tooz ===

[https://pypi.python.org/pypi/tooz tooz] is a library that aims at centralizing the most common distributed primitives like group membership protocol, lock service and leader election by providing a coordination API helping developers to build distributed applications.

Please file bugs in the [https://bugs.launchpad.net/python-tooz python-tooz project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/246,members]

== Principles ==

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

== Incubation ==

'''The Oslo Incubator is now dead. Refer to the [https://openstack.nimeyo.com/65080/openstack-dev-last-sync-from-oslo-incubator announcement] and the [https://review.openstack.org/#/c/245461/ change clearing out the repository].'''

== FAQs ==

=== Why aren't alpha releases of oslo.config published to PyPI? ===

See [http://specs.openstack.org/openstack/oslo-specs/specs/policy/versioning.html Choosing Version Numbers] for the current policies related to versioning and releases.

=== Why does oslo.config have a CONF object? Global object SUCK! ===

Indeed. Well, it's a long story and well documented in mailing list archives if anyone cares to dig up some links.

Around the time of the Folsom Design Summit, an attempt was made to remove our dependence on a global object like this. There was massive debate and, in the end, the rough consensus was to stick with using this approach.

Nova, through its use of the gflags library, used this approach from [https://github.com/openstack/nova/blob/bf6e6e7/nova/flags.py#L27 commit zero]. Some OpenStack projects didn't initially use this approach, but most now do. The idea is that having all projects use the same approach is more important than the objections to the approach. Sharing code between projects is great, but by also having projects use the same idioms for stuff like this it makes it much easier for people to work on multiple projects.

This debate will probably never completely go away, though. See [http://lists.openstack.org/pipermail/openstack-dev/2014-August/044050.html this latest discussion in August, 2014].

=== Why does Oslo observe feature freeze ===

Feature freeze is a time to stabilize all of the new features that were added during a development cycle, but since Oslo projects don't necessarily release on the same six month schedule as the other OpenStack projects (or at all in the case of oslo-incubator) it might seem odd that Oslo observes feature freeze.

For the graduated libraries this serves the same purpose as for any of the other projects - it's a time for focusing on bug fixes and stability.

For oslo-incubator, the primary motivation is making last-minute fixes needed by other projects easier to sync. If a new feature lands in oslo-incubator and an unrelated bug is discovered by one of the consuming projects, it becomes a problem to sync just the bug fix to the project. When 11th hour bug fixes are needed it's best if the sync is as simple and small as possible. To avoid problems, oslo-incubator respects the feature freeze period just like any other project.

=== How does Oslo manage versions? ===

See [[Oslo/VersioningPolicy]].

== Resources ==

=== Review policies ===

These overlay the regular review rules for OpenStack as a whole.

* Automated changes - patches from 'openstack proposal bot' and 'transifex' which have passed CI checks can be +2+A by a single core reviewer

=== Review Links ===

(See http://git.openstack.org/cgit/openstack/oslo-incubator/tree/dashboards for the source files to create these links)

* [https://review.openstack.org/#/dashboard/?foreach=%28project%3A%5Eopenstack%2F.%2Aoslo.%2A+OR+project%3A%5Eopenstack%2Ddev%2F.%2Aoslo.%2A+OR%0Aproject%3Aopenstack%2Fdebtcollector+OR+project%3Aopenstack%2Fpylockfile+OR%0Aproject%3Aopenstack%2Ffuturist+OR+project%3Aopenstack%2Fautomaton+OR%0Aproject%3Aopenstack%2Fstevedore+OR+project%3Aopenstack%2Ftaskflow+OR%0Aproject%3Aopenstack%2Ftooz+OR+project%3Aopenstack%2Ddev%2Fcookiecutter+OR%0Aproject%3Aopenstack%2Ddev%2Fpbr+OR+project%3Aopenstack%2Fdebtcollector+OR%0Aproject%3Aopenstack%2Fmox3%29%0Astatus%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%2D1+label%3AVerified%3E%3D1%0ANOT+label%3ACode%2DReview%3C%3D%2D1%2Cself+NOT+label%3ACode%2DReview%3E%3D1%2Cself&title=Oslo+Review+Inbox&Oslo+Specs=project%3Aopenstack%2Foslo%2Dspecs&Bug+Fixes=topic%3A%5Ebug%2F.%2A&Blueprints=message%3A%22Blueprint%22&Needs+Feedback+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode%2DReview%3C%3D2+age%3A5d&You+are+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=reviewer%3Aself&Needs+final+%2B2=label%3ACode%2DReview%3E%3D2+limit%3A50&New+Contributors=reviewer%3A10068&Passed+Jenkins%2C+No+Negative+Feedback=NOT+label%3ACode%2DReview%3E%3D2+NOT+label%3ACode%2DReview%3C%3D%2D1+limit%3A50&Wayward+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+label%3ACode%2DReview%3C%3D2+age%3A2d Oslo Review Dashboard]
* [https://review.openstack.org/#/dashboard/?foreach=is%3Aopen+branch%3Amaster+file%3A%5E.%2Aopenstack%2Fcommon.%2A+status%3Aopen%0ANOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%252D1+label%3AVerified%3E%3D1%252cjenkins%0ANOT+label%3ACode%252DReview%3C%3D%252D1%252cself+NOT+label%3ACode%252DReview%3E%3D1%252cself&title=Oslo+Sync+Review+Inbox&Integrated+Projects=NOT+project%3Aopenstack%2Foslo%252Dincubator+project%3A%5Eopenstack%2F.%2A%0ANOT+project%3A%5Eopenstack%2Fpython%252D.%2Aclient&Clients=project%3A%5Eopenstack%2Fpython%252D.%2Aclient&Stackforge+Projects=project%3A%5Estackforge%2F.%2A Oslo Syncs in Other Projects]
* [https://review.openstack.org/#/dashboard/?foreach=is%3Aopen&title=Oslo+Graduation+Changes&Graduating+Libraries=%28project%3Aopenstack%2Foslo.versionedobjects+OR%0Aproject%3Aopenstack%2Foslo.service+OR+project%3Aopenstack%2Foslo.reports+OR%0Aproject%3Aopenstack%2Foslo.cache+OR+project%3Aopenstack%2Foslo.service%29%0ANOT+owner%3Aself%0ANOT+label%3AWorkflow%3C%3D%252D1%0Alabel%3AVerified%3E%3D1&New+Libraries=%28project%3Aopenstack%2Ffuturist+OR%0Aproject%3Aopenstack%2Fautomaton%29%0ANOT+owner%3Aself%0ANOT+label%3AWorkflow%3C%3D%252D1%0Alabel%3AVerified%3E%3D1&Incubator=project%3Aopenstack%2Foslo%252Dincubator+topic%3A%5E.%2Agraduate.%2A&openstack%252Dinfra%2F%2A=project%3A%5Eopenstack%252Dinfra%2F.%2A++message%3A%22+oslo%22&openstack%252Ddev%2F%2A=project%3A%5Eopenstack%252Ddev%2F.%2A++message%3A%22+oslo%22&governance=project%3Aopenstack%2Fgovernance++message%3A%22+oslo%22 Graduation Work]
* [https://bugs.launchpad.net/oslo/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=INPROGRESS&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on In Progress Bugs]

=== Security Team ===

In addition to OpenStack's Vulnerability Management team, some members of the Oslo team have indicated their willingness to help with security related issues in Oslo code. See [[Oslo/Security]] for the current list.

=== Design Proposals ===

We use the [http://git.openstack.org/cgit/openstack/oslo-specs oslo-specs repo] to track design proposals across all Oslo projects.

See [http://specs.openstack.org/openstack/oslo-specs/specs/policy/spec-approval.html the Spec Approval policy] for details.

The [https://blueprints.launchpad.net/oslo blueprints on launchpad] detail the changes currently underway to implement these specs.

[http://specs.openstack.org/openstack/oslo-specs/ Approved Specs] are published separately.

=== Release Instructions ===

[[Oslo/ReleaseProcess]]

=== Newton ===

* [https://etherpad.openstack.org/p/newton-oslo-summit-planning Newton Summit Planning etherpads]

=== Mitaka ===

* [https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Oslo Mitaka Summit Planning etherpads]

=== Liberty ===

* [https://etherpad.openstack.org/p/liberty-oslo-summit-planning Liberty Summit Planning etherpad]

=== Kilo ===

* [[Summit/Kilo/Etherpads#Oslo]]

=== Juno ===

* [[Oslo/JunoGraduationPlans]]

=== Juno Etherpads ===

* [https://etherpad.openstack.org/p/juno-infra-library-testing|Testing pre-releases of Oslo libs with apps]

=== Icehouse Etherpads ===

Etherpads from sessions at the Icehouse Design summit.

* [https://etherpad.openstack.org/p/icehouse-oslo-pecan-wsme-tips Creating REST services with Pecan/WSME]
* [https://etherpad.openstack.org/p/icehouse-oslo-openstack-client-update OpenStack Client Update]
* [https://etherpad.openstack.org/p/icehouse-oslo-hacking-updates Updates to hacking, our code style enforcement tool]
* [https://etherpad.openstack.org/p/icehouse-oslo-i18n-policies I18n policies of messages]
* [https://etherpad.openstack.org/p/IcehouseOsloMessaging oslo.messaging - API design, plans for Icehouse]
* [https://etherpad.openstack.org/p/icehouse-oslo-config-import-side-effects oslo.config enhancements, including removing import side-effects from consumers]
* [https://etherpad.openstack.org/p/icehouse-oslo-rootwrap Rootwrap: Icehouse plans]
* [https://etherpad.openstack.org/p/icehouse-oslo-db-migrations State of affairs in DB schema migrations]
* [https://etherpad.openstack.org/p/icehouse-oslo-structured-notifications Towards more structured & qualified notifications]
* [https://etherpad.openstack.org/p/icehouse-oslo-logging-and-notifications Merge logging and notifications]
* [https://etherpad.openstack.org/p/icehouse-oslo-service-synchronization Writing a service synchronisation library]
* [https://etherpad.openstack.org/p/icehouse-oslo-status Oslo incubated libraries status]
* [https://etherpad.openstack.org/p/icehouse-oslo-splitting-the-incubator Aggressively split oslo-incubator]

=== Messaging Related Work in Havana ===

During the Havana cycle, work is going on to [https://wiki.openstack.org/wiki/Oslo/Messaging re-design our messaging APIs] and to [https://wiki.openstack.org/wiki/MessageSecurity add signatures and encryption to our messages].

See [https://etherpad.openstack.org/HavanaOsloMessaging this etherpad] for yet more details.

=== Havana Etherpads ===

Etherpads from sessions at the Havana Design summit.

* [https://etherpad.openstack.org/havana-oslo Oslo Status and Plans]
* [https://etherpad.openstack.org/havana-common-wsgi Pecan/WSME Status]
* [https://etherpad.openstack.org/HavanaNoDowntimeDBMigrations No-downtime DB migrations]
* [https://etherpad.openstack.org/HavanaRootwrap Rootwrap improvements for the Havana cycle]
* [https://etherpad.openstack.org/havana-oslo-packaging-and-hacking Common packaging support and code analysis tools]
* [https://etherpad.openstack.org/havana-rpc-api-review RPC API review]
* [https://etherpad.openstack.org/havana-rpc-zmq-for-ceilometer-and-quantum ZeroMQ RPC for Ceilometer and Quantum]
* [https://etherpad.openstack.org/havana-rpc-access-control Message queue access control]
* [https://etherpad.openstack.org/havana-rpc-signing-and-encryption RPC Message Signing and Encryption]
* [https://etherpad.openstack.org/zipkin-tracing Zipkin tracing in OpenStack]
* [https://etherpad.openstack.org/havana-oslo-i18n-strategy i18n strategy for OpenStack services]
* [https://etherpad.openstack.org/havana-common-xenapi-library Common XenAPI libary]

=== Grizzly Etherpads ===

Etherpads from sessions at the Grizzly Design summit.

* [http://etherpad.openstack.org/grizzly-oslo Oslo status and plans]
* [http://etherpad.openstack.org/grizzly-common-unified-cli Unified CLI, take 2]
* [http://etherpad.openstack.org/grizzly-common-rpc-security Adding optional security to RPC]
* [http://etherpad.openstack.org/grizzly-common-services-control Services framework for command and control]
* [http://etherpad.openstack.org/grizzly-common-messaging Using the message bus for messaging]
* [http://etherpad.openstack.org/grizzly-common-wsgi-frameworks Choosing a WSGI framework for API services]
* [http://etherpad.openstack.org/grizzly-common-xml-processing XML request/response processing]
* [http://etherpad.openstack.org/grizzly-common-entrypoints-plugins Entrypoints based plugins]
* [http://etherpad.openstack.org/grizzly-common-rootwrap-and-keyring Unified rootwrap & password management]
* [http://etherpad.openstack.org/grizzly-common-db A common database]
* [http://etherpad.openstack.org/grizzly-common-instrumentation Instrumentation monitoring]

=== Folsom Etherpads ===

Etherpads from sessions at the Folsom Design summit.

* [https://etherpad.openstack.org/FolsomOpenStackCommon openstack-common]
* [https://etherpad.openstack.org/FolsomDependencyManagement Dependency management]

Oslo

2016-03-21T17:54:32Z

Harlowja:

[[Category:Commonlibraries]]
[[File:Oslo-moose-color.svg|250px|thumbnail|right|OpenStack Oslo Logo]]

'''Official Title:''' OpenStack Common Libraries 

'''PTL:''' Davanum Srinivas <davanum@gmail.com> 

'''Mission Statement:''' <blockquote>To produce a set of python libraries containing code shared by OpenStack projects. The APIs provided by these libraries should be high quality, stable, consistent, documented and generally applicable.</blockquote>

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

[https://review.openstack.org/#/admin/groups/106,members 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 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 once the API is stable they help graduate the code to a library so it can be adopted by projects needing the functionality.

Each library has its own core team, which can include specialists in the area of the library who are not general Oslo cores. Because the scope of the Oslo project has grown so large, these library-specific cores are critical to the long-term health of the projects and anyone with an interest in a library is encouraged to get involved.

=== Project Meetings ===

See [[Meetings/Oslo]].

=== Getting in Touch ===

We use the [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev openstack-dev@lists.openstack.org] mailing list for discussions and we all hang out in #openstack-oslo and #openstack-dev on freenode.

Each project also designates a liaison for handling integration issues. See [[Oslo/ProjectLiaisons]].

== Libraries ==

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.

New libraries need to be careful to avoid introducing circular dependencies. See [[Oslo/Dependencies]].

Specialized libraries have their own core-review team with members who may not be part of the main Oslo core team. Unless otherwise indicated below, an Oslo library is maintained by [https://review.openstack.org/#/admin/groups/106 oslo-core].

=== automaton ===

[https://review.openstack.org/#/c/141961/ Proposal]

[http://git.openstack.org/cgit/openstack/automaton automaton] is a framework for building state machines.

Please file bugs in the [https://bugs.launchpad.net/automaton automaton project in launchpad].

=== cliff ===

[http://git.openstack.org/cgit/openstack/cliff cliff] is a framework for building command line programs.

Core review team: [https://review.openstack.org/#/admin/groups/258,members cliff-core]

Documentation: [http://docs.openstack.org/developer/cliff/]

Please file bugs in the [https://bugs.launchpad.net/python-cliff python-cliff project in launchpad].

=== cookiecutter ===

[https://review.openstack.org/#/c/42530/ Proposal]

[https://github.com/openstack-dev/cookiecutter cookiecutter] Cookiecutter is a project that creates a skeleton OpenStack project from a set of templates.

Please file bugs in the [https://bugs.launchpad.net/oslo oslo project in launchpad].

=== debtcollector ===

[https://review.openstack.org/#/c/141220/ Proposal]

[https://github.com/openstack/debtcollector debtcollector] A collection of python patterns that help you collect your technical debt in a non-destructive manner (following deprecation patterns and strategies and so-on).

Please file bugs in the [https://bugs.launchpad.net/debtcollector debtcollector project in launchpad].

=== futurist ===

[https://review.openstack.org/#/c/179890/ Proposal]

[https://github.com/openstack/futurist futurist] A collection of async functionality and additions from the future.

Please file bugs in the [https://bugs.launchpad.net/futurist futurist project in launchpad].

=== osprofiler ===

[https://github.com/openstack/osprofiler OsProfiler] is an OpenStack cross-project profiling library.

Please file bugs in the [https://bugs.launchpad.net/osprofiler osprofiler project in launchpad].

=== oslo.cache ===

A library for caching based on dogpile.

Please file bugs in the [https://bugs.launchpad.net/oslo.cache oslo.cache project in launchpad].

=== oslo.concurrency ===

A library for managing external processes and task synchronization.

Please file bugs in the [https://bugs.launchpad.net/oslo.concurrency oslo.concurrency project in launchpad].

=== oslo.context ===

[http://pypi.python.org/pypi/oslo.context oslo.context] has helpers to maintain useful information
about a request context

Please file bugs in the [https://bugs.launchpad.net/oslo.context oslo.context project in launchpad].

See [https://wiki.openstack.org/wiki/Oslo/Context this historical blueprint] describing the initial requirements for the API.

=== oslo.config ===

[http://pypi.python.org/pypi/oslo.config oslo.config] is a library for parsing configuration files and command line arguments.

Please file bugs in the [https://bugs.launchpad.net/oslo.config oslo.config project in launchpad].

See [https://wiki.openstack.org/wiki/Oslo/Config this historical blueprint] describing the initial requirements for the API.

=== oslo-cookiecutter ===

[https://github.com/openstack-dev/oslo-cookiecutter cookiecutter] oslo-cookiecutter creates a skeleton Oslo library from a set of templates.

Please file bugs in the [https://bugs.launchpad.net/oslo-cookiecutter oslo-cookiecutter project in launchpad].

=== oslo.db ===

[https://github.com/openstack/oslo.db oslo.db] is an Oslo database handling library.

Core review team: [https://review.openstack.org/#/admin/groups/331,members oslo-db-core]

Please file bugs in the [https://bugs.launchpad.net/oslo.db oslo.db project in launchpad].

=== oslo.i18n ===

oslo.i18n is a wrapper around Python's gettext module for string translation and other internationalization features.

Please file bugs in the [https://bugs.launchpad.net/oslo.i18n oslo.i18n project in launchpad]

=== oslo.log ===

[http://git.openstack.org/cgit/openstack/oslo.log/ oslo.log] is a logging configuration library.

Please file bugs and blueprints in the [https://bugs.launchpad.net/oslo.log oslo.log project in launchpad].

=== oslo.messaging ===

The [https://github.com/openstack/oslo.messaging oslo.messaging] provides a messaging API which supports RPC and notifications over a number of different messaging transports.

Bugs and blueprints should be filed using the [https://launchpad.net/oslo.messaging oslo.messaging launchpad project].

Core review team: [https://review.openstack.org/#/admin/groups/318 oslo-messaging-core]

[https://etherpad.openstack.org/HavanaOsloMessaging This etherpad] captures the latest status and background to this project.

=== oslo.middleware ===

A collection of WSGI middleware for web service development

Please file bugs in the [https://bugs.launchpad.net/oslo.middleware oslo.middleware project in launchpad].

=== oslo.policy ===

Rules engine for enforcing policy

Please file bugs in the [https://bugs.launchpad.net/oslo.policy oslo.policy project in launchpad].

=== oslo.privsep ===

[http://git.openstack.org/cgit/openstack/oslo.privsep oslo.privsep] is a mechanism for running selected python code with elevated privileges

Please file bugs in the [https://bugs.launchpad.net/oslo.privsep oslo.privsep project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/1135 oslo-privsep-core]

=== oslo.reports ===

[http://git.openstack.org/cgit/openstack/oslo.reports oslo.reports] allows projects to generate Guru Meditation Reports for debugging the current state of OpenStack processes. It can also be used to generating general reports on the fly that are serializable as plain text, JSON, or XML.

Please file bugs in the [https://bugs.launchpad.net/oslo.reports oslo.reports project in launchpad].

=== oslo.rootwrap ===

[http://git.openstack.org/cgit/openstack/oslo.rootwrap oslo.rootwrap] Rootwrap allows fine filtering of shell commands to run as root from OpenStack services.

Please file bugs in the [https://bugs.launchpad.net/oslo.rootwrap oslo.rootwrap project in launchpad]

Core review team: [https://review.openstack.org/#/admin/groups/293 oslo-rootwrap-core]

=== oslo.serialization ===

[http://git.openstack.org/cgit/openstack/oslo.serialization oslo.serialization] provides serialization functionality with special handling for some common types used in OpenStack.

Please file bugs in the [https://bugs.launchpad.net/oslo.serialization oslo.serialization project in launchpad].

=== oslo.service ===

[http://git.openstack.org/cgit/openstack/oslo.service oslo.service] provides functionality for running OpenStack services.

Please file bugs in the [https://bugs.launchpad.net/oslo.service oslo.service project in launchpad].

=== oslosphinx ===

[https://github.com/openstack/oslosphinx oslosphinx] provides theme and extension support for Sphinx documentation from the OpenStack project. It is maintained by Doug Hellmann.

Please file bugs in the [https://bugs.launchpad.net/oslosphinx oslosphinx project in launchpad].

=== oslotest ===

[http://git.openstack.org/cgit/openstack/oslotest oslotest] provide base classes and fixtures for creating unit and functional tests.

Please file bugs in the [https://bugs.launchpad.net/oslotest oslotest project in launchpad].

=== oslo.utils ===

A library of various low-level utility modules.

Please file bugs in the [https://bugs.launchpad.net/oslo.utils oslo.utils project in launchpad].

=== oslo.versionedobjects ===

[https://github.com/openstack/oslo.versionedobjects oslo.versionedobjects] deals with DB schema being at different versions than the code expects, allowing services to be operated safely during upgrades.

Please file bugs in the [https://bugs.launchpad.net/oslo.versionedobjects oslo.versionedobjects project in launchpad].

=== oslo.version ===

[https://review.openstack.org/#/c/40498/ Proposal]

[https://github.com/openstack/oslo.version oslo.version] handles getting the version for an installed piece of software from the python metadata that already exists. It is maintained by Monty Taylor.

Please file bugs in the [https://bugs.launchpad.net/oslo oslo project in launchpad].

=== oslo.vmware ===

Code common to the VMware drivers in several projects.

Please file bugs in the [https://bugs.launchpad.net/oslo.vmware oslo.vmware project in launchpad].

=== pylockfile ===

Inter-process lock management library

Please file bugs in the [https://bugs.launchpad.net/pylockfile pylockfile project in launchpad].

=== hacking ===

[https://pypi.python.org/pypi/hacking 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 [https://bugs.launchpad.net/hacking hacking project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/271 oslo-vmware-core]

=== pbr ===

[https://pypi.python.org/pypi/pbr pbr] (or Python Build Reasonableness) is a set of sensible default setuptools behaviours. It is maintained by Monty Taylor.

Please file bugs in the [https://bugs.launchpad.net/pbr pbr project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/154 pbr-core]

=== pyCADF ===

[http://git.openstack.org/cgit/openstack/pycadf pyCADF] is a python implementation of the DMTF Cloud Audit (CADF) data model.

Please file bugs in the [https://bugs.launchpad.net/pycadf pycadf project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/192 pycadf-core]

=== stevedore ===

[http://git.openstack.org/cgit/openstack/stevedore stevedore] is a library for managing plugins for Python applications.

Please file bugs in the [https://bugs.launchpad.net/python-stevedore python-stevedore project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/247 stevedore-core]

=== taskflow ===

[https://pypi.python.org/pypi/taskflow taskflow] is a library that helps create applications that handle state/failures... in a reasonable manner. It is maintained by [https://launchpad.net/~taskflow-dev taskflow-dev]

More details can be found at: https://wiki.openstack.org/TaskFlow

Please file bugs in the [https://bugs.launchpad.net/taskflow taskflow project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/173 taskflow-core]

=== tooz ===

[https://pypi.python.org/pypi/tooz tooz] is a library that aims at centralizing the most common distributed primitives like group membership protocol, lock service and leader election by providing a coordination API helping developers to build distributed applications.

Please file bugs in the [https://bugs.launchpad.net/python-tooz python-tooz project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/246,members]

== Principles ==

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

== Incubation ==

'''The Oslo Incubator is now dead. Refer to the [https://openstack.nimeyo.com/65080/openstack-dev-last-sync-from-oslo-incubator announcement] and the [https://review.openstack.org/#/c/245461/ change clearing out the repository].'''

== FAQs ==

=== Why aren't alpha releases of oslo.config published to PyPI? ===

See [http://specs.openstack.org/openstack/oslo-specs/specs/policy/versioning.html Choosing Version Numbers] for the current policies related to versioning and releases.

=== Why does oslo.config have a CONF object? Global object SUCK! ===

Indeed. Well, it's a long story and well documented in mailing list archives if anyone cares to dig up some links.

Around the time of the Folsom Design Summit, an attempt was made to remove our dependence on a global object like this. There was massive debate and, in the end, the rough consensus was to stick with using this approach.

Nova, through its use of the gflags library, used this approach from [https://github.com/openstack/nova/blob/bf6e6e7/nova/flags.py#L27 commit zero]. Some OpenStack projects didn't initially use this approach, but most now do. The idea is that having all projects use the same approach is more important than the objections to the approach. Sharing code between projects is great, but by also having projects use the same idioms for stuff like this it makes it much easier for people to work on multiple projects.

This debate will probably never completely go away, though. See [http://lists.openstack.org/pipermail/openstack-dev/2014-August/044050.html this latest discussion in August, 2014].

=== Why does Oslo observe feature freeze ===

Feature freeze is a time to stabilize all of the new features that were added during a development cycle, but since Oslo projects don't necessarily release on the same six month schedule as the other OpenStack projects (or at all in the case of oslo-incubator) it might seem odd that Oslo observes feature freeze.

For the graduated libraries this serves the same purpose as for any of the other projects - it's a time for focusing on bug fixes and stability.

For oslo-incubator, the primary motivation is making last-minute fixes needed by other projects easier to sync. If a new feature lands in oslo-incubator and an unrelated bug is discovered by one of the consuming projects, it becomes a problem to sync just the bug fix to the project. When 11th hour bug fixes are needed it's best if the sync is as simple and small as possible. To avoid problems, oslo-incubator respects the feature freeze period just like any other project.

=== How does Oslo manage versions? ===

See [[Oslo/VersioningPolicy]].

== Resources ==

=== Review policies ===

These overlay the regular review rules for OpenStack as a whole.

* Automated changes - patches from 'openstack proposal bot' and 'transifex' which have passed CI checks can be +2+A by a single core reviewer

=== Review Links ===

(See http://git.openstack.org/cgit/openstack/oslo-incubator/tree/dashboards for the source files to create these links)

* [https://review.openstack.org/#/dashboard/?foreach=%28project%3A%5Eopenstack%2F.%2Aoslo.%2A+OR+project%3A%5Eopenstack%2Ddev%2F.%2Aoslo.%2A+OR%0Aproject%3Aopenstack%2Fdebtcollector+OR+project%3Aopenstack%2Fpylockfile+OR%0Aproject%3Aopenstack%2Ffuturist+OR+project%3Aopenstack%2Fautomaton+OR%0Aproject%3Aopenstack%2Fstevedore+OR+project%3Aopenstack%2Ftaskflow+OR%0Aproject%3Aopenstack%2Ftooz+OR+project%3Aopenstack%2Ddev%2Fcookiecutter+OR%0Aproject%3Aopenstack%2Ddev%2Fpbr+OR+project%3Aopenstack%2Fdebtcollector+OR%0Aproject%3Aopenstack%2Fmox3%29%0Astatus%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%2D1+label%3AVerified%3E%3D1%0ANOT+label%3ACode%2DReview%3C%3D%2D1%2Cself+NOT+label%3ACode%2DReview%3E%3D1%2Cself&title=Oslo+Review+Inbox&Oslo+Specs=project%3Aopenstack%2Foslo%2Dspecs&Bug+Fixes=topic%3A%5Ebug%2F.%2A&Blueprints=message%3A%22Blueprint%22&Needs+Feedback+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode%2DReview%3C%3D2+age%3A5d&You+are+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=reviewer%3Aself&Needs+final+%2B2=label%3ACode%2DReview%3E%3D2+limit%3A50&New+Contributors=reviewer%3A10068&Passed+Jenkins%2C+No+Negative+Feedback=NOT+label%3ACode%2DReview%3E%3D2+NOT+label%3ACode%2DReview%3C%3D%2D1+limit%3A50&Wayward+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+label%3ACode%2DReview%3C%3D2+age%3A2d Oslo Review Dashboard]
* [https://review.openstack.org/#/dashboard/?foreach=is%3Aopen+branch%3Amaster+file%3A%5E.%2Aopenstack%2Fcommon.%2A+status%3Aopen%0ANOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%252D1+label%3AVerified%3E%3D1%252cjenkins%0ANOT+label%3ACode%252DReview%3C%3D%252D1%252cself+NOT+label%3ACode%252DReview%3E%3D1%252cself&title=Oslo+Sync+Review+Inbox&Integrated+Projects=NOT+project%3Aopenstack%2Foslo%252Dincubator+project%3A%5Eopenstack%2F.%2A%0ANOT+project%3A%5Eopenstack%2Fpython%252D.%2Aclient&Clients=project%3A%5Eopenstack%2Fpython%252D.%2Aclient&Stackforge+Projects=project%3A%5Estackforge%2F.%2A Oslo Syncs in Other Projects]
* [https://review.openstack.org/#/dashboard/?foreach=is%3Aopen&title=Oslo+Graduation+Changes&Graduating+Libraries=%28project%3Aopenstack%2Foslo.versionedobjects+OR%0Aproject%3Aopenstack%2Foslo.service+OR+project%3Aopenstack%2Foslo.reports+OR%0Aproject%3Aopenstack%2Foslo.cache+OR+project%3Aopenstack%2Foslo.service%29%0ANOT+owner%3Aself%0ANOT+label%3AWorkflow%3C%3D%252D1%0Alabel%3AVerified%3E%3D1&New+Libraries=%28project%3Aopenstack%2Ffuturist+OR%0Aproject%3Aopenstack%2Fautomaton%29%0ANOT+owner%3Aself%0ANOT+label%3AWorkflow%3C%3D%252D1%0Alabel%3AVerified%3E%3D1&Incubator=project%3Aopenstack%2Foslo%252Dincubator+topic%3A%5E.%2Agraduate.%2A&openstack%252Dinfra%2F%2A=project%3A%5Eopenstack%252Dinfra%2F.%2A++message%3A%22+oslo%22&openstack%252Ddev%2F%2A=project%3A%5Eopenstack%252Ddev%2F.%2A++message%3A%22+oslo%22&governance=project%3Aopenstack%2Fgovernance++message%3A%22+oslo%22 Graduation Work]
* [https://bugs.launchpad.net/oslo/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=INPROGRESS&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on In Progress Bugs]

=== Security Team ===

In addition to OpenStack's Vulnerability Management team, some members of the Oslo team have indicated their willingness to help with security related issues in Oslo code. See [[Oslo/Security]] for the current list.

=== Design Proposals ===

We use the [http://git.openstack.org/cgit/openstack/oslo-specs oslo-specs repo] to track design proposals across all Oslo projects.

See [http://specs.openstack.org/openstack/oslo-specs/specs/policy/spec-approval.html the Spec Approval policy] for details.

The [https://blueprints.launchpad.net/oslo blueprints on launchpad] detail the changes currently underway to implement these specs.

[http://specs.openstack.org/openstack/oslo-specs/ Approved Specs] are published separately.

=== Release Instructions ===

[[Oslo/ReleaseProcess]]

=== Mitaka ===

* [https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Oslo Mitaka Summit Planning etherpads]

=== Liberty ===

* [https://etherpad.openstack.org/p/liberty-oslo-summit-planning Liberty Summit Planning etherpad]

=== Kilo ===

* [[Summit/Kilo/Etherpads#Oslo]]

=== Juno ===

* [[Oslo/JunoGraduationPlans]]

=== Juno Etherpads ===

* [https://etherpad.openstack.org/p/juno-infra-library-testing|Testing pre-releases of Oslo libs with apps]

=== Icehouse Etherpads ===

Etherpads from sessions at the Icehouse Design summit.

* [https://etherpad.openstack.org/p/icehouse-oslo-pecan-wsme-tips Creating REST services with Pecan/WSME]
* [https://etherpad.openstack.org/p/icehouse-oslo-openstack-client-update OpenStack Client Update]
* [https://etherpad.openstack.org/p/icehouse-oslo-hacking-updates Updates to hacking, our code style enforcement tool]
* [https://etherpad.openstack.org/p/icehouse-oslo-i18n-policies I18n policies of messages]
* [https://etherpad.openstack.org/p/IcehouseOsloMessaging oslo.messaging - API design, plans for Icehouse]
* [https://etherpad.openstack.org/p/icehouse-oslo-config-import-side-effects oslo.config enhancements, including removing import side-effects from consumers]
* [https://etherpad.openstack.org/p/icehouse-oslo-rootwrap Rootwrap: Icehouse plans]
* [https://etherpad.openstack.org/p/icehouse-oslo-db-migrations State of affairs in DB schema migrations]
* [https://etherpad.openstack.org/p/icehouse-oslo-structured-notifications Towards more structured & qualified notifications]
* [https://etherpad.openstack.org/p/icehouse-oslo-logging-and-notifications Merge logging and notifications]
* [https://etherpad.openstack.org/p/icehouse-oslo-service-synchronization Writing a service synchronisation library]
* [https://etherpad.openstack.org/p/icehouse-oslo-status Oslo incubated libraries status]
* [https://etherpad.openstack.org/p/icehouse-oslo-splitting-the-incubator Aggressively split oslo-incubator]

=== Messaging Related Work in Havana ===

During the Havana cycle, work is going on to [https://wiki.openstack.org/wiki/Oslo/Messaging re-design our messaging APIs] and to [https://wiki.openstack.org/wiki/MessageSecurity add signatures and encryption to our messages].

See [https://etherpad.openstack.org/HavanaOsloMessaging this etherpad] for yet more details.

=== Havana Etherpads ===

Etherpads from sessions at the Havana Design summit.

* [https://etherpad.openstack.org/havana-oslo Oslo Status and Plans]
* [https://etherpad.openstack.org/havana-common-wsgi Pecan/WSME Status]
* [https://etherpad.openstack.org/HavanaNoDowntimeDBMigrations No-downtime DB migrations]
* [https://etherpad.openstack.org/HavanaRootwrap Rootwrap improvements for the Havana cycle]
* [https://etherpad.openstack.org/havana-oslo-packaging-and-hacking Common packaging support and code analysis tools]
* [https://etherpad.openstack.org/havana-rpc-api-review RPC API review]
* [https://etherpad.openstack.org/havana-rpc-zmq-for-ceilometer-and-quantum ZeroMQ RPC for Ceilometer and Quantum]
* [https://etherpad.openstack.org/havana-rpc-access-control Message queue access control]
* [https://etherpad.openstack.org/havana-rpc-signing-and-encryption RPC Message Signing and Encryption]
* [https://etherpad.openstack.org/zipkin-tracing Zipkin tracing in OpenStack]
* [https://etherpad.openstack.org/havana-oslo-i18n-strategy i18n strategy for OpenStack services]
* [https://etherpad.openstack.org/havana-common-xenapi-library Common XenAPI libary]

=== Grizzly Etherpads ===

Etherpads from sessions at the Grizzly Design summit.

* [http://etherpad.openstack.org/grizzly-oslo Oslo status and plans]
* [http://etherpad.openstack.org/grizzly-common-unified-cli Unified CLI, take 2]
* [http://etherpad.openstack.org/grizzly-common-rpc-security Adding optional security to RPC]
* [http://etherpad.openstack.org/grizzly-common-services-control Services framework for command and control]
* [http://etherpad.openstack.org/grizzly-common-messaging Using the message bus for messaging]
* [http://etherpad.openstack.org/grizzly-common-wsgi-frameworks Choosing a WSGI framework for API services]
* [http://etherpad.openstack.org/grizzly-common-xml-processing XML request/response processing]
* [http://etherpad.openstack.org/grizzly-common-entrypoints-plugins Entrypoints based plugins]
* [http://etherpad.openstack.org/grizzly-common-rootwrap-and-keyring Unified rootwrap & password management]
* [http://etherpad.openstack.org/grizzly-common-db A common database]
* [http://etherpad.openstack.org/grizzly-common-instrumentation Instrumentation monitoring]

=== Folsom Etherpads ===

Etherpads from sessions at the Folsom Design summit.

* [https://etherpad.openstack.org/FolsomOpenStackCommon openstack-common]
* [https://etherpad.openstack.org/FolsomDependencyManagement Dependency management]

Oslo

2016-02-29T23:16:33Z

Harlowja: /* Libraries */

[[Category:Commonlibraries]]
'''Official Title:''' OpenStack Common Libraries 

'''PTL:''' Davanum Srinivas <davanum@gmail.com> 

'''Mission Statement:''' <blockquote>To produce a set of python libraries containing code shared by OpenStack projects. The APIs provided by these libraries should be high quality, stable, consistent, documented and generally applicable.</blockquote>

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

[https://review.openstack.org/#/admin/groups/106,members 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 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 once the API is stable they help graduate the code to a library so it can be adopted by projects needing the functionality.

Each library has its own core team, which can include specialists in the area of the library who are not general Oslo cores. Because the scope of the Oslo project has grown so large, these library-specific cores are critical to the long-term health of the projects and anyone with an interest in a library is encouraged to get involved.

=== Project Meetings ===

See [[Meetings/Oslo]].

=== Getting in Touch ===

We use the [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev openstack-dev@lists.openstack.org] mailing list for discussions and we all hang out in #openstack-oslo and #openstack-dev on freenode.

Each project also designates a liaison for handling integration issues. See [[Oslo/ProjectLiaisons]].

== Libraries ==

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.

New libraries need to be careful to avoid introducing circular dependencies. See [[Oslo/Dependencies]].

Specialized libraries have their own core-review team with members who may not be part of the main Oslo core team. Unless otherwise indicated below, an Oslo library is maintained by [https://review.openstack.org/#/admin/groups/106 oslo-core].

=== automaton ===

[https://review.openstack.org/#/c/141961/ Proposal]

[http://git.openstack.org/cgit/openstack/automaton automaton] is a framework for building state machines.

Please file bugs in the [https://bugs.launchpad.net/automaton automaton project in launchpad].

=== cliff ===

[http://git.openstack.org/cgit/openstack/cliff cliff] is a framework for building command line programs.

Core review team: [https://review.openstack.org/#/admin/groups/258,members cliff-core]

Documentation: [http://docs.openstack.org/developer/cliff/]

Please file bugs in the [https://bugs.launchpad.net/python-cliff python-cliff project in launchpad].

=== cookiecutter ===

[https://review.openstack.org/#/c/42530/ Proposal]

[https://github.com/openstack-dev/cookiecutter cookiecutter] Cookiecutter is a project that creates a skeleton OpenStack project from a set of templates.

Please file bugs in the [https://bugs.launchpad.net/oslo oslo project in launchpad].

=== debtcollector ===

[https://review.openstack.org/#/c/141220/ Proposal]

[https://github.com/openstack/debtcollector debtcollector] A collection of python patterns that help you collect your technical debt in a non-destructive manner (following deprecation patterns and strategies and so-on).

Please file bugs in the [https://bugs.launchpad.net/debtcollector debtcollector project in launchpad].

=== futurist ===

[https://review.openstack.org/#/c/179890/ Proposal]

[https://github.com/openstack/futurist futurist] A collection of async functionality and additions from the future.

Please file bugs in the [https://bugs.launchpad.net/futurist futurist project in launchpad].

=== osprofiler ===

[https://github.com/openstack/osprofiler OsProfiler] is an OpenStack cross-project profiling library.

Please file bugs in the [https://bugs.launchpad.net/osprofiler osprofiler project in launchpad].

=== oslo.cache ===

A library for caching based on dogpile.

Please file bugs in the [https://bugs.launchpad.net/oslo.cache oslo.cache project in launchpad].

=== oslo.concurrency ===

A library for managing external processes and task synchronization.

Please file bugs in the [https://bugs.launchpad.net/oslo.concurrency oslo.concurrency project in launchpad].

=== oslo.context ===

[http://pypi.python.org/pypi/oslo.context oslo.context] has helpers to maintain useful information
about a request context

Please file bugs in the [https://bugs.launchpad.net/oslo.context oslo.context project in launchpad].

See [https://wiki.openstack.org/wiki/Oslo/Context this historical blueprint] describing the initial requirements for the API.

=== oslo.config ===

[http://pypi.python.org/pypi/oslo.config oslo.config] is a library for parsing configuration files and command line arguments.

Please file bugs in the [https://bugs.launchpad.net/oslo.config oslo.config project in launchpad].

See [https://wiki.openstack.org/wiki/Oslo/Config this historical blueprint] describing the initial requirements for the API.

=== oslo-cookiecutter ===

[https://github.com/openstack-dev/oslo-cookiecutter cookiecutter] oslo-cookiecutter creates a skeleton Oslo library from a set of templates.

Please file bugs in the [https://bugs.launchpad.net/oslo-cookiecutter oslo-cookiecutter project in launchpad].

=== oslo.db ===

[https://github.com/openstack/oslo.db oslo.db] is an Oslo database handling library.

Core review team: [https://review.openstack.org/#/admin/groups/331,members oslo-db-core]

Please file bugs in the [https://bugs.launchpad.net/oslo.db oslo.db project in launchpad].

=== oslo.i18n ===

oslo.i18n is a wrapper around Python's gettext module for string translation and other internationalization features.

Please file bugs in the [https://bugs.launchpad.net/oslo.i18n oslo.i18n project in launchpad]

=== oslo.log ===

[http://git.openstack.org/cgit/openstack/oslo.log/ oslo.log] is a logging configuration library.

Please file bugs and blueprints in the [https://bugs.launchpad.net/oslo.log oslo.log project in launchpad].

=== oslo.messaging ===

The [https://github.com/openstack/oslo.messaging oslo.messaging] provides a messaging API which supports RPC and notifications over a number of different messaging transports.

Bugs and blueprints should be filed using the [https://launchpad.net/oslo.messaging oslo.messaging launchpad project].

Core review team: [https://review.openstack.org/#/admin/groups/318 oslo-messaging-core]

[https://etherpad.openstack.org/HavanaOsloMessaging This etherpad] captures the latest status and background to this project.

=== oslo.middleware ===

A collection of WSGI middleware for web service development

Please file bugs in the [https://bugs.launchpad.net/oslo.middleware oslo.middleware project in launchpad].

=== oslo.policy ===

Rules engine for enforcing policy

Please file bugs in the [https://bugs.launchpad.net/oslo.policy oslo.policy project in launchpad].

=== oslo.privsep ===

[http://git.openstack.org/cgit/openstack/oslo.privsep oslo.privsep] is a mechanism for running selected python code with elevated privileges

Please file bugs in the [https://bugs.launchpad.net/oslo.privsep oslo.privsep project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/1135 oslo-privsep-core]

=== oslo.reports ===

[http://git.openstack.org/cgit/openstack/oslo.reports oslo.reports] allows projects to generate Guru Meditation Reports for debugging the current state of OpenStack processes. It can also be used to generating general reports on the fly that are serializable as plain text, JSON, or XML.

Please file bugs in the [https://bugs.launchpad.net/oslo.reports oslo.reports project in launchpad].

=== oslo.rootwrap ===

[http://git.openstack.org/cgit/openstack/oslo.rootwrap oslo.rootwrap] Rootwrap allows fine filtering of shell commands to run as root from OpenStack services.

Please file bugs in the [https://bugs.launchpad.net/oslo.rootwrap oslo.rootwrap project in launchpad]

Core review team: [https://review.openstack.org/#/admin/groups/293 oslo-rootwrap-core]

=== oslo.serialization ===

[http://git.openstack.org/cgit/openstack/oslo.serialization oslo.serialization] provides serialization functionality with special handling for some common types used in OpenStack.

Please file bugs in the [https://bugs.launchpad.net/oslo.serialization oslo.serialization project in launchpad].

=== oslo.service ===

[http://git.openstack.org/cgit/openstack/oslo.service oslo.service] provides functionality for running OpenStack services.

Please file bugs in the [https://bugs.launchpad.net/oslo.service oslo.service project in launchpad].

=== oslosphinx ===

[https://github.com/openstack/oslosphinx oslosphinx] provides theme and extension support for Sphinx documentation from the OpenStack project. It is maintained by Doug Hellmann.

Please file bugs in the [https://bugs.launchpad.net/oslosphinx oslosphinx project in launchpad].

=== oslotest ===

[http://git.openstack.org/cgit/openstack/oslotest oslotest] provide base classes and fixtures for creating unit and functional tests.

Please file bugs in the [https://bugs.launchpad.net/oslotest oslotest project in launchpad].

=== oslo.utils ===

A library of various low-level utility modules.

Please file bugs in the [https://bugs.launchpad.net/oslo.utils oslo.utils project in launchpad].

=== oslo.versionedobjects ===

[https://github.com/openstack/oslo.versionedobjects oslo.versionedobjects] deals with DB schema being at different versions than the code expects, allowing services to be operated safely during upgrades.

Please file bugs in the [https://bugs.launchpad.net/oslo.versionedobjects oslo.versionedobjects project in launchpad].

=== oslo.version ===

[https://review.openstack.org/#/c/40498/ Proposal]

[https://github.com/openstack/oslo.version oslo.version] handles getting the version for an installed piece of software from the python metadata that already exists. It is maintained by Monty Taylor.

Please file bugs in the [https://bugs.launchpad.net/oslo oslo project in launchpad].

=== oslo.vmware ===

Code common to the VMware drivers in several projects.

Please file bugs in the [https://bugs.launchpad.net/oslo.vmware oslo.vmware project in launchpad].

=== pylockfile ===

Inter-process lock management library

Please file bugs in the [https://bugs.launchpad.net/pylockfile pylockfile project in launchpad].

=== hacking ===

[https://pypi.python.org/pypi/hacking 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 [https://bugs.launchpad.net/hacking hacking project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/271 oslo-vmware-core]

=== pbr ===

[https://pypi.python.org/pypi/pbr pbr] (or Python Build Reasonableness) is a set of sensible default setuptools behaviours. It is maintained by Monty Taylor.

Please file bugs in the [https://bugs.launchpad.net/pbr pbr project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/154 pbr-core]

=== pyCADF ===

[http://git.openstack.org/cgit/openstack/pycadf pyCADF] is a python implementation of the DMTF Cloud Audit (CADF) data model.

Please file bugs in the [https://bugs.launchpad.net/pycadf pycadf project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/192 pycadf-core]

=== stevedore ===

[http://git.openstack.org/cgit/openstack/stevedore stevedore] is a library for managing plugins for Python applications.

Please file bugs in the [https://bugs.launchpad.net/python-stevedore python-stevedore project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/247 stevedore-core]

=== taskflow ===

[https://pypi.python.org/pypi/taskflow taskflow] is a library that helps create applications that handle state/failures... in a reasonable manner. It is maintained by [https://launchpad.net/~taskflow-dev taskflow-dev]

More details can be found at: https://wiki.openstack.org/TaskFlow

Please file bugs in the [https://bugs.launchpad.net/taskflow taskflow project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/173 taskflow-core]

=== tooz ===

[https://pypi.python.org/pypi/tooz tooz] is a library that aims at centralizing the most common distributed primitives like group membership protocol, lock service and leader election by providing a coordination API helping developers to build distributed applications.

Please file bugs in the [https://bugs.launchpad.net/python-tooz python-tooz project in launchpad].

Core review team: [https://review.openstack.org/#/admin/groups/246,members]

== Principles ==

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

== Incubation ==

'''The Oslo Incubator is now dead. Refer to the [https://openstack.nimeyo.com/65080/openstack-dev-last-sync-from-oslo-incubator announcement] and the [https://review.openstack.org/#/c/245461/ change clearing out the repository].'''

== FAQs ==

=== Why aren't alpha releases of oslo.config published to PyPI? ===

See [http://specs.openstack.org/openstack/oslo-specs/specs/policy/versioning.html Choosing Version Numbers] for the current policies related to versioning and releases.

=== Why does oslo.config have a CONF object? Global object SUCK! ===

Indeed. Well, it's a long story and well documented in mailing list archives if anyone cares to dig up some links.

Around the time of the Folsom Design Summit, an attempt was made to remove our dependence on a global object like this. There was massive debate and, in the end, the rough consensus was to stick with using this approach.

Nova, through its use of the gflags library, used this approach from [https://github.com/openstack/nova/blob/bf6e6e7/nova/flags.py#L27 commit zero]. Some OpenStack projects didn't initially use this approach, but most now do. The idea is that having all projects use the same approach is more important than the objections to the approach. Sharing code between projects is great, but by also having projects use the same idioms for stuff like this it makes it much easier for people to work on multiple projects.

This debate will probably never completely go away, though. See [http://lists.openstack.org/pipermail/openstack-dev/2014-August/044050.html this latest discussion in August, 2014].

=== Why does Oslo observe feature freeze ===

Feature freeze is a time to stabilize all of the new features that were added during a development cycle, but since Oslo projects don't necessarily release on the same six month schedule as the other OpenStack projects (or at all in the case of oslo-incubator) it might seem odd that Oslo observes feature freeze.

For the graduated libraries this serves the same purpose as for any of the other projects - it's a time for focusing on bug fixes and stability.

For oslo-incubator, the primary motivation is making last-minute fixes needed by other projects easier to sync. If a new feature lands in oslo-incubator and an unrelated bug is discovered by one of the consuming projects, it becomes a problem to sync just the bug fix to the project. When 11th hour bug fixes are needed it's best if the sync is as simple and small as possible. To avoid problems, oslo-incubator respects the feature freeze period just like any other project.

=== How does Oslo manage versions? ===

See [[Oslo/VersioningPolicy]].

== Resources ==

=== Review policies ===

These overlay the regular review rules for OpenStack as a whole.

* Automated changes - patches from 'openstack proposal bot' and 'transifex' which have passed CI checks can be +2+A by a single core reviewer

=== Review Links ===

(See http://git.openstack.org/cgit/openstack/oslo-incubator/tree/dashboards for the source files to create these links)

* [https://review.openstack.org/#/dashboard/?foreach=%28project%3A%5Eopenstack%2F.%2Aoslo.%2A+OR+project%3A%5Eopenstack%2Ddev%2F.%2Aoslo.%2A+OR%0Aproject%3Aopenstack%2Fdebtcollector+OR+project%3Aopenstack%2Fpylockfile+OR%0Aproject%3Aopenstack%2Ffuturist+OR+project%3Aopenstack%2Fautomaton+OR%0Aproject%3Aopenstack%2Fstevedore+OR+project%3Aopenstack%2Ftaskflow+OR%0Aproject%3Aopenstack%2Ftooz+OR+project%3Aopenstack%2Ddev%2Fcookiecutter+OR%0Aproject%3Aopenstack%2Ddev%2Fpbr+OR+project%3Aopenstack%2Fdebtcollector+OR%0Aproject%3Aopenstack%2Fmox3%29%0Astatus%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%2D1+label%3AVerified%3E%3D1%0ANOT+label%3ACode%2DReview%3C%3D%2D1%2Cself+NOT+label%3ACode%2DReview%3E%3D1%2Cself&title=Oslo+Review+Inbox&Oslo+Specs=project%3Aopenstack%2Foslo%2Dspecs&Bug+Fixes=topic%3A%5Ebug%2F.%2A&Blueprints=message%3A%22Blueprint%22&Needs+Feedback+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode%2DReview%3C%3D2+age%3A5d&You+are+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=reviewer%3Aself&Needs+final+%2B2=label%3ACode%2DReview%3E%3D2+limit%3A50&New+Contributors=reviewer%3A10068&Passed+Jenkins%2C+No+Negative+Feedback=NOT+label%3ACode%2DReview%3E%3D2+NOT+label%3ACode%2DReview%3C%3D%2D1+limit%3A50&Wayward+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+label%3ACode%2DReview%3C%3D2+age%3A2d Oslo Review Dashboard]
* [https://review.openstack.org/#/dashboard/?foreach=is%3Aopen+branch%3Amaster+file%3A%5E.%2Aopenstack%2Fcommon.%2A+status%3Aopen%0ANOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%252D1+label%3AVerified%3E%3D1%252cjenkins%0ANOT+label%3ACode%252DReview%3C%3D%252D1%252cself+NOT+label%3ACode%252DReview%3E%3D1%252cself&title=Oslo+Sync+Review+Inbox&Integrated+Projects=NOT+project%3Aopenstack%2Foslo%252Dincubator+project%3A%5Eopenstack%2F.%2A%0ANOT+project%3A%5Eopenstack%2Fpython%252D.%2Aclient&Clients=project%3A%5Eopenstack%2Fpython%252D.%2Aclient&Stackforge+Projects=project%3A%5Estackforge%2F.%2A Oslo Syncs in Other Projects]
* [https://review.openstack.org/#/dashboard/?foreach=is%3Aopen&title=Oslo+Graduation+Changes&Graduating+Libraries=%28project%3Aopenstack%2Foslo.versionedobjects+OR%0Aproject%3Aopenstack%2Foslo.service+OR+project%3Aopenstack%2Foslo.reports+OR%0Aproject%3Aopenstack%2Foslo.cache+OR+project%3Aopenstack%2Foslo.service%29%0ANOT+owner%3Aself%0ANOT+label%3AWorkflow%3C%3D%252D1%0Alabel%3AVerified%3E%3D1&New+Libraries=%28project%3Aopenstack%2Ffuturist+OR%0Aproject%3Aopenstack%2Fautomaton%29%0ANOT+owner%3Aself%0ANOT+label%3AWorkflow%3C%3D%252D1%0Alabel%3AVerified%3E%3D1&Incubator=project%3Aopenstack%2Foslo%252Dincubator+topic%3A%5E.%2Agraduate.%2A&openstack%252Dinfra%2F%2A=project%3A%5Eopenstack%252Dinfra%2F.%2A++message%3A%22+oslo%22&openstack%252Ddev%2F%2A=project%3A%5Eopenstack%252Ddev%2F.%2A++message%3A%22+oslo%22&governance=project%3Aopenstack%2Fgovernance++message%3A%22+oslo%22 Graduation Work]
* [https://bugs.launchpad.net/oslo/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=INPROGRESS&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on In Progress Bugs]

=== Security Team ===

In addition to OpenStack's Vulnerability Management team, some members of the Oslo team have indicated their willingness to help with security related issues in Oslo code. See [[Oslo/Security]] for the current list.

=== Design Proposals ===

We use the [http://git.openstack.org/cgit/openstack/oslo-specs oslo-specs repo] to track design proposals across all Oslo projects.

See [http://specs.openstack.org/openstack/oslo-specs/specs/policy/spec-approval.html the Spec Approval policy] for details.

The [https://blueprints.launchpad.net/oslo blueprints on launchpad] detail the changes currently underway to implement these specs.

[http://specs.openstack.org/openstack/oslo-specs/ Approved Specs] are published separately.

=== Release Instructions ===

[[Oslo/ReleaseProcess]]

=== Mitaka ===

* [https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Oslo Mitaka Summit Planning etherpads]

=== Liberty ===

* [https://etherpad.openstack.org/p/liberty-oslo-summit-planning Liberty Summit Planning etherpad]

=== Kilo ===

* [[Summit/Kilo/Etherpads#Oslo]]

=== Juno ===

* [[Oslo/JunoGraduationPlans]]

=== Juno Etherpads ===

* [https://etherpad.openstack.org/p/juno-infra-library-testing|Testing pre-releases of Oslo libs with apps]

=== Icehouse Etherpads ===

Etherpads from sessions at the Icehouse Design summit.

* [https://etherpad.openstack.org/p/icehouse-oslo-pecan-wsme-tips Creating REST services with Pecan/WSME]
* [https://etherpad.openstack.org/p/icehouse-oslo-openstack-client-update OpenStack Client Update]
* [https://etherpad.openstack.org/p/icehouse-oslo-hacking-updates Updates to hacking, our code style enforcement tool]
* [https://etherpad.openstack.org/p/icehouse-oslo-i18n-policies I18n policies of messages]
* [https://etherpad.openstack.org/p/IcehouseOsloMessaging oslo.messaging - API design, plans for Icehouse]
* [https://etherpad.openstack.org/p/icehouse-oslo-config-import-side-effects oslo.config enhancements, including removing import side-effects from consumers]
* [https://etherpad.openstack.org/p/icehouse-oslo-rootwrap Rootwrap: Icehouse plans]
* [https://etherpad.openstack.org/p/icehouse-oslo-db-migrations State of affairs in DB schema migrations]
* [https://etherpad.openstack.org/p/icehouse-oslo-structured-notifications Towards more structured & qualified notifications]
* [https://etherpad.openstack.org/p/icehouse-oslo-logging-and-notifications Merge logging and notifications]
* [https://etherpad.openstack.org/p/icehouse-oslo-service-synchronization Writing a service synchronisation library]
* [https://etherpad.openstack.org/p/icehouse-oslo-status Oslo incubated libraries status]
* [https://etherpad.openstack.org/p/icehouse-oslo-splitting-the-incubator Aggressively split oslo-incubator]

=== Messaging Related Work in Havana ===

During the Havana cycle, work is going on to [https://wiki.openstack.org/wiki/Oslo/Messaging re-design our messaging APIs] and to [https://wiki.openstack.org/wiki/MessageSecurity add signatures and encryption to our messages].

See [https://etherpad.openstack.org/HavanaOsloMessaging this etherpad] for yet more details.

=== Havana Etherpads ===

Etherpads from sessions at the Havana Design summit.

* [https://etherpad.openstack.org/havana-oslo Oslo Status and Plans]
* [https://etherpad.openstack.org/havana-common-wsgi Pecan/WSME Status]
* [https://etherpad.openstack.org/HavanaNoDowntimeDBMigrations No-downtime DB migrations]
* [https://etherpad.openstack.org/HavanaRootwrap Rootwrap improvements for the Havana cycle]
* [https://etherpad.openstack.org/havana-oslo-packaging-and-hacking Common packaging support and code analysis tools]
* [https://etherpad.openstack.org/havana-rpc-api-review RPC API review]
* [https://etherpad.openstack.org/havana-rpc-zmq-for-ceilometer-and-quantum ZeroMQ RPC for Ceilometer and Quantum]
* [https://etherpad.openstack.org/havana-rpc-access-control Message queue access control]
* [https://etherpad.openstack.org/havana-rpc-signing-and-encryption RPC Message Signing and Encryption]
* [https://etherpad.openstack.org/zipkin-tracing Zipkin tracing in OpenStack]
* [https://etherpad.openstack.org/havana-oslo-i18n-strategy i18n strategy for OpenStack services]
* [https://etherpad.openstack.org/havana-common-xenapi-library Common XenAPI libary]

=== Grizzly Etherpads ===

Etherpads from sessions at the Grizzly Design summit.

* [http://etherpad.openstack.org/grizzly-oslo Oslo status and plans]
* [http://etherpad.openstack.org/grizzly-common-unified-cli Unified CLI, take 2]
* [http://etherpad.openstack.org/grizzly-common-rpc-security Adding optional security to RPC]
* [http://etherpad.openstack.org/grizzly-common-services-control Services framework for command and control]
* [http://etherpad.openstack.org/grizzly-common-messaging Using the message bus for messaging]
* [http://etherpad.openstack.org/grizzly-common-wsgi-frameworks Choosing a WSGI framework for API services]
* [http://etherpad.openstack.org/grizzly-common-xml-processing XML request/response processing]
* [http://etherpad.openstack.org/grizzly-common-entrypoints-plugins Entrypoints based plugins]
* [http://etherpad.openstack.org/grizzly-common-rootwrap-and-keyring Unified rootwrap & password management]
* [http://etherpad.openstack.org/grizzly-common-db A common database]
* [http://etherpad.openstack.org/grizzly-common-instrumentation Instrumentation monitoring]

=== Folsom Etherpads ===

Etherpads from sessions at the Folsom Design summit.

* [https://etherpad.openstack.org/FolsomOpenStackCommon openstack-common]
* [https://etherpad.openstack.org/FolsomDependencyManagement Dependency management]