OpenStack - User contributions [en]

CrossProjectLiaisons

2025-04-18T14:27:32Z

Xek: Update Barbican security team link to LP, add myself as the security liaison to Barbican and Keystone

Many of our cross-project teams need focused help for communicating with the other project teams. This page lists the people who have volunteered for that work.

== Oslo ==

There are far more projects consuming code from Oslo libraries than we have Oslo contributors. That means it is not possible for the Oslo team to keep track of how every project is using Oslo code. We are asking for one person from each project to serve as a liaison between the project and Oslo, to let us know when they are having issues with a library, and to assist with work like migrating off deprecated features.

* The liaison should be active in the project and familiar with the project-specific requirements for having patches accepted, but does not need to be a core reviewer or the PTL.
* The liaison should be prepared to assist with writing and reviewing patches in their project as libraries are adopted, and with discussions of API changes to the libraries to make them easier to use within the project.
* Liaisons should pay attention to [Oslo] tagged messages on the openstack-dev mailing list.
* It is also useful for liaisons to be able to attend the Oslo team meeting ([[Meetings/Oslo]]) to participate in discussions and raise issues for real-time discussion.

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Barbican || Douglas Mendizábal || dmendiza[m]
|-
| Ceilometer || Julien Danjou || jd__
|-
| Cinder || Jay Bryant || jungleboyj
|-
| Cloudkitty || Christophe Sauthier || huats
|-
| Congress || Eric Kao || ekcs
|-
| Cue || Min Pae || sputnik13
|-
| Cyborg || Shaohe Feng || shaohe_feng
|-
| Designate || Michael Johnson || johnsom
|-
| Freezer || Saad Zaher || szaher
|-
| Glance || Abhishek Kekane|| akekane
|-
| Heat || Thomas Herve || therve
|-
| Horizon || Ivan Kolodyazhny || e0ne
|-
| I18n || Frank Kloeker || eumel8
|-
| Ironic || ||
|-
| Keystone || Douglas Mendizábal || dmendiza[m]
|-
| Manila || Thomas Bechtold || toabctl
|-
| Mistral || Dougal Matthews || d0ugal
|-
| Murano || Rong Zhu || zhurong
|-
| Neutron || Bernard Cafarelli || bcafarel
|-
| Nova || Stephen Finucane || stephenfin
|-
| [[Octavia]] || Michael Johnson || johnsom
|-
| Placement || Chris Dent || cdent
|-
| Qinling || Lingxian Kong || kong
|-
| Rally || Andrey Kurilin || andreykurilin
|-
| Sahara || Telles Nobrega, Shu Yingya || tellesnobrega, shuyingya
|-
| Senlin || Yanyan Hu || Yanyanhu
|-

| Swift || ||
|-
| Tricircle || Chaoyi Huang || joehuang
|-
| TripleO || Ben Nemec || bnemec
|-
| Trove || Lingxian Kong || lxkong
|-
| Zaqar || Flavio Percoco || flaper87
|-
| Zun || Hongbin Lu || hongbin
|-
|}

== Release management ==

The Release Management Liaison is responsible for communication with the Release Management team. Its tasks are described in the project team guide: http://docs.openstack.org/project-team-guide/release-management.html . That task has been traditionally filled by the PTL, but they may now delegate this task if they wish.

* By default, the liaison will be the PTL.
* The liaison may further delegate work to other subject matter experts

The liaisons list is now being maintained in the [https://opendev.org/openstack/releases/src/branch/master/data/release_liaisons.yaml release's repo here]. If you want to add/update liaison info, please submit a patch to the releases repository.

== QA ==

There are now more projects that are being tested by Tempest, and Grenade or a part deployable by Devstack than we have QA contributors. That means we are going to need your help to keep on top of everything. We are asking for one person from each project to serve as a liaison between the project and QA, and to assist with integrating changes as we move forward.

The liaison should be a core reviewer for the project, but does not need to be the PTL. The liaison should be prepared to assist with writing and reviewing patches that interact with their project, and with discussions of changes to the QA projects to make them easier to use within the project.

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Barbican || Douglas Mendizábal || dmendiza[m]
|-
| Ceilometer || Chris Dent || cdent
|-
| Cinder || Scott DAngelo and Ivan Kolodyazhny || scottda and e0ne
|-
| Congress || Eric Kao || ekcs
|-
| Cyborg || Chenke || chenker
|-
| Freezer || Guillermo Garcia || m3mo
|-
| Glance || Abhishek Kekane || abhishekk
|-
| Heat || Steve Baker || stevebaker
|-
| Horizon || Ivan Kolodyazhny || e0ne
|-
| Ironic || ||
|-
| Keystone || Douglas Mendizábal || dmendiza[m]
|-
| Manila || Dustin Schoenbrun || dustins
|-
| Murano || Rong Zhu || zhurong
|-
| Neutron || Slawek Kaplonski || slaweq
|-
| Nova || Ghanshyam Mann || gmann
|-
| Oslo || Davanum Srinivas || dims
|-
| Qinling || Lingxian Kong || kong
|-
| Sahara || Luigi Toscano || tosky
|-
| Senlin || Haiwei Xu || haiwei-xu
|-
| Swift || Thiago da Silva || tdasilva
|-
| Trove || Lingxian Kong || lxkong
|-
| Zaqar || Fei Long Wang || flwang
|-
| Zun || Hongbin Lu || hongbin
|}

== Documentation ==

The OpenStack Documentation is centralized on docs.openstack.org but often there's a need for specialty information when reviewing patches or triaging doc bugs. A doc liaison should be available to triage doc bugs when the docs team members don't know enough to triage accurately, and be added to doc reviews that affect your project. You'd be notified through email when you're added either to a doc bug or a doc review. We also would appreciate attendance at the [https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting weekly doc team meeting], We meet weekly in #openstack-meeting every Wednesday at alternating times for different timezones:

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Barbican || Douglas Mendizábal || dmendiza[m]
|-
| Ceilometer || Ildiko Vancsa || ildikov
|-
| Cinder || Jay Bryant || jungleboyj
|-
| Congress || Aimee Ukasick || aimeeu
|-
| Cyborg || Yumeng Bao || Yumeng
|-
| Designate || Omer Schwartz || oschwart
|-
| Freezer || Guillermo Garcia || m3mo
|-
| Heat || Rabi Mishra || ramishra
|-
| Horizon || Ivan Kolodyazhny || e0ne
|-
| I18n || Frank Kloeker || eumel8
|-
| Ironic || Julia Kreger || TheJulia
|-
| Keystone || Douglas Mendizábal || dmendiza[m]
|-
| Kolla || Mark Goddard || mgoddard
|-
| Magnum || Spyros Trigazis || strigazi
|-
| Manila || Tom Barron || tbarron
|-
| Mistral || Dougal Matthews || d0ugal
|-
| Murano || Rong Zhu || zhurong
|-
| Neutron || Akihiro Motoki || amotoki
|-
| Nova || Stephen Finucane || stephenfin
|-
| Octavia || Michael Johnson || johnsom
|-
| OpenStack-Ansible || Amy Marrich || spotz
|-
| Ops || Robert Starmer ||
|-
| Oslo || Stephen Finucane || stephenfin
|-
| Puppet OpenStack || Emilien Macchi || EmilienM
|-
| Qinling || Lingxian Kong || kong
|-
| Rally || Boris Pavlovic || boris-42
|-
| Sahara || Telles Nobrega and Luigi Toscano || tellesnobrega, tosky
|-
| Senlin || Cindia Blue || lixinhui
|-
| Swift || John Dickinson || notmyname
|-
| Tripleo || Steven Hardy || shardy
|-
| Trove || Lingxian Kong || lxkong
|-
| Watcher || Prudhvi Rao Shedimbi || pshedimb
|-
| Zaqar || Fei Long Wang || flwang
|-
| Zun || Hongbin Lu || hongbin
|}

== Stable Branch ==

The Stable Branch Liaison is responsible for making sure backports are proposed for critical issues in their project, and make sure proposed backports
are reviewed. They are also the contact point for stable branch release managers around point release times.

* By default, the liaison will be the PTL.
* The Stable Branch Liaison is considered a contributor to the Release Cycle Management Program and therefore is allowed to vote in its PTL election.
* The liaison may further delegate work to other subject matter experts

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Barbican || Douglas Mendizábal || dmendiza[m]
|-
| Ceilometer || Eoghan Glynn || eglynn
|-
| Cinder || Jay Bryant || jungleboyj
|-
| Congress || Masahito Muroi || masahito
|-
| Cyborg || Yumeng Bao || Yumeng
|-
| Freezer || Saad Zaher || szaher
|-
| Glance || ||
|-
| Heat || Zane Bitter || zaneb
|-
| Horizon || Akihiro Motoki || amotoki
|-
| Ironic || Dmitry Tantsur || dtantsur
|-
| Keystone || Douglas Mendizábal || dmendiza[m]
|-
| Manila || Goutham Pacha Ravi || gouthamr
|-
| Mistral || Dougal Matthews || d0ugal
|-
| Murano || Rong Zhu || zhurong
|-
| Neutron || Brian Haley || haleyb
|-
| Nova || Lee Yarwood || lyarwood
|-
| Octavia || Michael Johnson || johnsom
|-
| Placement || Matt Riedemann || mriedem
|-
| Qinling || Lingxian Kong || kong
|-
| Sahara || Telles Nobrega || tellesnobrega
|-
| Senlin|| Qiming Teng || Qiming
|-
| Swift || Matthew Oliver || mattoliverau
|-
| Trove || Lingxian Kong || lxkong
|-
| Watcher || David Tardivel || dtardivel
|-
| Zaqar || Fei Long Wang || flwang
|-
| Zun || Hongbin Lu || hongbin
|-
|}

== Vulnerability management ==

