OpenStack - User contributions [en]

Meetings/InfraTeamMeeting

2026-06-19T10:48:49Z

Frickler: add "zuul config errors" topic

= Weekly Project Infrastructure team meeting =

The OpenDev Team holds public weekly meetings in <code><nowiki>#opendev-meeting</nowiki></code> on OFTC, Tuesdays at 1900 UTC. Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend.

Please feel free to add agenda items (and your IRC nick in parenthesis).

== Agenda for next meeting ==

* Announcements

* Actions from last meeting

* Specs Review

* Topics
** Upgrading Old Servers (clarkb 20230627)
*** https://etherpad.opendev.org/p/opendev-server-upgrade-planning Central tracking document which may link to more host specific documents
*** Next on the list are graphite and backup servers
*** backup03.ca-ymq-1.vexxhost.opendev.org has been launched and is being backed up too
**** Preliminary checks all looked good. Should double check that all expected hosts are backing up to this server and confirm that a backup is mountable and looks accurate.
*** Remember to use launch-node's --config-drive flag when booting new Noble nodes in Rax Classic
** Deploying a Prometheus for Server Metrics (clarkb 20260331)
*** https://review.opendev.org/c/opendev/system-config/+/980840
*** This change and its child deploy prometheus with node exporter to collect server metrics
*** mnasiadka has proposed we use GrepTimeDB in conjunction with Prometheus to collect metrics over a longer period of time
** Gerrit Account Cleanups (clarkb 20260317)
*** Since the upgrade to Gerrit notedb we've had account inconsistencies that prevent us from push to the external ids ref/table directly.
*** clarkb did a bunch of work to get the number down from hundreds to about 33 consistency errors before stalling out.
*** The tail was the most difficult as it wasn't clear what the more appropriate fix for each account would be
*** Since then it has been years and those accounts are likely inactive and unused. We can rerun the Gerrit consistency check, feed the info back through our audit script then decide if we need to be careful with any of these accounts
*** Chances are we can simply disable them all and remove the conflicting external ids.
*** If we take good notes we can reconstruct the accounts as appropriate after the fact without Gerrit downtime should one of these users show up and wonder what happened.
** Gerrit 3.13 Upgrade Followup (clarkb 20260414)
*** We upgraded Gerrit last Friday to 3.13.6 from 3.12.7
*** https://etherpad.opendev.org/p/gerrit-upgrade-3.13 Upgrade plan and process that was used
*** Seems to be working, but a few things have been noticed
**** The lack of robot comment apis has created some questions. This was anticipated and we expect hard refreshes of browser clients to fix this
**** The robot comment api removal also broke gertty
**** corvus has suggested that Zuul stop using robot comments early as these comments effectively disappear post upgrade
**** Custom "Your -> Foo" links in the web ui can be set to open in new tabs. This is configurable through your user preferences in Gerrit
**** Some changes show up as conflicting with each other despite having a direct git tree relationship
*** https://review.opendev.org/c/opendev/system-config/+/991945/ and children will drop Gerrit 3.12 images, add 3.14 images, and test a 3.13 to 3.14 upgrade just as soon as we're confident we won't rollback to 3.12.
** Upgrading Grafana (clarkb 20260609)
*** https://review.opendev.org/c/opendev/system-config/+/991155 This change will upgrade grafana to the latest version
*** https://23.253.20.165/ is a held node for testing purposes. Things look good to clarkb and we can probably proceed.
** Zuul reporting empty public_v6 addresses for test nodes (clarkb 20260519)
*** Zuul is reporting public_v6 values of '' for test nodes that do have working ipv6 in clouds like rax classic and ovh
*** This may be an openstack api bug, an openstacksdk bug, or a zuul-launcher bug.
*** Be aware this may impact the behavior of some test jobs.
*** We will need to dig into why this is happening to understand it better.
** Larger VM sizes for tests (corvus 20260618)
*** corvus has been testing python 3.14 with zuul; zuul unit tests now use slightly more than 8GB under 3.14
*** We have 16gb nodes, but in two clouds, rax-classic and vexxhost, they have fewer vcpus than their 8gb counterparts, so we need to use 32gb nodes to compensate
*** Are we okay with this? Alternatives?
** Dealing with alien zuul config errors in the openstack tenant (frickler 20260617)
*** Currently there are still 185 zuul config errors in the openstack tenant, despite my year-long struggle to get rid of them.
*** Most of these are from "alien" repos (74 airship, 29 starlingx) that I have no motivation to fix myself with my OpenStack hats on
*** Efforts to motivate these projects to clean up their errors themselves have mostly failed
*** I still believe that cleaning these up and being able to easily identify fresh errors is important for the healthyness of the CI setup as a whole
*** One pretty strong action would be to move these repos into their own tenant(s) or a different shared one like opendev
*** I acknowledge that without further work this would break their CI setup, but I'm questioning now whether that impact would be worse than the impact the current situation has on my ability to maintain the OpenStack CI
*** Other ideas or opinions are welcome

* Open discussion

== Upcoming Project Renames ==
(any additions should mention original->new full names and link to the corresponding project-config rename change in Gerrit)
Changes should have their topic set to project-rename.

* Rename x/cursor -> openstack/cursor: https://review.opendev.org/c/openstack/project-config/+/990122 (stephenfin, fungi)

== Previous meetings ==
Previous meetings, with their notes and logs, can be found at http://eavesdrop.openstack.org/meetings/infra/ and earlier at http://eavesdrop.openstack.org/meetings/ci/

Meetings/TechnicalCommittee

2025-08-08T14:23:24Z

Frickler: /* Agenda */ add 2026.1 runtimes discussion

__NOTOC__