The Vulnerability Management Team needs domain specialists to help assessing the impact of reported issues, coordinate the development of patches, review proposed patches and propose backports. The liaison should be familiar with the [https://security.openstack.org/vmt-process.html Vulnerability Management process] and embargo rules, and have a good grasp of security issues in software design.

* The liaison should be a core reviewer for the project, but does not need to be the PTL.
* By default, the liaison will be the PTL unless explicitly listed.
* The liaison is the first line of contact for the Vulnerability Management team members
* The liaison is considered a contributor to the Release Cycle Management Program and therefore is allowed to vote in election its PTL
* The liaison may further delegate work to other subject matter experts
* The liaison maintains the members of the project's core security review team in Launchpad or StoryBoard (reviewers who will be given access to embargoed vulnerabilities by the VMT)
* If the project has multiple core security review teams for different deliverables they should be listed together in the appropriate column.

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle !! Security Team
|-
| Barbican || Grzegorz Grasza || xek || [https://launchpad.net/~barbican-coresec/+members all deliverables: barbican-coresec (LP)]
|-
| Cinder || || || [https://launchpad.net/~cinder-coresec/+members all deliverables: cinder-coresec (LP)]
|-
| Glance || Brian Rosmaita || rosmaita || [https://launchpad.net/~glance-coresec/+members all deliverables: glance-coresec (LP)]
|-
| Heat || Steve Hardy || shardy || all deliverables: openstack-heat-security (SB)
|-
| Horizon || Akihiro Motoki || amotoki || [https://launchpad.net/~horizon-coresec/+members all deliverables: horizon-coresec (LP)]
|-
| Keystone || Grzegorz Grasza || xek || [https://launchpad.net/~keystone-coresec/+members all deliverables: keystone-coresec (LP)]
|-
| Neutron || Miguel Lavalle || mlavalle || [https://launchpad.net/~neutron-coresec/+members all deliverables: neutron-coresec (LP)]
|-
| Nova || Michael Still || mikal || [https://launchpad.net/~nova-coresec/+members all deliverables: nova-coresec (LP)]
|-
| Oslo || [https://governance.openstack.org/tc/reference/projects/oslo.html DPL] || || [https://launchpad.net/~oslo-coresec/+members all deliverables: oslo-coresec (LP)]
|-
| Sahara || Telles Nobrega || tellesnobrega || all deliverables: openstack-sahara-security (SB)
|-
| Swift || || || [https://launchpad.net/~swift-coresec/+members all deliverables: swift-coresec (LP)]
|-
| Trove || Lingxian Kong || lxkong || all deliverables: openstack-trove-security (SB)
|-
|}

== API-SIG ==

The [[API_SIG|API-SIG]] seeks API subject matter experts for each project to communicate plans for API updates, review API guidelines with their project's view in mind, and review the API-SIG guidelines as they are drafted. The liaison should be familiar with the project's REST API design and future planning for changes to it.

The members of the [http://specs.openstack.org/openstack/api-sig/liaisons.html API-SIG Cross-Project Liaisons] are maintained in our repo. If you want to read the entire list of CPLs or add/remove yourself from the list, you'll need to update the [http://git.openstack.org/cgit/openstack/api-sig/tree/doc/source/liaisons.json liaisons.json] file. If you don't want to make the update yourself, please ask in #openstack-sdks on IRC and someone can make the change for you.

== Logging Working Group ==

The [[LogWorkingGroup|Log Working Group]] seeks experts for each project to assist with making the logging in projects match the new [http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html Logging Guidelines]

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Ironic || ||
|-
| Oslo || Doug Hellmann || dhellmann
|-
| Nova || John Garbutt || johnthetubaguy
|-
| Murano || Rong Zhu || zhurong
|-
| Sahara || Telles Nobrega || tellesnobrega
|}

== Infra ==

These are the project specific groups of people that Infra will look to ACK changes to that project's test configuration. Changes to project-config and devstack-gate should be +1'd by these groups when they are related to their project. Note that in an emergency this may not always be possible and Infra will ask for forgiveness but generally we should look for these +1s.

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Congress || Any Congress core reviewer may ACK: Anusha Ramineni, Eric Kao, Tim Hinrichs, Masahito Muroi || ramineni, ekcs, thinrichs, masahito
|-
| Freezer || Saad Zaher || szaher
|-
| Glance || Brian Rosmaita || rosmaita
|-
| I18n || Frank Kloeker || eumel8
|-
| Ironic || Dmitry Tantsur || dtantsur
|-
| Kolla || Any Kolla Core Reviewer may ack an infra change on behalf of the PTL || mgoddard, jeffrey4l, egonzalez, spsurya, hrw, mandre are primary contacts
|-
| Neutron || Slawek Kaplonski, YAMAMOTO Takashi || slaweq, yamamoto
|-
| Documentation || Andreas Jaeger|| AJaeger

|-
| Trove || Lingxian Kong || lxkong

|-
| Murano || Rong Zhu || zhurong

|-
| Sahara || Telles Nobrega and Luigi Toscano || tellesnobrega, tosky

|-
| Fuel || Aleksandra Fedorova, Igor Belikov || bookwar, igorbelikov
|-
| OpenStack-Ansible || Jean-Philippe Evrard, Jesse Pretorius || evrardjp, odyssey4me
|-
| Puppet OpenStack || Emilien Macchi, Alex Schultz || EmilienM, mwhahaha

|-
| TripleO || Emilien Macchi || EmilienM

|-
| Airship || Matt McEuen || mattmceuen
|}

== I18n ==
I18n team is responsible for making OpenStack ubiquitously accessible to people of all language backgrounds. The team have translators from all over the world to translate OpenStack into different languages.

If you want to communicate with translators in I18n team, send email to openstack-i18n@lists.openstack.org.

* The liaison should be a core reviewer (or a person who is not a core reviewer but agreed & approved by PTL) for the project and understand i18n status of the project.
* The liaison should understand project release schedule very well.
* The liaison should notify I18n team happens of important moments in the project release in time. For example, happen of soft string freeze, happen of hard string freeze, and happen of RC1 cutting.
* The liaison should take care of translation patches to the project, and make sure the patches are successfully merged to the final release version. When the translation patch is failed, the liaison should notify I18n team.

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| Barbican || ||
|-
| Cinder || ||
|-
| Designate || Graham Hayes || mugsie
|-
| Glance || Abhishek Kekane || akekane
|-
| Heat || ||
|-
| Horizon || Akihiro Motoki || amotoki
|-
| Ironic || ||
|-
| Keystone || ||
|-
| Magnum || Shu Muto || shu-mutou
|-
| Manila || ||
|-
| Monasca || ||
|-
| Murano || ||
|-
| Neutron || Akihiro Motoki || amotoki
|-
| Nova || ||
|-
| Oslo || ||
|-
| Sahara || Luigi Toscano, Jeremy Freudberg || tosky, jeremyfreudberg
|-
| Senlin || ||
|-
| Swift || ||
|-
| Tacker || ||
|-
| Telemetry || ||
|-
| TripleO || ||
|-
| Trove || ||
|-
| Watcher || Yumeng Bao || Yumeng
|-
| Zaqar || ||
|-
|}

== First Contact SIG ==

First Contact SIG aims to provide a place for new contributors to come for information and advice. This group will also analyze and document successful contribution models while seeking out and providing information to new members of the community. First Contact SIG project liaisons are important that they are connected with someone who can
get them up to speed on a project.

By default, the liaison will be the PTL. More than one liaison covering different TZ is recommended.

{| class="wikitable sortable"
! Name
! IRC
! Email
! Timezone
! Project
|-
| Masahito Muroi
| masahito
| muroi.masahito@lab.ntt.co.jp
|
| Blazar
|-
| Samuel Cassiba
| scas
| samuel@cassi.ba
| UTC-7
| [[Chef|Chef OpenStack]]
|-
| Jay Bryant
| jungleboyj
| jungleboyj@gmail.com
| UTC-6
| [[Cinder|Cinder]]
|-
| Ivan Kolodyazhny
| e0ne
| e0ne@e0ne.info
| UTC+3
| [[Cinder|Cinder]]
|-
| Luka Peschke
| peschk_l
| luka.peschke@objectif-libre.com
| CEST (UTC+2)
| Cloudkitty
|-
| Eric Kao
| ekcs
| ekcs.openstack@gmail.com
| UTC-8
| [[Congress|Congress]]
|-
| Ivan Kolodyazhny
| e0ne
| e0ne@e0ne.info
| UTC+3
| [[Horizon|Horizon]]
|-
| Howard Huang
| zhipeng
| zhipengh512@gmail.com
| UTC+8
| [[Cyborg/FirstContact|Cyborg]]
|-
| Graham Hayes
| mugsie
| gr@ham.ie
| UTC +1
| Designate
|-
| Petr Kovar
| pkovar
| pkovar@redhat.com
| UTC +1
| Documentation
|-
| Andrey Pavlov
| andrey-mp
| andrey.mp@gmail.com
|
| ec2-API
|-
| Saad Zaher
| szaher
| eng.szaher@gmail.com
|
| Freezer
|-
|
|
|
|
| Glance
|-
| Rico Lin
| ricolin
| rico.lin.guanyu@gmail.com
| UTC+8
| [[Heat|Heat]]
|-
| Frank Kloeker
| eumel8
| f.kloeker@telekom.de
| UTC+1
| I18n
|-
| Clark Boylan
| clarkb
| clark.boylan@gmail.com
| UTC+8
| Infrastructure
|-
| Julia Kreger
| TheJulia
| juliaashleykreger@gmail.com
| UTC+8
| Ironic
|-
| Ying Chen
| chenying
| ying.chen@huawei.com
|
| Karbor
|-
| Mark Goddard
| mgoddard
| mark@stackhpc.com
| UTC
| Kayobe
|-
| Kristi Nikolla
| knikolla
| knikolla@bu.edu
| UTC-4
| Keystone
|-
| Sam Yaple
| SamYaple
| sam+git@yaple.net
|
| LOCI
|-
| Spyros Trigazis
| strigazi
| spyridon.trigazis@cern.ch
|
| Magnum
|-
| Sampath Priyankara
| samP
| sam47priya@gmail.com
|
| Masakari
|-
| Stefano Canepa
| sc
| sc@linux.it
| UTC
| Monasca
|-
| Rong Zhu
| zhurong
| aaronzhu1121@gmail.com
| UTC+8
| Murano
|-
| Miguel Lavalle
| mlavalle
| miguel.lavalle@huawei.com
| UTC-6
| [[Neutron|Neutron]]
|-
| Slawek Kaplonski
| slaweq
| skaplons@redhat.com
| UTC+1
| [[Neutron|Neutron]]
|-
| Eric Fried
| efried
| openstack@fried.cc
| UTC-6
| Nova
|-
| Alex Xu
| alex_xu
| hejie.xu@intel.com
| UTC+8
| Nova
|-
| Michael Johnson
| johnsom
| johnsomor@gmail.com
| UTC-8
| [[Octavia|Octavia]]
|-
| James Page
| jamespage
| james.page@ubuntu.com
|
| OpenStack Charms
|-
| Jean-Philippe Evrard
| evrardjp
| jean-philippe@evrard.me
| UTC+2
| OpenStack-Ansible
|-
| Matt McEuen
| mattmceuen
| matt.mceuen@att.com
| UTC-6
| OpenStack-Helm
|-
| Chason Chan (chenxing)
| chason
| chason.chan@foxmail.com
| UTC+8
| OpenStack-Manuals
|-
| Dean Troyer
| dtroyer
| dtroyer@gmail.com
|
| OpenStackClient
|-
| Ben Nemec
| bnemec
| bnemec@redhat.com
| UTC-6
| Oslo
|-
| Javier Peña
| jpena
| jpena@redhat.com
|
| Packaging-rpm
|-
| Ed Leafe
| edleafe
| ed@leafe.com
| UTC-6
| Placement
|-
| Matthew Edmonds
| edmondsw
| edmondsw@us.ibm.com
| UTC-5
| PowerVMStackers
|-
| Ghanshyam Mann
| gmann
| gmann@ghanshyammann.com
| UTC-6
| [[QA|QA]]
|-
| Andrey Kurilin
| andreykurilin
| andr.kurilin@gmail.com
|
| Rally
|-
| Chris Hoge
| hogepodge
| chris@openstack.org
|
| Refstack
|-
| Sean McGinnis
| smcginnis
| sean.mcginnis@huawei.com
| UTC-6
| Release Management
|-
| Matthew Thode
| prometheanfire
| mthode@mthode.org
|
| Requirements
|-
| Telles Mota Vidal Nobrega
| tellesnobrega
| tenobrebrega@redhat.com
|
| Sahara
|-
| Trinh Nguyen
| dangtrinhnt
| dangtrinhnt@gmail.com
| UTC+9
| [https://wiki.openstack.org/wiki/Searchlight Searchlight]
|-
| Duc Truong
| dtruong
| duc.openstack@gmail.com
| UTC-8
| [[Senlin|Senlin]]
|-
| Rong Zhu
| zhurong
| aaronzhu1121@gmail.com
| UTC+8
| Solum
|-
| Tony Breeds
| tonyb
| tony@bakeyournoodle.com
| UTC +10
| Stable Branch Maintenance
|-
| Kota Tsuyuzaki
| kota_
| tsuyuzaki@lab.ntt.co.jp
|
| Storlets
|-
| Matt Oliver
| mattolverau
| matt@oliver.net.au
| UTC+10
| Swift
|-
| John Dickinson
| notmyname
| me@not.mn
| UTC-8
| Swift
|-
| Yong Sheng Gong
| gongysh
| gong.yongsheng@99cloud.net
|
| Tacker
|-
| Trinh Nguyen
| dangtrinhnt
| dangtrinhnt@gmail.com
|
| Telemetry
|-
| Zhiyuan Cai
| zhiyuan
| luckyvega.g@gmail.com
|
| Tricircle
|-
| Alex Schultz
| mwhahaha
| aschultz@redhat.com
|
| TripleO
|-
| Lingxian Kong
| lxkong
| anlin.kong@gmail.com
| UTC+12
| Trove
|-
| Alexander Chadin
| alexchadin
| a.chadin@servionica.ru
| UTC+3
| Watcher
|-
| Claudiu Belu
| claudiub
| cbelu@cloudbasesolutions.com
|
| Winstackers
|-
| Wang Hao
| wanghao
| szmatch1986@gmail.com
|
| Zaqar
|-
| Hongbin Lu
| hongbin
| hongbin.lu@huawei.com
| UTC-5
| Zun
|-
| Victoria Martinez de la Cruz
| vkmc
| victoria@redhat.com
| UTC-3
| Manila
|-
| Dougal Matthews
| d0ugal
| dougal@redhat.com
| UTC+0
| Mistral
|-
| Renat Akhmerov
| rakhmerov
| renat.akhmerov@nokia.com
| UTC+7
| Mistral
|-
| Omer Anson
| oanson
| omer.anson@toganetworks.com
| UTC+2
| [[Dragonflow|DragonFlow]]
|-
| Surya Prakash Singh
| spsurya
| singh.surya64mnnit@gmail.com
| UTC+9
| [[Kolla|Kolla]]
|-
| Daniel Mellado
| dmellado
| dmellado@redhat.com
| UTC+1
| [[Kuryr|Kuryr]]
|-
| Irena Berezovsky
| irenab
| Irena.berezovsky@toganetworks.com
| UTC+2
| [[Kuryr|Kuryr]]
|-
| Mohammed Naser
| mnaser
| mnaser@vexxhost.com
| UTC-5
| Puppet OpenStack
|-
| Ghanshyam Mann
| gmann
| gmann@ghanshyammann.com
| UTC-6
| [[Nova|Nova]]
|-
| Dharmendra Kushwaha
| dkushwaha
| dharmendra.kushwaha@india.nec.com
| UTC+5:30
| [[Tacker|Tacker]]
|-
| Jeffrey Zhang
| Jeffrey4l
| zhang.lei.fly@gmail.com
| UTC+8
| [[Kolla|Kolla]]
|-
|Canwei Li
| licanwei
| li.canwei2@zte.com.cn
| UTC+8
| [[Watcher|Watcher]]
|-
|Ade Lee
| alee
| alee@redhat.com
| UTC-4
| [[Barbican|Barbican]]
|-
|Lingxian Kong
| lxkong
| anlin.kong@gmail.com
| UTC+12
| [[Qinling|Qinling]]
|-
|Ifat Afek
| ifat_afek
| ifat.afek@nokia.com
| UTC+3
| [[Vitrage|Vitrage]]
|-
| Eduardo Gonzalez Gutierrez
| egonzalez
| dabarren@gmail.com
| UTC+1
| [[Kolla|Kolla]]
|-
| Mark Goddard
| mgoddard
| mark@stackhpc.com
| UTC
| [[Kolla|Kolla]]
|}

== Inter-project Liaisons ==

In some cases, it is useful to have liaisons between projects. [http://lists.openstack.org/pipermail/openstack-dev/2015-April/062327.html For example, it is useful for the Nova and Neutron projects to have liaisons, because the projects have complex interactions and dependencies.] Ideally, a cross-project effort should have two members, one from each project, to facilitate communication and knowledge transfer.

{| class="wikitable"
|-
! Projects !! Name !! IRC Handle !! Role
|-
| Nova / Neutron || || ||
|-
| || Sean K. Mooney || sean-k-mooney || Neutron liaison for Nova
|-
| Nova / Cinder || || ||
|-
| || Ildiko Vancsa || ildikov || Cinder liaison for Nova
|-
| || Matt Riedemann || mriedem || Nova liason for Cinder
|-
| Nova / Ironic || || ||
|-
| || Dmitry Tantsur || dtantsur || Ironic liaison for Nova
|-
| Neutron / Ironic || || ||
|-
| || Sukhdev Kapur || sukhdev || Neutron liaison for Ironic
|-
| || Sam Betts || sambetts || Ironic liaison for Neutron
|-
| Horizon / i18n || || ||
|-
| || Akihiro Motoki || amotoki || Horizon liaison for i18n
|-
| || TBD || || Heat liaison for Sahara
|-
| Fuel / Puppet || || ||
|-
| || Alex Schultz || mwhahaha || Fuel liaison for Puppet
|-
| Fuel / Ironic || || ||
|-
| || Evgeny L || evgenyl || Fuel liaison for Ironic
|-
| Bareon / Ironic || || ||
|-
| || Evgeny L || evgenyl || Bareon liaison for Ironic
|-
| Magnum / Kuryr || || ||
|-
| || Ton Ngo || tango || Magnum liaison for Kuryr
|-
| || Fawad Khaliq || fawadkhaliq || Kuryr liaison for Magnum
|-
| TripleO / Ironic || || ||
|-
| || Dmitry Tantsur || dtantsur || Ironic liaison for TripleO
|-
| Nova / Watcher || || ||
|-
| || Ed Leafe || edleafe || Nova liaison for Watcher
|}

=== Etherpads ===

The following is a list of etherpads that are used for inter-project liaisons, and are continuously updated.

Nova - Neutron: https://etherpad.openstack.org/p/nova-neutron

Meetings/Barbican

2024-01-02T14:55:30Z

Xek: /* Weekly Barbican Meeting */

= Weekly Barbican Meeting =

The [https://wiki.openstack.org/wiki/Barbican Barbican] project team holds a [https://meetings.opendev.org/#Barbican_Meeting weekly team meeting] in <code><nowiki>#openstack-barbican</nowiki></code>:

* Weekly on Mondays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=00&sec=0 1500 UTC]
* The blueprints that are used as a basis for the [https://launchpad.net/barbican Barbican project] can be found at https://blueprints.launchpad.net/barbican
* Notes for previous meetings can be found [http://eavesdrop.openstack.org/meetings/barbican here].
* Chair (to contact for more information): xek (#openstack-barbican @ OFTC IRC)

== Agenda ==

The weekly meeting agenda can be found/edited here: https://etherpad.openstack.org/p/barbican-weekly-meeting

Past meeting agenda archives can be found here: [[Barbican/Archive/Agenda|Archived Agenda]]

== Meeting organizers ==

* Publish the agenda 24h in advance
* Mail the agenda to the list and invite participants
* Ask each person responsible for an action from the previous meeting to prepare a line of the form, for each action item: . #info nickname description of the action link to the diff / mailing list thread etc. describing the implementation of the action
* Use http://meetbot.debian.net/Manual.html to get an automatic summary
* Prepare an outline for the meeting to speed things up (see http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-10-16.00.log.html for an actual example)
* Record decisions and commitments; review in the next meeting

Meetings/Barbican

2022-10-25T10:18:26Z

Xek: /* Weekly Barbican Meeting */

= Weekly Barbican Meeting =

The [https://wiki.openstack.org/wiki/Barbican Barbican] project team holds a weekly team meeting in <code><nowiki>#openstack-barbican</nowiki></code>:

* Weekly on Tuesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=12&min=00&sec=0 1200 UTC]
* The blueprints that are used as a basis for the [https://launchpad.net/barbican Barbican project] can be found at https://blueprints.launchpad.net/barbican
* Notes for previous meetings can be found [http://eavesdrop.openstack.org/meetings/barbican here].
* Chair (to contact for more information): xek (#openstack-barbican @ Freenode)

== Agenda ==

The weekly meeting agenda can be found/edited here: https://etherpad.openstack.org/p/barbican-weekly-meeting

Past meeting agenda archives can be found here: [[Barbican/Archive/Agenda|Archived Agenda]]

== Meeting organizers ==

* Publish the agenda 24h in advance
* Mail the agenda to the list and invite participants
* Ask each person responsible for an action from the previous meeting to prepare a line of the form, for each action item: . #info nickname description of the action link to the diff / mailing list thread etc. describing the implementation of the action
* Use http://meetbot.debian.net/Manual.html to get an automatic summary
* Prepare an outline for the meeting to speed things up (see http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-10-16.00.log.html for an actual example)
* Record decisions and commitments; review in the next meeting

Meetings/Barbican

2022-10-25T10:17:33Z

Xek: Update time and chair

= Weekly Barbican Meeting =

The [https://wiki.openstack.org/wiki/Barbican Barbican] project team holds a weekly team meeting in <code><nowiki>#openstack-barbican</nowiki></code>:

* Weekly on Tuesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=13&min=00&sec=0 1200 UTC]
* The blueprints that are used as a basis for the [https://launchpad.net/barbican Barbican project] can be found at https://blueprints.launchpad.net/barbican
* Notes for previous meetings can be found [http://eavesdrop.openstack.org/meetings/barbican here].
* Chair (to contact for more information): xek (#openstack-barbican @ Freenode)

== Agenda ==

The weekly meeting agenda can be found/edited here: https://etherpad.openstack.org/p/barbican-weekly-meeting

Past meeting agenda archives can be found here: [[Barbican/Archive/Agenda|Archived Agenda]]

== Meeting organizers ==

* Publish the agenda 24h in advance
* Mail the agenda to the list and invite participants
* Ask each person responsible for an action from the previous meeting to prepare a line of the form, for each action item: . #info nickname description of the action link to the diff / mailing list thread etc. describing the implementation of the action
* Use http://meetbot.debian.net/Manual.html to get an automatic summary
* Prepare an outline for the meeting to speed things up (see http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-10-16.00.log.html for an actual example)
* Record decisions and commitments; review in the next meeting

Meetings/KeystoneMeeting

2015-11-16T10:04:54Z

Xek: /* Main Agenda */

= Weekly Keystone team meeting =

If you're interested in identity, authentication, authorization, and/or policy for OpenStack, we hold public meetings weekly on [[IRC]] in <code><nowiki>#openstack-meeting</nowiki></code>, on [https://www.google.com/search?q=current+utc+time Tuesdays at 18:00 UTC]. Please feel free to add items to the agenda below with your name and we'll cover them.

== Regular attendees ==

Add yourself to this list to be pinged prior to each meeting:

ajayaa, amakarov, ayoung, breton, browne, davechen, david8hu, dolphm, dstanek, ericksonsantos, geoffarnold, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, lbragstad, lhcheng, marekd, morganfainberg, nkinder, raildo, rodrigods, roxanaghe, samueldmq, shaleh, stevemar, tsymanczyk, topol, vivekd, wanghong, claudiub, rderose, samleon, xek

== Agenda for next meeting ==

==== Main Agenda ====
Please add agenda items to the bottom of this section's list (be sure to include your <code>irc_handle</code>!).

2015-11-17
* HMT Phase 1 & Phase 2 <code>henrynash</code>
** At the summit we endorsed the 2-phase approach to HMT. Phase 1 being to store top-level domains as projects. For phase 2 (the actually reseller case where a cloud provider, delegates part of they cloud to a reseller who in turn sells this to their own customers), the request was to investigate using Federation instead of the proposed hierarchy of projects acting as domains. The analysis of this has been carried out and was sent to the dev list (see: http://lists.openstack.org/pipermail/openstack-dev/2015-October/078063.html)
** As outlined in the mail, I believe we cannot solve this with federation, but should implement the planned hierarchy of projects acting as domains.
* New reno-based process for release notes <code>bknudson</code>
** https://review.openstack.org/#/c/244343/
* Online Schema Migration
** https://review.openstack.org/#/c/245186/
** https://review.openstack.org/#/c/241603/

==== Review of Keystone Blueprints for No-Spec Requires Status ====
Please add BPs to the bottom of this sections list that should be reviewed as not requiring a spec (include your <code>irc_handle</code>!).

==== Keystone Weekly Bug Reports ====
Bugs for the various Keystone repositories are collects and published to the following links. (<code>lbragstad</code>)
* [http://keystone-weekly-bug-report.tempusfrangit.org/weekly-bug-reports/keystone-weekly-bug-report.html Keystone Weekly Bug Report]

==== Roles ====
Please keep this as a standing topic until we have consensus on direction
* [https://blueprints.launchpad.net/keystone/+spec/virtual-roles Support for Virtual Roles]<code>henrynash, ayoung</code>

== Previous meetings ==

Logs and meeting summaries of previous meetings are located [http://eavesdrop.openstack.org/meetings/keystone/ here].

Meetings/KeystoneMeeting

2015-11-05T15:19:36Z

Xek: /* Regular attendees */

= Weekly Keystone team meeting =

If you're interested in identity, authentication, authorization, and/or policy for OpenStack, we hold public meetings weekly on [[IRC]] in <code><nowiki>#openstack-meeting</nowiki></code>, on [https://www.google.com/search?q=current+utc+time Tuesdays at 18:00 UTC]. Please feel free to add items to the agenda below with your name and we'll cover them.

== Regular attendees ==

Add yourself to this list to be pinged prior to each meeting:

ajayaa, amakarov, ayoung, breton, browne, davechen, david8hu, dolphm, dstanek, ericksonsantos, geoffarnold, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, lbragstad, lhcheng, marekd, morganfainberg, nkinder, raildo, rharwood, rodrigods, roxanaghe, samueldmq, shaleh, stevemar, tsymanczyk, topol, vivekd, wanghong, claudiub, rderose, samleon, xek

== Agenda for next meeting ==

==== Main Agenda ====
Please add agenda items to the bottom of this section's list (be sure to include your <code>irc_handle</code>!).

2015-11-10
* Converting from MySQL's <code>DATETIME</code> to integers for timestamps. <code>lbragstad</code> <code>odyssey4me</code>
** Why?
** How?
** What does the migration look like?

==== Review of Keystone Blueprints for No-Spec Requires Status ====
Please add BPs to the bottom of this sections list that should be reviewed as not requiring a spec (include your <code>irc_handle</code>!).

==== Keystone Weekly Bug Reports ====
Bugs for the various Keystone repositories are collects and published to the following links. (<code>lbragstad</code>)
* [http://keystone-weekly-bug-report.tempusfrangit.org/weekly-bug-reports/keystone-weekly-bug-report.html Keystone Weekly Bug Report]

==== Roles ====
Please keep this as a standing topic until we have consensus on direction
* [https://blueprints.launchpad.net/keystone/+spec/virtual-roles Support for Virtual Roles]<code>henrynash, ayoung</code>

== Previous meetings ==

Logs and meeting summaries of previous meetings are located [http://eavesdrop.openstack.org/meetings/keystone/ here].

Meetings/Scheduler

2015-05-15T09:42:34Z

Xek: /* Previous meetings */

==== MEETING TIME: Tuesdays at 15:00 UTC ====

=== Agenda for next meeting ===

See mailing-list

=== Work tracking page ===
* [https://wiki.openstack.org/wiki/Gantt/kilo Kilo tracking page]
* [https://wiki.openstack.org/wiki/Gantt/liberty Liberty tracking page]

=== Previous meetings ===
* [http://eavesdrop.openstack.org/meetings/gantt/2015/ 2015]

Older meetings (note name change from scheduler to gantt)

* [http://eavesdrop.openstack.org/meetings/gantt/2015/ 2015]
* [http://eavesdrop.openstack.org/meetings/scheduler/2014/ 2014]
* [http://eavesdrop.openstack.org/meetings/scheduler/2013/ 2013]

[[Category: Nova]]
[[Category: meetings]]

Network/Meetings

2015-04-07T12:58:27Z

Xek: /* On Demand Agenda */ fix etherpad link

{{:Network/Header}}
'''Meeting time: The OpenStack Networking Team ([[Neutron]]) holds public meetings alternating between Mondays at 2100 UTC (#openstack-meeting) and Tuesdays at 1400 UTC (#openstack-meeting). Everyone is encouraged to attend.'''

== Apologies for Absence ==
* 4/7 Anita Kuno - in a car on my way to a train to PyCon
* 4/7 Edgar Magana - Still working at 1am PST. No way I can be up for the meeting in five hours! :-(

== Agenda for Next Neutron Team Meeting ==
'''Tuesday (4/7/2015) at 1400 UTC on #openstack-meeting'''

=== Announcements / Reminders ===
* Kilo dates to be aware of:
** RCs: April 9-23
** Kilo release: April 30
** https://wiki.openstack.org/wiki/Network/Meetings
* Neutron Liberty mid-cycle announcement
** June 24-26 in Fort Collins, CO
** http://lists.openstack.org/pipermail/openstack-dev/2015-April/060713.html
* Neutron Policies are documented here:
** http://git.openstack.org/cgit/openstack/neutron/tree/doc/source/policies

=== Bugs ===

 
Important bugs:
** [https://bugs.launchpad.net/neutron/+bug/1432065] DBDeadlock: (OperationalError) (1213, 'Deadlock found when trying to get lock; try restarting transaction') 'DELETE FROM ipallocationpools WHERE ipallocationpools.id
** [https://bugs.launchpad.net/neutron/+bug/1419723] DBDuplicateEntry when creating secgroup
** [https://bugs.launchpad.net/neutron/+bug/1359523] Security group rules errorneously applied to all ports having same ip addresses in different networks
** [https://bugs.launchpad.net/neutron/+bug/1335375] ping still working after security group rule is created, updated, or deleted (related to previous one)

 
These bugs are in nova but are related to neutron. It would be great if we could get neutron reviews on:
** Merged [https://review.openstack.org/#/c/80760/] Remove unneeded call to fetch network info on shutdown - arosen
** Merged [https://review.openstack.org/#/c/81674/] remove unneeded call to network_api on detach_interface - arosen
** Merged [https://review.openstack.org/#/c/81681/] remove unneeded call to network_api on rebuild_instance - arosen
** Merged [https://review.openstack.org/#/c/80055/] Optimize validate_networks to query neutron only when needed - arosen
** [https://review.openstack.org/#/c/80412/] deallocate_for_instance should delete all neutron ports on error - arosen
** [https://review.openstack.org/#/c/59578/] Fix port_security_enabled neutron extension - arosen
** [https://review.openstack.org/#/c/77043/] Fix pre-created ports in neutron from being deleted by nova - arosen

=== Docs (emagana)===

'''Networking Guide Doc Day: It is still to be decided but etherpad will be sent shortly as well as email with details'''

Open Items for Kilo: (feedback needed)
* Legacy scenario OVS: https://github.com/ionosphere80/openstack-networking-guide/blob/master/scenario-legacy-ovs/scenario-legacy-ovs.md
* Legacy scenario LB: https://github.com/ionosphere80/openstack-networking-guide/blob/master/scenario-legacy-lb/scenario-legacy-lb.md
* New networking diagrams for DVR: https://github.com/ionosphere80/openstack-networking-guide/blob/master/scenario-dvr/scenario-dvr.md

Networking Guide:
* ToC: https://wiki.openstack.org/wiki/NetworkingGuide/TOC
* Gerrit: https://github.com/openstack/openstack-manuals/tree/master/doc/networking-guide
* Minutes from 1/30/15 meeting: http://lists.openstack.org/pipermail/openstack-docs/2015-January/005776.html

=== On Demand Agenda ===
* Liberty Design Summit Sessions Discussion
** Etherpad is here: https://etherpad.openstack.org/p/liberty-neutron-summit-topics
** Please collect ideas there so we can work towards the final Summit agenda
* Nova-Network to Neutron Migration
** anteaya to give an update (http://lists.openstack.org/pipermail/openstack-dev/2014-December/053355.html)
* Neutron as the default in DevStack
** We need to document and create a single interface configuration - https://review.openstack.org/#/c/153208/
* Proposal to remove check for bash usage (https://review.openstack.org/#/c/170939/)

== Previous meeting logs ==
* Previous meetings, with their notes and logs, can be found [http://eavesdrop.openstack.org/meetings/networking/ here].
** [http://eavesdrop.openstack.org/meetings/networking/2015/?C=M;O=D networking-2015]
** [http://eavesdrop.openstack.org/meetings/networking/2014/?C=M;O=D networking-2014]
** [http://eavesdrop.openstack.org/meetings/networking/2013/?C=M;O=D networking-2013]
** [http://eavesdrop.openstack.org/meetings/quantum/2013/?C=M;O=D quantum-2013]
** [http://eavesdrop.openstack.org/meetings/quantum/2012/?C=M;O=D quantum-2012]
* Older meeting notes are here: ../MeetingLogs.

Oslo

2015-02-26T08:46:40Z

Xek:

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

'''PTL:''' Doug Hellmann <doug@doughellmann.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].

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

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/oslo oslo project in launchpad].

=== oslo.concurrency ===

A library for managing external processes and task synchronization.

Please file bugs in the [https://bugs.launchpad.net/oslo oslo 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 oslo 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 oslo 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 oslo 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 oslo project in launchpad].

=== oslo.i18n ===

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

=== oslo.log ===

A logging configuration library.

Please file bugs in the [https://bugs.launchpad.net/oslo oslo 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 oslo 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.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 oslo project in launchpad] and tag them with "rootwrap"

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 oslo 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/oslo oslo project in launchpad].

=== oslotest ===

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

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

=== oslo.utils ===

A library of various low-level utility modules.

Please file bugs in the [https://bugs.launchpad.net/oslo oslo 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 oslo project in launchpad].

=== pylockfile ===

Inter-process lock management library

Please file bugs in the [https://bugs.launchpad.net/oslo oslo 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 ==

Refer to [http://specs.openstack.org/openstack/oslo-specs/specs/policy/incubator.html The Oslo Incubator] in the Oslo policies for details.

=== Using an Oslo Library ===

See [[Oslo/UsingALibrary]] for steps for successfully introducing an Oslo library to a project.

=== Graduation ===

Code in the incubator is expected to move out to its own repository to be packaged as a standalone library or project.

See [http://specs.openstack.org/openstack/oslo-specs/specs/policy/incubator.html#graduation the Graduation section] of the team policy guide for more details.

See [[Oslo/CreatingANewLibrary]] for the steps involved.

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

(See http://git.openstack.org/cgit/stackforge/gerrit-dash-creator/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-dev%2F.%2Aoslo.%2A+OR+project%3Aopenstack%2Fcliff+OR+project%3Aopenstack%2Fpycadf+OR+project%3Aopenstack%2Fstevedore+OR+project%3Aopenstack%2Ftaskflow+OR+project%3Aopenstack-dev%2Fcookiecutter+OR+project%3Aopenstack-dev%2Fhacking+OR+project%3Aopenstack-dev%2Fpbr%29+status%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D-1+label%3AVerified%3E%3D1+NOT+label%3ACode-Review%3C%3D-1%252cself+NOT+label%3ACode-Review%3E%3D1%252cself&title=Oslo+Review+Inbox&&Oslo+Specs=project%3Aopenstack%2Foslo-specs&Bug+Fixes=topic%3A%5Ebug%2F.%2A&Graduation+Changes+in+Incubator=project%3Aopenstack%2Foslo-incubator+topic%3A%5E.%2Agraduate.%2A&Graduating+Libraries=%28project%3Aopenstack%2Foslo.concurrency+OR+project%3Aopenstack%2Foslo.log%29&Needs+Feedback+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode-Review%3C%3D2+age%3A5d&You+are+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=reviewer%3Aself&Needs+final+%2B2=label%3ACode-Review%3E%3D2+limit%3A50&New+Contributors=reviewer%3A10068&Passed+Jenkins%2C+No+Negative+Feedback=NOT+label%3ACode-Review%3E%3D2+NOT+label%3ACode-Review%3C%3D-1+limit%3A50&Wayward+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+label%3ACode-Review%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+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D-1+label%3AVerified%3E%3D1%2Cjenkins+NOT+label%3ACode-Review%3C%3D-1%2Cself+NOT+label%3ACode-Review%3E%3D1%2Cself&title=Oslo+Sync+Review+Inbox&Integrated+Projects=NOT+project%3Aopenstack%2Foslo-incubator+project%3A%5Eopenstack%2F.%2A+NOT+project%3A%5Eopenstack%2Fpython-.%2Aclient&Clients=project%3A%5Eopenstack%2Fpython-.%2Aclient&Stackforge+Projects=project%3A%5Estackforge%2F.%2A Oslo Syncs in Other Projects]
* [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]
* [https://review.openstack.org/#/dashboard/?foreach=is%3Aopen&title=Oslo+Graduation+Changes&&Graduating+Libraries=%28project%3Aopenstack%2Foslo.concurrency+OR+project%3Aopenstack%2Foslo.log%29+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D-1+label%3AVerified%3E%3D1&openstack-infra%2F%2A=project%3A%5Eopenstack-infra%2F.%2A++message%3A%22+oslo%22&openstack-dev%2F%2A=project%3A%5Eopenstack-dev%2F.%2A++message%3A%22+oslo%22&governance=project%3Aopenstack%2Fgovernance++message%3A%22+oslo%22 Graduation Work]

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

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

2015-02-26T08:45:56Z

Xek: add oslo.versionedobjects

Python3

2015-02-26T08:40:27Z

Xek: add oslo.versionedobjects

This page tracks the progress of Python 3 effort porting for OpenStack.

== Python 3 ==

[http://techs.enovance.com/6521/openstack_python3 Why should OpenStack move to Python 3 right now?]
:''Python 3 is usually seen as the new Python version which breaks compatibility and raises new Unicode issues. Python 3 is much more than that. It’s a new clean language which has a more consistent syntax. It has many new features, not less than 15 new modules. Python 3 is already well supported by major Linux distributions, whereas Python 2.7 reached its end-of-life. Slowly, some bugs cannot be fixed in Python 2.7 anymore and are only fixed in the latest Python 3 release. Python 3 is now 5 years old and considered as a mature programming language.''

== Port Python 2 code to Python 3 ==

OpenStack project chose to use the same code base for Python 2 and Python 3. The [http://pythonhosted.org/six/ Six: Python 2 and 3 Compatibility Library] helps to write code working on both versions. OpenStack supported Python 2.6 for RHEL up to Juno, but not Python 2.5 and older. Debian Stable provides Python 3 but only Python 3.2, so u'unicode' syntax should be avoided (use six.u('unicode') instead).

=== Common patterns ===

* Replace dict.iteritems() with six.iteritems(dict)
* Replace iterator.next() with next(iterator)
* Replace basestring with six.string_types
* Replace unicode with six.text_type

=== bytes.decode and unicode.encode ===

Python has a notion of "default encoding": sys.getdefaultencoding(). On Python 2, the default encoding is ASCII, whereas it is UTF-8 on Python 3.

Don't write <code>data.decode()</code> or <code>text.encode()</code> without parameter, because you will use a different encoding on Python 2 and Python 3.

Use an explicit encoding instead. Example: <code>data.decode('utf-8')</code> or <code>text.encode('utf-8')</code>. The right encoding depends on the use case, but UTF-8 is usually a good candidate (it is a superset of ASCII).

=== safe_decode ===

Olso Incubator has a function '''safe_decode()''' which can be used to decode a bytes string and pass text strings unchanged.

The default encoding is <code>sys.stdin.encoding or sys.getdefaultencoding()</code>:
* Python 3: the locale encoding, or UTF-8 if sys.stdin is "mocked" (io.StringIO instance)
* Python 2: the locale encoding, or ASCII if stdin is not a TTY or if sys.stdin is "mocked" (StringIO.StringIO instance)

It's safer to explicit the encoding to not rely on the locale encoding and have the same behaviour even if sys.stdin is "mocked".

Safe usage:
* <code>safe_decode(data, 'utf-8')</code>: decode bytes from UTF-8 or returns data unchanged if it's already a text string

Unsafe usage:
* <code>safe_decode(data)</code>

By default, the decoder is strict. You can specify a different error handler using the optional <code>errors</code> parameter. Example: safe_decode(b'[\xff]', 'ascii', 'ignore') returns '[]'.

=== safe_encode ===

Olso Incubator has a function '''safe_encode()''' which can be used to encode a string. Its usage is tricky and you should understand how it works and which encodings are used.
* <code>safe_encode(text)</code> encodes text to the output encoding
* <code>safe_encode(bytes)</code> may decode the string and then reencode to a different encoding if input and output encodings are different

The default input encoding (<code>incomding</code> parameter) is <code>sys.stdin.encoding or sys.getdefaultencoding()</code>:
* Python 3: the locale encoding, or UTF-8 if sys.stdin is "mocked" (io.StringIO instance)
* Python 2: the locale encoding, or ASCII if stdin is not a TTY or if sys.stdin is "mocked" (StringIO.StringIO instance)

The default output encoding (<code>encoding</code> parameter) is UTF-8.

It's safer to explicit the input encoding to not rely on the locale encoding and have the same behaviour even if sys.stdin is "mocked".

Safe usage:
* <code>safe_encode(data, incoming='utf-8')</code>: encode text to UTF-8 or returns data unchanged if it's already a bytes string (since the input and output encoding are UTF-8)

Unsafe usage:
* <code>safe_encode(data)</code>

Example:
* <code>safe_encode(b'\xe9', incoming='latin-1')</code> returns <code>b'\xc3\xa9'</code>.

By default, the encoder and the decoder are strict. You can specify a different error handler using the optional <code>errors</code> parameter. Example: <code>safe_encode(b'[\xff]', incoming='ascii', errors='ignore')</code> returns <code>b'[]'</code>.

=== logging module and format exceptions ===

On Python 2, the logging module accepts bytes and text strings. On Python 3, it only accepts text strings. For example, logging.error(b'hello') logs <code>b'hello'</code> instead of <code>'hello'</code>.

There is no clear rule for format exceptions yet. There are different choices depending on the project:

* <code>str(exc)</code>: native string, so use bytes on Python 2
* <code>six.text_type(exc)</code>: always use Unicode. It may raise unicode error depending on the exception, be careful. Example of such error in python 2: <code>unicode(Exception("nonascii:\xe9"))</code>.
* <code>six.u(str(exc))</code>: unsafe on Python 2 if str(exc) contains non-ASCII bytes, ex: <code>unicode(str(Exception("\xff")))</code>
* <code>LOG.exception(_LE("... %(exc)s ..."), {"exc": exc, ...})</code>

Since logging functions expect text strings on Python 3, logged exceptions should be formatted using <code>str(exc)</code>. Example: <code>LOG.debug(str(exc))</code>.

=== HTTP ===

The HTTP protocol is based on '''bytes''':

* HTTP body contains '''bytes'''. For example, use io.BytesIO for a stream storing an HTTP body.
* HTTPConnection.getresponse().read() returns '''bytes''' (in Python 3, '''str''' which is bytes in Python 2)
* On Python 3, the http.client accepts text for HTTP headers: keys are encoded to ASCII and values to ISO 8859-1 (which is only a small subset of the Unicode charset)
* It looks like Swift encodes internally HTTP headers to UTF-8 (directly using the UTF-8 encoding, not using a MIME encoding like =?UTF-8?Q?...?=. See the HTTP [RFC 2047 http://www.ietf.org/rfc/rfc2047.txt] and [http://stackoverflow.com/questions/4400678/http-header-should-use-what-character-encoding HTTP header should use what character encoding?]

=== References to port Python 2 code to Python 3 ===
* [http://python3porting.com/ Porting to Python 3 Book] by Lennart Regebro, especially the [http://python3porting.com/differences.html Language differences and workarounds].
* [http://docs.python.org/dev/howto/pyporting.html HOWTO: Porting Python 2 Code to Python 3] by Brett Cannon
* [https://wiki.python.org/moin/PortingPythonToPy3k Porting Python Code to 3.x]
* [http://code.google.com/p/python-incompatibility/ python-incompatibility]: Demonstrates incompatibilities between Python versions.

=== Common pitfalls ===

==== What is a string ? ====
You should definitely not talk about "strings" in your commit logs/reviews. In Python 2, a 'string' is bytes; in Python 3, it's a Unicode text string. The following code snippet may help in understanding the difference:

Python 2:
>>> type('foo')
<type 'str'>
>>> type(u'foo')
<type 'unicode'>
>>> type(b'foo')
<type 'str'>
>>> isinstance('foo', six.text_type)
False
>>> isinstance(u'foo', six.text_type)
True
>>> bytes is str
True
>>> b'foo'[0]
'f'

Python 3:
>>> type('foo')
<class 'str'>
>>> type(u'foo')
<class 'str'>
>>> type(b'foo')
<class 'bytes'>
>>> isinstance('foo', six.text_type)
True
>>> isinstance(b'foo', six.text_type)
False
>>> bytes is str
False
>>> b'foo'[0]
102

==== tox/testr error: db type could not be determined ====

The "db type could not be determined" error comes from .testrepository/times.dbm used by testr.

Workaround: "rm -rf .testrepository/".

== Python 3 Status of OpenStack projects ==

=== Oslo Incubator ===

'''BLOCKER BUG:''' Tests using testscenarios fail on Python 3 with nosetests because of this bug:
https://bugs.launchpad.net/testscenarios/+bug/872887

Recently merged reviews:

* https://review.openstack.org/#/c/79781/

{|class="wikitable sortable"
|-
! Test (full path) !! Patches !! Comment
|-

| style="background-color: lightgreen" | tests/unit/config/test_generator.py || https://review.openstack.org/#/c/88087/ ||
|-

| style="background-color: lightgreen" | tests/unit/crypto/test_utils.py || https://review.openstack.org/87413 ||
|-

| style="background-color: orange" | tests/unit/db/sqlalchemy/test_migration_common.py || https://review.openstack.org/#/c/107752/ ||
|-

| style="background-color: orange" | tests/unit/db/sqlalchemy/test_migrate.py || https://review.openstack.org/#/c/107921/ ||
|-

| style="background-color: lightgreen" | tests/unit/db/sqlalchemy/test_models.py || https://review.openstack.org/#/c/80307/ ||
|-

| style="background-color: lightgreen" | tests/unit/db/sqlalchemy/test_options.py || https://review.openstack.org/#/c/80627/ ||
|-

| style="background-color: lightgreen" | tests/unit/db/sqlalchemy/test_migrate_cli.py || https://review.openstack.org/107988 ||
|-

| style="background-color: red" | tests/unit/db/sqlalchemy/test_utils.py || ||
|-

| style="background-color: red" | tests/unit/db/sqlalchemy/test_sqlalchemy.py || ||
|-

| style="background-color: lightgreen" | tests/unit/fixture/test_logging.py || https://review.openstack.org/#/c/90318/ ||
|-

| style="background-color: lightgreen" | tests/unit/middleware/test_request_id.py || https://review.openstack.org/#/c/80336/ ||
|-

| style="background-color: lightgreen" | tests/unit/middleware/test_sizelimit.py || https://review.openstack.org/#/c/80450/ ||
|-

| style="background-color: red" | tests/unit/middleware/test_audit.py || || depends on pycadf ||
|-

| style="background-color: lightgreen" | tests/unit/reports/test_guru_meditation_report.py || https://review.openstack.org/#/c/87404/ ||
|-

| style="background-color: lightgreen" | tests/unit/reports/test_base_report.py || https://review.openstack.org/#/c/87973/ ||
|-

| style="background-color: lightgreen" | tests/unit/reports/test_openstack_generators.py || https://review.openstack.org/#/c/88124/ || ||
|-

| style="background-color: lightgreen" | tests/unit/reports/test_views.py || https://review.openstack.org/87376 ||
|-

| style="background-color: lightblue" | tests/unit/rpc/test_common.py || https://review.openstack.org/#/c/80533/ || The RPC code in the incubator is deprecated in favor of oslo.messaging. --[[User:Doug-hellmann|doug-hellmann]] ([[User talk:Doug-hellmann|talk]]) 15:40, 14 April 2014 (UTC)
|-

| style="background-color: lightgreen" | tests/unit/scheduler/test_base_filter.py || https://review.openstack.org/#/c/80321/ ||
|-

| style="background-color: lightgreen" | tests/unit/scheduler/test_weights.py || https://review.openstack.org/#/c/87336/ ||
|-

| style="background-color: lightgreen" | tests/unit/test_cliutils || https://review.openstack.org/#/c/74433/ ||
|-

| style="background-color: lightgreen" | tests/unit/test_fileutils || https://review.openstack.org/#/c/74728/ ||
|-

| style="background-color: lightgreen" | tests/unit/test_gettext.py || https://review.openstack.org/#/c/80534/ ||
|-

| style="background-color: lightgreen" | tests/unit/test_imageutils.py || https://review.openstack.org/#/c/90532/ ||
|-

| style="background-color: lightgreen" | tests/unit/test_jsonutils.py || https://review.openstack.org/#/c/80370/ ||
|-

| style="background-color: orange" | tests/unit/test_log.py || https://review.openstack.org/104890 ||
|-

| style="background-color: lightblue" | tests/unit/test_processutils.py || || processutils was moved to the new oslo.concurrency project ||
|-

| style="background-color: lightgreen" | tests/unit/test_quota.py || https://review.openstack.org/#/c/80564/ ||
|-

| style="background-color: lightgreen" | tests/unit/test_strutils.py ||
* https://review.openstack.org/#/c/80571/ (safe_encode)
* https://review.openstack.org/#/c/80573/
||
|-

|}

=== Common Libraries (Oslo Projects) ===

For the list of Common Libraries, see http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml#n160

{|class="wikitable sortable"
|-
! Project !! Python 3 compatibility !! Comment
|-
| [https://pypi.python.org/pypi/cliff cliff] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslo.concurrency oslo.concurrency] || style="background-color: orange;" | Partial || https://review.openstack.org/141206
|-
| [https://pypi.python.org/pypi/oslo.config oslo.config] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslo.db oslo.db] || style="background-color: orange;" | Partial || No unit tests with MySQL because of DB driver
|-
| [https://pypi.python.org/pypi/oslo.i18n oslo.i18n] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslo.log oslo.log] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslo.messaging oslo.messaging] || style="background-color: lightgreen;" | Yes || eventlet executor and qpid driver are not supported on Python 3, greenio
executor may help
|-
| [https://pypi.python.org/pypi/oslo.middleware oslo.middleware] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslo.rootwrap oslo.rootwrap] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslo.serialization oslo.serialization] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslosphinx oslosphinx] || ? || The project only contains two short .py files, it looks to be Python 3 compatible. Is Sphinx Python 3 compatible?
|-
| [https://pypi.python.org/pypi/oslotest oslotest] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslo.versionedobjects oslo.versionedobjects] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslo.vmware oslo.vmware] || style="background-color: red;" | No || Blocked suds dependency
|-
| [https://pypi.python.org/pypi/oslo.utils oslo.utils] || style="background-color: lightgreen;" | Yes ||
|-
| oslo.version || style="background-color: lightgreen;" | Yes || not released on PyPI yet
|-
| pylockfile || style="background-color: lightgreen;" | Yes || related to https://pypi.python.org/pypi/lockfile ?
|-
| [https://pypi.python.org/pypi/stevedore stevedore] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/taskflow taskflow] || style="background-color: lightgreen;" | Yes ||
|}

Development tools:

{|class="wikitable sortable"
|-
! Project !! Python 3 compatibility !! Comment
|-
| [https://pypi.python.org/pypi/cookiecutter cookiecutter] || ? ||
|-
| [https://pypi.python.org/pypi/oslo-cookiecutter oslo-cookiecutter] || ? ||
|-
| [https://pypi.python.org/pypi/hacking hacking] || ? ||
|-
| [https://pypi.python.org/pypi/pbr pbr] || ? ||
|}

=== OpenStack clients ===

{|class="wikitable sortable"
|-
! Project !! Python 3 compatibility !! CI tests running? !! Python 3 classifiers ? !! Blocked by !! Comment
|-

| [https://pypi.python.org/pypi/python-barbicanclient python-barbicanclient] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | Voting || style="background-color:orange;" | In the git repo, not on PyPI || ||
|-

| [https://pypi.python.org/pypi/python-ceilometerclient python-ceilometerclient] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | Voting || style="background-color:lightgreen;" | On PyPI || ||
|-

| [https://pypi.python.org/pypi/python-cinderclient python-cinderclient] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen" | Voting || style="background-color: lightgreen" | On PyPI || ||
|-

| [https://pypi.python.org/pypi/python-ganttclient python-ganttclient] || ? || ? || ? || ? ||
|-

| [https://pypi.python.org/pypi/python-glanceclient python-glanceclient] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen" | Voting || style="background-color:lightgreen" | On PyPI || ||
|-

| [https://pypi.python.org/pypi/python-heatclient python-heatclient] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | Voting || style="background-color: lightgreen" | On PyPI || ||
|-

| [https://pypi.python.org/pypi/python-ironicclient python-ironicclient] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen" | Voting || style="background-color: lightgreen;" | On PyPI || ||
|-

| [https://pypi.python.org/pypi/python-keystoneclient python-keystoneclient] || style="background-color: lightgreen;" | Yes || style="background-color:lightgreen;" | Voting || style="background-color: lightgreen;" | On PyPI || ||
|-

| [https://pypi.python.org/pypi/python-marconiclient python-marconiclient]|| style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | Voting || style="background-color: lightgreen;" | Yes || ||
|-

| [https://pypi.python.org/pypi/python-melangeclient python-melangeclient] || ? || ? || ? || ||
|-

| [https://pypi.python.org/pypi/python-novaclient python-novaclient] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | Voting || style="background-color: lightgreen;" | On PyPII || ||
|-

| [https://pypi.python.org/pypi/python-neutronclient python-neutronclient] || style="background-color: orange;" | Not released yet || style="background-color: lightgreen;" | Voting || style="background-color: lightgreen;" | Yes || ||
|-

| [https://pypi.python.org/pypi/python-openstackclient python-openstackclient] || style="background-color: lightgreen" | OK || style="background-color: lightgreen" | Voting || style="background-color: lightgreen" | Yes || || As of 0.9
|-

| [https://pypi.python.org/pypi/python-saharaclient python-saharaclient] || style="background-color: orange;" | In progress || style="background-color: orange" | Non-voting || || || https://review.openstack.org/#/c/73128/
|-

| [https://pypi.python.org/pypi/python-swiftclient python-swiftclient] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | Voting || style="background-color: lightgreen;" | [https://pypi.python.org/pypi/python-swiftclient/ On PyPI] || ||
|-

| [https://pypi.python.org/pypi/python-tuskarclient python-tuskarclient] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | Voting || style="background-color: lightgreen;" | On PyPI || ||
|-

| [https://pypi.python.org/pypi/python-troveclient python-troveclient] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | Voting || style="background-color: lightgreen" | On PyPI || ||
|}

=== Core OpenStack projects ===

Completely updated on Monday, September the 29th.

{| class="wikitable sortable"
|-
! Project !! Python 3 compatibility !! CI tests running? !! Trove classifiers !! Blocked by !! Comment
|-

| [https://pypi.python.org/pypi/ceilometer ceilometer] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No ||
Requirements
* croniter
* eventlet
* thrift (which is blocking happybase)
* oslo.db
* oslo.messaging
* python-neutronclient
* sqlalchemy-migrate
Requirements for tests
* mysql-python
* sphinxcontrib-docbookrestapi
* sphinxcontrib-httpdomain
* sphinxcontrib-pecanwsme
||
|-

| [https://pypi.python.org/pypi/cinder cinder] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No ||
Requirements
* eventlet
* oslo.db
* oslo.messaging
* paste
* python-barbicanclient
* rtslib-fb
* sqlalchemy-migrate
* suds
Requirements for tests
* mysql-python

||
|-

| [https://pypi.python.org/pypi/glance glance] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No ||
Requirements
* eventlet
* glance_store
* oslo.db
* oslo.messaging
* paste
* sqlalchemy-migrate
Requirements for tests
* mysql-python
* qpid-python

||
|-

| [https://pypi.python.org/pypi/heat heat] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No ||
Requirements
* eventlet
* oslo.db
* oslo.messaging
* python-neutronclient
* python-saharaclient
* qpid-python
* sqlalchemy-migrate
Requirements for tests
* mysql-python
||
|-

| [https://pypi.python.org/pypi/horizon horizon] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No ||
Requirements
* django-pyscss
* eventlet
* python-neutronclient
* python-saharaclient
* xstatic
* xstatic-angular
* xstatic-angular-cookies
* xstatic-angular-mock
* xstatic-bootstrap-datepicker
* xstatic-d3
* xstatic-font-awesome
* xstatic-hogan
* xstatic-jasmine
* xstatic-jquery
* xstatic-jquery-migrate
* xstatic-jquery.quicksearch
* xstatic-jquery.tablesorter
* xstatic-jsencrypt
* xstatic-qunit
* xstatic-rickshaw
* xstatic-spin
Requirements for tests
* nodeenv
* nose-exclude
* nosehtmloutput
* openstack.nose_plugin
||
|-

| [https://pypi.python.org/pypi/keystone keystone] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No ||
* eventlet
* oslo.db
* oslo.messaging
* paste
* pycadf
* sqlalchemy-migrate
Requirements for tests
* ldappool
* paste (which is blocking pysaml2)
* python-ldap
||
|-

| [https://pypi.python.org/pypi/neutron neutron] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No ||
Requirements
* eventlet
* jsonrpclib
* oslo.db
* oslo.messaging
* paste
* python-neutronclient
||
|-

| [https://pypi.python.org/pypi/nova nova] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No ||
* eventlet
* oslo.db
* oslo.messaging
* paste
* pycadf
* python-neutronclient
* sqlalchemy-migrate
* suds
* websockify
Requirements for tests
* libvirt-python
* mysql-python
||
|-

| [https://pypi.python.org/pypi/swift swift] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No ||
Requirements
* eventlet
Requirements for tests
* nosehtmloutput
* openstack.nose_plugin

||
|-

|}

Number of core OpenStack projetcs blocked by each dependency:
9 eventlet
7 oslo.messaging
7 oslo.db
6 sqlalchemy-migrate
6 paste
5 python-neutronclient
5 mysql-python
2 suds
2 qpid-python
2 python-saharaclient
2 pycadf
2 openstack.nose_plugin
2 nosehtmloutput
1 xstatic-spin
1 xstatic-rickshaw
1 xstatic-qunit
1 xstatic-jsencrypt
1 xstatic-jquery.tablesorter
1 xstatic-jquery.quicksearch
1 xstatic-jquery-migrate
1 xstatic-jquery
1 xstatic-jasmine
1 xstatic-hogan
1 xstatic-font-awesome
1 xstatic-d3
1 xstatic-bootstrap-datepicker
1 xstatic-angular-mock
1 xstatic-angular-cookies
1 xstatic-angular
1 xstatic
1 websockify
1 thrift
1 sphinxcontrib-pecanwsme
1 sphinxcontrib-httpdomain
1 sphinxcontrib-docbookrestapi
1 rtslib-fb
1 python-ldap
1 python-barbicanclient
1 nose-exclude
1 nodeenv
1 libvirt-python
1 ldappool
1 jsonrpclib
1 glance_store
1 django-pyscss
1 croniter

=== Dependencies ===

[https://caniusepython3.com/check/4fd5dda2-b1f1-4db4-a636-67cd3276cb6a Porting status] for [https://github.com/openstack/requirements/blob/master/global-requirements.txt global-requirement.txt].

It's now possible to specify different dependencies for Python 2 and Python 3 using:
* requirements-py2.txt: all dependencies for Python 2 (not only dependencies specific to Python 2)
* requirements-py3.txt: all dependencies for Python 3 (not only dependencies specific to Python 3)
* (same for test-requirements.txt)

You have to edit tox.ini to specify the right requirements file. Extract of a tox.ini file:

<pre>
...
[testenv:py33]
deps = -r{toxinidir}/requirements-py3.txt
-r{toxinidir}/test-requirements-py3.txt
...
</pre>

See also a patch to support markers in requirements (in pip): [https://github.com/pypa/pip/issues/1433 pip issue: Support markers in setup(install_requires)?]; [https://github.com/pypa/pip/pull/1472 Victor Stinner's pull request: "parse requirements in markers"]

OpenStack Dependencies:

* mox: use mox3 or port tests on mock which works on Python 3 (mock has been integrated in Python 3.3 as unittest.mock). Examples:
** neutronclient: https://review.openstack.org/#/c/95786/
** Oslo Incubator: https://review.openstack.org/#/c/93729/

{|class="wikitable sortable"
|-
! Project !! Python 3 compatibility !! CI tests running? !! Python 3 classifiers ? !! Blocked by !! Comment
|-

| [https://pypi.python.org/pypi/boto boto] || style="background-color:lightgreen;" | Yes || N/A || style="background-color: lightgreen;" | Yes || || See https://github.com/boto/boto3 (experimental) <- This seems dead, and https://github.com/boto/boto works with Python 3.x (since 2.32).
|-

| [https://pypi.python.org/pypi/django-compressor django-compressor] || style="background-color:lightgreen;" | Yes || N/A || style="background-color: lightgreen;" | Yes || || Requirements upgraded: https://review.openstack.org/94357
|-

| [https://pypi.python.org/pypi/django-openstack-auth django-openstack-auth] || style="background-color:lightgreen;" | Yes || N/A || style="background-color: lightgreen;" | Yes || ||
As of 1.1.6
|-

| [https://pypi.python.org/pypi/dnspython dnspython] || style="background-color:lightgreen;" | Yes || N/A|| style="background-color: lightgreen;" | Yes || || Must use the [https://pypi.python.org/pypi/dnspython3/ Python 3 version], see https://github.com/rthalley/dnspython/issues/60
|-

| [https://pypi.python.org/pypi/ecdsa ecdsa] || style="background-color:lightgreen;" | Yes || N/A || style="background-color: orange;" | In the Git repo || ||Py3 support merge before the 0.10 release (see https://github.com/warner/python-ecdsa/commits/master)
|-

| [https://pypi.python.org/pypi/eventlet eventlet] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || || eventlet portage to Python 3 in progress: [https://github.com/eventlet/eventlet/issues/6 eventlet issue #6: Support Python 3.3] and [https://github.com/eventlet/eventlet/pull/99 Pull request #99: Fix several issues with python3 thread patching]. Victor Stinner is working on [http://trollius.readthedocs.org/ Trollius] (asyncio for Python 2) which may replace eventlet: [http://techs.enovance.com/6562/asyncio-openstack-python3 Use the new asyncio module and Trollius in OpenStack]
|-

| [https://pypi.python.org/pypi/hacking hacking] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || || Cyril Roelandt patch: [https://review.openstack.org/#/c/77585/ Make hacking Python 3 compatible]
|-

| [https://pypi.python.org/pypi/jsonrpclib jsonrpclib] || style="background-color:red;" | No || N/A || style="background-color: red;" | No || || The project seems dead :(
|-

| [https://pypi.python.org/pypi/mysql-python mysql-python] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || || 2 pull requests for Python 3 (https://github.com/farcepest/MySQLdb1/pulls). The projects is being renamed to moist (https://github.com/farcepest/moist), Python 3 support might happen there.
|-

| [https://pypi.python.org/pypi/netifaces netifaces] || style="background-color:lightgreen;" | Yes || N/A|| style="background-color: lightgreen;" | Yes || || Patch sent by Victor Stinner (in private): [https://bitbucket.org/haypo/misc/src/tip/openstack/netifaces_python3.patch netifaces_python3.patch], Debian has patches too. Python 3 support as of 0.10.4. Pushed to requirements: https://review.openstack.org/94358 .
|-

| [https://pypi.python.org/pypi/nose-exclude nose-exclude] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || || https://bitbucket.org/kgrandis/nose-exclude/issue/10/test-failures-with-python-3
|-

| [https://pypi.python.org/pypi/nosehtmloutput nosehtmloutput] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No ||
* nose-exclude (tests only)
* openstack.nose-plugin
||
* https://bugs.launchpad.net/ubuntu/+source/python-nosehtmloutput/+bug/1287247
* https://review.openstack.org/#/c/80956/
|-
| [https://pypi.python.org/pypi/nosexcover nosexcover] || style="background-color:lightgreen;" | No || N/A || style="background-color: lightgreen;" | On PyPI || || Python 3 support since 1.0.9
|-
| [https://pypi.python.org/pypi/openstack.nose-plugin openstack.nose-plugin] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || ||
|-
| [https://pypi.python.org/pypi/oslo.vmware oslo.vmware] || style="background-color:red;" | No || style="background-color: lightgreen;" | Voting || style="background-color: lightgreen;" | Yes || suds ||
|-
| [https://pypi.python.org/pypi/oslo.config oslo.config] || style="background-color:lightgreen;" | Yes || style="background-color: lightgreen;" | Voting || style="background-color: lightgreen;" | On PyPI || ||
|-
| [https://pypi.python.org/pypi/oslo.messaging oslo.messaging] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || || Portage in Progress by Victor Stinner ([https://review.openstack.org/#/dashboard/9107 dashboard])
|-
| [https://pypi.python.org/pypi/oslo.rootwrap oslo.rootwrap] || style="background-color:lightgreen;" | Yes || style="background-color: lightgreen;" | Yes || style="background-color: orange;" | In the Git repo, not on PyPI (1.1.0) || ||
|-
| [https://pypi.python.org/pypi/oslosphinx oslosphinx] || style="background-color:lightgreen;" | Yes || No tests :) || style="background-color: lightgreen;" | In the git repo, not on PyPI || || https://review.openstack.org/#/c/79311/
|-
| [https://pypi.python.org/pypi/oslo.sphinx oslo.sphinx] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || || Must be replaced by oslosphinx (without the dot)
|-

| [https://pypi.python.org/pypi/pam pam] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || || The fork [https://pypi.python.org/pypi/simplepam simplepam] works on Python 2 and 3
|-

| [https://pypi.python.org/pypi/paramiko paramiko] || style="background-color:lightgreen;" | Yes || N/A || style="background-color: lightgreen;" | On PyPI || || Requirements upgraded: https://review.openstack.org/#/c/81132/
|-

| [https://pypi.python.org/pypi/paste paste] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || || https://bitbucket.org/ianb/paste/pull-request/9/python-3-support/diff
|-

| [https://pypi.python.org/pypi/pycadf pycadf] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || || Classifiers added https://review.openstack.org/#/c/133088/
|-

| [https://pypi.python.org/pypi/python-ldap python-ldap] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || || The project seems dead.
|-

| [https://pypi.python.org/pypi/python-memcached python-memcached] || style="background-color:green;" | Not released, but last commit on git has it || style="background-color: red;" | No || style="background-color: red;" | No || || [https://github.com/jbalogh/django-cache-machine/issues/52 Issue #52: Python 3.3 support? ], [https://github.com/linsomniac/python-memcached/pull/26 Pull request #26: Python 3.3 Support] -- Julien Danjou ported [https://pypi.python.org/pypi/pymemcache pymemcache] to Python 3, another memcached client, he suggests to use this one instead
|-

| [https://pypi.python.org/pypi/qpid-python qpid-python] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || ||
|-
| [https://pypi.python.org/pypi/rtslib-fb rtslib-fb] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || ||
|-
| [https://pypi.python.org/pypi/sphinxcontrib-docbookrestapi sphinxcontrib-docbookrestapi] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || ||
|-
| [https://pypi.python.org/pypi/sphinxcontrib-httpdomain sphinxcontrib-httpdomain] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || ||
|-
| [https://pypi.python.org/pypi/sphinxcontrib-pecanwsme sphinxcontrib-pecanwsme] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || ||
|-
| [https://pypi.python.org/pypi/sqlalchemy-migrate sqlalchemy-migrate] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No||
* hacking
* ibm-db-sa
* scripttest
||
|-
| [https://pypi.python.org/pypi/suds suds] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || || "Lightweight SOAP client". Last commit 2 years ago: https://fedorahosted.org/suds/browser See also this fork which is promising: https://bitbucket.org/jurko/suds
|-
| [https://pypi.python.org/pypi/taskflow taskflow] || style="background-color:lightgreen;" | Yes || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | Yes || ||
|-
| [https://pypi.python.org/pypi/thrift thrift] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || ||
|-
| [https://pypi.python.org/pypi/websockify websockify] || style="background-color:red;" | No || style="background-color: red;" | No || style="background-color: red;" | No || ||
|-

|}

=== Other OpenStack projects ===

Python 3 compatible:

* stackforge/python-jenkins : https://review.openstack.org/#/c/95004/ (py33 gate is voting)
* openstack-infra/jenkins-job-builder : https://review.openstack.org/87810 (Python 3 support finally merged in, Sept. 2014)

== Reports at OpenStack Summits ==

* Havana summit notes: https://etherpad.openstack.org/p/havana-python3
* Icehouse summit notes: https://etherpad.openstack.org/p/IcehousePypyPy3
* Juno summit notes: https://etherpad.openstack.org/p/juno-cross-project-future-of-python (Oslo) and https://etherpad.openstack.org/p/juno_swift_python3 (Swift)

== Pycon Montreal 2014: Sprint Port OpenStack to Python 3 ==

Enovance organizes a sprint to Port OpenStack to Python 3 during 4 days: between April, 14 (Monday) and April, 17 (Thursday). See the page [[Python3/SprintPycon2014]].

Network/Meetings

2015-01-12T13:40:12Z

Xek: /* On Demand Agenda */

{{:Network/Header}}
'''Meeting time: The OpenStack Networking Team ([[Neutron]]) holds public meetings alternating between Mondays at 2100 UTC (#openstack-meeting) and Tuesdays at 1400 UTC (#openstack-meeting). Everyone is encouraged to attend.'''

== Apologies for Absence ==

== Agenda for Next Neutron Team Meeting ==
'''Monday (1/13/2015) at 1400 UTC on #openstack-meeting'''

=== Announcements / Reminders ===
* Kilo-2 is one month from today (February 5):
** https://wiki.openstack.org/wiki/Kilo_Release_Schedule
* Bi-weekly meetings to discuss L2 Gateway API are scheduled every other Monday at 1800 UTC (added by Sukhdev)
**See details here: https://wiki.openstack.org/wiki/Meetings#Networking_L2_Gateway_meeting
**If you are interested in this topic or want to contribute/discuss, please join us
* Neutron Policies are documented here:
** https://wiki.openstack.org/wiki/NeutronPolicies

=== Bugs ===

 
Important bugs:
** [https://bugs.launchpad.net/neutron/+bug/1403291] test_server_connectivity_pause_unpause fails with "AssertionError: False is not true : Timed out waiting for 172.24.4.64 to become reachable"
** [https://bugs.launchpad.net/neutron/+bug/1401895] Ensure a smooth upgrade path after adv svc split
** [https://bugs.launchpad.net/tempest/+bug/1357055] Race to delete shared subnet in Tempest neutron full jobs
** [https://bugs.launchpad.net/neutron/+bug/1382064] Failure to allocate tunnel id when creating networks concurrently
** [https://bugs.launchpad.net/neutron/+bug/1332450] br-tun lost ports/flows if openvswitch restart
** [https://bugs.launchpad.net/neutron/+bug/1359523] Security group rules errorneously applied to all ports having same ip addresses in different networks
** [https://bugs.launchpad.net/neutron/+bug/1335375] ping still working after security group rule is created, updated, or deleted (related to previous one)

 
These bugs are in nova but are related to neutron. It would be great if we could get neutron reviews on:
** Merged [https://review.openstack.org/#/c/80760/] Remove unneeded call to fetch network info on shutdown - arosen
** Merged [https://review.openstack.org/#/c/81674/] remove unneeded call to network_api on detach_interface - arosen
** Merged [https://review.openstack.org/#/c/81681/] remove unneeded call to network_api on rebuild_instance - arosen
** Merged [https://review.openstack.org/#/c/80055/] Optimize validate_networks to query neutron only when needed - arosen
** [https://review.openstack.org/#/c/80412/] deallocate_for_instance should delete all neutron ports on error - arosen
** [https://review.openstack.org/#/c/59578/] Fix port_security_enabled neutron extension - arosen
** [https://review.openstack.org/#/c/77043/] Fix pre-created ports in neutron from being deleted by nova - arosen

 
This issue is still happening
** https://bugs.launchpad.net/neutron/+bug/1254555
As suggested in last weeks meeting, there is a new BZ https://bugs.launchpad.net/neutron/+bug/1398566. This needs confirmation so it can be given appropriate status. In the live systems where it shows up it is rather awkward to work around as you basically have to shutdown all of the agents before restarting the API server.
I've put a patch up for review.
** https://review.openstack.org/#/c/127633/
The steps to reproduce are very timing and order dependent. I've created video demonstration on how I've simulated a loaded environment and the steps to reproduce, a discussion of Vincent Untz's patch that my patch is derived from and a demonstration of the fix http://youtu.be/-nL1gyL3KL8 and http://youtu.be/XUY82_a7k5Q . I apologize for the blurry text quality - but the HD transcoding is completed now so if you set the playback to 1080p, it is what you see IRL.

=== Docs (emagana)===

Open Items for Kilo:
* New networking diagrams for DVR: https://github.com/ionosphere80/openstack-networking-guide/blob/master/scenario-dvr/scenario-dvr.md

Networking Guide:
* ToC: https://wiki.openstack.org/wiki/NetworkingGuide/TOC
* Gerrit: https://github.com/openstack/openstack-manuals/tree/master/doc/networking-guide

=== On Demand Agenda ===
* Nova-Network to Neutron Migration
** anteaya to give an update (http://lists.openstack.org/pipermail/openstack-dev/2014-December/053355.html)
* Seeking advice on setup for VPN testing with DevStack in VMs
** There are currently no functional tests for VPN. Is there a reason that this isn't being tackled first? It should be possible to validate the majority of use cases with functional testing and avoid the complex requirements proposed here. (marun)
** Tried single DevStack (VM) and two routers - issue restricting visibility between private networks.
** Tried two VMs, each running devstack - issues with pinging public IPs on other end, and getting Nova VMs to start (stuck in paused power state).
* Quick walk through of Kilo-2 specs
** https://launchpad.net/neutron/+milestone/kilo-2
** If your spec is in blocked state, it's because it's approved but has no code proposed
* Compiling a list of Neutron upgrades implementation status and known problems
** upgrading running systems with no downtime - what are the major issues?
** upgrade compatibility: oslo.versionedobjects adoption status
** upgrade compatibility: other areas of focus and known problems

== Previous meeting logs ==
* Previous meetings, with their notes and logs, can be found [http://eavesdrop.openstack.org/meetings/networking/ here].
** [http://eavesdrop.openstack.org/meetings/networking/2014/?C=M;O=D networking-2014]
** [http://eavesdrop.openstack.org/meetings/networking/2013/?C=M;O=D networking-2013]
** [http://eavesdrop.openstack.org/meetings/quantum/2013/?C=M;O=D quantum-2013]
** [http://eavesdrop.openstack.org/meetings/quantum/2012/?C=M;O=D quantum-2012]
* Older meeting notes are here: ../MeetingLogs.