The OpenStack Technical Committee is one of the [https://governance.openstack.org governing bodies] of the OpenStack project. You can find more information about it, such as the list of its [https://governance.openstack.org/tc/ current members] or its [https://governance.openstack.org/tc/reference/charter.html governance charter], on the OpenStack TC governance website at https://governance.openstack.org/tc/ .

In order to include as many people as possible in the discussion, the Technical Committee relies on asynchronous communications as much as possible. We propose and vote on changes through the [http://git.openstack.org/cgit/openstack/governance openstack/governance repository]. Large-impact changes are discussed on the openstack-discuss mailing-list. '''We track current initiatives on the [[Technical_Committee_Tracker]].'''

Although we don't hold office hours, you can find various members of the TC at various times throughout the week in the [http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ #openstack-tc] IRC channel. We also meet formally [http://eavesdrop.openstack.org/#Technical_Committee_Meeting each week] in #openstack-tc. The first meeting of the month is usually a video meeting; connection information will be posted below when that's the case.

=== Next Meeting ===

* Date: 2025 Aug 12
* Time: 17.00 UTC: http://eavesdrop.openstack.org/#Technical_Committee_Meeting
* Chair: Goutham Pacha Ravi (gouthamr)
* Agenda to be published on the OpenStack-discuss mailing list before the meeting
* Location:
** [https://webchat.oftc.net/?nick=&channels=%23openstack-tc&uio=d4 IRC (OFTC) - #openstack-tc]

==== Agenda ====

* Roll call
** courtesy-ping: gouthamr, noonedeadpunk, gmaan, frickler, spotz[m], gtema, cardoe, mnasiadka, bauzas
* Last Week's AIs
* A check on gate health
* TC Tracker
** #link https://etherpad.opendev.org/p/tc-2025.2-tracker (Technical Committee activity tracker - 2025.2)
* Discuss runtimes for 2026.1 development cycle
** Add Debian Trixie and python3.13?
** Drop python3.10 and Ubuntu 22.04?
* Open Discussion and Reviews

==== Absence ====

* bauzas (Aug 5,12,19)

=== Past meetings logs ===

Logs of past TC meetings can be accessed at http://eavesdrop.openstack.org/meetings/tc for IRC meetings and https://www.youtube.com/@openstack-tc for video meetings.

[[Category: meetings]]

Meetings/TechnicalCommittee

2024-11-30T07:49:17Z

Frickler: /* Agenda */ Add topic "Unmaintained branch cleanup"

__NOTOC__

The OpenStack Technical Committee is one of the [https://governance.openstack.org governing bodies] of the OpenStack project. You can find more information about it, such as the list of its [https://governance.openstack.org/tc/ current members] or its [https://governance.openstack.org/tc/reference/charter.html governance charter], on the OpenStack TC governance website at https://governance.openstack.org/tc/ .

In order to include as many people as possible in the discussion, the Technical Committee relies on asynchronous communications as much as possible. We propose and vote on changes through the [http://git.openstack.org/cgit/openstack/governance openstack/governance repository]. Large-impact changes are discussed on the openstack-discuss mailing-list. '''We track current initiatives on the [[Technical_Committee_Tracker]].'''

Although we don't hold office hours, you can find various members of the TC at various times throughout the week in the [http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ #openstack-tc] IRC channel. We also meet formally [http://eavesdrop.openstack.org/#Technical_Committee_Meeting each week] in #openstack-tc. The first meeting of the month is usually a video meeting; connection information will be posted below when that's the case.

=== Next Meeting ===

* Date: 2024 Nov 26
* Time: 18.00 UTC: http://eavesdrop.openstack.org/#Technical_Committee_Meeting
* Chair: Goutham Pacha Ravi (gouthamr)
* Agenda to be published on the OpenStack-discuss mailing list before the meeting
* Location:
** [https://webchat.oftc.net/?nick=&channels=%23openstack-tc&uio=d4 IRC (OFTC) - #openstack-tc]

==== Agenda ====

* Roll call
** courtesy-ping: gouthamr, noonedeadpunk, gmann, frickler, spotz, gtema, cardoe, slaweq, bauzas
* Last Week's AIs
* Watcher's launchpad tracker recovery
** #link https://answers.launchpad.net/launchpad/+question/819336
* A check on gate health
* PTG AIs and the TC Tracker
** #link https://etherpad.opendev.org/p/tc-2025.1-tracker (Technical Committee activity tracker - 2025.1)
* Unmaintained branch cleanup
** #link https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html (Resolution)
** It says "By default, only the latest eligible Unmaintained branch is kept.", but this is not implemented, the default for git repositories is to stay in place unless some action is taken
** Started some cleanup action e.g. https://review.opendev.org/c/openstack/releases/+/935373 but it keeps getting delayed by discussions
** More automated approach needed that checks basic criteria and acts on them?
** "The CI for all branches must be in good standing at the time of opt-in." need to be more formalized in order to be able to be automated?
** Branches with Zuul config errors certainly do not meet this criterium
** #link https://zuul.opendev.org/t/openstack/config-errors?branch=unmaintained%2Fvictoria&severity=error&skip=0 (Zuul config errors for unmaintained/victoria branches)
* Open Discussion and Reviews

==== Absence ====

=== Past meetings logs ===

Logs of past TC meetings can be accessed at http://eavesdrop.openstack.org/meetings/tc for IRC meetings and https://www.youtube.com/@openstack-tc for video meetings.

[[Category: meetings]]

Meetings/InfraTeamMeeting

2024-10-30T06:01:01Z

Frickler: /* Agenda for next meeting */ added topics bounce processing and registry failures

Meetings

2024-10-30T04:51:25Z

Frickler: /* Official IRC meetings */ Update links

== Official IRC meetings ==

The OpenStack project holds its various public meetings on '''[[IRC]]''', in project-specific channels on OFTC. Everyone is encouraged to attend. [https://webchat.oftc.net/ Connect to IRC via webclient].

Meetings are [http://eavesdrop.openstack.org/meetings/ logged] using [http://meetbot.debian.net/Manual.html#user-reference MeetBot].

NB: Holding meetings in common IRC channels increases the ability of the community at large to participate.

'''The schedule for our meetings now lives at: https://meetings.opendev.org/'''

'''The ical containing all our meetings is now at https://meetings.opendev.org/irc-meetings.ical'''

The schedule and descriptions of our meetings are now driven from a git repository at '''[https://opendev.org/opendev/irc-meetings opendev/irc-meetings]'''.
To create or modify a meeting, you should from now on propose a change on that repository through Gerrit. It will be automatically checked for conflicts.

[[Category:Contribute]]
[[Category:Connect]]
[[Category:Resources]]
[[Category: Meetings]]

Meetings/TechnicalCommittee

2024-08-09T22:49:57Z

Frickler: /* Absence */

Meetings/InfraTeamMeeting

2024-07-06T05:58:17Z

Frickler: /* Agenda for next meeting */ Add x/* config errors topic

= Weekly Project Infrastructure team meeting =

The OpenDev Team holds public weekly meetings in <code><nowiki>#opendev-meeting</nowiki></code> on OFTC, Tuesdays at 1900 UTC. Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend.

Please feel free to add agenda items (and your IRC nick in parenthesis).

== Agenda for next meeting ==

* Announcements
** Holiday at the end of the week for some of us.

* Actions from last meeting

* Specs Review

* Topics
** Upgrading Old Servers (clarkb 20230627)
*** https://etherpad.opendev.org/p/opendev-bionic-server-upgrades
**** wiki.openstack.org: https://etherpad.opendev.org/p/opendev-mediawiki-upgrade
**** tonyb looking at cacti after wiki
*** https://etherpad.opendev.org/p/opendev-focal-server-upgrades
**** tonyb expects to try a simple focal -> noble upgrade this week
** AFS Mirror cleanups (clarkb 20240220)
*** Ubuntu Xenial cleanups are starting to show up under topic:drop-ubuntu-xenial
*** CentOS 8 Stream EOLd and jobs can no longer successfully run there. Cleanup is happening under topic:drop-centos-8-stream
**** Projects like glance are still holding onto these old jobs despite no hope of them ever succeeding. Do we want to say Monday July 8 we're force merging cleanups on our side and projects will have to deal with the fallout since they aren't fixing things now?
*** Can followup with webserver log processing to determine which other mirrors may be dead.
** Gitea 1.22 Upgrade Planning (clarkb 20240528)
*** There is a Gitea 1.22.0 release now. Once we have the general upgrade working we can test the doctor tool to fixup the DB case sensitivity.
*** https://review.opendev.org/c/opendev/system-config/+/920580
** OpenMetal Cloud Rebuild (clarkb 20240604)
*** Waiting on a response from OpenMetal about the best way to proceed. I don't want to try and fix things and step on their toes or vice versa.
** Testing Rackspace's New Cloud Offering (clarkb 20240604)
*** Clarkb is still waiting to hear back from rax on whether or not a meeting works to discuss this further and if so when.
** Nodepool in Zuul (corvus 20240702)
*** Nodepool in Zuul work is proceeding
*** Creating Opendev image build jobs
*** Running zuul-launcher in shadow mode
** Collating backlog items from $everyone (tonyb 20240107)
*** Review of approved specs: https://docs.opendev.org/opendev/infra-specs/latest/ Seems like that could do with some love
*** Would it be helpful to have a '#noteit' IRC action that'd record the timestamp for context and add it to an editable list?
*** There is a pretty solid risk of this becoming long and write only :/
** Drop x/* projects with config errors from zuul (frickler 20240706)
*** Patch proposed at https://review.opendev.org/c/openstack/project-config/+/923509
*** Send a final warning to the ML first? Or is there a volunteer to chase down individual projects?
** zuul db performance issues (frickler 20240705)
*** https://zuul.opendev.org/t/openstack/buildsets times out without showing results
*** https://zuul.opendev.org/t/openstack/buildsets?pipeline=gate takes 20-30s
*** Makes investigating gate status more complicated
*** Not sure if our deployment is reaching its limits or Zuul needs some more query optimization?
** Reconsider queue depth for integrated gate (frickler 20240705)
*** During the rush to get fixes for the recent CVE merged, a lot of gate failures happened
*** Chances that patch #20 in the pipeline gets merged without any issue in the 19 patches before it seems neglegible
*** Suggestion: Reduce depth to 10 for now, which still seems pretty optimistic

* Open discussion

== Upcoming Project Renames ==
(any additions should mention original->new full names and link to the corresponding project-config rename change in Gerrit)
Changes should have their topic set to project-rename.

* Rename example/foo -> example/bar: https://review.opendev.org/c/openstack/project-config/+/123456

== Previous meetings ==
Previous meetings, with their notes and logs, can be found at http://eavesdrop.openstack.org/meetings/infra/ and earlier at http://eavesdrop.openstack.org/meetings/ci/

Meetings/InfraTeamMeeting

2024-07-05T06:39:11Z

Frickler: /* Agenda for next meeting */ Add zuul db performance and gate queue depth topics

Meetings/TechnicalCommittee

2024-07-02T06:14:21Z

Frickler: /* Absence */ -frickler

__NOTOC__

The OpenStack Technical Committee is one of the [https://governance.openstack.org governing bodies] of the OpenStack project. You can find more information about it, such as the list of its [https://governance.openstack.org/tc/ current members] or its [https://governance.openstack.org/tc/reference/charter.html governance charter], on the OpenStack TC governance website at https://governance.openstack.org/tc/ .

In order to include as many people as possible in the discussion, the Technical Committee relies on asynchronous communications as much as possible. We propose and vote on changes through the [http://git.openstack.org/cgit/openstack/governance openstack/governance repository]. Large-impact changes are discussed on the openstack-discuss mailing-list. '''We track current initiatives on the [[Technical_Committee_Tracker]].'''

Although we don't hold office hours, you can find various members of the TC at various times throughout the week in the [http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ #openstack-tc] IRC channel. We also meet formally [http://eavesdrop.openstack.org/#Technical_Committee_Meeting each week] in #openstack-tc. The first meeting of the month is usually a video meeting; connection information will be posted below when that's the case.

=== Next Meeting ===

* Date: 2024 Jul 02
* Time: 18.00 UTC: http://eavesdrop.openstack.org/#Technical_Committee_Meeting
* Chair: Goutham Pacha Ravi (gouthamr)
* Agenda to be published on the OpenStack-discuss mailing list before the meeting
* Location:
** [https://us06web.zoom.us/j/87108541765?pwd=emlXVXg4QUxrUTlLNDZ2TTllWUM3Zz09 Video Conference (Zoom)]
** IRC (OFTC): #openstack-tc

==== Agenda ====

* Roll call
* AIs from last week
* Eventlet Removal (hberaud/zzzeek)
* Project Activity Tracking
** #link https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html#current-inactive-projects
* A check on gate health
* 2024.2 TC Tracker
** #link https://etherpad.opendev.org/p/tc-2024.2-tracker (Technical Committee activity tracker)
* Open Discussion and Reviews

==== Absence ====
* frickler: zoom boycott

=== Past meetings logs ===

Logs of past TC meetings can be accessed at http://eavesdrop.openstack.org/meetings/tc for IRC meetings and https://www.youtube.com/@openstack-tc for video meetings.

[[Category: meetings]]

Meetings/QATeamMeeting

2024-04-30T15:19:53Z

Frickler: /* Agenda for next Office hours */ Updates for 2024.2, drop old eom branches in queries

__TOC__

= Weekly QA Team meeting =
The [[QA|OpenStack Quality Assurance (QA)]] team Develop, maintain, and initiate tools and plans to ensure the upstream stability and quality of OpenStack, and its release readiness at any point during the release cycle.

The [[QA|OpenStack Quality Assurance (QA)]] team holds public weekly Office hours:
* Channel: <code><nowiki>#openstack-qa</nowiki></code>
* Time:
** Tuesdays biweekly at 15:00 UTC (even weeks, starting week 46, 2023)
** Wednesday biweekly at 17:00 UTC (odd weeks, starting week 45, 2023)
* ical - http://eavesdrop.openstack.org/#QA_Team_Office_hours

Everyone interested in testing, quality assurance, performance engineering, etc, should attend! The meeting minutes of previous meetings can be found here: [http://eavesdrop.openstack.org/meetings/qa meeting minutes on eavesdrop]

'''''Rules for adding to the agenda''''':
* anyone is free to add to proposed agenda, please do so by 1 hr before the Office hours
* if you add an item to the agenda, please include your ircnick (i.e. sdague) to the end of your item, so we know who did, and who should lead the discussion

'''''Tips to Chair the Office hours''''':
* Start this meeting using: #startmeeting qa
* If nothing much to discuss then we can always finish Office hours any time before 1 hour.
* Announcement and Priority Items progress (first 2 items of Agenda) can be skipped and need not to be tracked every week.
* End this meeting using: #endmeeting

== Agenda for next Office hours ==
PING LIST-
* Announcement and Action Item (Optional)
* Priority Items progress
** go through the 2024.2 priority items list and try to plan the work / highlight milestones
*** https://etherpad.opendev.org/p/qa-dalmatian-priority
* OpenStack Events Updates and Planning (Optional)
** <This includes the OpenStack Summit and PTG updates and planning>
* Gate Status / Fix Checks
** <not just QA projects gate but any other project gate also where QA team can help>
** Gate Blocker Fix / Urgent Change
*** https://review.opendev.org/q/label:Review-Priority%253D%252B2+status:open+(project:openstack/tempest+OR+project:openstack/patrole+OR+project:openstack/devstack+OR+project:openstack/grenade)
** Bare Recheck tracking:
*** https://etherpad.opendev.org/p/recheck-weekly-summary
*** #info STOP DOING BARE RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures
* Changes with Review-Priority == +1
** https://review.opendev.org/q/label:Review-Priority%253D%252B1+status:open+(project:openstack/tempest+OR+project:openstack/patrole+OR+project:openstack/devstack+OR+project:openstack/grenade)
* Periodic jobs Status Checks
** Periodic stable full: https://zuul.openstack.org/builds?pipeline=periodic-stable&job_name=tempest-full-2023-1&job_name=tempest-full-2023-2&job_name=tempest-full-2024-1
** Periodic stable slow: https://zuul.openstack.org/builds?job_name=tempest-slow-2024-1&job_name=tempest-slow-2023-2&job_name=tempest-slow-2023-1
** Periodic extra tests: https://zuul.openstack.org/builds?job_name=tempest-full-2024-1-extra-tests&job_name=tempest-full-2023-2-extra-tests&job_name=tempest-full-2023-1-extra-tests
** Periodic master: https://zuul.openstack.org/builds?project=openstack%2Ftempest&project=openstack%2Fdevstack&pipeline=periodic
* Distros check:
** Centos 9: https://zuul.openstack.org/builds?job_name=tempest-full-centos-9-stream&job_name=devstack-platform-centos-9-stream&skip=0
** Debian: https://zuul.openstack.org/builds?job_name=devstack-platform-debian-bullseye&job_name=devstack-platform-debian-bookworm&skip=0
** Rocky: https://zuul.openstack.org/builds?job_name=devstack-platform-rocky-blue-onyx
** openEuler: https://zuul.openstack.org/builds?job_name=devstack-platform-openEuler-22.03-ovn-source&job_name=devstack-platform-openEuler-22.03-ovs&skip=0
** jammy: https://zuul.opendev.org/t/openstack/builds?job_name=devstack-platform-ubuntu-jammy-ovn-source&job_name=devstack-platform-ubuntu-jammy-ovs&skip=0
* Sub Teams highlights (Sub Teams means individual projects under QA program)
** Tempest: https://review.openstack.org/#/q/project:openstack/tempest+status:open
** Patrole: https://review.openstack.org/#/q/project:openstack/patrole+status:open
** Devstack: https://review.openstack.org/#/q/project:openstack/devstack+status:open
** Grenade: https://review.openstack.org/#/q/project:openstack/grenade+status:open
** Hacking: https://review.opendev.org/#/q/project:openstack/hacking+status:open
* Open Discussion
** [everyone feel free to add their topics under Open Discussion prior to the Office hours with your irc nickname]

* Bug Triage (last 30 min)
** https://etherpad.openstack.org/p/qa-bug-triage-dalmatian

== Previous meetings ==
* All previous meetings, with their notes and logs, can be found at http://eavesdrop.openstack.org/meetings/qa/.
* Old agendas are stored on [[Meetings/QATeamMeeting/OldAgendas]]

IRC

2024-03-23T12:13:30Z

Frickler: Update meeting link, mention OFTC, drop #openstack-upstream-institute

IRC, or Internet Relay Chat, is often used as a real-time communication capability with open source projects. We're pretty proud of the friendly vibe in the OpenStack channels and invite anyone wanting to ask questions or talk about all things OpenStack to the channels.

=== New to IRC ? ===

Please see the IRC chapter in our Contributors Guide: '''https://docs.openstack.org/contributors/common/irc.html'''

=== OpenStack IRC channels and meetings ===

We are using the OFTC IRC network, our main channels are:

* #openstack (for usage questions)
* #openstack-dev (for development questions)
* #openstack-infra (for questions about the project infrastructure)

You can access the complete list of channels and the schedule of IRC meetings on: '''https://meetings.opendev.org/'''

=== How to read messages exchanged when you're offline ===

IRC, unlike other chat systems, doesn't keep messages when you're offline. In order to be notified of relevant communications you can either look at the [http://eavesdrop.openstack.org/irclogs/ channel logs] or setup an IRC proxy.

The most common IRC proxies are [http://wiki.znc.in/ZNC znc] and [https://bip.milkypond.org/ bip]. See the following guides to configure them:

* [https://kashyapc.fedorapeople.org/notes-bip-IRC-proxy/README Installation notes for Fedora/RH-like] and [https://kashyapc.fedorapeople.org/notes-bip-IRC-proxy/bip.conf example bip.conf] contributed by Kashyap Chamarthy
* ZNC [https://dague.net/2014/09/13/my-irc-proxy-setup/ configuration notes] contributed by Sean Dague
* [https://weechat.org/ WeeChat] IRC client combines proxy and client, and allows you to run the client in a shell and access that client additionally from a web client or Android app.

[[Category:Connect]]

Meetings/TechnicalCommittee

2024-02-05T11:15:59Z

Frickler: /* Absence */

Meetings/InfraTeamMeeting

2023-12-17T10:42:23Z

Frickler: couple of new topics added

= Weekly Project Infrastructure team meeting =

The OpenDev Team holds public weekly meetings in <code><nowiki>#opendev-meeting</nowiki></code> on OFTC, Tuesdays at 1900 UTC. Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend.

Please feel free to add agenda items (and your IRC nick in parenthesis).

== Agenda for next meeting ==

* Announcements
** No meetings December 12, 26, and January 2.

* Actions from last meeting

* Specs Review

* Topics
** Upgrading Bionic servers to Focal/Jammy (clarkb 20230627)
*** https://etherpad.opendev.org/p/opendev-bionic-server-upgrades
*** Tonyb is adding new mirror servers.
*** New mirror servers should be ready. Is it time to update CNAMEs and plan for old server cleanup?
** DIB bionic support (ianw 20231206)
*** py36 tox unittesting broken -- proposal to drop https://review.opendev.org/c/openstack/diskimage-builder/+/901093
*** unit testing has been kept this long to ensure in-chroot tools are python3.6 clean -- bionic only platform still supported
*** one suggestion is to pause bionic builds - see comment in https://review.opendev.org/c/openstack/project-config/+/901692 and comments in PS1
**** clarkb points out this is painful if cloud providers change, and dib _probably_ won't break the build anyway
*** second option is to drop tox 36 testing, but leave bionic test in dib-functests. Probably enough coverage for basic support. Should probably do a release first.
** Python container updates (tonyb 20230718)
*** https://review.opendev.org/q/(topic:bookworm-python3.11+OR+hashtag:bookworm)+status:open Next round of image rebuilds onto bookworm.
*** zuul-operator is the last hold out on python3.10. Working through failures in CI there.
**** https://review.opendev.org/c/zuul/zuul-operator/+/881245 is the change we need to get landed.
** Gitea 1.21.1 Upgrade (clarkb 20230926)
*** https://review.opendev.org/c/opendev/system-config/+/902490 Configure Gerrit to use new SSH key
*** After Gerrit is restarted and using the new key we can remove the old key from Gitea. At that point we should be ready to plan the Gitea upgrade.
*** https://review.opendev.org/c/opendev/system-config/+/897679 Upgrade to Gitea 1.21.0
** Updating Zuul's database server (clarkb 20231121)
*** Currently this is an older mysql 5.7 trove instance
*** We can move it to a self hosted instance (maybe on a dedicated host?) running out of docker like many of our other services and get it more up to date.
*** Are there other services we should consider this for as well?
*** Research/Planning questions: https://etherpad.opendev.org/p/opendev-zuul-mysql-upgrade
** Annual Report Season (clarkb 20231128)
*** OpenDev's 2023 Annual Report Draft will live here: https://etherpad.opendev.org/p/2023-opendev-annual-report
** EMS discontinuing legacy/consumer hosting plans (fungi 20231219)
*** We have until 2024-02-07 to upgrade to a business hosting plan (prepaying a year at 10x the current price) or move elsewhere.
** Followup on 20231216 incident (frickler 20231217)
*** Do we want to pin external images like haproxy and only bump them after testing? (Not sure that would've helped for the current issue though)
*** Use docker prune less aggressively for easier rollback?
**** We do so for some services, like https://opendev.org/opendev/system-config/src/branch/master/playbooks/roles/gitea/tasks/main.yaml#L71-L76, might want to duplicate for all containers? Bump the hold time to 7d?
*** Add timestamps to zuul_reboot.log?
**** https://opendev.org/opendev/system-config/src/branch/master/playbooks/service-bridge.yaml#L41-L55
**** Also this is running on Saturdays (weekday: 6), do we want to fix the comment or the dow?
*** Do we want to document or implement a procedure for rolling back zuul upgrades? Or do we assume that issues can always be fixed in a forward going way?
** AFS quota issues (frickler 20231217)
*** mirror.openeuler has reached its quota limit and the mirror job seems to be failing since two weeks. I'm also a bit worried that they seem do have doubled their volume over the last 12 months
*** ubuntu mirrors are also getting close, but we might have another couple of months time there
*** mirror.centos-stream seems to have a steep increase in the last two months and might also run into quota limits soon
*** project.zuul with the latest releases is getting close to its tight limit of 1GB (sic), I suggest to simply double that
** Broken wheel build issues (frickler 20231217)
*** wheel builds for centos >=8 seem broken, with nobody maintaining these it might be better to drop them?
* Open discussion
** (tonyb 20231128) [If time permits]. Could we enable via roles/jobs or with an additional nodepool driver. The ability for [OpenStack] project teams to run unit tests with the python images we already build eg https://review.opendev.org/c/opendev/system-config/+/898756.

== Upcoming Project Renames ==
(any additions should mention original->new full names and link to the corresponding project-config rename change in Gerrit)
Changes should have their topic set to project-rename.

* Rename foo/example -> bar/example: https://review.opendev.org/123456

== Previous meetings ==
Previous meetings, with their notes and logs, can be found at http://eavesdrop.openstack.org/meetings/infra/ and earlier at http://eavesdrop.openstack.org/meetings/ci/

Meetings/TechnicalCommittee

2023-11-27T07:49:41Z

Frickler: Added "inactive projects" topic

__NOTOC__

The OpenStack Technical Committee is one of the [https://governance.openstack.org governing bodies] of the OpenStack project. You can find more information about it, such as the list of its [https://governance.openstack.org/tc/ current members] or its [https://governance.openstack.org/tc/reference/charter.html governance charter], on the OpenStack TC governance website at https://governance.openstack.org/tc/ .

In order to include as many people as possible in the discussion, the Technical Committee relies on asynchronous communications as much as possible. We propose and vote on changes through the [http://git.openstack.org/cgit/openstack/governance openstack/governance repository]. Large-impact changes are discussed on the openstack-discuss mailing-list. '''We track current initiatives on the [[Technical_Committee_Tracker]].'''

Although we don't hold office hours, you can find various members of the TC at various times throughout the week in the [http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ #openstack-tc] IRC channel. We also meet formally [http://eavesdrop.openstack.org/#Technical_Committee_Meeting each week] in #openstack-tc. The first meeting of the month is usually a video meeting; connection information will be posted below when that's the case.

=== Next Meeting ===

'''2023 November 21 meeting cancelled due to Amercian Thanksgiving'''

* Date: 2023 November 28
* Time: 18.00 UTC: http://eavesdrop.openstack.org/#Technical_Committee_Meeting
* Chair: Jay Faulkner (JayF)
* Agenda to be published on the OpenStack-discuss mailing list before the meeting
* Location: #openstack-tc on OFTC IRC

==== Agenda Suggestions ====

* Roll call
* Follow up on tracked action items: https://meetings.opendev.org/meetings/tc/2023/tc.2023-11-07-18.00.html
** Rosmaita to propose amendment to unmaintained branch resolution allowing a single review group
** Rosmaita to email mailing list about progress implementing unmaintained branch resolution
* Gate health check
* Leaderless projects (gmann)
* Implementation of Unmaintained branch statuses
* 2024.1 TC Tracker
** https://etherpad.opendev.org/p/tc-2024.1-tracker
* Upgrade issue between tooz and cinder
** https://review.opendev.org/c/openstack/requirements/+/901131
** https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/L72QU3SR2VFVYOFXVYH74V7HGMQ3YJRU/
* Declare projects inactive for lack of ...?
** Working py311 unit tests
** Support for sqla2
** Broken CI since 2023.2 release
** Do we want/need to look at specific deliverables or only whole projects?
* Open Discussion and Reviews

==== Absence ====

=== Past meetings logs ===

Logs of past TC meetings can be accessed at http://eavesdrop.openstack.org/meetings/tc for IRC meetings and https://www.youtube.com/@openstack-tc for video meetings.

[[Category: meetings]]

Meetings/TechnicalCommittee

2023-11-20T12:42:25Z

Frickler: /* Agenda Suggestions */ added tooz/cinder topic

__NOTOC__

The OpenStack Technical Committee is one of the [https://governance.openstack.org governing bodies] of the OpenStack project. You can find more information about it, such as the list of its [https://governance.openstack.org/tc/ current members] or its [https://governance.openstack.org/tc/reference/charter.html governance charter], on the OpenStack TC governance website at https://governance.openstack.org/tc/ .

In order to include as many people as possible in the discussion, the Technical Committee relies on asynchronous communications as much as possible. We propose and vote on changes through the [http://git.openstack.org/cgit/openstack/governance openstack/governance repository]. Large-impact changes are discussed on the openstack-discuss mailing-list. '''We track current initiatives on the [[Technical_Committee_Tracker]].'''

Although we don't hold office hours, you can find various members of the TC at various times throughout the week in the [http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ #openstack-tc] IRC channel. We also meet formally [http://eavesdrop.openstack.org/#Technical_Committee_Meeting each week] in #openstack-tc. The first meeting of the month is usually a video meeting; connection information will be posted below when that's the case.

=== Next Meeting ===

'''2023 November 21 meeting cancelled due to Amercian Thanksgiving'''

* Date: 2023 November 28
* Time: 18.00 UTC: http://eavesdrop.openstack.org/#Technical_Committee_Meeting
* Chair: Jay Faulkner (JayF)
* Agenda to be published on the OpenStack-discuss mailing list before the meeting
* Location: #openstack-tc on OFTC IRC

==== Agenda Suggestions ====

* Roll call
* Follow up on tracked action items: https://meetings.opendev.org/meetings/tc/2023/tc.2023-11-07-18.00.html
** Rosmaita to propose amendment to unmaintained branch resolution allowing a single review group
** Rosmaita to email mailing list about progress implementing unmaintained branch resolution
* Gate health check
* Leaderless projects (gmann)
* Implementation of Unmaintained branch statuses
* 2024.1 TC Tracker
** https://etherpad.opendev.org/p/tc-2024.1-tracker
* Upgrade issue between tooz and cinder
** https://review.opendev.org/c/openstack/requirements/+/901131
** https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/L72QU3SR2VFVYOFXVYH74V7HGMQ3YJRU/
* Open Discussion and Reviews

==== Absence ====

=== Past meetings logs ===

Logs of past TC meetings can be accessed at http://eavesdrop.openstack.org/meetings/tc for IRC meetings and https://www.youtube.com/@openstack-tc for video meetings.

[[Category: meetings]]

Meetings/InfraTeamMeeting

2023-10-05T19:57:27Z

Frickler: Added meeting timeslot agenda item

Network/Meetings

2023-01-24T10:16:44Z

Frickler: add frickler to ping list

The OpenStack Networking Team ([[Neutron]]) holds public meetings as advertised on [http://eavesdrop.openstack.org/#Neutron_Team_Meeting OpenStack IRC Meetings Calendar]. If you are unable to attend, please check the most recent [http://eavesdrop.openstack.org/meetings/networking/ logs.]

'''Ping list''': bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, sahid, slawek, tobias-urdin, ykarel, lajoskatona

=== Announcements / Reminders ===
* TO TALK ABOUT THE IN-PERSON MEETING AGENDA!!!
* Antelope / 2023.1 schedule: https://releases.openstack.org/antelope/schedule.html
** This week, the release team will send the first Antelope release, milestone-2.
** #link https://review.opendev.org/q/project:openstack%252Freleases+status:open
** Open reviews:
*** https://review.opendev.org/c/openstack/releases/+/869060/
*** https://review.opendev.org/c/openstack/releases/+/869054
*** https://review.opendev.org/c/openstack/releases/+/869055

* Rechecks

* OpenInfra Live event - https://openinfra.dev/live/#all-episodes - there are some interesting presentations there, maybe You would be interested in some of them

* Antelope cycle PTG summary and etherpad:
** https://lists.openstack.org/pipermail/openstack-discuss/2022-October/030986.html
** https://etherpad.opendev.org/p/neutron-antelope-ptg

=== Bugs and Gate issues ===

* Report from lucasgomes:
** https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031796.html

* Bugs without assignee or to be commented:
** https://bugs.launchpad.net/neutron/+bug/2002577

* This week jlibosva is the deputy, next week will be obondarev.

* More discussion on this topic takes place during the Neutron CI meeting: https://wiki.openstack.org/wiki/Meetings/NeutronCI

* Clean up tox:
** https://review.opendev.org/q/topic:cleanup-tox
https://review.opendev.org/q/topic:tox4

* [https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.tag=gate-failure Confirmed gate failures]
* [https://bugs.launchpad.net/neutron/+bugs?field.tag=needs-attention Bugs that need attention]
* [https://bugs.launchpad.net/neutron/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.tag=deprecation All bug reports associated to deprecation issues]
* [https://goo.gl/KtEwbL Bugs Sheet]
* [http://grafana.openstack.org/dashboard/db/neutron-failure-rate Grafana dashboards]

==== Bug deputy ====

You can find more information about what the role is here: https://docs.openstack.org/neutron/latest/contributor/policies/bugs.html#neutron-bug-deputy. During the Denver PTG we made the decision to institute a fixed rotation for the the bugs deputy role. The currently scheduled rotation is the following:
{| class="wikitable" style="text-align: center;"
|-
! Date !! who !! note
|-
| 2022-11-14 || Bernard Cafarelli (bcafarel) ||
|-
| 2022-11-21 || Lajos Katona (lajoskatona) ||
|-
| 2022-11-28 || Slawek Kaplonski (slaweq) ||
|-
| 2022-12-05 || Brian Haley (haleyb) ||
|-
| 2022-12-12 || Akihiro Motoki (amotoki) ||
|-
| 2022-12-19 || Miguel Lavalle (mlavalle) ||
|-
| 2022-12-26 || Bence Romsics (rubasov) ||
|-
| 2023-01-02 || Rodolfo Alonso Hernandez (ralonsoh) ||
|-
| 2023-01-09 || Lucas Alvares Gomes (lucasgomes) ||
|-
| 2023-01-16 || Jakub Libosvar (jlibosva) ||
|-
| 2023-01-23 || Oleg Bondarev (obondarev) ||
|-
| 2023-01-30 || Mamatisa Nurmatov (isabek) ||
|-
| 2023-02-06 || Elvira García Ruiz (elvira) ||
|-
| 2023-02-13 || Yatin Karel (ykarel) ||
|}

In preparation for their duty week, deputies are encouraged to review the Neutron bugs policy: https://docs.openstack.org/neutron/latest/contributor/policies/bugs.html

=== ryu os-ken ===

* To move os-ken from https://storyboard.openstack.org/ to launchpad.
https://ethercalc.openstack.org/make_os-ken_and_ryu_sync

* Story board to track ryu backports: https://storyboard.openstack.org/#!/story/2009283

* New patches in ryu:
** (nothing)

=== Specs ===

Specs: https://review.opendev.org/q/project:openstack%252Fneutron-specs+status:open

=== Community Goals ===

* Last TC meeting summary: https://lists.openstack.org/pipermail/openstack-discuss/2022-December/031380.html

* Current Selected (Active) Goals:
** Consistent and Secure Default RBAC
*** https://review.opendev.org/c/openstack/tempest/+/614484
*** https://review.opendev.org/c/openstack/devstack/+/861930
*** https://review.opendev.org/c/openstack/neutron-lib/+/864213
** Migration to Ubuntu 22.04:
*** https://review.opendev.org/c/openstack/neutron/+/862492
*** https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/857031
** Clean-up neutron-legacy code in devstack
*** Devstack code merged
*** Removal of dependencies of lib/neutron-legacy: https://review.opendev.org/q/topic:drop-lib-neutron
*** https://review.opendev.org/q/topic:drop-lib-neutron
** Neutron client deprecation
*** https://bugs.launchpad.net/neutron/+bug/1999774
**** https://review.opendev.org/c/openstack/tap-as-a-service/+/867786

=== Neutron-lib, planned refactoring and other impacts ===

<>

=== On Demand Agenda ===

We can only pick one or two topics we can talk in the time left of the meeting. People should add ideas to the topics section. We will select one or two topics we can chew during the next meeting. Please follow the template below:

* Topic for the meeting (keep this template, please):
** (ralonsoh): tox envlist: keep "py38" or move to "py3". This should be consistent on any Neutron related project
** (ralonsoh): to have a "pinging list". This is an IRC nickname list with the people who wants to be actively pinged just before the meeting. We currently have 3 main meetings (Neutron, CI and drivers); we can propose separate lists or a single one (to be decided).
** (lajoskatona) [For 24. Jan. Meeting]: [ptl][tc] OpenStack packages PyPi additional external maintainers audit & cleanup #link https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031848.html
*** https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup

== 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/2023/?C=M;O=D networking-2023]
** [http://eavesdrop.openstack.org/meetings/networking/2022/?C=M;O=D networking-2022]
** [http://eavesdrop.openstack.org/meetings/networking/2021/?C=M;O=D networking-2021]
** [http://eavesdrop.openstack.org/meetings/networking/2020/?C=M;O=D networking-2020]
** [http://eavesdrop.openstack.org/meetings/networking/2019/?C=M;O=D networking-2019]
** [http://eavesdrop.openstack.org/meetings/networking/2018/?C=M;O=D networking-2018]
** [http://eavesdrop.openstack.org/meetings/networking/2017/?C=M;O=D networking-2017]
** [http://eavesdrop.openstack.org/meetings/networking/2016/?C=M;O=D networking-2016]
** [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]

Meetings/InfraTeamMeeting

2022-11-15T13:42:27Z

Frickler: add twitter topic

Meetings/InfraTeamMeeting

2022-11-07T15:29:00Z

Frickler:

Meetings/InfraTeamMeeting

2022-10-08T11:10:04Z

Frickler: Add "switch base job to jammy" topic

Meetings/InfraTeamMeeting

2022-06-11T10:44:04Z

Frickler: Added two new project ideas

Meetings/InfraTeamMeeting

2022-05-23T06:55:01Z

Frickler: Add requirements propose-updates topic

UsingIRC

2022-04-29T13:07:46Z

Frickler: Drop old pic referring freenode and link to current docs instead.

= How to talk to OpenStack community members on IRC Channel =
IRC, or Internet Relay Chat, is often used as a real-time communication capability with open source projects. We're pretty proud of the friendly vibe in the OpenStack channel and invite anyone wanting to ask questions or talk about all things OpenStack to the channel.

You don't have to have a complex setup to use IRC. You can use the web client for OFTC, which doesn't require any download or setup. Just pick a nickname and join #openstack: http://webchat.oftc.net/?channels=openstack,openstack-dev. For more information see https://docs.openstack.org/contributors/common/irc.html and https://docs.opendev.org/opendev/infra-manual/latest/irc.html .

== How to read messages exchanged when you're offline ==

IRC, unlike other chat systems, doesn't keep when you're offline. In order to be notified of relevant communications you can either look at the [http://eavesdrop.openstack.org/irclogs/ channel logs] or setup an IRC proxy.

The most common IRC proxies are [http://wiki.znc.in/ZNC znc] and [https://bip.milkypond.org/ bip].

=== Notes to configure bip ===

* [https://kashyapc.fedorapeople.org/notes-bip-IRC-proxy/README Installation notes for Fedora/RH-like] and [https://kashyapc.fedorapeople.org/notes-bip-IRC-proxy/bip.conf example bip.conf] contributed by Kashyap Chamarthy

=== Notes to configure znc ===

* [https://dague.net/2014/09/13/my-irc-proxy-setup/ Configuration notes] contributed by Sean Dague

Meetings/InfraTeamMeeting

2022-04-25T04:47:43Z

Frickler: Add jammy topic

Meetings/InfraTeamMeeting

2022-01-27T15:14:58Z

Frickler: Gerrit mergeabilityComputationBehavior

Meetings/InfraTeamMeeting

2022-01-13T10:08:06Z

Frickler: Propose review cleanup

Network/Meetings

2021-11-16T09:51:15Z

Frickler:

The OpenStack Networking Team ([[Neutron]]) holds public meetings as advertised on [http://eavesdrop.openstack.org/#Neutron_Team_Meeting OpenStack IRC Meetings Calendar]. If you are unable to attend, please check the most recent [http://eavesdrop.openstack.org/meetings/networking/ logs.]

=== Announcements / Reminders ===

* Yoga cycle calendar https://releases.openstack.org/yoga/schedule.html
** Week R-19: http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025756.html
* OpenInfra Live event - https://openinfra.dev/live/#all-episodes - there are some interesting presentations there, maybe You would be interested in some of them
* Yoga cycle PTG summary: http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025528.html

=== Blueprints ===

Blueprints which we should include in Yoga milestones:

=== Community Goals ===

* RBAC....
** Mail from last meeting of TC: http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025693.html
** Etherpad with notes: https://etherpad.opendev.org/p/policy-popup-yoga-ptg
** https://review.opendev.org/c/openstack/governance/+/815158

This slot is to used to track the progress of the community goals.
https://governance.openstack.org/tc/goals/index.html#release-cycles

=== Bugs and Gate issues ===

slaweq was bug deputy last week: http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025770.html

This week hongbin is the deputy, and next week haleyb will be.

More discussion on this topic takes place during the Neutron CI meeting: https://wiki.openstack.org/wiki/Meetings/NeutronCI

* [https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.tag=gate-failure Confirmed gate failures]
* [https://bugs.launchpad.net/neutron/+bugs?field.tag=needs-attention Bugs that need attention]
* [https://bugs.launchpad.net/neutron/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.tag=deprecation All bug reports associated to deprecation issues]
* [https://goo.gl/KtEwbL Bugs Sheet]
* [http://grafana.openstack.org/dashboard/db/neutron-failure-rate Grafana dashboards]

==== Bug deputy ====

You can find more information about what the role is here: https://docs.openstack.org/neutron/latest/contributor/policies/bugs.html#neutron-bug-deputy

During the Denver PTG we made the decision to institute a fixed rotation for the the bugs deputy role. The currently scheduled rotation is the following:

{| class="wikitable" style="text-align: center;"
|-
! Date !! who !! note
|-
| Nov-1-2021 || Bernard Cafarelli (bcafarel) ||
|-
| Nov-8-2021 || Slawek Kaplonski (slaweq) ||
|-
| Nov-15-2021 || Hongbin Lu (hongbin) ||
|-
| Nov-22-2021 || Brian Haley (haleyb) ||
|-
| Nov-29-2021 || Lajos Katona (lajoskatona) ||
|-
| Dec-6-2021 || Akihiro Motoki (amotoki) ||
|-
| Dec-13-2021 || Miguel Lavalle (mlavalle) ||
|-
| Dec-20-2021 || Bence Romsics (rubasov) ||
|-
| Dec-27-2021 || Rodolfo Alonso Hernandez (ralonsoh) ||
|-
| Jan-3-2022 || Lucas Alvares Gomes (lucasgomes) ||
|-
| Jan-10-2022 || Jakub Libosvar (jlibosva) ||
|-
| Jan-17-2022 || Oleg Bondarev (obondarev) ||
|-
| Jan-24-2022 || Mamatisa Nurmatov (isabek) ||
|}

In preparation for their duty week, deputies are encouraged to review the Neutron bugs policy: https://docs.openstack.org/neutron/latest/contributor/policies/bugs.html

=== L3 subteam ===
Blueprints:
* https://blueprints.launchpad.net/neutron/+spec/openflow-based-dvr-l3
* https://blueprints.launchpad.net/neutron/+spec/multiple-external-gateways
* https://blueprints.launchpad.net/neutron/+spec/floatingips-portforwarding-ranges
* https://blueprints.launchpad.net/neutron/+spec/support-for-ecmp
* https://blueprints.launchpad.net/neutron/+spec/bgp-enhancement

Other:
* [RFE] Add distributed datapath for metadata
* https://bugs.launchpad.net/neutron/+bug/1933222

=== ryu os-ken ===

* No new changes in ryu.
* os-ken 2.3.0 is out now.

https://ethercalc.openstack.org/make_os-ken_and_ryu_sync

=== Neutron performance subteam ===

=== Docs ===

* The future of OpenStack documentation - http://lists.openstack.org/pipermail/openstack-dev/2016-July/099012.html
* Documentation bugs - https://bugs.launchpad.net/neutron/+bugs?field.tag=doc

=== Neutron-lib, planned refactoring and other impacts ===

HOUSE KEEPING
* Neutron-lib work items and volunteers are being tracked via etherpad: https://etherpad.openstack.org/p/neutron-lib-volunteers-and-punch-list
* For a list of "current" consumers who receive neutron-lib updates and consumption patches, see: http://codesearch.openstack.org/?q=neutron-lib-current
* For a complete list of neutron-lib consumption patches that may impact consumers see: https://review.openstack.org/#/q/message:%22NeutronLibImpact%22

PATCHES THAT NEED REVIEWS
* Decouple DB workstream/blueprint: https://review.openstack.org/#/q/status:open+topic:bp/neutronlib-decouple-db+label:Workflow%253D0
* Callback payload workstream: https://review.openstack.org/#/q/status:open+topic:use-callback-payloads+label:Workflow%253D0

=== On Demand Agenda ===

We can only pick one or two topics we can talk in the time left of the meeting. People should add ideas to the topics section. We will select one or two topics we can chew during the next meeting. Please follow the template below:

* Topic for the meeting (keep this template, please):
** (nick): topic
** (frickler): Bugs/Gaps with OVN and DNS resolution
*** https://bugs.launchpad.net/neutron/+bug/1950686 [OVN] dns-nameserver=0.0.0.0 for a subnet isn't treated properly
*** https://bugs.launchpad.net/neutron/+bug/1951074 [OVN] default setting leak nameserver config from the host to instances
*** https://bugs.launchpad.net/neutron/+bug/1902950 [OVN] DNS resolution not forwarded with OVN driver
*** https://bugs.launchpad.net/neutron/+bug/1899207 [OVN][Docs] admin/config-dns-res.html should be updated for OVN

== 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/2021/?C=M;O=D networking-2021]
** [http://eavesdrop.openstack.org/meetings/networking/2020/?C=M;O=D networking-2020]
** [http://eavesdrop.openstack.org/meetings/networking/2019/?C=M;O=D networking-2019]
** [http://eavesdrop.openstack.org/meetings/networking/2018/?C=M;O=D networking-2018]
** [http://eavesdrop.openstack.org/meetings/networking/2017/?C=M;O=D networking-2017]
** [http://eavesdrop.openstack.org/meetings/networking/2016/?C=M;O=D networking-2016]
** [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]

Meetings/Kolla

2021-10-27T15:03:19Z

Frickler: Add frickler to ping list

== Weekly Kolla team meeting ==

Meeting time: Wednesdays at 15:00 UTC in <code><nowiki>#openstack-kolla</nowiki></code> (OFTC IRC network).

More info on how to join: http://eavesdrop.openstack.org/#Kolla_Team_Meeting

We track CI, release, and feature status in the [https://etherpad.openstack.org/p/KollaWhiteBoard whiteboard].

=== Agenda for the next meeting ===

<pre>
* Roll-call
* Agenda
* Announcements
* Review action items from the last meeting
* CI status
* Release tasks
* Yoga cycle planning
* Open discussion
</pre>

=== Regular agenda ===
Copy/Paste into IRC to kick the meeting off:
<pre>
#startmeeting kolla
</pre>

Then, once the bot has caught up and everyone is settled:

<pre>
#topic rollcall
</pre>

Once folks have checked in, run the agenda by the group present:

<pre>
#topic agenda
copy and paste agenda from above
</pre>

Go through topics from agenda

<pre>
#topic something
</pre>

And in the end finish the meeting

<pre>
#endmeeting
</pre>

=== Copy/Paste for IRC ===

* https://bugs.launchpad.net/kolla
* https://blueprints.launchpad.net/kolla

<pre>
#link https://bugs.launchpad.net/kolla
#link https://blueprints.launchpad.net/kolla
</pre>

=== Previous meetings ===

* IRC logs [http://eavesdrop.openstack.org/meetings/kolla]

=== 10 minute warning ===

Please add your name to the following list if you would like a 10 minute warning in #openstack-kolla.
<pre>
mgoddard mnasiadka hrw egonzalez yoctozepto rafaelweingartne cosmicsound osmanlicilegi bbezak parallax Fl1nt frickler
</pre>

== Other Kolla meetings ==

[https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_4_Sw Kolla Klub - biweekly (every other Thursday 15:00 UTC) operator-oriented calls]

[[Meetings/Kolla/Kall|Kolla Kall - biweekly (every other Thursday 15:00 UTC) developer-oriented calls]]

Meetings/InfraTeamMeeting

2021-10-14T17:21:24Z

Frickler:

= Weekly Project Infrastructure team meeting =

The OpenDev Team holds public weekly meetings in <code><nowiki>#opendev-meeting</nowiki></code> on OFTC, Tuesdays at 1900 UTC. Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend.

Please feel free to add agenda items (and your IRC nick in parenthesis).

== Agenda for next meeting ==

* Announcements

* Actions from last meeting

* Specs Review
** Prometheus spec https://review.opendev.org/c/opendev/infra-specs/+/804122
*** This appears to have the votes. Plan to merge it Thursday 23:00UTC ish if no objections show up.
** Mailman 3 spec https://review.opendev.org/810990
*** Can use more reviews, but looks good to clarkb.

* Topics
** Improving OpenDev's CD throughput (clarkb 20211012)
*** We can run many of our jobs in parallel in all of our CD pipelines. But this requires we properly document/address dependencies
**** Need to understand our job dependencies and properly note them in Zuul config or address them by combining jobs.
***** Example 1: Combine service-gitea-lb and service-gitea jobs.
***** Example 2: Combine letsencrypt and nameserver jobs
***** Example 3: Have all jobs with webserver config express a dependency on the letsencrypt job
**** Suggest we document the known job dependencies in a human readable format, then encode this into zuul, then we can switch to parallel runs.
**** https://review.opendev.org/c/opendev/system-config/+/807672
***** should list dependencies for all jobs
***** zuul doesn't trigger on this? not sure on best approach to make it mergable
**** https://review.opendev.org/c/opendev/base-jobs/+/807807
***** currently every executor adds keys for bridge, then logs in and clones system-config before running playbooks
***** this change makes split jobs to do this. however, production remains the same as both are called.
**** https://review.opendev.org/c/opendev/system-config/+/807808
***** this is a follow-on that adds a base job to clone system-config, and stops the other production jobs re-cloning.
***** this job must run first, but then all other jobs can run in parallel, as they are all in the same buildset and using the same "view" of system-config for that particular run
** Gerrit Account cleanups (clarkb 20211012)
*** 33 conflicts remain. Clarkb has written notes on proposed plans for each user in the comments of review02:~clarkb/gerrit_user_cleanups/audit-results-annotated.yaml
** Scheduling Gerrit project renames (clarkb 20211012)
*** October 15 at 18:00UTC.
*** Now is the time to make sure projects have their changes in order and that we are ready.
*** Updating the process to update project metadata on renamed projects
** Upgrading to Gerrit 3.3 (ianw 20211012)
*** Upgrade happened over the weekend. Went very smoothly
*** clarkb has been using hashtag:gerrit-3.3 to track post upgrade changes that we want to land related to the upgrade
*** Are we ready to drop the 3.2 images? https://review.opendev.org/c/opendev/system-config/+/813074
*** Next up 3.4!
** Improve zuul restarts (frickler 20211014)
*** Docs at https://docs.opendev.org/opendev/system-config/latest/zuul.html#restarting-the-scheduler need updating
**** What to restart (scheduler,web,fingergw?) and how (docker restart vs. docker-compose)
**** When to run the re-enqueue
**** Collecting debug information
*** Don't reenqueue periodic jobs

* Open discussion

== Upcoming Project Renames ==
(any additions should mention original->new full names and link to the corresponding project-config rename change in Gerrit)

* Venus project (below repos) moving from inspur to openstack namespace: https://review.opendev.org/808149
** inspur/python-venusclient -> openstack/python-venusclient
** inspur/venus -> openstack/venus
** inspur/venus-specs -> openstack/venus-specs
** inspur/venus-tempest-plugin -> openstack/venus-tempest-plugin
** inspur/venus-dashboard -> openstack/venus-dashboard
* osf to openinfra namespace move: https://review.opendev.org/808479
* ansible-role-refstack-client from x to openinfra: https://review.opendev.org/765787

== Previous meetings ==
Previous meetings, with their notes and logs, can be found at http://eavesdrop.openstack.org/meetings/infra/ and earlier at http://eavesdrop.openstack.org/meetings/ci/

Meetings/InfraTeamMeeting

2021-02-15T07:14:13Z

Frickler:

Meetings/InfraTeamMeeting

2020-10-30T16:07:24Z

Frickler:

Meetings/InfraTeamMeeting

2020-09-07T10:21:53Z

Frickler: /* Agenda for next meeting */

Meetings/InfraTeamMeeting

2020-02-26T13:03:46Z

Frickler: /* Agenda for next meeting */

= Weekly Project Infrastructure team meeting =

The OpenStack Project Infrastructure Team holds public weekly meetings in <code><nowiki>#openstack-meeting</nowiki></code>, Tuesdays at 1900 UTC. Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend.

Please feel free to add agenda items (and your IRC nick in parenthesis).

== Agenda for next meeting ==

* Announcements

* Actions from last meeting

* Specs approval
** https://review.opendev.org/#/c/709579/ Cleaning up python dev tools on our CI images.
*** https://etherpad.openstack.org/p/pTFF4U9Klz : clarkb writeup of major issues
*** https://review.opendev.org/707499 : discussion in comments
*** https://review.opendev.org/707513 : use venv for glean
*** https://review.opendev.org/707750 : use venv in project-config elements; drop pip-and-virtualenv inclusion from element and move to individual configs; add node type with no pip-and-virtualenv. this can be used for job testing.
** https://review.opendev.org/#/c/709236/ Website activity stats

* Priority Efforts (Standing meeting agenda items. Please expand if you have subtopics.)
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/update-config-management.html Update Config Management]
*** topic:update-cfg-mgmt
*** Zuul as CD engine
** OpenDev
*** Progress on Governance changes
**** https://review.opendev.org/#/c/703134/ Split OpenDev out of OpenStack governance.
**** https://review.opendev.org/#/c/703488 Updates to our project documentation with governance info

* General topics
** Xwiki for opendev (ttx 20200224)
** Vancouver PTG attendance. (clarkb 20200225)
*** Request space for a small group in Vancouver. Mentioned that we can be flexible, but having some official time is useful so that people can find us with questions. Then with a small group it is easy enough to meet in an ad hoc fashion (this worked well in Shanghai).
** Trusty Upgrade Progress (clarkb 20200225)
*** Wiki updates
** static.openstack.org (ianw,corvus,mnaser,fungi 20200225)
*** static.openstack.org transition should be complete
*** still tasks remaining (haproxy redirects, few other publishing sites)
** Discuss future IRC channel usage (frickler 20200226)
*** We have both #openstack-infra and #opendev, maybe after the governance change we can now focus on using the latter?
*** In particular the high number of duplicated gerritbot msgs is seen as an annoyance, some are even seen yet once more elsewhere, like for zuul/zuul.

* Open discussion

== Upcoming Project Renames ==
(any additions should mention original->new full names and link to the corresponding project-config rename change in Gerrit)

None currently.

== Previous meetings ==
Previous meetings, with their notes and logs, can be found at http://eavesdrop.openstack.org/meetings/infra/ and earlier at http://eavesdrop.openstack.org/meetings/ci/

Release Naming/W Proposals

2020-01-24T09:55:26Z

Frickler:

== W Release Naming ==

According to the [http://governance.openstack.org/reference/release-naming.html Release Naming Process], this page will contain a list of nominated names for the W release of OpenStack. We will accept nominations until February 7, 2020 23:59:59 UTC.

=== Release Name Criteria ===

The way we do release naming has changed slightly from past releases. Rather than restricting name candidates to the geographic region where the Summit is held, we will now accept any name a member of the community would like to propose, as long as the name begins with the appropriate letter. The current release naming criteria are:

* Each release name must start with the letter of the ISO basic Latin alphabet following the initial letter of the previous release, starting with the initial release of "Austin". After "Z", the next name should start with "A" again.
* The name must be composed only of the 26 characters of the ISO basic Latin alphabet. Names which can be transliterated into this character set are also acceptable.
* The name must be a single word with a maximum length of 10 characters.

Names which do not meet these criteria but otherwise sound really cool
should be added to a separate section of the wiki page and the TC may
make an exception for one or more of them to be considered in the
Condorcet poll. The naming official is responsible for presenting the
list of exceptional names for consideration to the TC before the poll
opens.

=== Proposed Names ===

Please list names with any relevant links to more details. If there is a particular reason you think a name would be a good choice, please add a brief rationale with the name.

* [https://en.wikipedia.org/wiki/Wallaby Wallaby] Wallabies are native to Australia, which at the start of this naming period is currently experiencing unprecedented wild fires.
* [https://en.wikipedia.org/wiki/Monty_Python%27s_Life_of_Brian Wodewick] A reference to a famous and hilarious scene ("Release Wodewick!") in a movie by Monty Python (also the source of the name of the Python language), and/or a cheap joke at the expense of people with [https://en.wikipedia.org/wiki/Rhotacism_(speech_impediment) speech impediments], depending on your perspective. Would also show our reverence to the recently passed [https://en.wikipedia.org/wiki/Terry_Jones Terry Jones], the director of that movie.
* [https://en.wikipedia.org/wiki/NATO_phonetic_alphabet Whiskey] The International Radiotelephony Spelling Alphabet codeword for the letter W.
* [https://en.wikipedia.org/wiki/Whisky#Names_and_spellings Whisky] A popular alcoholic beverage.
* [https://www.lexico.com/en/definition/wow Wow] A noun that represents a sensational success, like OpenStack.
* [https://www.whistlerblackcomb.com/ Whistler] Renowned year-round resort known for skiing, snowboarding, biking.
* [https://en.wiktionary.org/wiki/worldwide Worldwide] - OpenStack is a truly global phenomenon now.
* [https://en.wiktionary.org/wiki/wheelhouse Wheelhouse] - An idiom meaning "in an area of one's greatest capabilities or expertise". Comes from the place a pilot would stand to navigate a ship (Kubernetes metaphors galore). Also, an excellent gastropub in Dallas.
* [https://en.wikipedia.org/wiki/Winter Winter] Climate change might lead to winter not coming anymore. At least OpenStack could bring winter to us easily.
* [https://en.wikipedia.org/wiki/Wasabi Wasabi] It is a japanese plant and a paste made of this plant. It is served with sushi.
* [https://en.wiktionary.org/wiki/woodwind Woodwind] Because woodwinds are better than brass.
* [https://en.wikipedia.org/wiki/Washington Washington] the geographical area just south of Victoria, also the capital of the USA.
* [https://en.wikipedia.org/wiki/Washi Washi] Japanese paper often used for origami
* [https://en.wikipedia.org/wiki/Wakanda Wakanda] Although a fictional country, it represents state-of-the-art tech advancements which conforms to OpenStack's standards
* [https://www.thesprucecrafts.com/steam-locomotive-classes-2382510 Western] Name for 4-8-4 Steam Locomotive on the Denver and Rio Grande Western Railroad
* [https://www.thesprucecrafts.com/steam-locomotive-classes-2382510 Wyoming] Name for 4-8-4 Steam Locomotive on the Lehigh Valley Railroad
* [https://en.wiktionary.org/wiki/Wesen Wesen] German for being or essence, among other translations
* [https://en.wikipedia.org/wiki/Wonju Wonju] Wonju is the most populous city in Gangwon province, South Korea and it is one of the fastest growing cities.
* [https://en.wikipedia.org/wiki/Warrior Warrior] Each individual who contributes to OpenStack is a brave Warrior.
* [https://en.wikipedia.org/wiki/Wakame Wakame] A seaweed in Japan. It is one of superfood and very healthy and tasty. It also is rich in expandability and elasticability in dried form.

=== Proposed Names that do not meet the criteria ===

Release Naming/W Proposals

2020-01-14T13:40:53Z

Frickler: /* Proposed Names */ Add Wodewick

OpenstackChefStablebranchCreateNotes

2019-12-10T12:48:58Z

Frickler: Update instructions for stable branch

== Steps to create stable/<release> branch ==

Awesome! We've decided as a group to create the next stable branch. Here are some steps to remind you on how to do it.

# Go to [https://review.openstack.org/#/admin/projects/openstack/cookbook-openstack-compute,branches each repo] as a core member and create the branch with the SHA you want, usually you will just branch from master.
# Changes for each cookbook and repo, create a bug to tie all the following branch work together
## update.gitreview to ref defaultbranch=stable/<release>
## update Berksfile to ref branch: 'stable/<release>'
## see https://github.com/openstack/cookbook-openstack-identity/commit/3a99613b89fb28d21def8cbeaa63e40da32768f5 for example
# Create a review with the above and put it up against the stable/<release> branch.
# Get it merged in and you should be good

If you think doing this manually for all the cookbooks sucks, these commands might help you automating it (please CHECK the git diff before you actually push something)
# first pull all the cookbooks into one folder and then try to run these commands one by one from the root folder (they are intentionally separated, since they will create some changes that you do not want to push)
# check your sed version and make sure you have at least v 4.2.1 (if you are on OS X you have to install gnu-sed via Homebrew since the one installed does work in mysterious ways)

for i in $(ls | grep cookbook); do
cd $i
git checkout stable/<release>
sed -i '/opendev/a\ \ branch: stable\/<release>' Berksfile
sed -i 's/opendev.*$/&,/' Berksfile
echo 'defaultbranch=stable/rocky' >> .gitreview
berks install
sed -i '/Berksfile\.lock/d' .gitignore
git add Berksfile.lock
cd ..
done

# the next one is important, since there are changes that are wrong and should
# be corrected manually (like adding the branch: stable/liberty for a non
# openstack cookbook)
for i in $(ls | grep cookbook); do cd $i; git diff; cd .. ; done

# after you checked all your changes, you can go ahead, commit it and push it
# up for review
for i in $(ls | grep cookbook); do
cd $i
git commit -am 'stable/<release> release patch'
git review
cd ..
done

== Steps for new master branch ==

Now we have a new master, need to get it in sync with matching base openstack release.

# Possible infra changes for changes to the gates we want for this release
# Decide on new levels of tools (ChefDK, rubocop, foodcritic), we have always be trying to move forward with these
# Changes for each cookbook and repo.
## update metadata with new version level
## update common bootstrap with newer level of ChefDK
## create rubocop TODO file to outline that work to be done (rubocop --auto-gen-config and add "inherit_from: .rubocop_todo.yml" in your .rubocop.yml)
## update code with refs to old openstack release (i.e. "ocata" -> "pike" (Common release and yum attributes, ...)
## update all code looking for deprecation's that can now be removed
## update any package dependencies that have changed for each component
## update all spec test platforms to targeted levels we want for this release

In order to pass gates, these need to be done in the following order:
# Common, Identity, Ops-Database and Ops-Messaging
# Image, BlockStorage, Network, Dashboard, Object-Storage
# Compute, Orchestration, Telemetry, Integration-Test
# Repo

back to main page: https://wiki.openstack.org/wiki/Chef/GettingStarted

Meetings/InfraTeamMeeting

2019-11-15T12:28:14Z

Frickler: /* Agenda for next meeting */

Meetings/InfraTeamMeeting

2019-11-11T12:22:18Z

Frickler: /* Agenda for next meeting */

= Weekly Project Infrastructure team meeting =

The OpenStack Project Infrastructure Team holds public weekly meetings in <code><nowiki>#openstack-meeting</nowiki></code>, Tuesdays at 1900 UTC. Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend.

Please feel free to add agenda items (and your IRC nick in parenthesis).

== Agenda for next meeting ==

* Announcements
** Summit and PTG next week. Meeting on November 5 Cancelled.

* Actions from last meeting

* Specs approval

* Priority Efforts (Standing meeting agenda items. Please expand if you have subtopics.)
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/task-tracker.html A Task Tracker for OpenStack]
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/update-config-management.html Update Config Management]
*** topic:update-cfg-mgmt
*** Zuul as CD engine
** OpenDev

* General topics
** Graphite update (clarkb 20191029)
*** Retention for stats.timers reduced. Files updated and rechowned.
** PTG Planning (clarkb 20191029)
*** https://etherpad.openstack.org/p/OpenDev-Shanghai-PTG-2019
*** https://www.openstack.org/ptg/#tab_schedule PTG Schedule
** Cleaning up OpenSuse 150 images (clarkb 20191029)
*** The 150 images in nodepool were replaced by the 15 images. Need to update jobs so that we can remove the 150 images.
*** https://review.opendev.org/#/q/topic:use-opensuse-15
** Trusty Upgrade Progress (clarkb 20191029)
*** Wiki updates
** static.openstack.org (ianw,corvus,mnaser,fungi 20191029)
*** Review spec: https://review.opendev.org/683852
*** Sign up for tasks at https://etherpad.openstack.org/p/static-services
*** https://etherpad.openstack.org/p/openstack-org-dns
** ask.openstack.org apache2 crashing daily during logrotate (frickler 20191111)
*** Needs a volunteer to further debug and find a permanent fix
*** Some logs: http://paste.openstack.org/show/785843/

* Open discussion

== Upcoming Project Renames ==
(any additions should mention original->new full names and link to the corresponding project-config rename change in Gerrit)

== Previous meetings ==
Previous meetings, with their notes and logs, can be found at http://eavesdrop.openstack.org/meetings/infra/ and earlier at http://eavesdrop.openstack.org/meetings/ci/

Meetings/InfraTeamMeeting

2019-11-11T12:20:11Z

Frickler: /* Agenda for next meeting */

= Weekly Project Infrastructure team meeting =

The OpenStack Project Infrastructure Team holds public weekly meetings in <code><nowiki>#openstack-meeting</nowiki></code>, Tuesdays at 1900 UTC. Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend.

Please feel free to add agenda items (and your IRC nick in parenthesis).

== Agenda for next meeting ==

* Announcements
** Summit and PTG next week. Meeting on November 5 Cancelled.

* Actions from last meeting

* Specs approval

* Priority Efforts (Standing meeting agenda items. Please expand if you have subtopics.)
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/task-tracker.html A Task Tracker for OpenStack]
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/update-config-management.html Update Config Management]
*** topic:update-cfg-mgmt
*** Zuul as CD engine
** OpenDev

* General topics
** Graphite update (clarkb 20191029)
*** Retention for stats.timers reduced. Files updated and rechowned.
** PTG Planning (clarkb 20191029)
*** https://etherpad.openstack.org/p/OpenDev-Shanghai-PTG-2019
*** https://www.openstack.org/ptg/#tab_schedule PTG Schedule
** Cleaning up OpenSuse 150 images (clarkb 20191029)
*** The 150 images in nodepool were replaced by the 15 images. Need to update jobs so that we can remove the 150 images.
*** https://review.opendev.org/#/q/topic:use-opensuse-15
** Trusty Upgrade Progress (clarkb 20191029)
*** Wiki updates
** static.openstack.org (ianw,corvus,mnaser,fungi 20191029)
*** Review spec: https://review.opendev.org/683852
*** Sign up for tasks at https://etherpad.openstack.org/p/static-services
*** https://etherpad.openstack.org/p/openstack-org-dns
** ask.openstack.org apache2 crashing daily during logrotate (frickler 20191111)
*** Needs a volunteer to further debug and find a permanent fix

* Open discussion

== Upcoming Project Renames ==
(any additions should mention original->new full names and link to the corresponding project-config rename change in Gerrit)

== Previous meetings ==
Previous meetings, with their notes and logs, can be found at http://eavesdrop.openstack.org/meetings/infra/ and earlier at http://eavesdrop.openstack.org/meetings/ci/

Neutron/LBaaS/Deprecation

2019-09-26T13:16:58Z

Frickler: Update mailing list information

= OpenStack neutron-lbaas Deprecation FAQ =

__TOC__

== Why are we deprecating neutron-lbaas? ==

There are many reasons we have been working towards deprecating neutron-lbaas, some are:

* OpenStack load balancing no longer requires deep access into the neutron code base and database. All of the required networking capabilities are now available via stable APIs.
* The neutron stadium has become large, leading to project management scaling issues. As part of the [http://specs.openstack.org/openstack/neutron-specs/specs/newton/neutron-stadium.html neutron stadium evolution] neutron-lbaas was identified as a project that should spin out of neutron and become a top level [https://governance.openstack.org/tc/reference/projects/octavia.html OpenStack project].
* The [http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html load balancing spin out of neutron] was approved during the newton release cycle.
* This change de-couples the load balancing release versioning from the rest of the OpenStack deployment. Since Octavia uses stable APIs when interacting with other OpenStack services, you can run a different version of Octavia in relation to your OpenStack cloud deployment. One operator is running Queens Octavia against a Liberty release based cloud (We highly recommend you do extensive testing when running with mis-matched releases).
* We increase the performance of the load balancing API by removing layers of neutron API code supporting extensions.
* The addition of new API features required patches in up to four different repositories when running under neutron. With the new Octavia project we have reduced this down to two repositories.
* We were limited in some API capabilities by the neutron API extensions framework.
* The neutron-lbaas API code has some fundamental defects in the object locking logic that led to inconsistent state with very high API call rates. Fixing these would essentially require a full re-write of the API code which Octavia already provides.
* As an independent project, we can evolve faster. For example, Octavia supported the [https://governance.openstack.org/tc/goals/pike/python35.html python 3.5] and [https://governance.openstack.org/tc/goals/queens/policy-in-code.html policy-in-code] community goals before neutron.
* People are confused because it has "neutron" in the name.

== What does neutron-lbaas deprecation mean? ==

neutron-lbaas and neutron-lbaas-dashboard will not longer accept new feature enhancements.

This is an indicator that deployments and driver developers will need to start planing for a migration to Octavia.

Both projects will continue to be supported and receive bug fixes for the duration of the deprecation cycle.

The code and projects will not be retired until the end of the deprecation cycle.

For more information on the OpenStack deprecation process see the [https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html follows-standard-deprecation document] and the TC resolution [https://governance.openstack.org/tc/resolutions/20170620-volunteer-support.html#deprecation Definition of Upstream Support].

== When is neutron-lbaas being marked as deprecated? ==

neutron-lbaas and neutron-lbaas-dashboard are marked deprecated as of the Queens OpenStack release cycle.
The neutron client was marked as [https://docs.openstack.org/releasenotes/python-neutronclient/ocata.html deprecated during the Ocata OpenStack release cycle].

== When will the neutron-lbaas deprecation cycle end? ==

At a minimum it will be two release cycles, meaning the first release that the projects could be retired in would be the "T" OpenStack release cycle.

We plan to retire neutron-lbaas and neutron-lbaas-dashboard in September 2019 or the "U" OpenStack release cycle, whichever comes first. This means the code will be be removed and will not be released as part of the "U" OpenStack release.
The September 2019 date lands in the Train release cycle, meaning neutron-lbaas will not be released as part of the Train release. Neutron-lbaas will be retired during the Train release cycle.

== What does retiring neutron-lbaas mean? ==

The infrastructure manual describes the process of [https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project retiring a project].

== What are the replacement projects? ==

* neutron-lbaas is replaced by [https://docs.openstack.org/octavia/latest/ Octavia]
* neutron-lbaas-dashboard is replaced by [https://docs.openstack.org/octavia-dashboard/latest/ octavia-dashboard]
* neutron client (python-neutronclient) is replaced by [https://docs.openstack.org/python-octaviaclient/latest/ python-octaviaclient] for load balancer commands.
* Python bindings for the Octavia v2 API are provided by the [https://docs.openstack.org/python-openstacksdk/latest/ OpenStack SDK].

== Neutron-lbaas vs. LBaaS v2 API vs. Octavia vs. Octavia v2 API ==

=== neutron-lbaas ===
Neutron-lbaas is a neutron extension that extends the neutron API to provide load balancing capabilities. It implements the LBaaS v2 API. Neutron-lbaas runs inside the neutron API process and must be installed with the neutron API.

=== LBaaS v2 API ===
LBaaS v2 API is the second version of the Load Balancing as a Service (LBaaS) API. LBaaS v1 is End of Life (EoL) as of the Mitaka OpenStack release cycle and has been retired.

Both neutron-lbaas and octavia implement the LBaaS v2 API, however octavia is a superset of the LBaaS v2 API meaning it includes additional features.

=== Octavia ===
Octavia is an official OpenStack service project providing load balancing capabilities for OpenStack. It includes a standalone API endpoint advertised in Keystone as service-type "load-balancer". Octavia includes a reference load balancing driver, octavia, that provides load balancing by using "amphora" which are currently implemented as service VMs. Octavia implements the LBaaS v2 API, like neutron-lbaas, but also provides additional features. See the [https://developer.openstack.org/api-ref/load-balancer/v2/index.html Octavia v2 API reference].

=== Octavia v2 API ===
The Octavia v2 API is a fully backward compatible superset of the LBaaS v2 API. It includes all of the capabilities of the LBaaS v2 API with additional features such as: listener statistics, batch member updates, load balancer failover, status fields for all objects, cascade delete, and many more.

See the [https://developer.openstack.org/api-ref/load-balancer/v2/index.html Octavia v2 API reference] for more information on the Octavia v2 API.

== How do I migrate to Octavia? ==

If your neutron-lbaas load balancers are using the Octavia driver all you need to do is upgrade Octavia to the Pike release of OpenStack or newer and enable the v2 API. Your load balancer details are already in the Octavia database and using the Octavia driver infrastructure. This means that your applications can simply update the endpoint being used for load balancing from the neutron API endpoint to the Octavia API endpoint. The one caveat to this is that if neutron-lbaas created the VIP neutron port(s), Octavia will not delete it when the load balancer is deleted via the Octavia API. There will be a port migration tool provided to transfer ownership of the neutron port(s) from neutron-lbaas to Octavia.

A migration guide will be developed and made available in the [https://docs.openstack.org/octavia/latest/admin/index.html administration documentation].

The lbaasv2-proxy neutron service plugin is available to allow users to continue to access load balancing via the neutron API during your migration.
Please see the section titled "What migration tools are available?" for more information.

== What migration tools are available? ==

The lbaasv2-proxy neutron service plugin is available to allow users to continue to access load balancing via the neutron API during your migration.
This proxy will forward all load balancing requests received via the neutron API to the Octavia API. This should be used as a temporary migration tool as it is included in the neutron-lbaas code base and deprecation. You can enable it by editing your neutron.conf file, [DEFAULT] section and change the "service_plugins" setting from "lbaasv2" to "lbaasv2-proxy".

The database schema for Octavia is very similar to the neutron-lbaas schema in the neutron database. A database migration tool will be made available to move existing load balancers from the neutron-lbaas database into the Octavia database.

This tool is now available here: https://git.openstack.org/cgit/openstack/neutron-lbaas/tree/tools/nlbaas2octavia
This tool supports live migration of running load balancers if the provider driver supports it, such as the Octavia amphora driver.

== How do I install Octavia? ==

You may already have Octavia installed as part of your neutron-lbaas installation. Octavia has been the reference driver since the OpenStack Liiberty release. If this is the case you only need to upgrade to the Pike release of OpenStack or newer and enable the v2 API.

There are a number of ways to install Octavia:
* By hand using the [https://docs.openstack.org/octavia/latest/install/index.html installation documentation].
* Using [https://docs.openstack.org/openstack-ansible/latest/ OpenStack Ansible]
* Using [https://docs.openstack.org/tripleo-docs/latest/ OpenStack Tripleo]
* Using [https://docs.openstack.org/puppet-openstack-guide/latest/ Puppet]
* Using vendor distributions that include Octavia.

== Does Octavia support RBAC? ==
Yes, Octavia has Role Based Access Control (RBAC) on the Octavia v2 API. Please see the [https://docs.openstack.org/octavia/latest/configuration/policy.html Octavia Policies] page in the Octavia documentation.

== Does Octavia support quotas? ==
Yes, Octavia has quota support in the Octavia v2 API. Please see the [https://developer.openstack.org/api-ref/load-balancer/v2/index.html#quotas Quota] section in the Octavia v2 API documentation.

If you are using the neutron-lbaas proxy plugin to pass load balancing requests from the neutron API to the Octavia API, both the neutron quota settings and those configured in Octavia will be enforced. You may want to consider setting the neutron load balancing quotas to unlimited when you enable the neutron-lbaas proxy plugin.

== Does Octavia have a Horizon dashboard (Web GUI)? ==
Yes, the [https://docs.openstack.org/octavia-dashboard/latest/ Octavia dashboard] provides a greatly enhanced load balancing horizon dashboard.

== What is the Command Line Interface (CLI) for Octavia? ==
The [https://docs.openstack.org/python-octaviaclient/latest/ python-octaviaclient] project provides an [https://docs.openstack.org/python-openstackclient/latest/ OpenStack Client (OSC)] plugin.

The OpenStack Client is a unified CLI client for all OpenStack projects. It replaces the, deprecated since Ocata, neutron CLI client.

A [https://docs.openstack.org/python-octaviaclient/latest/reference/decoder.html command mapping table] is available as part of the python-octaviaclient documentation.

[https://docs.openstack.org/python-octaviaclient/latest/cli/index.html Detailed command documentation] is available as part of the [https://docs.openstack.org/python-octaviaclient/latest/ python-octaviaclient] documentation.

Updated user [https://docs.openstack.org/octavia/latest/user/index.html Cookbooks] are also available as part of the Octavia user documentation set.

== What about neutron-lbaas provider drivers? ==

In cooperation with our driver authors, a [https://docs.openstack.org/octavia/latest/contributor/specs/version1.1/enable-provider-driver.html provider driver specification] has merged for the Octavia API. This specification brings significant enhancements to the driver capabilities available to operators through the [https://docs.openstack.org/octavia/latest/contributor/specs/version1.0/flavors.html flavors mechanism].

This change will require some modification to the drivers to support the new provider driver specification. This may require more effort if the prior driver was using non-stable internal neutron interfaces.

Over the course of the neutron-lbaas deprecation cycle we expect provider drivers to become available for the Octavia API. These drivers will be listed in the [https://docs.openstack.org/octavia/latest/admin/index.html Octavia Administration documentation].

Using the database migration tool descibed above, you should be able to migrate existing load balancers that are using a provider driver without incurring data plane downtime to the load balancer. However, this capability may vary depending on the driver implementation.

Aside from the Octavia reference driver used for testing, provider drivers will no longer exist inside the Octavia project repository. We typically do not have access to the required hardware or software to properly test and maintain these drivers as part of the main Octavia repository. Moving these drivers into their own repository will allow independent development cycles for the drivers. Provider drivers will use Stevedore and packaging to allow easy installation of the driver into the Octavia API.

For more information about provider drivers see the [https://docs.openstack.org/octavia/latest/contributor/specs/version1.1/enable-provider-driver.html provider driver specification].

== Can I run Octavia at the same time as neutron-lbaas? ==

Yes you can. However note that only load balancers using the Octavia reference driver will be visible in both systems and actions against the Octavia API may not be fully reflected in neutron-lbaas.

The lbaasv2-proxy plugin can also be used to allow load balancers in Octavia to be visible via the neutron API.

The OpenStack Client plugin for load balancing only supports the Octavia v2 API. To interact with neutron-lbaas from the command line you must continue to use the "neutron" client.

== What about the Octavia v1 API? ==

The Octavia v1 API was intended for use by the neutron-lbaas Octavia driver. It should not be exposed to end users as it does not implement access controls. For Octavia API processes hosting the Octavia v2 API for users, the v1 API should be disabled via the octavia.conf file setting "[api_settings] api_v1_enabled = False". You will also see log messages warning you if you have both API versions enabled on the same API process. If you require both APIs available in your cloud, we recommend running a separate v1 API process that is access controlled for your neutron-lbaas octavia drivers to use. This can be accomplished by either running it on an alternate, security group controlled, port or on alternate controller hosts/containers.

The Octavia v1 API will follow the neutron-lbaas deprecation cycle and be removed when neutron-lbaas is removed.

The Octavia v1 API is a proprietary API and is not compatible with the LBaaS v2 API specification or any other LBaaS API specification.

== Where do I get more information? ==
* The [https://docs.openstack.org/octavia/latest/ Octavia documentation].
* The best way to reach the LBaaS team is via IRC on the Freenode IRC network channel #openstack-lbaas
* Weekly Meeting: 20:00 UTC on Wednesdays in #openstack-lbaas on the Freenode IRC network.
* Sending email to the OpenStack mailing list: openstack-discuss [at] lists [dot] openstack [dot] org. Please prefix the subject with '[Octavia]'

Chef/GettingStarted

2019-09-02T11:12:09Z

Frickler: Update links

This page serves as a getting started guide for community members interested in introducing themselves to the OpenStack Chef cookbooks and community.

==Communication==

* The OpenStack + Chef community leverages the main [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss openstack-discuss mailing list] with the tag of [chef] in the subject line.
* There is an [https://webchat.freenode.net/?channels=openstack-chef #openstack-chef channel] on freenode.net. Come hang out with us and collaborate there.
* We have a maintainers list located [https://opendev.org/openstack/openstack-chef-specs/src/branch/master/MAINTAINERS.md here]. Please don't hesitate to reach out.

==Bug Tracking==

We track bugs and feature requests using a single Launchpad project called [https://launchpad.net/openstack-chef OpenStack + Chef]. You can [https://bugs.launchpad.net/openstack-chef see the list of open bugs] or [https://bugs.launchpad.net/openstack-chef/+filebug file a new bug].

==Blueprints / Feature Tracking==

For major feature enhancements and planning you can use Launchpad's Blueprints system for the OpenStack + Chef project on Launchpad. You can [https://blueprints.launchpad.net/openstack-chef/+addspec create a new blueprint] that may be targeted to a milestone and tracked appropriately.
The process for blueprint content reviews is documented here: https://opendev.org/openstack/openstack-chef-specs

==How to Contribute==
We have broken this off into another page [https://wiki.openstack.org/wiki/Chef/Contributing here].

Python3

2019-03-07T14:17:17Z

Frickler: Update link for oslo_serialization.jsonutils.dump_as_bytes(obj)

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

== IRC: #openstack-dev ==

Join the #openstack-dev IRC channel on the Freenode network to discuss Python 3.

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

== Python 2: Python 2.6 support dropped, Python 2.7 only ==

OpenStack Liberty targets Python 2.7 and 3.4.

Python 2.6 support is being dropped in OpenStack since OpenStack Juno for servers. Python 2.6 support is currently kept in Oslo libraries and clients. See [https://etherpad.openstack.org/p/juno-cross-project-future-of-python juno-cross-project-future-of-python] etherpad.

Python 3.3 support is being dropped since OpenStack Liberty.

Python 2.6 is slowly being dropped in the whole OpenStack project, ex: [https://review.openstack.org/#/c/201295/ Remove p26 job from DIB].

Python 2.6 support will be removed in Oslo and Clients clients for OpenStack Mitaka: [http://markmail.org/message/oe6wewgvbvvyts73 Oslo libraries dropping python 2.6 compatability].

== 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. As we are targeting Python 3.4 and up, there is no need to avoid u'unicode' syntax. Do not use six.u('unicode').

=== Before you begin ===

If you're doing development with Ubuntu/Debian (and not using devstack with the USE_PYTHON flag set), then you'll need the following packages installed to run the py34 tox unit test targets in the projects:

sudo apt-get install python3.4 python3.4-dev

=== sixer tool ===

The [https://pypi.python.org/pypi/sixer sixer] tool helps to replace most basic patterns to add Python 3 compatibility and it respects OpenStack coding style.

=== Common patterns ===

* Replace "for key in dict.iterkeys()" with "for key in dict"
* Replace dict.iteritems() with dict.items()
* Replace dict.itervalues() with dict.values()

Note: Replacing dict.iteritems()/.itervalues() with six.iteritems(dict)/six.itervalues(dict) was preferred in the past, but there was [http://lists.openstack.org/pipermail/openstack-dev/2015-June/066391.html a discussion suggesting to avoid six for this]. The overhead of creating a temporary list on Python 2 is negligible.

* Replace iterator.next() with next(iterator)
* Replace basestring with six.string_types
* Replace unicode with six.text_type
* Replace (str, unicode) with six.string_types
* Replace (int, long) with six.integer_types
* Replace func.func_name with func.__name__
* Replace exceptions.OSError with OSError and remove "import exceptions"
* map() and filter() if a list is needed on Python 3:
** Replace map(func, data) with [func(item) for item in data]
** Replace filter(lambda obj: test(obj), data) with [obj for obj in data if test(obj)]
** Note: Usually, tests fail because map() or filter() objects have no length

=== Serialization: base64, JSON, etc. ===

* [with oslo.serialization 1.10 or newer] Get the [http://docs.openstack.org/developer/oslo.serialization/api.html#module-oslo_serialization.base64 base64 module] from oslo_serialization (from oslo_serialization import base64) to get functions:
** oslo_serialization.base64.decode_as_bytes(encoded)
** oslo_serialization.base64.decode_as_text(encoded, encoding='utf-8')
** oslo_serialization.base64.encode_as_bytes(s, encoding='utf-8')
** oslo_serialization.base64.encode_as_text(s, encoding='utf-8')
* Replace text.encode('base64') and base64.b64encode(text) with:
** base64.b64encode(text): only accept bytes and returns bytes,
** or: oslo_serialization.base64.encode_as_bytes(text): accept bytes or Unicode and returns bytes
** or: oslo_serialization.base64.encode_as_text(text): accept bytes and Unicode and returns Unicode
** '''Warning:''' base64.encodestring(raw) adds a newline ("\n"), whereas encode_as_bytes() and encode_as_text() don't.
* Replace raw.decode('base64') with:
** base64.b64decode(raw): return bytes
** oslo_serialization.base64.decode_as_bytes(encoded): accept bytes and Unicode, returns bytes
** oslo_serialization.base64.decode_as_text(encoded): accept bytes and Unicode, returns Unicode

Hexadecimal:

* Replace raw.decode('hex') with binascii.unhexlify(raw)
* Replace bytes.encode('hex') with binascii.hexlify(bytes)

JSON:

* [with oslo.serialization 1.10 or newer] Replace json.dumps(obj) with [https://docs.openstack.org/oslo.serialization/latest/reference/index.html#oslo_serialization.jsonutils.dump_as_bytes oslo_serialization.jsonutils.dump_as_bytes(obj)]
* Replace json.loads(obj) with oslo_serialization.jsonutils.loads(obj): it accepts bytes and Unicode, bytes is decoded from UTF-8. It avoids "if isinstance(obj, bytes): obj = obj.decode('utf-8')" which may require a second temporary variable.

=== contextlib.nested ===

To replaced contextlib.nested is to use [https://docs.python.org/3/library/contextlib.html#contextlib.ExitStack contextlib.ExitStack]. It's available on Python 2 using [https://contextlib2.readthedocs.org/en/latest/#contextlib2.ExitStack contextlib2.ExitStack]. For contextlib.nested, nova/test.py defines:

if six.PY3:
@contextlib.contextmanager
def nested(*contexts):
with contextlib.ExitStack() as stack:
yield [stack.enter_context(c) for c in contexts]
else:
nested = contextlib.nested

Another option to replaced contextlib.nested is to use the @mock.patch decorator. Example with nested function:

def test_thing(self):
@mock.patch(...)
@mock.patch(...)
@mock.patch(...)
def do_test(...):
...

do_test()

More options:
* Mock provides a context that patches multiple things so that no nesting is needed: [https://docs.python.org/dev/library/unittest.mock.html#patch-multiple mock.patch.multiple()]
* oslotest provides fixtures for mock, so you don't need a context: [http://docs.openstack.org/developer/oslotest/api.html#module-oslotest.mockpatch oslotest.mockpatch].

=== oslo_utils.encodeutils.to_utf8 ===

oslo.utils 3.5 has an oslo_utils.encodeutils.to_utf8() function to encode Unicode to UTF-8 and return bytes unchanged.

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

The <code>exception_to_unicode(exc)</code> function of oslo_utils.encodeutils is the recommanded way to format an exception to Unicode. This function works on Python 2 and Python 3 and it should avoid mojibake is most cases.

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/" and then run "tox -e py34" before running "tox -e py27". You only have to do this once. The problem only occurs with "tox -e py34" when .testrepository/ was created by Python 2.

== Python 3 Status of OpenStack projects ==

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

See [http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml programs.yaml] for the list of Common Libraries.

{|class="wikitable sortable"
|-
! Project !! Python 3 compatibility !! Comment
|-
| [https://pypi.python.org/pypi/automaton automaton] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/castellan castellan] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/cliff cliff] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/debtcollector debtcollector] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/futurist futurist] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslo.cache oslo.cache] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslo.concurrency oslo.concurrency] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslo.config oslo.config] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslo.context oslo.context] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslo.db oslo.db] || style="background-color: lightgreen;" | Yes ||
PyMySQL driver is now used by default for MySQL. setup.cfg contains the Python 3 classifier.
|-
| [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 ||
oslo.messaging is now fully compatible with Python 3. The old (and now removed) Qpid transport was not compatible, the AMQP driver was ported recently.
|-
| [https://pypi.python.org/pypi/oslo.middleware oslo.middleware] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslo.policy oslo.policy] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslo.privsep oslo.privsep] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/oslo.reports oslo.reports] || 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/oslo.service oslo.service] || style="background-color: orange;" | Partial ||
WSGI module SSL support is broken under Python 3. We want projects to support deployment without relying on that code, but not all do (see glance and designate below).
|-
| [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: lightgreen;" | Yes || Supports Python 3 since oslo.vmware 0.13.0
|-
| [https://pypi.python.org/pypi/oslo.utils oslo.utils] || style="background-color: lightgreen;" | Yes ||
|-
| pylockfile || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/stevedore stevedore] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/taskflow taskflow] || style="background-color: lightgreen;" | Yes ||
|-
| [https://pypi.python.org/pypi/tooz tooz] || style="background-color: lightgreen;" | Yes ||
|}

=== Development tools ===

{|class="wikitable sortable"
|-
! Project !! Python 3 compatibility !! Comment
|-
| [https://pypi.python.org/pypi/cookiecutter cookiecutter] || style="background-color: lightgreen;" | yes ||
|-
| [https://pypi.python.org/pypi/hacking hacking] || style="background-color: lightgreen;" | yes ||
|-
| [https://pypi.python.org/pypi/pbr pbr] || style="background-color: lightgreen;" | yes ||
|-
| stackforge/python-jenkins || style="background-color: lightgreen;" | yes || py33 gate is voting
|-
| openstack-infra/jenkins-job-builder || style="background-color: orange;" | partial || https://review.openstack.org/172238
|}

=== OpenStack clients ===

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

| [https://pypi.python.org/pypi/keystonemiddleware keystonemiddleware] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | Voting || style="background-color: lightgreen;" | On PyPI || python-memcached || keystonemiddleware 1.6.1 supports Python 3.
|-

| [https://pypi.python.org/pypi/python-barbicanclient python-barbicanclient] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | Voting || style="background-color:lightgreen;" | 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-fuelclient python-fuelclient] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | On PyPI || ||
|-

| [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-manilaclient python-manilaclient] || 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;" | On PyPI || ||
|-

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

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

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

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

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

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

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

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

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

| [https://pypi.python.org/pypi/python-swiftclient python-swiftclient] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | Voting || style="background-color: lightgreen;" | 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 || ||
|-

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

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

|}

=== OpenStack Libraries ===

{|class="wikitable sortable"
|-
! Project !! Python 3 compatibility !! CI tests running? !! Python 3 classifiers ? !! Comment
|-
| blazar-nova || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-
| ceilometermiddleware || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| [https://pypi.python.org/pypi/django_openstack_auth django_openstack_auth] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
django_openstack_auth 2.0 is fully compatible with Python 3.
|-

| [https://pypi.python.org/pypi/glance_store glance_store] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes || glance_store 0.7.0 added the Python 3 support.
|-

| heat-translator || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| ironic-lib || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| keystoneauth || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| keystonemiddleware || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| ldappool || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| monasca-statsd || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| mistral-lib || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| neutron-lib || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| octavia-lib || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| [https://pypi.python.org/pypi/os-brick os-brick] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes || os-brick 0.3.2 added Python 3 support.

|-

| os-client-config || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| os-traits || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| os-vif || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| os-win || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| osc-lib || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| osc-placement || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| pycadf || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| shade || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

| [https://pypi.python.org/pypi/sqlalchemy-migrate sqlalchemy-migrate] || style="background-color:lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color:lightgreen;" | Yes ||
|-

| sushy || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

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

| tosca-parser || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | Yes ||
|-

|}

=== Dependencies: Environment markers ===

Example to not install the "futures" dependency on Python 3.3 and newer:

<pre>
futures; python_version < '3.2'
</pre>

=== OpenStack applications (tc:approved-release) ===

OpenStack applications [https://governance.openstack.org/tc/reference/tags/tc_approved-release.html#tag-tc-approved-release approved by the OpenStack Technical Committee].

{| class="wikitable sortable"
|-
! style="width: 10%;" | Project !! style="width: 10%;" | Unit tests pass on Python 3 !! style="width: 10%;" | py35 gate !! style="width: 20%;" | functional tests !! Comments
|-

| [https://pypi.python.org/pypi/ceilometer ceilometer] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
|-

| [https://pypi.python.org/pypi/cinder cinder] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | integrated-gate-py35 ||
[https://blueprints.launchpad.net/cinder/+spec/cinder-python3 cinder-python3] blueprint (written by Victor Stinner) has been accepted for Liberty. Patches: [https://review.openstack.org/#/q/project:openstack/cinder+topic:bp/cinder-python3,n,z bp/cinder-python3 topic]. Note: Commit message must use "Partial-Implements: blueprint cinder-python3" to be linked to the blueprint. Kendall Nelson, Ivan Kolodyazhny (core) and Eric Harney (core) prefer this syntax: see [https://review.openstack.org/#/c/229991/2//COMMIT_MSG COMMIT_MSG].
|-

| designate || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | designate-bind9-py36 designate-bind9-py35 || ! style="background-color: orange;" | Relies on oslo.service WSGI code that does not work under Python 3 with SSL. Functional tempest tests are ran on both of these jobs. [http://lists.openstack.org/pipermail/openstack-dev/2018-May/130277.html]
|-

| [https://pypi.python.org/pypi/glance glance] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | integrated-gate-py35 || ! style="background-color: orange;" | Relies on oslo.service WSGI code that does not work under Python 3. [http://lists.openstack.org/pipermail/openstack-dev/2018-May/130277.html]
Victor Stinner is working on porting Glance to Python3. Patches: [https://review.openstack.org/#/q/status:open+project:openstack/glance+branch:master+topic:py3,n,z Patches for glance (topic: py3)].
|-

| [https://pypi.python.org/pypi/heat heat] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | heat-functional-convg-mysql-lbaasv2-py35 ||
Sirushti Murugesan wrote and implemented the spec [http://specs.openstack.org/openstack/heat-specs/specs/liberty/heat-python34-support.html Python34 Support] (which was accepted for Liberty). Mitaka version will fully support Python 3. Great job Sirushti Murugesan who did almost all the work!
|-

| [https://pypi.python.org/pypi/horizon horizon] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | horizon-openstack-tox-python3-django111,horizon-integration-tests, horizon-dsvm-tempest-plugin ||
George Peristerakis wrote [https://blueprints.launchpad.net/horizon/+spec/porting-python3 Make Horizon python3.4 compatible] in May 2015, the blueprint was approved. Patches: [https://review.openstack.org/#/q/topic:bp/porting-python3+project:openstack/horizon,n,z bp/porting-python3 topic].
|-

| [https://pypi.python.org/pypi/ironic ironic] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | ironic-tempest-dsvm-ipa-partition-pxe_ipmitool-tinyipa-python3 ||
[http://lists.openstack.org/pipermail/openstack-dev/2015-May/064049.html Python 3.4 unit tests are now being run for openstack/ironic. The unit tests are a voting job.]
Thanks to Victor Sergeyev for all of his work to update the Ironic code to make it pass the unit tests using Python 3.4: [https://review.openstack.org/#/c/156192/ Run tests in py34 environment]
|-

| [https://pypi.python.org/pypi/keystone keystone] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | integrated-gate-py35 ||
The move to pyldap and new ldappool were major hurdles solved in Newton. Great work by the Keystone team to get the last things through the gate in Newton.
|-

| [https://pypi.python.org/pypi/neutron neutron] || style="background-color:lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | integrated-gate-py35 ||
[https://review.openstack.org/#/c/172962/ Porting to Python 3] spec (by Cyril Roelandt) accepted for Liberty, port in progress. [https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/neutron-python3,n,z Patches of the blueprint neutron-python3]
|-

| neutron-lbaas || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | neutron-lbaasv2-dsvm-py3x-api and neutron-lbaasv2-dsvm-py3x-api-namespace ||
Patches: [https://review.openstack.org/#/q/topic:bp/neutron-python3 topic:bp/neutron-python3].
|-

| neutron-fwaas || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: orange;" | neutron-fwaas-networking-midonet-cross-py35 (non-voting) ||
|-

| neutron-vpnaas || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
|-

| [https://pypi.python.org/pypi/nova nova] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | integrated-gate-py35 ||
Status at 2019-01-24: Unit tests all running and voting under Python 3 via the use of the mox3 package. There are only 3 unit test files left that are using mox3 (nova/tests/unit/cells/test_cells_messaging.py, nova/tests/unit/network/test_neutronv2.py, nova/tests/unit/network/test_manager.py).

We advised contributors not to spend time replacing mox in files testing cells v1 and nova-network (test_cells_messaging.py and test_manager.py), as both are slated for removal as soon as we're able. Progress is being tracked at: https://blueprints.launchpad.net/nova/+spec/mox-removal-stein
|-

| [https://pypi.python.org//pypi/sahara sahara] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: orange;" | sahara-tests-scenario-py3 (experimental) || Status at 2018-02-23: the job fails during devstack deployment, because swift does not start. The list of its dependencies is minimal and components like keystone are optional. This was partially addressed with an extra dependency: https://review.openstack.org/#/c/544121/ but this requires a) support in devstack (tentative support in https://review.openstack.org/#/c/544383/) b) at least another extra, or a more generic way of doing this; even with an additional extra explicitly required in devstack, the extras would be installed from pip breaking the test of depending patches.
We are facing an issue with pickle library and python 3, once that gets fixed we can try to make the python 3 gate voting.
|-

| [https://pypi.python.org/pypi/swift swift] || style="background-color: red;" | blocked || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
Status at 2016-06-22: 3/4,498 unit tests (0%), TODO: 4,495 tests

Update (2016-06-27): [http://lists.openstack.org/pipermail/openstack-dev/2016-June/097102.html master branch is currently in a soft-freeze in order to get encryption middleware merged]

Python 3 bugs: https://bugs.launchpad.net/swift/+bug/1614289

[http://lists.openstack.org/pipermail/openstack-dev/2015-October/078058.html Plan to add Python 3 support to Swift]. Patches: [https://review.openstack.org/#/q/project:openstack/swift+branch:master+topic:py3,n,z Patches with the topic py3]

Python 3 unit tests require liberasurecode >= 1.0.9 and PyEClib >= 1.0.9. To install liberasurecode (in /usr):

git clone https://bitbucket.org/tsg-/liberasurecode/
cd liberasurecode
/autogen.sh && /configure --prefix=/usr && make && sudo make install

liberasurecode >= 1.0.9 is available in Ubuntu Precise, Ubuntu Trusty, Fedora 22, Fedora 23 and CentoOS 7.

Update 2018-02-22: A list of current blockers: https://gist.github.com/tipabu/833b03a865dba96e9fa2230b82f5d075

Update 2018-03-06: Current list of blockers with progress notes: https://etherpad.openstack.org/p/Swift_py3

|-

| [https://pypi.python.org/pypi/trove trove] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | trove-devstack-base ||
Status at 2019-01-06:
Unit tests - 1708 tests, 1707 passed, 1 skipped.

Integration tests are based on trove-devstack-base job.

Status at 2016-07-25: 1,155 / 2,014 (run_tests.py: 398; testr: 1,521; generate_examples: 95) unit tests (57%), TODO: 859 tests

Status at 2016-06-22: 839 (testtools) / 1,992 (run_tests.py: 398; testr: 1,499; generate_examples: 95) unit tests (42%), TODO: 1,153 tests

Status at 2018-02-22: It appears that only one test is in the blacklist now: guestagent.test_operating_system

run_tests.py (proboscis) failures: https://review.openstack.org/#/c/346905/1

Victor Stinner proposed the [https://blueprints.launchpad.net/trove/+spec/trove-python3 trove-python3 blueprint] for Mitaka.

From Victor (3/17/2016): "I propose to discuss Python 3 before the summit. For example, prepare a concrete plan to port Trove to Python 3, list technical issues like MySQL-Python, etc."

Patches: [https://review.openstack.org/#/q/topic:bp/trove-python3,n,z search for the bp/trove-python3 topic].
|-

|}

=== Other OpenStack Applications and Projects ===

List of all OpenStack projects: [http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml projects.yaml].

{| class="wikitable sortable"
|-
! style="width: 10%;" | Project !! style="width: 10%;" | Unit tests pass on Python 3 !! style="width: 10%;" | py35 gate || style="width: 20%;" | functional tests !! Comments
|-

| adjutant || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: orange;" | Partial* || (*) Adjutant's unit tests include a suite of API tests against Adjutant APIs using DRF's internal test classes. While not true functional tests, they do stand up an internal web server and process real workloads from Adjutant's perspective, with mocking for external APIs and services (Keystone, Nova, Neutron, etc) in the places we touch their clients. This tests 92% of the code, so in all likelihood covers most py3 vs py2 issues. Tempest tests are also planned for later.
|-

| [https://pypi.python.org/pypi/aodh aodh] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
|-

| [https://pypi.python.org/pypi/barbican barbican] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | unspecified ||
Blueprint [https://blueprints.launchpad.net/barbican/+spec/barbican-py3 barbican-py3].
|-

| blazar || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | blazar-devstack-dsvm-py35 ||
|-

| cloudkitty || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | cloudkitty-tempest-full-python3 ||
|-

| [https://pypi.python.org/pypi/congress congress] || style="background-color: lightgreen;" | Yes || style="background-color: orange;" | voting* || style="background-color: lightgreen;" | congress-devstack-py35-api-mysql ||
(*)py35 support required tiny modification to antlr3 package, creating debian packaging difficulty

Random Stacker wrote a [https://blueprints.launchpad.net/congress/+spec/support-python3 support-python3 blueprint]. Patches: [https://review.openstack.org/#/q/project:openstack/congress+branch:master+topic:bp/support-python3,n,z search for the topic bp/support-python3].
|-

| cyborg || style="background-color: red;" | No job || style="background-color: red;" | No job || style="background-color: red;" | no job ||
|-

| [https://pypi.python.org/pypi/designate designate] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: orange;" | designate-devstack-pdns4-py35 (check queue only) ||
Pradeep Kumar Singh proposed the [https://blueprints.launchpad.net/designate/+spec/designate-py3 blueprint designate-py3] which was accepted for Liberty. Patches: [https://review.openstack.org/#/q/status:open+project:openstack/designate+branch:master+topic:bp/designate-py3,n,z topic:bp/designate-py3].
|-

| [https://pypi.python.org/pypi/ec2-api ec2-api] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | openstack-tox-py35 ||
|-

| [https://pypi.python.org/pypi/freezer freezer] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
|-

| karbor || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
|-

| [https://pypi.python.org/pypi/kuryr-kubernetes kuryr] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | openstack-tox-py35 ||
|-

| [https://pypi.python.org/pypi/magnum magnum] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | (voting: magnum-functional-api) AND (non-voting: magnum-functional-k8s AND magnum-functional-swarm-mode) ||
|-

| [https://github.com/openstack/manila manila] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | manila-tempest-minimal-dsvm-dummy || ||
|-

| [https://github.com/openstack/manila-ui manila-ui] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | horizon-openstack-tox-python3-django111 ||
|-

| masakari || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | openstack-tox-py35 ||
|-

| [https://pypi.python.org/pypi/mistral mistral] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
|-

| monasca-agent || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | monasca-tempest-python3-influxdb || https://storyboard.openstack.org/#!/story/2000975 ||
|-

| monasca-api || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | monasca-tempest-python3-influxdb || https://storyboard.openstack.org/#!/story/2000975 ||
|-

| monasca-log-api || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | monascalog-python3-tempest ||
|-

| monasca-ui || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job || https://storyboard.openstack.org/#!/story/2000975 ||
|-

| [https://pypi.python.org/pypi/murano murano] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
Blueprint: [https://blueprints.launchpad.net/murano/+spec/murano-python-3-support murano-python-3-support].
|-

| murano-agent || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
Blueprint: [https://blueprints.launchpad.net/murano/+spec/murano-python-3-support murano-python-3-support].
|-

| [https://wiki.openstack.org/wiki/Octavia octavia] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | octavia-tox-functional-py35 ||
|-

| panko || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | panko-tox-py35-mysql and panko-tox-py35-postgresql ||
|-

| qinling || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
|-

| [https://pypi.python.org/pypi/rally rally] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | rally-tox-functional-py3 and rally-tox-self ||
A big thank to Andrey Kurilin for a lot of work in this direction
|-

| [https://wiki.openstack.org/wiki/Searchlight searchlight] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | openstack-tox-py36 ||
|-

| [https://wiki.openstack.org/wiki/Senlin senlin] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: orange;" | senlin-dsvm-tempest-py35-api, senlin-dsvm-tempest-py35-functional, senlin-dsvm-tempest-py35-integration (check only, non-voting) ||
|-

| [https://wiki.openstack.org/wiki/Solum solum] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: orange;" | solum-devstack-py35 (check only) ||
Victor Stinner proposed the [https://blueprints.launchpad.net/solum/+spec/solum-python3 blueprint solum-python3] which was approved. Patches: [https://review.openstack.org/#/q/status:open+topic:bp/solum-python3,n,z search for bp/solum-python3 topic] (open reviews).
|-

| storlets || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job (likely blocked on swift) ||
|-

| tacker || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: orange;" | tacker-functional-devstack-python3 (check only, non-voting) ||
|-

| tricircle || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
|-

| vitrage || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | vitrage-dsvm-api-py35 and vitrage-dsvm-datasources-py35 ||
|-

| [https://wiki.openstack.org/wiki/Watcher watcher] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
|-

| [https://wiki.openstack.org/wiki/Zaqar zaqar] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
|-

| [https://github.com/openstack/zun zun] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | zun-tempest-py35-docker-sql ||
|-

| networking-l2gw || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
|-

| [https://pypi.org/project/vmware-nsx vmware-nsx] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | All 3rd part CI jobs are running python 3 ||
|-

| [https://pypi.org/project/vmware-nsxlib vmware-nsxlib] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | tempest-api-vmware-nsxv3 is running python 3.5 and is voting ||
|-

|-
|}

Unsorted projects:
* [https://wiki.openstack.org/wiki/App-Catalog App Catalog]
* Chef OpenStack (Ruby)
* [https://github.com/openstack/kolla/ Kolla]: ~2100 lines of Python, but not "tox -e py27" target
* OpenStack Ansible (Python): Ansible playbooks and roles for deployment
* Puppet OpenStack (Ruby)
* TripleO

=== Enable Python 3 in DevStack ===

* Fedora::

sudo dnf install python3-devel
sudo python3 -m pip install python-memcached # needed by keystonemiddleware

* localrc: add the following line

USE_PYTHON3=True

See [https://review.openstack.org/#/c/414176/ Switch to python 3.5].

=== Functional and Integration Tests ===

Etherpad: https://etherpad.openstack.org/p/support-python3.5-functional-tests

Doug Hellmann wrote a cross-project specification to run integration tests on Python 3: [http://specs.openstack.org/openstack/openstack-specs/specs/enable-python-3-int-func-tests.html Enabling Python 3 for Application Integration Tests] (spec approved for Liberty).

Patch for DevStack: [https://review.openstack.org/#/c/181165/ Enable optional Python 3 support].

Projects wanting to run their existing functional test suite against their services on Python 3 should:-
* Add the Python3.4 trove classifier to the setup.cfg configuration file of the respective service.
* set USE_PYTHON3=True in Devstack's localrc config file before running stack.sh after [https://review.openstack.org/#/c/181165/ the DevStack change] is merged or cherry-pick until then.
* set basepython = python3.5 in tox for the necessary functional/integration tests environment.

Then run tox -e<your functional test suite name>. Example:- tox -efunctional to run the functional the tests of a certain project.

Once the functional test suite is reliably passing against the service in a python 3.5 env, the trove classifiers must be updated along with a new gate job being added to the project.

Sirushti Murugesan's attempt on Heat: https://review.openstack.org/#/c/188033/

=== Python 3.5 ===

* project-config: [https://review.openstack.org/#/c/336272/ Add python35 jobs]
* nova: [https://review.openstack.org/#/c/336432/ Add a py35 environment to tox]
* Neutron issues: https://bugs.launchpad.net/neutron/+bug/1559191
* There is no Jenkins job using Python 3.5 yet
* /usr/bin/python3 is Python 3.5 in Fedora 24, Ubuntu 16.04 LTS (Xenial Xerus) and Debian Stretch (Testing)

=== Python 3.6 status ===

Python 3.6 is scheduled to be the default/only version of Python available in Ubuntu 18.04 LTS (Bionic Beaver) and Debian 10 (Buster).

Known issues:

* eventlet<0.21.0 is broken with Python 3.6, see https://github.com/eventlet/eventlet/issues/371. There is also https://github.com/eventlet/eventlet/issues/401 which is fixed in 0.22.0, so it might seem feasible to upgrade to eventlet-0.22.1 once we can do proper testing.
* Horizon explicitly only claims support for Python 3.5, when running devstack with Python 3.6 one needs to set:
ENABLED_PYTHON3_PACKAGES=horizon

== Status of Python 3 in Linux distributions ==

* ArchLinux already [https://www.archlinux.org/news/python-is-now-python-3 switched to Python 3 by default] in 2011
* Ubuntu wants to remove Python 2 from the default installation for Ubuntu 18.04 LTS: see [https://wiki.ubuntu.com/Python (Python) Plans for 18.04].
* Fedora schedules the switch in Fedora 23 (october 2015): [https://fedoraproject.org/wiki/Changes/Python_3_as_Default Python 3 as the Default Implementation]
** [http://fedora.portingdb.xyz/ Python 3 Porting Database for Fedora] and [http://fedora.portingdb.xyz/history/ history of packages tracked by the Fedora portingdb]
** [https://lwn.net/Articles/690676/ Python 3 in Fedora] (Python 3 in Fedora)
* RHEL: [https://www.softwarecollections.org/en/scls/rhscl/python33/ Python 3.3] and [https://www.softwarecollections.org/en/scls/rhscl/rh-python34/ Python 3.4] are available on RHEL6 and RHEL7 using SCL.
* CentOS: [https://www.softwarecollections.org/en/scls/rhscl/python33/ Python 3.3] and [https://www.softwarecollections.org/en/scls/rhscl/rh-python34/ Python 3.4] are available on CentOS 6 and 7 using SCL (no Red Hat subscription needed, CentOS has its own flavor of SCL)
* In Debian, the plan is to deprecate Python 2 in Stretch (aka: Debian 9, the next Stable Debian after Jessie) and to completely remove Python 2 for the Buster release of Debian (aka: Debian 10, to be released in approximatively 2019).

Check the [https://governance.openstack.org/tc/reference/project-testing-interface.html#linux-distributions Project Testing Interface] for updates about the platforms each release is tested on.

== Status of Python 2 Support Being Dropped in Dependencies ==

* Django 2.0 will not include Python 2 support (23 Jan 2017 we use Django>=1.8,<1.9)
** https://github.com/django/django/pull/7867/files
** https://github.com/django/django/pull/7871/files
* Pylons/Pyramid are also considering dropping Python 2
** https://github.com/Pylons/pyramid/issues/2903
** This is the same team that maintains webob, but it isn't clear if they intend to also drop support there.

[https://governance.openstack.org/tc/resolutions/20180529-python2-deprecation-timeline.html OpenStack plans to start dropping Python 2 support at the start of the U cycle]

== Progress reports, meetings and sprints ==

* Pike PTG: https://etherpad.openstack.org/p/ptg-pike-python35
* Ocata Summit
** https://etherpad.openstack.org/p/ocata-python-3
* openstack-dev: [http://lists.openstack.org/pipermail/openstack-dev/2016-June/097930.html Status of the OpenStack port to Python 3] (Jun 22, 2016). 80 projects/83 (96%) have unit tests passing on Python 3, TODO (3): Nova, Swift and Trove.
* Mitaka Summit
** Cross-project session: Python 3 was proposed, https://etherpad.openstack.org/p/mitaka-cross-project-session-planning
* Liberty Summit
** Cross-project session on enabling app integration testing: https://etherpad.openstack.org/p/liberty-cross-project-python3
* Kilo Summit
** Doug Hellmann: "Moving our applications to Python 3" cross-project session
** Victor Stinner: "Port nova to Python 3", https://etherpad.openstack.org/p/liberty-nova-summit-ideas
* 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)
* Icehouse summit notes: https://etherpad.openstack.org/p/IcehousePypyPy3
* Havana summit notes: https://etherpad.openstack.org/p/havana-python3

== Articles ==

* [http://blogs.rdoproject.org/7894/status-of-python-3-in-openstack-mitaka Status of Python 3 in OpenStack Mitaka] (Victor Stinner, March 2016)
* [http://techs.enovance.com/7807/python-3-status-openstack-liberty Python 3 Status in OpenStack Liberty] (Cyril Roelandt and Victor Stinner, September 2015)
* [http://techs.enovance.com/6722/status-of-the-openstack-port-to-python-3-2 Status of the OpenStack port to Python 3] (Cyril Roelandt, February 2014)
* [http://techs.enovance.com/6521/openstack_python3 Why should OpenStack move to Python 3 right now?] (Victor Stinner, December 2013)

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

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

Meetings/InfraTeamMeeting

2019-02-14T14:51:04Z

Frickler:

Meetings/InfraTeamMeeting

2018-12-17T13:47:36Z

Frickler: Add link to fresh review

= Weekly Project Infrastructure team meeting =

The OpenStack Project Infrastructure Team holds public weekly meetings in <code><nowiki>#openstack-meeting</nowiki></code>, Tuesdays at 1900 UTC. Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend.

Please feel free to add agenda items (and your IRC nick in parenthesis).

== Agenda for next meeting ==

* Announcements
** Holiday season for many is upon us:
*** Last meeting of 2018: December 18
*** First meeting of 2019: January 8

* Actions from last meeting
** Clarkb started OpenDev website content draft: https://review.openstack.org/622624
** ianw and dmsimard still looking for reviews on https://review.openstack.org/#/q/topic:inner-ara-results
** ianw looking for reviews on glean + networkmanager + fedora29 support: https://review.openstack.org/#/q/status:open+topic:fedora29

* Specs approval
** https://review.openstack.org/623033 OpenDev Repo Hosting Rework Spec
** https://review.openstack.org/607377 Storyboard Attachements
** https://review.openstack.org/581214 Anomaly Detection in CI Logs

* Priority Efforts (Standing meeting agenda items. Please expand if you have subtopics.)
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/task-tracker.html A Task Tracker for OpenStack]
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/update-config-management.html Update Config Management]
*** topic:puppet-4 and topic:update-cfg-mgmt
*** Zuul as CD engine
** OpenDev
*** https://review.openstack.org/#/c/624149/1 Stack of changes to add content to hosting of opendev.org

* General topics
** Shared Github admin account (with 2fa) (clarkb 20181218)
*** https://review.openstack.org/#/c/624531/
** Pre holiday bug fixing (clarkb 20181218)
*** https://review.openstack.org/625350 Fix base-server play. Related ansible bug https://github.com/ansible/ansible/issues/49969
*** https://review.openstack.org/625095 Change pypi cache proxy behavior to cache indexes
** Docker failing when mirror contains a path element (frickler/mgoddard 20181218)
*** Breaks our zuul-quick-start job: http://logs.openstack.org/55/624855/3/check/zuul-quick-start/00d956c/job-output.txt.gz#_2018-12-17_12_36_58_996620
*** http://paste.openstack.org/show/737483/
*** Upstream issue doesn't look like it is going to be fixed any time soon: https://github.com/moby/moby/issues/36598
*** kolla-ansible is also suffering from this: http://logs.openstack.org/89/568289/2/check/kolla-ansible-ubuntu-source-ceph/6983d0d/primary/logs/system_logs/docker.txt.gz
*** Proposed workaround: Switch to using the pathless :8082 variant of our mirror unconditionally - https://review.openstack.org/625596

* Open discussion

== Upcoming Project Renames ==
(any additions should mention original->new full names and link to the corresponding project-config rename change in Gerrit)

== Previous meetings ==
Previous meetings, with their notes and logs, can be found at http://eavesdrop.openstack.org/meetings/infra/ and earlier at http://eavesdrop.openstack.org/meetings/ci/

Meetings/InfraTeamMeeting

2018-12-17T13:28:52Z

Frickler:

= Weekly Project Infrastructure team meeting =

The OpenStack Project Infrastructure Team holds public weekly meetings in <code><nowiki>#openstack-meeting</nowiki></code>, Tuesdays at 1900 UTC. Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend.

Please feel free to add agenda items (and your IRC nick in parenthesis).

== Agenda for next meeting ==

* Announcements
** Holiday season for many is upon us:
*** Last meeting of 2018: December 18
*** First meeting of 2019: January 8

* Actions from last meeting
** Clarkb started OpenDev website content draft: https://review.openstack.org/622624
** ianw and dmsimard still looking for reviews on https://review.openstack.org/#/q/topic:inner-ara-results
** ianw looking for reviews on glean + networkmanager + fedora29 support: https://review.openstack.org/#/q/status:open+topic:fedora29

* Specs approval
** https://review.openstack.org/623033 OpenDev Repo Hosting Rework Spec
** https://review.openstack.org/607377 Storyboard Attachements
** https://review.openstack.org/581214 Anomaly Detection in CI Logs

* Priority Efforts (Standing meeting agenda items. Please expand if you have subtopics.)
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/task-tracker.html A Task Tracker for OpenStack]
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/update-config-management.html Update Config Management]
*** topic:puppet-4 and topic:update-cfg-mgmt
*** Zuul as CD engine
** OpenDev
*** https://review.openstack.org/#/c/624149/1 Stack of changes to add content to hosting of opendev.org

* General topics
** Shared Github admin account (with 2fa) (clarkb 20181218)
*** https://review.openstack.org/#/c/624531/
** Pre holiday bug fixing (clarkb 20181218)
*** https://review.openstack.org/625350 Fix base-server play. Related ansible bug https://github.com/ansible/ansible/issues/49969
*** https://review.openstack.org/625095 Change pypi cache proxy behavior to cache indexes
** Docker failing when mirror contains a path element (frickler/mgoddard 20181218)
*** Breaks our zuul-quick-start job: http://logs.openstack.org/55/624855/3/check/zuul-quick-start/00d956c/job-output.txt.gz#_2018-12-17_12_36_58_996620
*** http://paste.openstack.org/show/737483/
*** Upstream issue doesn't look like it is going to be fixed any time soon: https://github.com/moby/moby/issues/36598
*** kolla-ansible is also suffering from this: http://logs.openstack.org/89/568289/2/check/kolla-ansible-ubuntu-source-ceph/6983d0d/primary/logs/system_logs/docker.txt.gz
*** Proposed workaround: Create a dedicated docker mirror vhost so that we can drop the path element from the mirror URI

* Open discussion

== Upcoming Project Renames ==
(any additions should mention original->new full names and link to the corresponding project-config rename change in Gerrit)

== Previous meetings ==
Previous meetings, with their notes and logs, can be found at http://eavesdrop.openstack.org/meetings/infra/ and earlier at http://eavesdrop.openstack.org/meetings/ci/

Meetings/InfraTeamMeeting

2018-12-17T13:28:10Z

Frickler: Add docker mirror issue

= Weekly Project Infrastructure team meeting =

The OpenStack Project Infrastructure Team holds public weekly meetings in <code><nowiki>#openstack-meeting</nowiki></code>, Tuesdays at 1900 UTC. Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend.

Please feel free to add agenda items (and your IRC nick in parenthesis).

== Agenda for next meeting ==

* Announcements
** Holiday season for many is upon us:
*** Last meeting of 2018: December 18
*** First meeting of 2019: January 8

* Actions from last meeting
** Clarkb started OpenDev website content draft: https://review.openstack.org/622624
** ianw and dmsimard still looking for reviews on https://review.openstack.org/#/q/topic:inner-ara-results
** ianw looking for reviews on glean + networkmanager + fedora29 support: https://review.openstack.org/#/q/status:open+topic:fedora29

* Specs approval
** https://review.openstack.org/623033 OpenDev Repo Hosting Rework Spec
** https://review.openstack.org/607377 Storyboard Attachements
** https://review.openstack.org/581214 Anomaly Detection in CI Logs

* Priority Efforts (Standing meeting agenda items. Please expand if you have subtopics.)
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/task-tracker.html A Task Tracker for OpenStack]
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/update-config-management.html Update Config Management]
*** topic:puppet-4 and topic:update-cfg-mgmt
*** Zuul as CD engine
** OpenDev
*** https://review.openstack.org/#/c/624149/1 Stack of changes to add content to hosting of opendev.org

* General topics
** Shared Github admin account (with 2fa) (clarkb 20181218)
*** https://review.openstack.org/#/c/624531/
** Pre holiday bug fixing (clarkb 20181218)
*** https://review.openstack.org/625350 Fix base-server play. Related ansible bug https://github.com/ansible/ansible/issues/49969
*** https://review.openstack.org/625095 Change pypi cache proxy behavior to cache indexes
** Docker failing when mirror contains a path element
*** Breaks our zuul-quick-start job: http://logs.openstack.org/55/624855/3/check/zuul-quick-start/00d956c/job-output.txt.gz#_2018-12-17_12_36_58_996620
*** http://paste.openstack.org/show/737483/
*** Upstream issue doesn't look like it is going to be fixed any time soon: https://github.com/moby/moby/issues/36598
*** kolla-ansible is also suffering from this: http://logs.openstack.org/89/568289/2/check/kolla-ansible-ubuntu-source-ceph/6983d0d/primary/logs/system_logs/docker.txt.gz
*** Proposed workaround: Create a dedicated docker mirror vhost so that we can drop the path element from the mirror URI

* Open discussion

== Upcoming Project Renames ==
(any additions should mention original->new full names and link to the corresponding project-config rename change in Gerrit)

== Previous meetings ==
Previous meetings, with their notes and logs, can be found at http://eavesdrop.openstack.org/meetings/infra/ and earlier at http://eavesdrop.openstack.org/meetings/ci/

Meetings/Designate

2018-10-09T12:02:37Z

Frickler:

= DNSaaS Meetings =

The DNSaaS team holds a biweekly IRC meeting in #openstack-meeting on '''Wednesdays'''. Every four weeks on week 0 of the four week rotation the meeting starts at 1100 UTC and on week 2 of the four week rotation it starts at 1700 UTC.

Meeting logs are available at http://eavesdrop.openstack.org/meetings/designate/

=== Agenda ===

* Announcements (if any)
* Action Items from last meeting
* Specific Items:
** Bug Triage (recurring)
*** https://bugs.launchpad.net/designate/+bugs?search=Search&field.status=New
*** https://bugs.launchpad.net/python-designateclient/+bugs?search=Search&field.status=New
*** https://bugs.launchpad.net/designate-dashboard/+bugs?search=Search&field.status=New
** Stable Backport Triage
*** git log --oneline --since '4 weeks ago'
* Open Discussion
** Rolling upgrade (trungnv)
*** Launchpad Blueprint
**** https://blueprints.launchpad.net/designate/+spec/designate-rolling-upgrade
*** Specs
**** https://review.openstack.org/#/c/451865/

=== Future/Unscheduled Agenda Items ===

Meetings/QATeamMeeting

2018-07-09T13:24:13Z

Frickler:

Meetings/InfraTeamMeeting

2018-04-17T08:37:53Z

Frickler: Add "magic word topic" topic

= Weekly Project Infrastructure team meeting =

The OpenStack Project Infrastructure Team holds public weekly meetings in <code><nowiki>#openstack-meeting</nowiki></code>, Tuesdays at 1900 UTC. Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend.

Please feel free to add agenda items (and your IRC nick in parenthesis).

== Agenda for next meeting ==

* Announcements

* Actions from last meeting

* Specs approval

* Priority Efforts
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/task-tracker.html A Task Tracker for OpenStack]
** We should reevaluate current projects and add a priority effort or two.
*** Gerrit 2.14/2.15 upgrade
*** Control plane operating system upgrades
*** Wiki?
*** Puppet 4/5
*** More Ansible

* General topics
** Future of 3rd-party CI instructions (ianw 2018-04-10)
*** http://eavesdrop.openstack.org/meetings/zuul/2018/zuul.2018-04-09-22.01.log.html#l-52
*** http://git.openstack.org/cgit/openstack-infra/puppet-openstackci/tree/manifests/single_node_ci.pp#n297
*** puppet-openstackci single-node deploy basically does not support zuul/nodepool v3; a lot of "logic" in system-config
*** we have offers of help, how do we direct people?
*** Some options:
**** Fix puppet-openstackci so it deploys zuul/zuul-[executor|launcher]/nodepool-[launcher|builder]/zk stack?
**** 1) follow zuul-from-scratch 2) here's how to connect to openstack gerrit 3) here's tox-ish/devstack job examples
**** 1) Use windmill 2) here's tox-ish/devstack job examples
** Add mention of magic word(s) "infra-root" and maybe "config-core" to #openstack-infra topic? (frickler 2018-04-17)
*** Came up in recent help request that someone was using "infraroot" instead, which doesn't highlight (at least for me)
*** Also so various variants of this already. Might help users find the right contact. OTOH might attract spam? Should be discussed IMHO.

* Open discussion

== Upcoming Project Renames ==
(any additions should mention original->new full names and link to the corresponding project-config rename change in Gerrit)

== Previous meetings ==
Previous meetings, with their notes and logs, can be found at http://eavesdrop.openstack.org/meetings/infra/ and earlier at http://eavesdrop.openstack.org/meetings/ci/

Release Naming/S Proposals

2018-03-02T13:57:10Z

Frickler: /* Proposed Names */ Add Sonne - Sonnenallee

== S Release Naming ==

According to the [http://governance.openstack.org/reference/release-naming.html Release Naming Process], this page will contain a list of nominated names for the S release of OpenStack. We will accept nominations until 2018-03-05 23:59:59 UTC.

=== Release Name Criteria ===

* Each release name must start with the letter of the ISO basic Latin alphabet following the initial letter of the previous release, starting with the initial release of "Austin". After "Z", the next name should start with "A" again.
* The name must be composed only of the 26 characters of the ISO basic Latin alphabet. Names which can be transliterated into this character set are also acceptable.
* The name must refer to the physical or human geography of the region encompassing the location of the OpenStack design summit for the corresponding release. The exact boundaries of the geographic region under consideration must be declared before the opening of nominations, as part of the initiation of the selection process.
* The name must be a single word with a maximum of 10 characters. Words that describe the feature should not be included, so "Foo City" or "Foo Peak" would both be eligible as "Foo".

Names which do not meet these criteria but otherwise sound really cool
should be added to a separate section of the wiki page and the TC may
make an exception for one or more of them to be considered in the
Condorcet poll. The naming official is responsible for presenting the
list of exceptional names for consideration to the TC before the poll
opens.

=== Exact Geographic Region ===

The Geographic Region from where names for the S release will come is [https://en.wikipedia.org/wiki/Berlin Berlin]

=== Proposed Names ===
[https://en.wikipedia.org/wiki/Spree Spree] (a river that flows through the Saxony, Brandenburg and Berlin states of Germany)

[https://en.wikipedia.org/wiki/Berlin_S-Bahn SBahn] (The Berlin S-Bahn is a rapid transit system in and around Berlin)

[https://en.wikipedia.org/wiki/Spandau Spandau] (One of the twelve boroughs of Berlin)

[https://duckduckgo.com/?q=steinstra%C3%9Fe+berlin&t=ffsb&ia=web&iaxm=places Stein] (Steinstraße or "Stein Street" in Berlin, can also be conveniently abbreviated as 🍺)

[https://en.wikipedia.org/wiki/Steglitz Steglitz] (a locality in the South Western part of the city)

[https://en.wikipedia.org/wiki/Axel_Springer_SE Springer] (Berlin is headquarters of Axel Springer publishing house)

[https://en.wikipedia.org/wiki/Staaken Staaken] (a locality within the Spandau borough)

[https://en.wikipedia.org/wiki/Niedersch%C3%B6nhausen#Subdivision Schoenholz] (A zone in the Niederschönhausen district of Berlin)

[https://www.berlin.de/en/attractions-and-sights/3561325-3104052-shell-building.en.html Shellhaus] (A famous office building)

[https://de.wikipedia.org/wiki/Bahnhof_Berlin_S%C3%BCdkreuz Suedkreuz] ("southern cross" - a railway station in Tempelhof-Schöneberg)

[http://www.berlin.de/senuvk/umwelt/stadtgruen/gruenanlagen/de/gruenanlagen_plaetze/mitte/schillerpark/index.shtml Schiller] (A park in the Mitte borough)

[https://goo.gl/maps/SXXNdhi6oFA2 Saatwinkel] (The name of a super tiny beach, and its surrounding neighborhood)
(The adjective form, Saatwinkler is also [https://de.wikipedia.org/wiki/Saatwinkler_Steg a really cool bridge] but that form is too long)

[https://en.wikipedia.org/wiki/Sonnenallee_(Berlin) Sonne] (Sonnenallee is the name of a large street in Berlin crossing the former wall, also translates as "sun")

=== Proposed Names that do not meet the criteria ===

[https://en.wikipedia.org/wiki/Black_Forest Schwarzwald] (The Black Forest is outside of the Berlin vicinity, but soooo cool))

[https://en.wikipedia.org/wiki/Sch%C3%B6nhausen_Palace Schoenhausen Palace] (German: Schloss Schönhausen, a Baroque palace in the borough of Pankow, Berlin)

[https://en.wikipedia.org/wiki/Sch%C3%B6neberg Schoeneberg] (German: Schöneberg, one of Berlin's localities, part of Tempelhof-Schöneberg borough)

[https://en.wikipedia.org/wiki/Schwanenwerder Schwanenwerder] (a pretty island that is totally within the city limits)

[https://en.wikipedia.org/wiki/Schm%C3%B6ckwitz Schmoeckwitz] (German: Schmöckwitz, a cool locality in the South East with a lot of water)

Schmetterlingswiesen ("butterfly meadows" - a park in eastern Berlin)

[https://en.wikipedia.org/wiki/SO36 SO36] (historic denomination of a part of Kreuzberg, and also a famous club associated with the punk scene) (if digits are allowed...?)

[https://en.wikipedia.org/wiki/Sanssouci Sanssouci] (The palace of Frederick the Great located just outside of Berlin in Pottsdam, but considered by many as part of Berlin)

[https://en.wikipedia.org/wiki/Bread_roll Schrippe] (A frequently used word in original Berlin dialect for bread roll)