OpenStack - User contributions [en]

Meetings/InfraTeamMeeting

2020-07-04T09:05:20Z

Jaegerandi: /* Upcoming Project Renames */

= Weekly Project Infrastructure team meeting =

The OpenDev Team holds public weekly meetings in <code><nowiki>#opendev-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
** Clarkb out July 7. Will need someone else to run the meeting.

* Actions from last meeting

* Specs approval
** Authentication broker service, https://review.opendev.org/#/c/731838/
*** Not yet ready for approval but is worthy of review.

* 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
*** Gerrit on docker updates
**** Gerritbot still outstanding todo item.
*** Zuul as CD engine
*** Zuul executors running on containers
** OpenDev
*** Progress on Governance changes
**** http://lists.opendev.org/pipermail/service-discuss/2020-May/000026.html Advisory Board thread. Bumped with July 2, 2020 deadline.
*** Gitea api troubles.
**** Workaround: https://review.opendev.org/#/c/738109/
**** Upstream fix: https://github.com/go-gitea/gitea/pull/12057

* General topics
** DNS cleanup (ianw 20200630)
*** https://etherpad.opendev.org/p/rax-dns-openstack-org First pass of record removals has been done. Could use a second pass.
*** On the agenda as a reminder for clarkb to do this second cleanup pass.
** Trusty Upgrade Progress (clarkb 20200630)
*** Wiki updates
** Time to retire the openstack-infra ML yet? (fungi 20200630)
** Grafana on containers (clarkb 20200630)
*** https://review.opendev.org/#/q/status:open+topic:grafana-container
** Project Renames (clarkb 20200707)

* Open discussion

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

* foo/example -> bar/example: https://review.opendev.org/#/c/123456
* openstack/transparency-policy -> osf/transparency-policy: https://review.opendev.org/#/c/739286/
* x/devstack-plugin-topiko -> x/devstack-plugin-tobiko: https://review.opendev.org/#/c/738979

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

2020-07-04T09:02:30Z

Jaegerandi: /* Upcoming Project Renames */

= Weekly Project Infrastructure team meeting =

The OpenDev Team holds public weekly meetings in <code><nowiki>#opendev-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
** Clarkb out July 7. Will need someone else to run the meeting.

* Actions from last meeting

* Specs approval
** Authentication broker service, https://review.opendev.org/#/c/731838/
*** Not yet ready for approval but is worthy of review.

* 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
*** Gerrit on docker updates
**** Gerritbot still outstanding todo item.
*** Zuul as CD engine
*** Zuul executors running on containers
** OpenDev
*** Progress on Governance changes
**** http://lists.opendev.org/pipermail/service-discuss/2020-May/000026.html Advisory Board thread. Bumped with July 2, 2020 deadline.
*** Gitea api troubles.
**** Workaround: https://review.opendev.org/#/c/738109/
**** Upstream fix: https://github.com/go-gitea/gitea/pull/12057

* General topics
** DNS cleanup (ianw 20200630)
*** https://etherpad.opendev.org/p/rax-dns-openstack-org First pass of record removals has been done. Could use a second pass.
*** On the agenda as a reminder for clarkb to do this second cleanup pass.
** Trusty Upgrade Progress (clarkb 20200630)
*** Wiki updates
** Time to retire the openstack-infra ML yet? (fungi 20200630)
** Grafana on containers (clarkb 20200630)
*** https://review.opendev.org/#/q/status:open+topic:grafana-container
** Project Renames (clarkb 20200707)

* Open discussion

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

* foo/example -> bar/example: https://review.opendev.org/#/c/123456
* openstack/transparency-policy -> osf/transparency-policy: https://review.opendev.org/#/c/739286/
* x/devstack-plugin-topiko -> x/devtsack-plugin-tobiko: https://review.opendev.org/#/c/738979

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

2020-03-11T20:27:56Z

Jaegerandi: /* 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
** Switching to #opendev now - and merge https://review.opendev.org/#/c/711106/
** http://lists.openstack.org/pipermail/foundation/2020-March/002852.html OSF email on 2020 events
** DST change has happened in some parts of the world. Double check your calendar entries.

* Actions from last meeting

* Specs approval
** https://review.opendev.org/#/c/710057/ xwiki for wikis

* 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
**** http://lists.openstack.org/pipermail/openstack-infra/2020-March/006603.html OpenDev as OSF pilot project
**** https://review.opendev.org/#/c/710020/ Split OpenDev out of OpenStack governance.
**** https://review.opendev.org/#/c/703488 Updates to our project documentation with governance info

* General topics
** Trusty Upgrade Progress (clarkb 20200310)
*** Wiki updates
** static.openstack.org (ianw,corvus,mnaser,fungi 20200310)
*** Now down to cleanup of servers
** Discuss future IRC channel usage (frickler 20200310)
*** Splitting the channels has begun. Openstack events removed from #opendev.
*** https://review.opendev.org/#/c/711106/1 if we get quorum on that change we can announce the migration then start holding people to it after an agreed on date.
** FortNebula now OpenEdge Cloud (clarkb 20200310)
*** Has been redeployed and is being spun back up again.

* Open discussion

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

* x/devstack-plugin-nfs -> openstack/devstack-plugin-nfs: https://review.opendev.org/#/c/711834/
* openstack/infra-manual -> opendev/infra-manual: https://review.opendev.org/712149

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

2020-03-10T18:22:26Z

Jaegerandi: /* Upcoming Project Renames */

= 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
** http://lists.openstack.org/pipermail/foundation/2020-March/002852.html OSF email on 2020 events
** DST change has happened in some parts of the world. Double check your calendar entries.

* Actions from last meeting

* Specs approval
** https://review.opendev.org/#/c/710057/ xwiki for wikis

* 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
**** http://lists.openstack.org/pipermail/openstack-infra/2020-March/006603.html OpenDev as OSF pilot project
**** https://review.opendev.org/#/c/710020/ Split OpenDev out of OpenStack governance.
**** https://review.opendev.org/#/c/703488 Updates to our project documentation with governance info

* General topics
** Trusty Upgrade Progress (clarkb 20200310)
*** Wiki updates
** static.openstack.org (ianw,corvus,mnaser,fungi 20200310)
*** Now down to cleanup of servers
** Discuss future IRC channel usage (frickler 20200310)
*** Splitting the channels has begun. Openstack events removed from #opendev.
*** https://review.opendev.org/#/c/711106/1 if we get quorum on that change we can announce the migration then start holding people to it after an agreed on date.
** FortNebula now OpenEdge Cloud (clarkb 20200310)
*** Has been redeployed and is being spun back up again.

* Open discussion

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

* x/devstack-plugin-nfs -> openstack/devstack-plugin-nfs: https://review.opendev.org/#/c/711834/
* openstack/infra-manual -> opendev/infra-manual: https://review.opendev.org/712149

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

2020-03-10T18:13:03Z

Jaegerandi: /* Upcoming Project Renames */

= 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
** http://lists.openstack.org/pipermail/foundation/2020-March/002852.html OSF email on 2020 events
** DST change has happened in some parts of the world. Double check your calendar entries.

* Actions from last meeting

* Specs approval
** https://review.opendev.org/#/c/710057/ xwiki for wikis

* 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
**** http://lists.openstack.org/pipermail/openstack-infra/2020-March/006603.html OpenDev as OSF pilot project
**** https://review.opendev.org/#/c/710020/ Split OpenDev out of OpenStack governance.
**** https://review.opendev.org/#/c/703488 Updates to our project documentation with governance info

* General topics
** Trusty Upgrade Progress (clarkb 20200310)
*** Wiki updates
** static.openstack.org (ianw,corvus,mnaser,fungi 20200310)
*** Now down to cleanup of servers
** Discuss future IRC channel usage (frickler 20200310)
*** Splitting the channels has begun. Openstack events removed from #opendev.
*** https://review.opendev.org/#/c/711106/1 if we get quorum on that change we can announce the migration then start holding people to it after an agreed on date.
** FortNebula now OpenEdge Cloud (clarkb 20200310)
*** Has been redeployed and is being spun back up again.

* Open discussion

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

* x/devstack-plugin-nfs -> openstack/devstack-plugin-nfs: https://review.opendev.org/#/c/711834/
* openstack/infra-manual -> opendev/infra-manual: Review WIP

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

2020-01-07T19:25:42Z

Jaegerandi: /* Agenda for next meeting */

Meetings/InfraTeamMeeting

2020-01-07T19:24:50Z

Jaegerandi: /* Upcoming Project Renames */

StarlingX/MultiOS

2019-10-21T06:36:23Z

Jaegerandi:

== MultiOS Sub-project ==

Welcome to the MultiOS sub-project!

=== Team members ===

* Project Lead: Victor Rodriguez <victor.rodriguez.bahena@intel.com>
* Technical Lead : Saul Wold
* Contributors: Saul Wold, Mario Alfredo C Arevalo, Yi C Wang; Yan Chen Scott Little, Abraham Arce Moreno, Bruce Jones, Marcela Rosales, Stephen Gooch, Babak SarAshki.

=== Weekly call ===

Every Monday 4PM Pacific time https://zoom.us/j/342730236

Project notes https://etherpad.openstack.org/p/stx-multios

=== Goals ===
Our goals for this sub-project are:
* Enable StarlingX to be built on and run on multiple host operating systems
** Our initial target operating systems are CentOS (currently supported), Clear Linux and Ubuntu
* Enable StarlingX to provide software management services for multiple package file formats
** This requires building abstraction layers in the StarlingX Flock to allow package management to be defined per-OS (or per package manager)

=== Dependencies ===
This work is dependent on work being done in the [[StarlingX/Pyton2|Python2 to Python3 Transition]] and [[StarlingX/Devstack|Devstack Integration]] sub-projects, and will become easier as the Upstreaming project gets the StarlingX forks closed.

=== Work items ===
* All Storyboard stories created for this team should use the tag "stx.multios" and the prefix [MultiOS].
* The work items for this team can be found in Storyboard [https://storyboard.openstack.org/#!/story/list?status=active&project_group_id=86&tags=stx.multios here].
* The bugs open against the project can be found in TBD

=== Operating System Dependent Notes and Issues ===
==== Debian ====

See [[StarlingX/MultiOS/Debian|Debian]]

==== openSUSE ====

See [[StarlingX/MultiOS/OpenSUSE|openSUSE]]

==== Clear Linux ====

See [[StarlingX/MultiOS/ClearLinux|Clear Linux]]

==== Yocto/Wind River Linux ====

See [[StarlingX/MultiOS/Yocto|Yocto]]

Meetings/InfraTeamMeeting

2019-09-29T10:05:33Z

Jaegerandi: /* Agenda for next meeting */

IRC

2019-07-11T05:59:33Z

Jaegerandi: /* OpenStack IRC channels (chat.freenode.net) */

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.

IRC software can be found for all operating systems. The [https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_clients#Operating_system_support IRC clients comparison chart on Wikipedia] can help you pick one for your operating system.

You don't have to have a complex setup to use IRC. You can use the web client for Freenode, which doesn't require any download or setup. Just pick a nickname and join #openstack: http://webchat.freenode.net/?channels=openstack,openstack-dev.

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

=== IRC meetings ===

The OpenStack project holds its various public meetings on IRC. See [[Meetings]] for details.

== OpenStack IRC channels (chat.freenode.net) ==

If you want to start a new IRC channel, please consult with the InfrastructureTeam in #openstack-infra or at openstack-infra@lists.openstack.org to ensure it gets registered appropriately.

'''Many IRC channels are logged and [http://eavesdrop.openstack.org/irclogs/ recordings are publicly accessible]'''. If you're concerned about privacy consider using a [https://freenode.net/kb/answer/cloaks cloak], [https://freenode.net/kb/answer/chat tor], hide your real name and be mindful not to write sensitive data in these channels.

{| class="wikitable sortable" border="1"
|-
! IRC Channel !! Description
|-
|'''#openstack''' || general discussion, support
|-
|'''#openstack-ansible''' || [http://docs.openstack.org/developer/openstack-ansible/ OpenStack-Ansible] discussions
|-
|'''#openstack-anvil''' || [http://anvil.readthedocs.org/ Anvil] discussion channel
|-
|'''#openstack-app-catalog''' || [http://apps.openstack.org Community App Catalog] discussions
|-
|'''#openstack-barbican''' || [[Barbican]] related team discussions
|-
|'''#openstack-blazar''' || blazar (formerly climate) team discussions
|-
|'''#openstack-board''' || OpenStack Foundation Board Meeting Back channel (mainly quiet except during meetings)
|-
|'''#openstack-telemetry''' || Telemetry team (ceilometer, aodh, gnocchi) discussions
|-
|'''#openstack-chef''' || deployment and operating OpenStack with Chef
|-
| '''#openstack-chinese''' || general discussion, support in Chinese
|-
| '''#openstack-cinder''' || cinder team discussions
|-
| '''#openstack-community''' || coordination of community activity
|-
| '''#openstack-containers''' || Magnum team discussion
|-
| '''#openstack-cue''' || Cue team discussion
|-
|'''#openstack-defcore''' || Defcore discussion channel
|-
|'''#openstack-dev''' || general and cross-project development discussion
|-
|'''#openstack-dib''' || Discussion around diskimage-builder
|-
|'''#openstack-dns''' || Designate DNS team discussions
|-
|'''#openstack-doc''' || documentation team discussion
|-
|'''#openstack-dragonflow''' || [https://docs.openstack.org/dragonflow/ Dragonflow] team discussion
|-
|'''#openstack-ec2api''' || EC2 API discussion channel
|-
|'''#openstack-fr''' || general discussion, support in French
|-
|'''#openstack-fwaas''' || Firewall as a Service discussions
|-
|'''#openstack-gbp''' || Group Based Policy discussions
|-
|'''#openstack-glance''' || glance team discussions
|-
|'''#openstack-glare''' || glare team discussions
|-
|'''#openstack-freezer''' || freezer team discussions
|-
|'''#openstack-gsoc''' || google summer of code discussions
|-
|'''#openstack-ha''' || High Availability discussions
|-
|'''#openstack-heat-translator''' || Heat-Translator and TOSCA-Parser team discussions
|-
|'''#openstack-helm''' || openstack-helm discussions
|-
|'''#openstack-horizon''' || horizon team discussions
|-
|'''#openstack-hyper-v''' || Microsoft Windows guests and hypervisor discussion
|-
| '''#openstack-i18n''' || I18N team discussions
|-
|'''#openstack-infra''' || developer community infrastructure, continuous integration testing
|-
|'''#openstack-ironic''' || ironic & bare metal discussions
|-
|'''#openstack-jjb''' || Jenkins Job Builder discussions
|-
|'''#openstack-karbor''' || karbor team discussions
|-
|'''#openstack-keystone''' || keystone team discussions
|-
|'''#openstack-ko''' || general discussion, support in Korean
|-
|'''#openstack-kolla''' || Kolla team discussion channel
|-
|'''#openstack-kuryr''' || Kuryr team discussion channel
|-
|'''#openstack-latinamerica''' || OpenStack Latin America (Spanish)
|-
|'''#openstack-lbaas''' || Neutron LBaaS and Project Octavia discussions
|-
|'''#openstack-manila''' || shared / distributed file system service team discussions
|-
|'''#openstack-marconi''' || queue/messaging marconi team discussions
|-
|'''#openstack-meeting''' || team meetings
|-
|'''#openstack-meeting-alt''' || team meetings, alternate channel
|-
|'''#openstack-meeting-3''' || team meetings, another alternate channel
|-
|'''#openstack-meeting-4''' || team meetings, another alternate channel
|-
|'''#openstack-mistral''' || Mistral Workflow Service for OpenStack
|-
|'''#openstack-monasca''' || Monasca Monitoring and Logging as-a-Service for OpenStack
|-
|'''#openstack-neutron''' || neutron team discussions
|-
|'''#openstack-nfv''' || [[Teams/NFV|NFV]] team discussions
|-
|'''#openstack-nova''' || nova team discussions
|-
|'''#openstack-operators''' || OpenStack Operators discussion channel
|-
|'''#openstack-opw''' || GNOME OPW mentor, intern and supporter discussions
|-
|'''#openstack-oslo''' || [https://wiki.openstack.org/wiki/Oslo Oslo] development discussion
|-
|'''#openstack-performance''' || All OpenStack performance related discussions
|-
|'''#openstack-pkg''' || Debian packaging discussions
|-
|'''#openstack-pl''' || OpenStack discussions in Polish
|-
|'''#openstack-powervm''' || PowerVM OpenStack drivers discussion channel
|-
|'''#openstack-publiccloud''' || Public Cloud Working Group discussions
|-
| '''#openstack-qa''' || QA team discussion (tempest, devstack, grenade projects and friends)
|-
| '''#openstack-qinling''' || Function as a Service discussion channel
|-
|'''#openstack-rally''' || [https://wiki.openstack.org/wiki/Rally Rally] measure performance of your cloud
|-
|'''#openstack-rating''' || Rating team discussions
|-
|'''#openstack-release''' || Release managers channel
|-
|'''#openstack-requirements''' || Requirements discussion channel
|-
|'''#openstack-rpm-packaging''' || RPM packaging discussions
|-
|'''#openstack-sahara''' || [https://wiki.openstack.org/wiki/Sahara Sahara] team discussions
|-
|'''#openstack-sdks''' || Development of SDKs to work with OpenStack and the unified OpenStack command line tool
|-
|'''#openstack-security''' || General discussion about OpenStack security and open channel for the OpenStack Security Group (OSSG)
|-
|'''#openstack-searchlight''' || [wiki.openstack.org/wiki/Searchlight] - Search your OpenStack resources
|-
|'''#openstack-stable''' || stable branch management discussions
|-
|'''#openstack-state-management''' || [https://wiki.openstack.org/wiki/TaskFlow TaskFlow] and state-management development discussion
|-
|'''#openstack-swift''' || swift team discussions
|-
|'''#openstack-third-party-ci''' || OpenStack third-party CI operators
|-
|'''#openstack-trove''' || trove database team discussions
|-
|'''#openstack-tw''' || general discussion, support in Taiwan
|-
|'''#openstack-uk''' || OpenStack UK Community
|-
|'''#openstack-upstream-institute''' || OpenStack Upstream Institute team discussions and a forum to discuss questions and best practices about on-boarding new contributors
|-
| '''#openstack-ux''' || discussion channel for user experience
|-
|'''#openstack-vmware''' || The VMwareAPI team discussion channel
|-
|'''#openstack-watcher''' || [https://wiki.openstack.org/wiki/Watcher Watcher] discussion channel
|-
|'''#openstack-zaqar''' || [https://docs.openstack.org/zaqar/latest/ Zaqar] discussion channel
|-
|'''#openstack-zun''' || [https://wiki.openstack.org/wiki/Zun Zun] discussion channel
|-
|'''#airshipit''' || OpenStack [https://www.airshipit.org/ Airship] discussion channel - declarative automated cloud provisioning and management
|-
|'''#congress''' || Congress policy developer discussion channel
|-
|'''#fuel''' || Fuel users&developers discussion channel
|-
|'''#heat''' || Heat developer discussion channel
|-
|'''#magnetodb''' || Key-Value storage for OpenStack
|-
|'''#murano''' || Murano team discussions
|-
|'''#nova-docker''' || Nova Docker team discussions
|-
|'''#puppet-openstack''' || OpenStack Puppet modules discussions
|-
|'''#refstack''' || RefStack
|-
|'''#senlin''' || [https://wiki.openstack.org/wiki/Senlin Senlin] team discussions
|-
|'''#storyboard''' || StoryBoard team discussions
|-
|'''#tacker''' || [https://wiki.openstack.org/wiki/Tacker Tacker] NFV Orchestrator team discussions
|-
|'''#tripleo''' || TripleO team discussions
|-}

[[Category:Connect]]

Meetings/InfraTeamMeeting

2019-05-31T17:59:55Z

Jaegerandi: /* Upcoming Project Renames */

Python3

2018-08-30T15:33:51Z

Jaegerandi: /* IRC: #openstack-python3 */

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 [http://docs.openstack.org/developer/oslo.serialization/api.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.

The py34 check job is not more voting because of [//bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1367907 ubuntu still uses Python 3.4.0 which has a severe bug].
|-
| [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 ||
oslo.rootwrap 2.4 works on Python 3, but eventlet tests hangs on Python 3. It's now fixed in the development version. oslo.rootwrap has a non-voting python34 check job.
|-
| [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 || py33 gate is not voting
|-
| [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-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-saharaclient 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 ||
|-

| [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: orange;" | 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-devstack-pdns4-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]
|-

| [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: red;" | no job ||
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: orange;" | work in progress || style="background-color: lightgreen;" | voting || style="background-color: lightgreen;" | integrated-gate-py35 ||
Status at 2016-06-22: 10,284/13,477 unit tests passed (76%), TODO: 3,193 tests

Status at 2016-06-28: Matt Riedemann: "Keep in mind that Thursday 6/30 is the nova non-priority blueprint feature freeze (end of day really). So the majority of review focus this week should be on non-priority blueprints." Sylvain Bauzas: "Well, IIRC we discussed in the previous year on some of those blueprints (including the Py3 effort) that are not really features (rather refactoring items) and which shouldn't be hit by the non-priority feature freeze."

Status at 2016-08-01: Michael Still: "Per Matt's email, the merge window for these is now closed in Newton."

Status at 2016-09-22: 11,221/14,298 unit tests passed (78%), TODO: 3077 tests

Status at 2017-01-05: 13,888/14,537 unit tests passed (96%), TODO: 649 tests

Links:

* Paches: [https://review.openstack.org/#/q/topic:bp/nova-python3-newton bp/nova-python3-newton]
* [https://blueprints.launchpad.net/nova/+spec/nova-python3-newton nova-python3-newton blueprint]
* [http://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/adding-python34-support-to-nova.html Adding Python 3.4 support to Nova] spec (by Victor Stinner) accepted for Liberty.

See also:

* Old patches (old topic): [https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/nova-python3,n,z master (bp/nova-python3)].
* dims: [https://review.openstack.org/#/c/261045/ python3: byte/string conversions and enable more tests] (abandonned after 100 revisions)
* dims: [https://review.openstack.org/#/c/262083/ python3: Port more code to python3] (abandonned after 45 revisions)
|-

| [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.
|-

| [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: orange;" | work in progress || style="background-color: lightgreen;" | voting || style="background-color: orange;" | no 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
|-

| [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: red;" | no job ||
|-

| [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].
|-

| [https://pypi.python.org/pypi/cue cue] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
Patches: [https://review.openstack.org/#/q/status:open+project:openstack/cue+branch:master+topic:py3,n,z search for topic py3].
|-

| [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/magnum magnum] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
|-

| [https://github.com/openstack/manila manila] || style="background-color: lightgreen;" | Yes but... (*) || style="background-color: lightgreen;" | voting || style="background-color: orange;" | manila-tempest-minimal-py35-dsvm-cephfs-native-centos-7 is defined but not running? (tbarron: we have several centos jobs that we should port to fedora so we can run them under py3) ||
Valeriy Ponomaryov wrote the [https://blueprints.launchpad.net/manila/+spec/py3-compatibility py3-compatibility blueprint].

(*) SSL tests are skipped because of the bug [https://bugs.launchpad.net/manila/+bug/1482633 requests to SSL wrapped sockets hang while reading using py3] (tbarron: I don't find any such skips in the current manila/tests codebase).
|-

|[https://github.com/openstack/manila-ui manila-ui] || style="background-color: red;" | No || style="background-color: orange;" | non-voting || style="background-color: red;" | no job || |https://review.openstack.org/#/c/552121/ ||
|-

| [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: red;" | No || style="background-color: orange;" | non-voting || style="background-color: red;" | no job || https://storyboard.openstack.org/#!/story/2000975 ||
|-

| monasca-api || style="background-color: red;" | No || style="background-color: orange;" | non-voting || style="background-color: red;" | no job || https://storyboard.openstack.org/#!/story/2000975 ||
|-

| monasca-log-api || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
|-

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

| [https://pypi.python.org/pypi/rally rally] || style="background-color: lightgreen;" | Yes || style="background-color: lightgreen;" | voting || style="background-color: red;" | no job ||
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: red;" | no job ||
|-

| [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: orange;" | tempest-api-vmware-tvd-t and tempest-api-vmware-nsxv3 running python 3.5, but tempest-api-vmware-tvd-v and tempest-api-vmware-nsxv need to be updated ||
|-

| [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).

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

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

2018-01-08T16:50:24Z

Jaegerandi: /* Agenda for next meeting */

Meetings/InfraTeamMeeting

2018-01-08T06:16:53Z

Jaegerandi: /* Agenda for next meeting */

Meetings/InfraTeamMeeting

2017-09-19T06:09:15Z

Jaegerandi: /* Agenda for next meeting */

Meetings/InfraTeamMeeting

2017-07-25T13:30:22Z

Jaegerandi: /* Agenda for next meeting */

Translations

2017-06-23T07:27:58Z

Jaegerandi: /* Integrating translations into your project */

''Note: We switched in September 2015 to using [https://translate.openstack.org/ Zanata] for the Liberty cycle. Please direct questions to the [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n openstack-i18n mailing list] and update the documentation below to fully explain Zanata.''

= Translation, Internationalization and Localization in OpenStack =

OpenStack is committed to broad international support, and as such there must be
an ongoing concern with making OpenStack usable for all audiences. This includes
proper use of internationalization and localization tools by developers, and
high-quality translations for both user-facing messages and documentation.

== Translation & Management ==

Let's start with a working definition: translation is the act of taking the
written materials in one language and converting them into another language in
the most meaningful way possible. In terms of OpenStack, translation happens on
both the written documentation and on strings marked for translation in the
projects' codebases.

''NOTE: information on how to prepare your code or documentation for translation, see the section on internationalization below.''

=== Zanata ===

OpenStack is using a Zanata instance running at [https://translate.openstack.org/ https://translate.openstack.org/] as translation management platform.

=== Downloading translation files ===

If you wish to download the translation files (.po files) you can do so by
selecting the language you're interested in, then clicking on the name of
the project resource you wish to download. In the modal dialog which appears,
you can use any of the "download" options depending on your use case.

=== Translating on the site ===

Translation is most efficiently done right on Zanata's site. You don't
need to download any files or applications to get started.

If your language already exists, select a project, select the "master" version, select your language and then select a document to start translating.

=== Downloading translation files ===

You can also download translation files and translate locally.

'''TODO: Explain exactly how this is done with Zanata.'''

== Release cycle ==

One of the most challenging aspects of managing translations in an Open Source
project is handling the interplay between translators and developers during
the release cycle. The key piece of this equation is the "string freeze".

=== String Freeze ===

''NOTE: OpenStack's string freeze happens at the close of the final milestone in the development cycle, giving translators the entire RC period to update translations.''

At a predefined time during the release cycle there will be a "string freeze",
which means that after this point strings marked for translation in the
codebase can no longer be changed except in the case of critical-priority bugs.

Once the string freeze is in effect, the translation files in Zanata can
be assumed to be static, and translation efforts should happen in full force.
This is not to say that translation can't happen all the time. But during the
development process strings may change and translation efforts may end up being
wasted.

Any changes during the RC period should be carefully vetted to ensure they
do not alter or add translation strings, or else coordinated with translators
to ensure that changes are handled appropriately.

Check out http://docs.openstack.org/project-team-guide/release-management.html for more details.

=== Re-incorporating Translations ===

The OpenStack Infrastructure team has set up automatic generation of reviews
for translations so that they can be re-incorporated with minimal effort
at any time. For each project where this is setup in our CI infrastructure, every day a job is run. This job regenerates the original pot file and imports all well enough translated files and then proposes them to the project as patches. Only files that have 75 per cent or more translated strings are downloaded.

The list of current open proposed imports is available at [https://review.openstack.org/#/q/status:open++branch:master+topic:transifex/translations,n,z review.openstack.org].

Most importantly though, immediately prior to the release of each Release
Candidate, and before cutting the Final Release for each version, the
translation files should be merged back into their respective projects to
make sure they are properly distributed with the release.

At present it is the responsibility of each project's PTL or appointed
translation manager to make sure this happens, though OpenStack's release
managers, translation team coordinators, etc. are also encouraged to help
ensure that this happens smoothly.

=== Stable Releases and Backports ===

At present, changes to translations will not be backported to stable release
branches. Doing so would require maintaining wholly separate copies of each
set of translations and massively increases the burden on translators.

== Internationalization (i18n) ==

The term internationalization is used to broadly describe coding practices
that allow software to be adapted to the linguistic and technical differences
of various regions. This includes practices such as marking strings for
translation, supporting non-ASCII character sets, etc.

=== Integrating translations into your project ===

==== Python Projects (General) ====

For most of the OpenStack core projects (and any that use Python), the preferred
tools for internationalization are [http://docs.python.org/library/gettext.html gettext] and [http://babel.edgewall.org/ babel] (Debian/Ubuntu package name ''python-pybabel''). Getting started is
pretty easy:

===== Adopt oslo.i18n =====
First step is to adopt oslo.i18n in your project - [http://docs.openstack.org/developer/oslo.i18n/usage.html How to Use oslo.i18n in Your Application or Library]

===== Extract messages =====
Once you have some [http://docs.openstack.org/developer/oslo.i18n/guidelines.html#choosing-a-marker-function messages to translate], we need to extract those messages using Babel. The easiest way is to run "python setup.py extract_messages" in say the py27 venv.

Configure your project to use Babel to easily create your translation files. First, add `Babel` to your requirements.txt file (or wherever you track dependencies). Second, create a `babel.cfg` file in the root of your project; at it's simplest it can just contain this line:
<pre><nowiki>
[python: **.py]
</nowiki></pre>

Finally, add the following to your `setup.cfg` file:
<pre><nowiki>
[extract_messages]
keywords = _ gettext ngettext l_ lazy_gettext
mapping_file = babel.cfg
output_file = <project name>/locale/<project name>.pot
</nowiki></pre>

That will allow you to run `python setup.py extract_messages` and have it automatically generate the base translation resource file for your project.

Now you are ready to merge the generated files into your project (see example [https://review.openstack.org/#/c/182848/ review]). Note that an initial file needs to be imported into your project for the scripts that interact with the translation site.

===== Setup Zanata server, import and export of translations =====

Now you are ready to setup Zanata and the CI infrastructure. Read the [https://docs.openstack.org/infra/manual/creators.html#enabling-translation-infrastructure Infra manual] on how to do it.

==== Horizon (Django) ====

Django has built-in internationalization tools that go well-beyond the basics
of `gettext` to ensure proper unicode support throughout the entire codebase
and to make advanced features more accessible. As such, Horizon uses Django's
family of `ugettext` functions from `django.utils.translation`. It is
preferrable to explicitly import the translation function you wish to use:

<pre><nowiki>#!highlight python
from django.utils.translation import ugettext, ugettext_lazy # ..., etc.
</nowiki></pre>

For more information on the internationalization tools Django makes available,
see the [https://docs.djangoproject.com/en/dev/topics/i18n/ Django i18n Docs].

==== Documentation ([[DocBook]]) ====

While developer documentation for projects can generally be maintained solely in
English, user-oriented documentation such as that produced and maintained by
OpenStack's Docs team is also a high-priority for translation. This includes
installation and administration manuals.

''NOTE: For the first release this does not include API documentation. Typically these are sourced in the `openstack-manuals` project.''

For specifics on translation of OpenStack Documentation, please refer to the
[[Documentation/Translation]].

==== What To Translate ====

At present the convention is to translate ''all'' user-facing strings. This means
API messages, CLI responses, documentation, help text, etc.

See [[LoggingStandards#Log_Translation]] for information about translating log messages.

Exception text should ''not'' be marked for translation, because if an exception
occurs there is no guarantee that the translation machinery will be functional.

== Localization (L10n) ==

The term localization is used more specifically than internationalization to
cover coding practices that allow a software's input and output characteristics
to adjust to variances in style from region to region. This includes things
like number and date formatting, especially.

=== Dates, Numbers, and Other Concerns ===

Going beyond What is accomplished by Internationalization, the most important
aspect to consider is regional differences in formatting for dates and numbers.
For example::

<pre><nowiki>
Dates:
04/01/2012 == April 1st, 2012 (US)
04/01/2012 == January 4th, 2012 (UK)

Numbers:
1,000.42 == One thousand and 42 hundredths (US)
1.000,42 == One thousand and 42 hundredths (EU)
</nowiki></pre>

Accepting any format and naively passing it into our code would horribly break
things. Accepting only one format leaves out large chunks of the world.
Therefore, we use localization tools to accept these formats and normalize
them into data structures Python can handle universally on input, and to
convert them back to the user's expected format for display.

Another less common (for OpenStack) issue related to localization revolves
around name formats, which vary culturally. The western style of "first name"
and "last name" doesn't fit for many cultural naming conventions. This isn't
something a software tool can account for, so for problems such as these the
best solution is to simply accept the broadest range of inputs (e.g. a single
"name" field).

=== How To Localize Your Project ===

==== Horizon (Django) ====

Horizon has excellent localization tools available since it is built on top of
the Django web framework. Most conversions happen automatically when the
localization framework is active. Full support for a localized user dashboard
experience is a high-priority feature.

==== Other [[OpenStack]] Projects ====

Python's `locale` and `gettext` modules offer most of the tools necessary
to localize a Python project with some effort. More information on this will
be added in the future.

== Translation infrastructure ==
The translation infrastructure and workflow is documented on the [[Translations/Infrastructure]] page.

----
[[Category:I18n]]

Meetings/InfraTeamMeeting

2017-04-18T17:35:07Z

Jaegerandi: /* Agenda for next meeting */

Meetings/InfraTeamMeeting

2017-04-17T15:46:36Z

Jaegerandi: /* Agenda for next meeting */

Meetings/InfraTeamMeeting

2017-04-17T15:44:27Z

Jaegerandi: /* Agenda for next meeting */

Template:OpenStack Documentation Navbar

2017-02-18T10:35:27Z

Jaegerandi:

{{Navbar|TITLE=[[Documentation|OpenStack Documentation]]| CONTENT=
[[Meetings/DocTeamMeeting|Documentation team meeting]] - [https://docs.openstack.org/contributor-guide/index.html Documentation Contributor Guide] - [[Documentation/Conventions|Conventions]] - [https://docs.openstack.org/contributor-guide/quickstart/first-timers.html HowTo for first timers] - [https://docs.openstack.org/contributor-guide/docs-builds.html Documentation builds] - [https://docs.openstack.org/contributor-guide/blueprints-and-specs.html Content Specification] - [[Documentation/SpecialityTeams|Speciality Teams]]}}

Template:OpenStack Documentation Navbar

2017-02-18T10:34:24Z

Jaegerandi: use https

{{Navbar|TITLE=[[Documentation|OpenStack Documentation]]| CONTENT=
[[Meetings/DocTeamMeeting|Documentation team meeting]] - [https://docs.openstack.org/contributor-guide/index.html Documentation Contributor Guide] - [[Documentation/Conventions|Conventions]] - [https://docs.openstack.org/contributor-guide/quickstart/first-timers.html HowTo for first timers] - [https://docs.openstack.org/contributor-guide/docs-builds.html Documentation builds] - [https://docs.openstack.org/contributor-guide/content-specs.html Content Specification] - [[Documentation/SpecialityTeams|Speciality Teams]]}}

Template:OpenStack Documentation Navbar

2017-02-18T10:33:01Z

Jaegerandi:

{{Navbar|TITLE=[[Documentation|OpenStack Documentation]]| CONTENT=
[[Meetings/DocTeamMeeting|Documentation team meeting]] - [http://docs.openstack.org/contributor-guide/index.html Documentation Contributor Guide] - [[Documentation/Conventions|Conventions]] - [https://docs.openstack.org/contributor-guide/quickstart/first-timers.html HowTo for first timers] - [http://docs.openstack.org/contributor-guide/docs-builds.html Documentation builds] - [http://docs.openstack.org/contributor-guide/content-specs.html Content Specification] - [[Documentation/SpecialityTeams|Speciality Teams]]}}

Meetings/InfraTeamMeeting

2017-01-24T19:05:07Z

Jaegerandi: /* Upcoming Project Renames */

Documentation/VendorDrivers

2017-01-19T11:04:04Z

Jaegerandi:

{{OpenStack_Documentation_Navbar}}

= Vendor Driver Documentation =

As explained in our [http://specs.openstack.org/openstack/docs-specs/specs/kilo/move-driver-docs.html specification for guidelines for vendor drivers], the Documentation team requests a contact person for each driver. At a minimum, driver docs are published in [http://docs.openstack.org/juno/config-reference/content/ the Configuration Reference per release]. The contact person should have a Launchpad account so that bugs can be assigned to the person.

Fill in the table below with details following the example

{| border="1" cellpadding="2" cellspacing="0" class="wikitable"
|-
!colspan="3"|Vendor Driver Contacts
|-
! Vendor
! File (in doc/config-reference)
! Contact person name <email>
|-
| Example: OpenStack Documentation team
| block-storage/drivers/nfs-volume-driver.xml
| Documentation team <openstack-docs@lists.openstack.org>
|-
!colspan="3"|Block Storage (cinder)
|-
| Blockbridge
| block-storage/drivers/blockbridge-eps-driver.xml
| Joshua Huber <jhuber@blockbridge.com>
|-
| Coho Data
| block-storage/drivers/coho-storage-driver.xml
| Bardia Keyoumarsi <bardia.keyoumarsi@cohodata.com>
|-
| CoprHD
| block-storage/drivers/coprhd-driver.xml
| Vinita Deshpande <vinita.deshpande@emc.com>
|-
| Datera (Elastic Data Fabric)
| block-storage/drivers/datera-volume-driver.rst
| Matt Smith <mss@datera.io>, IRC: _alastor_
|-
| Dell Storage (EqualLogic)
| block-storage/drivers/dell-equallogic-driver.xml
| Sean McGinnis <openstack-cinder@dell.com>
|-
| Dell Storage (Storage Center)
| block-storage/drivers/dell-storagecenter-driver.xml
| Sean McGinnis <openstack-cinder@dell.com>
|-
| Dot Hill
| block-storage/drivers/dothill-driver.xml
| Chris Maio <cinder@tristero.net>
|-
| EMC (ScaleIO)
| block-storage/drivers/emc-scaleio-driver.xml
| Xing Yang <xing.yang@emc.com>
|-
| EMC (VMAX)
| block-storage/drivers/emc-vmax-driver.xml
| Xing Yang <xing.yang@emc.com>
|-
| EMC (VNX)
| block-storage/drivers/emc-vnx-direct-driver.xml
| EMC VNX OpenStack <EMC.VNX.OpenStack@emc.com>
|-
| EMC (XtremIO)
| block-storage/drivers/emc-xtremio-driver.xml
| Shay Halsband <shay.halsband@emc.com>
|-
| FalconStor (FSS)
| block-storage/drivers/falconstor-fss-driver.rst
| Soffie Huang <Soffie.Huang@falconstor.com>
|-
| Fujitsu (ETERNUS DX)
| doc/config-reference/source/block-storage/drivers/fujitsu-eternus-dx-driver.rst
| Yusuke Hayashi <hayashi-yusuke@jp.fujitsu.com>
|-
| HDS (HNAS)
| block-storage/drivers/hds-hnas-driver.xml
| HNAS Openstack Team <OpenstackDevelopment@hds.com>
|-
| HDS (HBSD)
| block-storage/drivers/hitachi-storage-volume-driver.rst
| HNAS Openstack Team <OpenstackDevelopment@hds.com>
|-
| HPE (3PAR/StoreServ)
| block-storage/drivers/hpe-3par-driver.xml
| MSDU OpenStack <msdu-openstack@groups.ext.hpe.com>
|-
| HPE (LeftHand/StoreVirtual)
| block-storage/drivers/hpe-lefthand-driver.xml
| MSDU OpenStack <msdu-openstack@groups.ext.hpe.com>
|-
| HP MSA
| block-storage/drivers/hp-msa-driver.xml
| Chris Maio <cinder@tristero.net>
|-
|Huawei
| block-storage/drivers/huawei-storage-driver.xml
| liuxinguo <liuxinguo@huawei.com>
|-
| IBM (FlashSystem)
| block-storage/drivers/ibm-flashsystem-volume-driver.xml
| Yanlin Ren <renylin@cn.ibm.com>
|-
| IBM (Storwize)
| block-storage/drivers/ibm-storwize-volume-driver.xml
| Ivy Zhang <shzyu@cn.ibm.com>
|-
| Kaminario (K2 All-Flash Array)
|
| Nikesh Mahalka <Nikesh.Mahalka.ctr@kaminario.com>
|-
| ITRI (DISCO)
|
| Weiru Lee <WeiRu.Lee@itri.org.tw>
|-
| Lenovo
| block-storage/drivers/lenovo-driver.xml
| Chris Maio <cinder@tristero.net>
|-
| NetApp
| block-storage/drivers/netapp-volume-driver.xml
| Goutham Pacha Ravi <gouthampravi AT g mail DOT com> (gouthamr)
|-
| Nexenta
| block-storage/drivers/nexenta*
| Alexey Khodos <alexey.khodos@nexenta.com>, Ilya Grafutko <ilya.grafutko@nexenta.com>
|-
| Nimble Storage
| block-storage/drivers/nimble-volume-driver.xml
| Nimble OpenStack Team <openstack-ci@nimblestorage.com>
|-
| Oracle
| block-storage/drivers/zfssa-nfs-driver.xml,
block-storage/drivers/zfssa-iscsi-driver.xml
| Kedar Vidvans <kedar.vidvans@oracle.com>,
Alka Deshpande <alka.deshpande@oracle.com>
|-
| Pure Storage
| block-storage/drivers/pure-storage-driver.xml
| Openstack Dev <openstack-dev@purestorage.com>
|-
|Quobyte
| block-storage/drivers/quobyte.xml
| Silvan Kaiser <silvan@quobyte.com>, kaisers @IRC
|-
| RedHat (GlusterFS Storage)
| block-storage/drivers/glusterfs-driver.xml
| Bharat Kumar Kobagana <bharat.kobagana@redhat.com>
|-
| Scality (SOFS)
| block-storage/drivers/scality-sofs-driver.xml
| Openstack Eng <openstack-eng@scality.com>
|-
| SolidFire
| block-storage/drivers/solidfire-driver.xml
| John Griffith <john.griffith@solidfire.com>
|-
| Synology
| block-storage/drivers/synology-dsm-driver.rst
| Taylor Huang <taylorh@synology.com>
|-
| Tintri
| block-storage/drivers/tintri-volume-driver.xml
| OpenStack Dev <openstack-dev@tintri.com>
|-
| Violin Memory (V7000)
| block-storage/drivers/violin-v7000-driver.xml
| Garfield Freeman <gfreeman@vmem.com>
|-
| Violin Memory (V6000)
| block-storage/drivers/violin-v6000-driver.xml
| Garfield Freeman <gfreeman@vmem.com>
|-
| Virtuozzo Storage
| block-storage/drivers/vzstorage-driver.rst
| Maxim Nestratov <mnestratov@virtuozzo.com>
|-
| VMware
| block-storage/drivers/vmware-vmdk-driver.xml
| Vipin Balachandran <vbala@vmware.com>
|-
| X-IO technologies
| block-storage/drivers/xio-volume-driver.xml
| Richard Hedlind <openstack-dev@x-io.com>
|-
| Zadara Storage
| block-storage/drivers/zadara-volume-driver.rst
| Shlomi Avihou <shlomi@zadarastorage.com>
|-
!colspan="3"|Fibre Channel Zone Manager (Cinder)
|-
|-
| Brocade
| block-storage/section_fc-zoning.xml
| Angela Smith <Angela.Smith@brocade.com>
|-
| Cisco
| block-storage/section_fc-zoning.xml
| Yamini Umapathy <yumapath@cisco.com>,
Midun Kumar <mneelame@cisco.com>
|-
!colspan="3"|Shared File Systems (manila)
|-
|-
| EMC (Isilon)
| shared-file-systems/drivers/emc-isilon-driver.xml
| Xing Yang <xing.yang@emc.com>
|-
| EMC (Unity)
| shared-file-systems/drivers/emc-unity-driver.xml
| EMC VNX OpenStack <EMC.VNX.OpenStack@emc.com>
|-
| EMC (VMAX)
| shared-file-systems/drivers/dell-emc-vmax-driver.rst
| Xing Yang <xing.yang@emc.com>
|-
| EMC (VNX)
| shared-file-systems/drivers/emc-vnx-driver.xml
| EMC VNX OpenStack <EMC.VNX.OpenStack@emc.com>
|-
| Generic Driver
| shared-file-systems/drivers/generic-driver.xml
| Valeriy Ponomaryov <vponomaryov@mirantis.com>
|-
| RedHat (GlusterFS)
| shared-file-systems/drivers/glusterfs-driver.xml
| Ramana Raja <rraja@redhat.com>
|-
| RedHat (GlusterFS Native)
| shared-file-systems/drivers/glusterfs-native-driver.xml
| Ramana Raja <rraja@redhat.com>
|-
| Intel
| shared-file-systems/drivers/hdfs-native-driver.xml
| Weiting Chen <weiting.chen@intel.com>
|-
| Hitachi (HNAS)
| shared-file-systems/drivers/hitachi-hnas-driver.xml
| HNAS Openstack Team <OpenstackDevelopment@hds.com>
|-
| Hitachi (HSP)
| shared-file-systems/drivers/hitachi-hsp-driver.rst
| HSP Openstack Team <OpenstackDevelopment@hds.com>
|-
| HPE (3PAR/StoreServ)
| shared-file-systems/drivers/hpe-3par-share-driver.xml
| Mark Sturdevant <mark.sturdevant@hpe.com>
|-
| Huawei
| shared-file-systems/drivers/huawei-nas-driver.xml
| zhongjun <jun.zhongjun@huawei.com>
|-
| IBM (GPFS)
| shared-file-systems/drivers/ibm-gpfs-driver.xml
| Gaurang Tapase <gaurang.tapase@in.ibm.com>
|-
| NetApp (Clustered Data ONTAP)
| shared-file-systems/drivers/netapp-cluster-mode-driver.xml
| Clinton Knight <cknight@netapp.com>
|-
| Quobyte
| TBD
| Silvan Kaiser <silvan@quobyte.com>, kaisers @IRC
|-
!colspan="3"|Networking (Neutron)
|-
| Brocade Vyatta
| doc/common/tables/neutron-brocade_vyatta_l3.xml
| Harkirat Singh <harkirat@brocade.com>
|-
!colspan="3"|Compute (Nova)
|-
| Hyper-V
| doc/config-reference/source/compute/hypervisor-hyper-v.rst
| ???
|-
| Virtuozzo
| doc/config-reference/source/compute/hypervisor-virtuozzo.rst
| mnestratov@virtuozzo.com
|-|}

----
[[Category:Documentation]]

Meetings/InfraTeamMeeting

2017-01-02T16:30:17Z

Jaegerandi: /* Agenda for next meeting */

Meetings/InfraTeamMeeting

2017-01-02T16:29:35Z

Jaegerandi: /* Agenda for next meeting */

Meetings/InfraTeamMeeting

2017-01-02T16:29:17Z

Jaegerandi: /* Agenda for next meeting */

Meetings/InfraTeamMeeting

2017-01-02T16:28:37Z

Jaegerandi: /* Agenda for next meeting */

Documentation/DocImpact

2016-12-15T17:58:06Z

Jaegerandi:

=== Using the DocImpact Flag in a Commit Message ===
In any OpenStack project, you can add a DocImpact flag in a commit message to automatically log a bug in a specified project in Launchpad. The bug is not set to "Confirmed" until the patch merges. The entire commit message is included in the bug.

This method offers notification and tracking of the possible impact to documentation due to the patch. If your commit could have an impact on documentation - be it an added/altered/removed command line option, a deprecated or new feature, a caveat, if you've written docs in the patch, or if you're just not sure, just add "DocImpact" to a line in your commit message.

This creates a Launchpad bug for the project indicated in the gerrit/projects.yaml file in the openstack/project-config repository. It doesn't guarantee docs will be written, but offers visibility of the change and tracking. You can also use it as a reminder to yourself to write docs for the feature later, or remind yourself to find a writer to write for you. With over 2000 contributors to the code base and a handful of writers, there's always doc work to be done.

If you are a doc contributor, these are the steps we take once a DocImpact notification comes to the list.

1. Create a new doc bug in either openstack-manuals or openstack-api-site. In the bug:
* In the title, put "grizzly" or "havana" depending on the release the patch will land in.
* Copy and paste the review.openstack.org link in the bug description.
* Describe the documentation that is affected if the code patch lands in the bug description.
* Keep the doc bug set to "New" until the code patch is merged.

2. Continue to check on the patch and change the status to "Confirmed" once merged.

3. Use the information in the Doc Bug Triaging Guidelines section to set priority once it lands.

=== Writing Good Commit Messages for DocImpact ===

Because the entire commit message is included in the logged bug, try to put as much information as you can into the commit message about which doc audience is affected by the change or enhancement, what the change is, why it matters, and so on.

* Who would use the feature?
* Why use the feature?
* What is the exact usage for the feature? If it's an API change, give example requests and responses.
* Does the feature also have permissions/policies attached? If so, what are the requirements?

If it is a configuration option change, our automation will pick it up but we would still want a bug to track with. If it's a CLI change, we also have automation that picks up the help text, but extra usage information is useful. Read an [http://justwriteclick.com/2013/09/17/openstack-docimpact-flag-walk-through/ example walkthrough] or look at an existing [https://bugs.launchpad.net/openstack-manuals/+bug/1334674 DocImpact logged bug] that had to be triaged further for more information.

==== Third-Party DocImpact settings ====

By default DocImpact tag creates bugs using the repository name as project in Launchpad.
To change this behaviour the '''docimpact-group''' option in [https://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml projects.yaml] can be used.
For example, if you set project like this::

- project: stackforge/project-name
description: Latest and greatest cloud stuff.
upstream: git://github.com/awesumsauce/project-name.git
docimpact-group: Project

documentation bugs will be created in http://launchpad.net/Project

----
[[Category:Documentation]]

Sprints/QAInfraNewtonSprint

2016-09-11T19:28:20Z

Jaegerandi: /* Registration */

== Event Details ==
* Date: 19th - 21th September
* Location: SAP HQ Walldorf Germany
* [http://go.sap.com/documents/2014/11/3eeebe20-3b7c-0010-82c7-eda71af511fa.html SAP how to find us and building map]
* Rooms:
** Main room: WDF.03 B2.05 (~30p)
** Breakout rooms:
*** 19th: WDF.03 H3.02 (14p)
*** 20th: WDF.03 BE.02 (14p)
*** 21th: WDF.03 B1.03 (14p)

== Travel ==
* Flight to Frankfurt am Main (FFM) Germany
* Bus transfer ~1h to Walldorf
SHUTTLE SERVICE
Please make an advance reservation if you wish to use this direct minibus service.<br />
Travel time is approximately one hour. At the airport, go to the meeting point in the arrival area.<br />
This shuttle service is provided by Wörns Airport Transfer – to reserve, please contact:Tel. +49/ 62 27/ 5 59 55 Fax +49/ 62 27/ 5 50 61<br />
Bookings can be made by e-mail transfer@woerns-ts.de or online at www.woerns-ts.de.

== Hotels ==
All hotels in walking distance:
* Hotel Villa Verde: http://www.villaverde-walldorf.de/?lang=en
* Hotel Grünshof, grani: http://www.hotel-gruenshof.de/
* Leonardo Hotel Heidelberg-Walldorf: https://www.leonardo-hotels.com/leonardo-hotel-heidelberg-walldorf

== General Help and Visas ==
* In case of general questions feel free to contact:
** Marc Koderer (mkoderer, freenode) marc AT koderer.com
** Maya Tahrilova Linares, maya.tahrilova.linares AT sap.com
* Visa regulations for Germany: http://www.auswaertiges-amt.de/EN/EinreiseUndAufenthalt/Visabestimmungen_node.html

== Topics ==
Please write topics on this wiki or the following etherpad as you like :-)

Etherpad: https://etherpad.openstack.org/p/qa-infra-newton-midcycle
* Proposed Infra topics
** Zuulv3
** Infra Cloud
* Accepted Infra topics
** Puppet-ansible hardening/bugfixing
*** nibalizer

== Registration ==

We have seats for ~30 people.
Please register your info on the following table if you are interested in.

{| class="wikitable sortable"
|-
! || Name !! Company !! IRC name !! Comments !! Email
|-
| 1 || Ken Omichi || NEC || oomichi || || ken1ohmichi at gmail.com
|-
| 2 || Joshua Hesketh || Rackspace || jhesketh || || joshua.hesketh at gmail.com
|-
| 3 || Marc Koderer || SAP || mkoderer || Welcome to Germany again ;) || marc AT koderer.com
|-
| 4 || Tom Patzig || SAP || tpatzig || || tom.patzig at sap.com
|-
| 5 || Daniel Mellado || Red Hat || dmellado || || dmellado at redhat.com
|-
| 6 || Matthew Treinish || HPE || mtreinish || || mtreinish at kortar.org
|-
| 7 || Daniel Gonzalez || SAP || dgonzalez || || daniel at gonzalez-nothnagel.de
|-
| 8 || Ghanshyam Mann || NEC || gmann || || ghanshyammann at gmail.com
|-
| 9 || Masayuki Igawa || HPE || masayukig || || masayuki.igawa at gmail.com
|-
| 10 || Elizabeth K. Joseph || HPE || pleia2 || || lyz at princessleia.com
|-
| 11 || Attila Fazekas || RHT || afazekas || || afazekas KUKAC redhat PONT com
|-
| 12 || Spencer Krum || IBM || nibalizer || || nibz at spencerkrum.com
|-
| 13 || Yolanda Robla || RedHat || yolanda || || info at ysoft.biz
|-
| 14 || Matthew Wagoner || IBM || olaph || || zxkuqyb at gmail.com
|-
| 15 || Clark Boylan || OpenStack Foundation || clarkb || || cboylan at sapwetik.org
|-
| 16 || Ricardo Carrillo Cruz || HPE || rcarrillocruz || || ricardo.carrillo.cruz at gmail.com
|-
| 17 || David Paterson || Dell|| dpaterson || || david_paterson at dell.com
|-
| 18 || Chris Hoge || OpenStack Foundation || hogepodge || || chris@openstack.org
|-
| 19 || Martin Stadtler || Linaro || martinst || || martin.stadtler at linaro.org
|-
| 20 || Gema Gomez || Linaro || gema || || gema.gomez-solano at linaro.org
|-
| 21 || Dong Ma || HPE || larainema || || winterma.dong at gmail.com
|-
| 22 || Paul Belanger || Red Hat || pabelanger || || pabelanger at redhat.com
|-
| 23 || James Blair || Red Hat || jeblair || || corvus at inaugust.com
|-
| 24 || Fatih Degirmenci || Ericsson || fdegir || || fatih.degirmenci at ericsson.com
|-
| 25 || Monty Taylor || Red Har || mordred || || mordred at inaugust.com
|-
| 26 || Maurice Schreiber || SAP || - || 20th & 21st only || maurice.schreiber at sap.com
|-
| 27 || Andreas Jaeger || SUSE || AJaeger || 20th only || aj at suse.com
|}

Meetings/InfraTeamMeeting

2016-08-09T13:19:14Z

Jaegerandi: /* 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
** VOTING: [https://review.openstack.org/340641 Pholio Service Installation] (craige, fungi)
* Priority Efforts
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/ansible_puppet_apply.html Ansible Puppet Apply]
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/infra-cloud.html Infra-cloud]
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html Common OpenStack CI Solution]
** [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/zuulv3.html Zuul v3]
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/nodepool-zookeeper-workers.html Nodepool: Use Zookeeper for Workers]
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/newton-on-xenial.html Newton testing on Xenial]
* Its-storyboard plugin fixes and Gerrit 2.11.4 upgrade (zaro)
** [https://review.openstack.org/351323 fix its_rules parameterization in template]
** [https://review.openstack.org/351336 Fix setup of server certificate for its-storyboard]
** [https://review.openstack.org/351273 Update its-storyboard actions on review-dev.o.o]
** [https://review.openstack.org/#/c/352543 upgrade for review-dev.o.o]
* [http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_c2c11d642eafb0e0 Infra mascot/logo] (fungi)
* Switch to chrony (ianw 8-Aug-16)
** We moved away from using ntpdate in devstack-gate [https://review.openstack.org/#/c/299677]
** This caused various flow-on problems with waiting for time-sync from ntpd. Details in [https://bugzilla.redhat.com/show_bug.cgi?id=1361382]
*** In short; if the time is not *already* set, ntpd can take a long time to synchronise
** Additional problems with ntp-wait for snapshot users [https://review.openstack.org/352621]
** In short : chrony looks like a better choice for our situation of brining up servers and wanting them synced quickly (RH ntpd maintainer suggestion)
** Can we agree to switch to chrony?
** If so, we have a number of "include ::ntp" calls in other puppet
*** Should we remove these for a new chrony class (a few open-source versions, or something simple we write ourselves)
*** Or re-implement puppet-ntp to actually install chrony, meaning existing ntp class includes will "just work"
* Bindep uses now bindep.txt by default
* Constraints can be used in tox
* Open discussion

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

* Fix snafu with the openstack-infra/ansible-puppet rename on June 3 (transparent to users, but we need some Gerrit cleanup for a duplicate project)
* Rename openstack/higgins to openstack/zun: https://review.openstack.org/#/c/326306/

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

Documentation/InstallGuideWorkItems

2016-06-16T18:20:13Z

Jaegerandi: /* Project-Specific Install Guides */

= Install Guide Work Items =

== Existing Install Guide ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/installguide.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/installguidenewton

* Update the title (OpenStack Installation Tutorial) to reflect that it is for training and not production, and add preamble to explain that purpose.
** Change filename from install-guide to install-tutorial
** Update /shared/setup.cfg
** Theme somewhere?
* <s>Document from packages to best use existing content, but continue to revisit this problem over time, as more data emerges about which installation method users prefer.</s>
* <s>Edit the existing content so that it uses manual configuration only.</s>
* Create scripts that can be run and automatically tested and include snippets of these scripts verbatim in the guide. This will accelerate testing of the guide.
* <s>Create a ‘cookie cutter’ template that can be used for all services (AJaeger): https://review.openstack.org/#/c/314229/</s>
* Document the process of adding a big tent project under the new governance, including what tests and dependencies are required.
* Move Shared File Systems (Manila), Object Storage (Swift), Orchestration (Heat), Telemetry (Ceilometer), Database (Trove) to project repositories and link them in the “Additional projects” chapter.
** Orchestration (pkovar)
** Shared File Systems (gouthamr)
** Object Storage (pkovar)
** Telemetry (ildikov)
** Database (Laurel Michaels, Andreas Jaeger)

== Project-Specific Install Guides ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/project-specific-installguides.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/projectspecificinstallguides

* Move projects that are now out of scope of the basic install guide into in their own repositories. Also, create initial skeleton for these project specific install guides so that project teams have a consistent starting point that others can follow as example. This affects: Orchestration (heat), Telemetry (telemetry), Object Storage (swift), Shared File system (manila).
** Orchestration (pkovar): https://review.openstack.org/#/c/325389/ Merged
** Shared File Systems (gouthamr): https://review.openstack.org/#/c/317152/
** Object Storage (pkovar): https://review.openstack.org/#/c/330070/
** Telemetry (ildikov)
** Database (jaegerandi): https://review.openstack.org/#/c/330540/
* Create new chapter “project specific install guides” as skeleton.
* Create new project-specific install guides section on http://docs.openstack.org .
* Create example jobs for publishing of project-specific install guides (jaegerandi): https://review.openstack.org/#/c/326039/
* Work with operator tags team to amend the ops:docs:install-guide tag (thingee)
* <s>Create a “cookie cutter” template for use by projects when creating new Install Guides</s>

=== For projects to create a guide ===

This is documented in the [http://docs.openstack.org/contributor-guide/project-install-guide.html Contributor Guide].

Documentation/InstallGuideWorkItems

2016-06-16T18:19:25Z

Jaegerandi: /* Existing Install Guide */

= Install Guide Work Items =

== Existing Install Guide ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/installguide.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/installguidenewton

* Update the title (OpenStack Installation Tutorial) to reflect that it is for training and not production, and add preamble to explain that purpose.
** Change filename from install-guide to install-tutorial
** Update /shared/setup.cfg
** Theme somewhere?
* <s>Document from packages to best use existing content, but continue to revisit this problem over time, as more data emerges about which installation method users prefer.</s>
* <s>Edit the existing content so that it uses manual configuration only.</s>
* Create scripts that can be run and automatically tested and include snippets of these scripts verbatim in the guide. This will accelerate testing of the guide.
* <s>Create a ‘cookie cutter’ template that can be used for all services (AJaeger): https://review.openstack.org/#/c/314229/</s>
* Document the process of adding a big tent project under the new governance, including what tests and dependencies are required.
* Move Shared File Systems (Manila), Object Storage (Swift), Orchestration (Heat), Telemetry (Ceilometer), Database (Trove) to project repositories and link them in the “Additional projects” chapter.
** Orchestration (pkovar)
** Shared File Systems (gouthamr)
** Object Storage (pkovar)
** Telemetry (ildikov)
** Database (Laurel Michaels, Andreas Jaeger)

== Project-Specific Install Guides ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/project-specific-installguides.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/projectspecificinstallguides

* Move projects that are now out of scope of the basic install guide into in their own repositories. Also, create initial skeleton for these project specific install guides so that project teams have a consistent starting point that others can follow as example. This affects: Orchestration (heat), Telemetry (telemetry), Object Storage (swift), Shared File system (manila).
** Orchestration (pkovar): https://review.openstack.org/#/c/325389/ Merged
** Shared File Systems (gouthamr): https://review.openstack.org/#/c/317152/
** Object Storage (pkovar): https://review.openstack.org/#/c/330070/
** Telemetry (ildikov)
* Create new chapter “project specific install guides” as skeleton.
* Create new project-specific install guides section on http://docs.openstack.org .
* Create example jobs for publishing of project-specific install guides (jaegerandi): https://review.openstack.org/#/c/326039/
* Work with operator tags team to amend the ops:docs:install-guide tag (thingee)
* <s>Create a “cookie cutter” template for use by projects when creating new Install Guides</s>

=== For projects to create a guide ===

This is documented in the [http://docs.openstack.org/contributor-guide/project-install-guide.html Contributor Guide].

Documentation/InstallGuideWorkItems

2016-06-09T11:15:27Z

Jaegerandi: /* Project-Specific Install Guides */

= Install Guide Work Items =

== Existing Install Guide ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/installguide.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/installguidenewton

* Update the title (OpenStack Installation Tutorial) to reflect that it is for training and not production, and add preamble to explain that purpose.
* Document from packages to best use existing content, but continue to revisit this problem over time, as more data emerges about which installation method users prefer.
* Edit the existing content so that it uses manual configuration only.
* Create scripts that can be run and automatically tested and include snippets of these scripts verbatim in the guide. This will accelerate testing of the guide.
* Create a ‘cookie cutter’ template that can be used for all services (AJaeger): https://review.openstack.org/#/c/314229/
* Document the process of adding a big tent project under the new governance, including what tests and dependencies are required.
* Move Shared File Systems (Manila), Object Storage (Swift), Orchestration (Heat), Telemetry (Ceilometer), Database (Trove) to project repositories and link them in the “Additional projects” chapter.
** Orchestration (pkovar)
** Shared File Systems (gouthamr)
** Object Storage (pkovar)
** Telemetry (ildikov)

== Project-Specific Install Guides ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/project-specific-installguides.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/projectspecificinstallguides

* Move projects that are now out of scope of the basic install guide into in their own repositories. Also, create initial skeleton for these project specific install guides so that project teams have a consistent starting point that others can follow as example. This affects: Orchestration (heat), Telemetry (telemetry), Object Storage (swift), Shared File system (manila).
** Orchestration (pkovar): https://review.openstack.org/#/c/325389/ Merged
** Shared File Systems (gouthamr): https://review.openstack.org/#/c/317152/
** Object Storage (pkovar)
** Telemetry (ildikov)
* Create new chapter “project specific install guides” as skeleton.
* Create new project-specific install guides section on http://docs.openstack.org .
* Create example jobs for publishing of project-specific install guides (jaegerandi): https://review.openstack.org/#/c/326039/
* Work with operator tags team to amend the ops:docs:install-guide tag (thingee)
* Create a “cookie cutter” template for use by projects when creating new Install Guides: done

=== For projects to create a guide ===

This is documented in the [http://docs.openstack.org/contributor-guide/project-install-guide.html Contributor Guide].

Documentation/InstallGuideWorkItems

2016-06-09T10:53:24Z

Jaegerandi: /* For projects to create a guide */

= Install Guide Work Items =

== Existing Install Guide ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/installguide.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/installguidenewton

* Update the title (OpenStack Installation Tutorial) to reflect that it is for training and not production, and add preamble to explain that purpose.
* Document from packages to best use existing content, but continue to revisit this problem over time, as more data emerges about which installation method users prefer.
* Edit the existing content so that it uses manual configuration only.
* Create scripts that can be run and automatically tested and include snippets of these scripts verbatim in the guide. This will accelerate testing of the guide.
* Create a ‘cookie cutter’ template that can be used for all services (AJaeger): https://review.openstack.org/#/c/314229/
* Document the process of adding a big tent project under the new governance, including what tests and dependencies are required.
* Move Shared File Systems (Manila), Object Storage (Swift), Orchestration (Heat), Telemetry (Ceilometer), Database (Trove) to project repositories and link them in the “Additional projects” chapter.
** Orchestration (pkovar)
** Shared File Systems (gouthamr)
** Object Storage (pkovar)
** Telemetry (ildikov)

== Project-Specific Install Guides ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/project-specific-installguides.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/projectspecificinstallguides

* Move projects that are now out of scope of the basic install guide into in their own repositories. Also, create initial skeleton for these project specific install guides so that project teams have a consistent starting point that others can follow as example. This affects: Orchestration (heat), Telemetry (telemetry), Object Storage (swift), Shared File system (manila).
** Orchestration (pkovar): https://review.openstack.org/#/c/325389/
** Shared File Systems (gouthamr): https://review.openstack.org/#/c/317152/
** Object Storage (pkovar)
** Telemetry (ildikov)
* Create new chapter “project specific install guides” as skeleton.
* Create new project-specific install guides section on http://docs.openstack.org .
* Create example jobs for publishing of project-specific install guides (jaegerandi): https://review.openstack.org/#/c/326039/
* Work with operator tags team to amend the ops:docs:install-guide tag (thingee)
* Create a “cookie cutter” template for use by projects when creating new Install Guides: done

=== For projects to create a guide ===

This is documented in the [http://docs.openstack.org/contributor-guide/project-install-guide.html Contributor Guide].

Documentation/InstallGuideWorkItems

2016-06-07T06:30:10Z

Jaegerandi: /* For projects to create a guide */

= Install Guide Work Items =

== Existing Install Guide ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/installguide.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/installguidenewton

* Update the title (OpenStack Installation Tutorial) to reflect that it is for training and not production, and add preamble to explain that purpose.
* Document from packages to best use existing content, but continue to revisit this problem over time, as more data emerges about which installation method users prefer.
* Edit the existing content so that it uses manual configuration only.
* Create scripts that can be run and automatically tested and include snippets of these scripts verbatim in the guide. This will accelerate testing of the guide.
* Create a ‘cookie cutter’ template that can be used for all services (AJaeger): https://review.openstack.org/#/c/314229/
* Document the process of adding a big tent project under the new governance, including what tests and dependencies are required.
* Move Shared File Systems (Manila), Object Storage (Swift), Orchestration (Heat), Telemetry (Ceilometer), Database (Trove) to project repositories and link them in the “Additional projects” chapter.
** Orchestration (pkovar)
** Shared File Systems (gouthamr)
** Object Storage (pkovar)
** Telemetry (ildikov)

== Project-Specific Install Guides ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/project-specific-installguides.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/projectspecificinstallguides

* Move projects that are now out of scope of the basic install guide into in their own repositories. Also, create initial skeleton for these project specific install guides so that project teams have a consistent starting point that others can follow as example. This affects: Orchestration (heat), Telemetry (telemetry), Object Storage (swift), Shared File system (manila).
** Orchestration (pkovar): https://review.openstack.org/#/c/325389/
** Shared File Systems (gouthamr): https://review.openstack.org/#/c/317152/
** Object Storage (pkovar)
** Telemetry (ildikov)
* Create new chapter “project specific install guides” as skeleton.
* Create new project-specific install guides section on http://docs.openstack.org .
* Create example jobs for publishing of project-specific install guides (jaegerandi): https://review.openstack.org/#/c/326039/
* Work with operator tags team to amend the ops:docs:install-guide tag (thingee)
* Create a “cookie cutter” template for use by projects when creating new Install Guides: done

=== For projects to create a guide ===
''This is a first draft, please help refine it''
* Move existing content over to repository or start with new content using the installguide-cookiecutter from https://git.openstack.org/cgit/openstack/installguide-cookiecutter.
* Include tox.ini environment for 'install-guide' like:
<pre>
[testenv:install-guide]
# NOTE(jaegerandi): this target does not use constraints because
# upstream infra does not yet support it. Once that's fixed, we can
# drop the install_command.
install_command = pip install -U --force-reinstall {opts} {packages}
commands = sphinx-build -a -E -W -d install-guide/build/doctrees -b html install-guide/source install-guide/build/html
</pre>
* Add openstackdocs-theme to test-requirements.txt file.
* Once the changes above are merged, add jobs for it, see https://review.openstack.org/#/c/326039/ for details.
* TBD

Documentation/InstallGuideWorkItems

2016-06-07T06:28:53Z

Jaegerandi: /* For projects to create a guide */

= Install Guide Work Items =

== Existing Install Guide ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/installguide.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/installguidenewton

* Update the title (OpenStack Installation Tutorial) to reflect that it is for training and not production, and add preamble to explain that purpose.
* Document from packages to best use existing content, but continue to revisit this problem over time, as more data emerges about which installation method users prefer.
* Edit the existing content so that it uses manual configuration only.
* Create scripts that can be run and automatically tested and include snippets of these scripts verbatim in the guide. This will accelerate testing of the guide.
* Create a ‘cookie cutter’ template that can be used for all services (AJaeger): https://review.openstack.org/#/c/314229/
* Document the process of adding a big tent project under the new governance, including what tests and dependencies are required.
* Move Shared File Systems (Manila), Object Storage (Swift), Orchestration (Heat), Telemetry (Ceilometer), Database (Trove) to project repositories and link them in the “Additional projects” chapter.
** Orchestration (pkovar)
** Shared File Systems (gouthamr)
** Object Storage (pkovar)
** Telemetry (ildikov)

== Project-Specific Install Guides ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/project-specific-installguides.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/projectspecificinstallguides

* Move projects that are now out of scope of the basic install guide into in their own repositories. Also, create initial skeleton for these project specific install guides so that project teams have a consistent starting point that others can follow as example. This affects: Orchestration (heat), Telemetry (telemetry), Object Storage (swift), Shared File system (manila).
** Orchestration (pkovar): https://review.openstack.org/#/c/325389/
** Shared File Systems (gouthamr): https://review.openstack.org/#/c/317152/
** Object Storage (pkovar)
** Telemetry (ildikov)
* Create new chapter “project specific install guides” as skeleton.
* Create new project-specific install guides section on http://docs.openstack.org .
* Create example jobs for publishing of project-specific install guides (jaegerandi): https://review.openstack.org/#/c/326039/
* Work with operator tags team to amend the ops:docs:install-guide tag (thingee)
* Create a “cookie cutter” template for use by projects when creating new Install Guides: done

=== For projects to create a guide ===
''This is a first draft, please help refine it''
* Move existing content over to repository or start with new content using the installguide-cookiecutter from https://git.openstack.org/cgit/openstack/installguide-cookiecutter.
* Include tox.ini environment for 'install-guide' like:
<pre>
[testenv:install-guide]
# NOTE(jaegerandi): this target does not use constraints because
# upstream infra does not yet support it. Once that's fixed, we can
# drop the install_command.
install_command = pip install -U --force-reinstall {opts} {packages}
commands = sphinx-build -a -E -W -d install-guide/build/doctrees -b html install-guide/source install-guide/build/html
</pre>
* Once it's merged, add jobs for it, see https://review.openstack.org/#/c/326039/ for details.
* TBD

Documentation/InstallGuideWorkItems

2016-06-07T06:22:32Z

Jaegerandi: /* Project-Specific Install Guides */

= Install Guide Work Items =

== Existing Install Guide ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/installguide.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/installguidenewton

* Update the title (OpenStack Installation Tutorial) to reflect that it is for training and not production, and add preamble to explain that purpose.
* Document from packages to best use existing content, but continue to revisit this problem over time, as more data emerges about which installation method users prefer.
* Edit the existing content so that it uses manual configuration only.
* Create scripts that can be run and automatically tested and include snippets of these scripts verbatim in the guide. This will accelerate testing of the guide.
* Create a ‘cookie cutter’ template that can be used for all services (AJaeger): https://review.openstack.org/#/c/314229/
* Document the process of adding a big tent project under the new governance, including what tests and dependencies are required.
* Move Shared File Systems (Manila), Object Storage (Swift), Orchestration (Heat), Telemetry (Ceilometer), Database (Trove) to project repositories and link them in the “Additional projects” chapter.
** Orchestration (pkovar)
** Shared File Systems (gouthamr)
** Object Storage (pkovar)
** Telemetry (ildikov)

== Project-Specific Install Guides ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/project-specific-installguides.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/projectspecificinstallguides

* Move projects that are now out of scope of the basic install guide into in their own repositories. Also, create initial skeleton for these project specific install guides so that project teams have a consistent starting point that others can follow as example. This affects: Orchestration (heat), Telemetry (telemetry), Object Storage (swift), Shared File system (manila).
** Orchestration (pkovar): https://review.openstack.org/#/c/325389/
** Shared File Systems (gouthamr): https://review.openstack.org/#/c/317152/
** Object Storage (pkovar)
** Telemetry (ildikov)
* Create new chapter “project specific install guides” as skeleton.
* Create new project-specific install guides section on http://docs.openstack.org .
* Create example jobs for publishing of project-specific install guides (jaegerandi): https://review.openstack.org/#/c/326039/
* Work with operator tags team to amend the ops:docs:install-guide tag (thingee)
* Create a “cookie cutter” template for use by projects when creating new Install Guides: done

=== For projects to create a guide ===
''This is a first draft, please help refine it''
* Move existing content over to repository or start with new content using the installguide-cookiecutter from https://git.openstack.org/cgit/openstack/installguide-cookiecutter.
* Include tox.ini environment for 'install-guide' like:
* Once it's merged, add jobs for it, see https://review.openstack.org/#/c/326039/ for details.
* TBD

Documentation/InstallGuideWorkItems

2016-06-06T17:32:37Z

Jaegerandi: /* Install Guide Work Items */

= Install Guide Work Items =

== Existing Install Guide ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/installguide.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/installguidenewton

* Update the title (OpenStack Installation Tutorial) to reflect that it is for training and not production, and add preamble to explain that purpose.
* Document from packages to best use existing content, but continue to revisit this problem over time, as more data emerges about which installation method users prefer.
* Edit the existing content so that it uses manual configuration only.
* Create scripts that can be run and automatically tested and include snippets of these scripts verbatim in the guide. This will accelerate testing of the guide.
* Create a ‘cookie cutter’ template that can be used for all services (AJaeger): https://review.openstack.org/#/c/314229/
* Document the process of adding a big tent project under the new governance, including what tests and dependencies are required.
* Move Shared File Systems (Manila), Object Storage (Swift), Orchestration (Heat), Telemetry (Ceilometer), Database (Trove) to project repositories and link them in the “Additional projects” chapter.
** Orchestration (pkovar)
** Shared File Systems (gouthamr)
** Object Storage (pkovar)

== Project-Specific Install Guides ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/project-specific-installguides.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/projectspecificinstallguides

* Move projects that are now out of scope of the basic install guide into in their own repositories. Also, create initial skeleton for these project specific install guides so that project teams have a consistent starting point that others can follow as example. This affects: Orchestration (heat), Telemetry (telemetry), Object Storage (swift), Shared File system (manila).
** Orchestration (pkovar): https://review.openstack.org/#/c/325389/
** Shared File Systems (gouthamr): https://review.openstack.org/#/c/317152/
** Object Storage (pkovar)
* Create new chapter “project specific install guides” as skeleton.
* Create new project-specific install guides section on http://docs.openstack.org .
* Create example jobs for publishing of project-specific install guides (jaegerandi): https://review.openstack.org/#/c/326039/
* Work with operator tags team to amend the ops:docs:install-guide tag (thingee)
* Create a “cookie cutter” template for use by projects when creating new Install Guides: done

Documentation/InstallGuideWorkItems

2016-06-06T17:30:38Z

Jaegerandi: /* Existing Install Guide */

= Install Guide Work Items =

== Existing Install Guide ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/installguide.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/installguidenewton

* Update the title (OpenStack Installation Tutorial) to reflect that it is for training and not production, and add preamble to explain that purpose.
* Document from packages to best use existing content, but continue to revisit this problem over time, as more data emerges about which installation method users prefer.
* Edit the existing content so that it uses manual configuration only.
* Create scripts that can be run and automatically tested and include snippets of these scripts verbatim in the guide. This will accelerate testing of the guide.
* Create a ‘cookie cutter’ template that can be used for all services (AJaeger): https://review.openstack.org/#/c/314229/
* Setup jobs to publish install guide content: https://review.openstack.org/#/c/326039/
* Document the process of adding a big tent project under the new governance, including what tests and dependencies are required.
* Move Shared File Systems (Manila), Object Storage (Swift), Orchestration (Heat), Telemetry (Ceilometer), Database (Trove) to project repositories and link them in the “Additional projects” chapter.
** Orchestration (pkovar): https://review.openstack.org/#/c/325389/
** Shared File Systems (gouthamr)
** Object Storage (pkovar)

== Project-Specific Install Guides ==

Spec: http://specs.openstack.org/openstack/docs-specs/specs/newton/project-specific-installguides.html

Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/projectspecificinstallguides

* Move projects that are now out of scope of the basic install guide into in their own repositories. Also, create initial skeleton for these project specific install guides so that project teams have a consistent starting point that others can follow as example. This affects: Orchestration (heat), Telemetry (telemetry), Object Storage (swift), Shared File system (manila).
** Orchestration (pkovar): https://review.openstack.org/#/c/325389/
** Shared File Systems (gouthamr): https://review.openstack.org/#/c/317152/
** Object Storage (pkovar)
* Create new chapter “project specific install guides” as skeleton.
* Create new project-specific install guides section on http://docs.openstack.org .
* Create example jobs for publishing of project-specific install guides (jaegerandi).
* Work with operator tags team to amend the ops:docs:install-guide tag (thingee)
* Create a “cookie cutter” template for use by projects when creating new Install Guides.

Documentation/NewtonDeliverables

2016-05-06T07:03:32Z

Jaegerandi: /* Docs Tools/Infra */

=Newton Docs Deliverables=

==Ops and Arch Guides==
* Review content of both guides, and delete anything out of date
* Review architecture of both guides, and possibly combine
* Move Ops Guide into openstack-manuals repo
* Gather content from Ops internal documentation

==HA Guide==
* Move HA Guide into openstack-manuals
* OR consolidate information into other guides (e.g. admin).

==Install Guide==
* Project-specific Install Guides to be written/maintained by each project: https://review.openstack.org/#/c/301284/
* Remainder of the work to be done on the existing Install Guide: https://review.openstack.org/#/c/310588
* New spec/poc for potentially automating test process in a future release

==Contributor Guide==
* UI/UX section improvement
* Improve documentation of docs tools/theme etc
* Add diagram recommendations
* Document new Install Guide process
* Process discussions: Who should follow this guide? Introduction of a minimal review time? Section about contribution recommendations: what devs should contribute, review expectations of docs, expected turn-around time, etc. How to deprecate/remove docs? Also define which are continuous-release, versioned, etc.

==Security Guide==
* Pull printed guide.
* Updating neutron section

==API Docs==
* Migration to RST + YAML: sign up for a service on the wiki: https://wiki.openstack.org/wiki/Documentation/Migrate#API_Reference_Plan
* Freeze api-site/api-ref
* Add a redirect to new HTML pages
* API site bug list cleanup: move specific service API ref bugs to project's Launchpad
* Write tutorials!
* Work on "First Application with OpenStack" patches and updates.

==User Guides==
* Work with the Ops Guide to check for duplicated content
* Check for missing content and out of date content - fix links
* Bring new service projects into the User Guides - esp. projects that have info in dev docs that could be moved into the user guide
* IA plan - consistency, links, findability plus tables, code snippets, naming conventions (use contributor guide)

==Docs Tools/Infra==
* Docbook XML tool removal
* OpenStackdocstheme work
* Create cookiecutter template for project-specific install guides
* Config option to mark documents as deprecated (assuming we will work out how to uniformly decide that)
* Get off cloudsite, ability to delete properly. Spec: http://specs.openstack.org/openstack-infra/infra-specs/specs/doc-publishing.html

Documentation/Migrate

2016-05-04T04:01:24Z

Jaegerandi: /* API Reference Plan */

== Doc Migration from DocBook to RST Overview ==
Previously, we migrated the <service>-api repos from DocBook to RST. These were API reference documents that were meant for the contributor developer to know what was going into an API. So, the history of that document was forged as a specification. As projects beyond swift and nova were added, projects made similar documents. They're output to HTML at http://docs.openstack.org/api/api-specs.html. However, as we now have a <project>-specs repo, it makes sense to move to those repos. In that move, also it makes sense to migrate to RST rather than DocBook/WADL.

== Migration Conventions ==

Follow the RST markup conventions in the [http://docs.openstack.org/contributor-guide/rst-conv.html OpenStack Documentation Contributor Guide] .

=== Headings ===

First title in an RST file, use equals signs above and below. Second title, use tilde. Third title, use a series of dashes. Try not to need a Heading 4 if you can help it by rewriting or reorganizing.

<pre>
<nowiki>
========
Heading 1
========

Heading 2
~~~~~~~~~

Heading 3
---------
</nowiki>
</pre>

=== File names ===

As a rule, we want to keep the xml:id identical so that the output HTML files do not need redirection. However, we also at the same time want to get rid of ch_ and section_ nomenclatures while going to a page-based, topical approach. So, first use the XML:ID, and if the XML:ID has ch_ or section_ in it, remove the prefix.

=== Cross references ===

Use :ref: when doing cross references so that you don't have to have the exact title. This means you will have to add markup to create anchors, such as:

<nowiki>

.. _dashboard-project-tab:

</nowiki>

Please use the existing XML:Ids if possible for these cross references.

Also, while intersphinx is an enabled extension for many of the contributor developer docs, we don't have an intersphinx requirement yet for the end user guide or admin user guide. We'll investigate that as we add more guides.

=== Figures and images ===

Store the figures in a /figures/ directory with the deliverable itself.

=== Notes and admonitions ===

If the conversion outputs Note as a heading, change it to use the .. note:: directive.

=== Line numbers in code blocks ===

If your file has lots of code blocks, be sure to set up line numbering for the entire file. Each code-block must have :linenos: after the .. code-block:: directive, the code itself must be indented at the same level as the :lineos: line, and you must have at the start of the file this directive:

<pre><nowiki>
.. highlight: python
:linenothreshold: 5</nowiki></pre>

so that any code-blocks longer than five lines long will have line numbers.

== Migration Issues ==

List of bugs or missing features for the Sphinx template, openstackdocstheme: https://bugs.launchpad.net/openstack-manuals/+bugs?field.tag=openstackdocstheme

Can you have line breaks in something with inline semantic markup like :guilabel: at the end of the line? For example:

<pre>
<nowiki>
#. Select the volume to add to an instance and click :guilabel:`Edit Attachments`.
</nowiki>
</pre>

That line is longer than 79 characters, so Attachments`. must be on the second line, but when you do that, the HTML output is incorrect.

Since RST documents impose a 79 character limit when building files in .rst format. When tables exceed that limit, a list table role can help create content in a new table without exceeding the character limit. The issue is when a table is generated by an OpenStack service, and returned as a result of a command. These tables are constructed with +, -, and | characters. The table created by a list table role has solid lines forming rows, columns, and cells. The content is similar, however users might be surprised by a table with solid lines rather than a table built with +, -, and | characters.

Large scale content inside tables.

When building tables with a list table role, some items that appear inside the table cells might exceed the 79 character limit. Is there a solution to recreating this large scale content in a table such that it does not affect the character limit?

The :orphan: role and references.

Files with an :orphan: role at the top of the file, not included in the toc tree, will not link to another file when the :ref: role is used to link to the file from a different file. Is there a solution to this linking issue?

Pandoc conversion problems.

When converting files with Pandoc, some entries in the .xml file will not convert accurately. Procedure titles and sub section titles will not parse correctly, and will be deleted from the converted document. Pandoc also removes procedure numbering. Currently, the solution is to compare the complete .rst file to the built .xml version, and check the headings, subheadings, and procedure numbers to make sure they are correct, and line up with original. This is an issue that could also be discussed.

*Contact details for RST issues that we can't solve:
** Author: David Goodger
** Contact: docutils-develop@lists.sourceforge.net

== Migration How To ==

'''Note:''' If you don't want to use tox, install these prereqs locally: pip install sphinx; pip install openstackdocstheme and then switch to the directory containing a conf.py and run sphinx-build /path/to/source/ path/to/build/ to get html output by default.

Because Sphinx builds have dependent requirements it is best to work with in a virtual environment. Fortunately the openstack-manuals project already has tox set up so that you can create a virtualenv that contains the required dependencies. To use it, do this on a Mac or Ubuntu machine with Python and pip already installed:

# Clone the openstack-manuals repository.
# Change directories into openstack-manuals.
# Run this:
#: <pre>tox -e py27</pre>
# When you get a congratulations message, run this:
Mac/Ubuntu:
<pre>source .tox/py27/bin/activate</pre>

Windows:
<pre> source .tox/py27/Scripts/activate</pre>

Your prompt should now have (py27) as a preface.

Now you have all the pre-requisites installed and can run additional tox commands. To see the list of commands, view or edit tox.ini in the openstack-manuals directory. To build the RST docs, run:

tox -e docs

This will run sphinx-build doc/playground-user-guide/source/ doc/playground-user-guide/build/html.

When the build is finished, you can open doc/playground-user-guide/build/html/index.html to view the resulting output.

===Migration Using Oxygen===
# Open DocBook book file in Oxygen.
# Choose Document > Transformation > Configure Transformation Scenario(s).
# Select DocBook XHTML - Chunk.
# Click Apply associated (1).
# Within the /out/xhtml-chunks/ directory that's generated, run the following script:
#: <pre>
#:: for i in *.xhtml
#:: do
#:: # Convert from XHTML to RST
#:: file_name=${i%.*l}.rst
#:: pandoc -s -t rst $i -o $file_name
#:: sed -i -e '4,16d' $file_name
#:: sed -i -e '/+--------------------------+$/,$d' $file_name
#:: sed -i -e '$d' $file_name
#:: sed -i -e '$d' $file_name
#:: # Rename file to second line of new RST content, but lowercase and all non-alphanumeric chars renamed to underscores:
#:: real_file_name=$(sed 's/[^a-zA-Z0-9\-]/_/g;2q;d' $file_name | awk '{print tolower($0)}').rst
#:: mv $file_name $real_file_name<pre><nowiki>
#:: # Replace all cross-refs to xhtml files to renamed rst files:
#:: sed -i '' -e "s/\<$i/fixmefixmefixme/g" *.rst
#:: # sed -i '' -e "s/\ fixmefixmefixme.*\`__//g" *.rst
#:: done</pre>
# Clean up where the fixmefixmefixme is output, it indicates where a cross-reference cannot exist any longer.
# Clean up tables where the pandoc conversion just outputs paragraphs.
# Remove numbering from Example titles and Table titles.
# Rename chapter_ files and ensure they are titled to match the contents of the file, such as "Networking API 2.0 Overview" to networking-api-2.0-overview" for example.
# Remove "programlisting" "screen" and "literallayout" from .. code:: lines.
# When commiting conversion patches, include the related blueprint in your commit message. For example:
#: <pre>
#:: Convert ch_compute_focus.xml to RST
#:: Implements: blueprint archguide-mitaka-rst</pre>

===Migration Using a Text Editor===
# Install [http://pandoc.org/installing.html pandoc].
# Update your openstack-manuals master branch, and create a branch.
# Run the pandoc command to convert the .xml file to .rst. For example:
#: <pre>pandoc -f docbook -t rst -s ch_compute_focus.xml -o compute-focus.rst</pre>
# Move converted files to the <guide>/source folder.
# Rename converted RST files and ensure they are titled to match the contents of the file, such as "Networking API 2.0 Overview" to networking-api-2.0-overview" for example.
# Pandoc has its quirks, so check all the content has been migrated from the source file.
# Use a text editor to complete the following tasks:
## Clean up tables where the pandoc conversion just outputs paragraphs.
## Remove numbering from Example titles and Table titles.
## Remove "programlisting" "screen" and "literallayout" from .. code:: lines.
## Check the converted RST file follow conventions described in the [http://docs.openstack.org/contributor-guide/rst-conv.html OpenStack Documentation Contributor Guide]
# Build the guide locally, to check for errors:
#: <pre>tox -e docs</pre>
# Commit your changes, including the related blueprint in your commit message. For example:
#: <pre>
#:: Convert ch_compute_focus.xml to RST
#:: Implements: blueprint archguide-mitaka-rst</pre>

== Doc Migration Plan ==

For the Mitaka release, we migrated the Configuration Reference Guide and the Architecture Design Guide. Refer to the [http://specs.openstack.org/openstack/docs-specs/index.html detailed specification] for details.

=== API Reference Plan ===

See [http://docs.openstack.org/contributor-guide/api-guides.html http://docs.openstack.org/contributor-guide/api-guides.html] for explanation of the process. Anne has already preprocessed the files, so the other migration steps on this wiki page are not needed at all.

Sign up below for a service, then download the files from this patch: https://review.openstack.org/#/c/311596/. These will require a lot of cleanup manually but gets them as far as the tools can get them. Also, setup a job to publish data like https://review.openstack.org/312184.

{| class="wikitable"
|-
! Service name !! Service version !! Project !! Name !! Patch URL !! Status
|-
| Compute || v2.1 || nova || Sean Dague || https://review.openstack.org/#/q/status:merged+project:openstack/nova+branch:master+topic:bp/api-ref-in-rst || In progress
|-
| Identity || v2.0 || keystone || Harry Sutton || ||
|-
| Identity || v3 (and extensions) || keystone || Harry Sutton || ||
|-
| Bare metal || v1 || ironic || Jim Rollenhagen ||https://review.openstack.org/#/c/312181/ and https://review.openstack.org/312184 || In progress
|-
| Block Storage || v1 || cinder || Sheel Rana Insaan || https://review.openstack.org/#/c/312113 || In progress
|-
| Block Storage || v2 || cinder || Sheel Rana Insaan || https://review.openstack.org/#/c/312113 || In progress
|-
| Clustering || v1 || senlin || || ||
|-
| Data Processing || v1.1 || sahara || || ||
|-
| Database || v1.0 || trove || || ||
|-
| Image || v1 || glance || rosmaita || || in progress
|-
| Image || v2 || glance || rosmaita || || in progress
|-
| Networking || v2.0 (and extensions) || neutron || HenryG || ||
|-
| Object Storage || v1 || swift || Anne Gentle || https://review.openstack.org/312315 || In review
|-
| Orchestration || v1 || heat || Jay Dobies (jdob) || ||
|-
| Shared File Systems || v1 || manila || Daniel Gonzalez || || In progress
|-
| Shared File Systems || v2 || manila || Daniel Gonzalez || || In progress
|-
| Telemetry || v2 || ceilometer || || ||
|-

|}

=== Operations Guide ===

Sign up below for a chapter, then create a patch with RST in doc/ops-guide/source for others to review. Contributions are welcome.
Please add "Implements: blueprint ops-guide-rst" in the commit message.

'''''Please make sure this book follows [http://chimera.labs.oreilly.com/books/123000000https://review.openstack.org/#/c/292036/0969/ch02.html O'Reilly conventions].'''''

{| class="wikitable"
|-
! Chapter/Section (old filename) !! Chapter/Section (new filename) !! Name !! Patch URL !! Status
|-
| bk_ops_guide.xml || || || ||
|-
| preface_ops.xml || preface_ops.rst || venkatamahesh || https://review.openstack.org/#/c/292071 || Merged
|-
| part_architecture.xml || part_architecture.rst || venkatamahesh || https://review.openstack.org/#/c/292064 || Merged
|-
| part_operations.xml || operations.rst || KATO Tomoyuki || https://review.openstack.org/#/c/291987/ || Merged
|-
| ch_arch_cloud_controller.xml || ch_arch_cloud_controller.rst || venkatamahesh || https://review.openstack.org/#/c/292061 || Merged
|-
| ch_arch_compute_nodes.xml || ch_arch_compute_nodes.rst || venkatamahesh || https://review.openstack.org/#/c/292059 || Merged
|-
| ch_arch_examples.xml || ch_arch_examples.rst || venkatamahesh || https://review.openstack.org/#/c/292052 || Merged
|-
| section_arch_example-neutron.xml || section_arch_example-neutron.rst || venkatamahesh || https://review.openstack.org/#/c/291965 || Merged
|-
| section_arch_example-nova.xml || section_arch_example-nova.rst || venkatamahesh || https://review.openstack.org/#/c/291783 || Merged
|-
| ch_arch_network_design.xml || ch_arch_network_design.rst || venkatamahesh || https://review.openstack.org/#/c/291974 || Merged
|-
| ch_arch_provision.xml || ch_arch_provision.rst || venkatamahesh || https://review.openstack.org/#/c/291976 || Merged
|-
| ch_arch_scaling.xml || ch_arch_scaling.rst || venkatamahesh || https://review.openstack.org/#/c/291978 || Merged
|-
| ch_arch_storage.xml || ch_arch_storage.rst || venkatamahesh || https://review.openstack.org/#/c/292007 || Merged
|-
| ch_ops_advanced_configuration.xml || ch_ops_advanced_configuration.rst || venkatamahesh || https://review.openstack.org/#/c/292008 || Merged
|-
| ch_ops_backup_recovery.xml || ch_ops_backup_recovery.rst || venkatamahesh || https://review.openstack.org/#/c/292011 || Merged
|-
| ch_ops_customize.xml || ch_ops_customize.rst || venkatamahesh || https://review.openstack.org/#/c/292013 || Merged
|-
| ch_ops_lay_of_land.xml || lay_of_the_land.rst || KATO Tomoyuki || https://review.openstack.org/#/c/291996/ || Merged
|-
| ch_ops_log_monitor.xml || ch_ops_log_monitor.rst || venkatamahesh || https://review.openstack.org/#/c/292015 || Merged
|-
| ch_ops_maintenance.xml || ch_ops_maintenance.rst || venkatamahesh || https://review.openstack.org/#/c/292022 || Merged
|-
| ch_ops_network_troubleshooting.xml || ch_ops_network_troubleshooting.rst || venkatamahesh || https://review.openstack.org/#/c/292027 || Merged
|-
| ch_ops_projects_users.xml || projects_users.rst || KATO Tomoyuki || https://review.openstack.org/#/c/292002/ || Merged
|-
| ch_ops_resources.xml || ch_ops_resources.rst || venkatamahesh || https://review.openstack.org/#/c/292033 || Merged
|-
| ch_ops_upgrades.xml || ch_ops_upgrades.rst || venkatamahesh || https://review.openstack.org/#/c/292035 || Merged
|-
| ch_ops_upstream.xml || ch_ops_upstream.rst || venkatamahesh || https://review.openstack.org/#/c/292036 || Merged
|-
| ch_ops_user_facing.xml || ch_ops_user_facing.rst || venkatamahesh || https://review.openstack.org/#/c/292050 || Merged
|-
|}

== Completing conversion to RST ==

Once we have reviewed the draft guide and think it's ready to publish, we need to do the following steps:

# Create a patch with the following steps (for example, see https://review.openstack.org/#/c/248577/ or https://review.openstack.org/211766)
## Delete the old guide, here security-guide
## Move the RST guide to the location of new guide (security-guide-rst -> security-guide).
## Update tools/build-all-rst.sh for the change
## Delete the entry from doc/pom.xml
## Update RELEASENOTES.rst
## If the repository has no further DocBook guides in it, update tox.ini
## Update doc-tools-check-languages.conf
## Rename localization files to new directory name
## If there is a ".tx/config" file, update it (remove RST guide and update paths)
# If the repository has no further DocBook guides in it:
#* Remove jobs from Jenkins. For example: https://review.openstack.org/211843
#* Cleanup tox.ini. For example: https://review.openstack.org/212127
#* Remove tools/generatepot. For example: https://review.openstack.org/212129
# Update .gitignore. For example: https://review.openstack.org/212685
# If the repository is not the openstack-manuals repo, stop syncing of XML files: https://review.openstack.org/211842 and remove the copied files once that patch is merged: https://review.openstack.org/211904
# Fix links on docs.openstack.org and in other guides: https://review.openstack.org/212044
#* Create redirects from content directory to top-level index.html file
#* Update all links so that they go to new guide (security-guide, not security-guide/content)
#* Remove links to PDF of guide
# Sync translations from old guide with new guide (needs to be done in transifex by Andreas)
# Tell i18n team that conversion is finished and which resource is active.
# Remove old guide and draft RST guides from docs.openstack.org (needs docs.openstack.org admin access)
# Regenerate sitemap.xml after all changes are in: https://review.openstack.org/212689 and blacklist the change: https://review.openstack.org/212690

----
[[Category:Documentation]]

Documentation/Migrate

2016-05-03T18:37:18Z

Jaegerandi: /* API Reference Plan */ Add ironic

== Doc Migration from DocBook to RST Overview ==
Previously, we migrated the <service>-api repos from DocBook to RST. These were API reference documents that were meant for the contributor developer to know what was going into an API. So, the history of that document was forged as a specification. As projects beyond swift and nova were added, projects made similar documents. They're output to HTML at http://docs.openstack.org/api/api-specs.html. However, as we now have a <project>-specs repo, it makes sense to move to those repos. In that move, also it makes sense to migrate to RST rather than DocBook/WADL.

== Migration Conventions ==

Follow the RST markup conventions in the [http://docs.openstack.org/contributor-guide/rst-conv.html OpenStack Documentation Contributor Guide] .

=== Headings ===

First title in an RST file, use equals signs above and below. Second title, use tilde. Third title, use a series of dashes. Try not to need a Heading 4 if you can help it by rewriting or reorganizing.

<pre>
<nowiki>
========
Heading 1
========

Heading 2
~~~~~~~~~

Heading 3
---------
</nowiki>
</pre>

=== File names ===

As a rule, we want to keep the xml:id identical so that the output HTML files do not need redirection. However, we also at the same time want to get rid of ch_ and section_ nomenclatures while going to a page-based, topical approach. So, first use the XML:ID, and if the XML:ID has ch_ or section_ in it, remove the prefix.

=== Cross references ===

Use :ref: when doing cross references so that you don't have to have the exact title. This means you will have to add markup to create anchors, such as:

<nowiki>

.. _dashboard-project-tab:

</nowiki>

Please use the existing XML:Ids if possible for these cross references.

Also, while intersphinx is an enabled extension for many of the contributor developer docs, we don't have an intersphinx requirement yet for the end user guide or admin user guide. We'll investigate that as we add more guides.

=== Figures and images ===

Store the figures in a /figures/ directory with the deliverable itself.

=== Notes and admonitions ===

If the conversion outputs Note as a heading, change it to use the .. note:: directive.

=== Line numbers in code blocks ===

If your file has lots of code blocks, be sure to set up line numbering for the entire file. Each code-block must have :linenos: after the .. code-block:: directive, the code itself must be indented at the same level as the :lineos: line, and you must have at the start of the file this directive:

<pre><nowiki>
.. highlight: python
:linenothreshold: 5</nowiki></pre>

so that any code-blocks longer than five lines long will have line numbers.

== Migration Issues ==

List of bugs or missing features for the Sphinx template, openstackdocstheme: https://bugs.launchpad.net/openstack-manuals/+bugs?field.tag=openstackdocstheme

Can you have line breaks in something with inline semantic markup like :guilabel: at the end of the line? For example:

<pre>
<nowiki>
#. Select the volume to add to an instance and click :guilabel:`Edit Attachments`.
</nowiki>
</pre>

That line is longer than 79 characters, so Attachments`. must be on the second line, but when you do that, the HTML output is incorrect.

Since RST documents impose a 79 character limit when building files in .rst format. When tables exceed that limit, a list table role can help create content in a new table without exceeding the character limit. The issue is when a table is generated by an OpenStack service, and returned as a result of a command. These tables are constructed with +, -, and | characters. The table created by a list table role has solid lines forming rows, columns, and cells. The content is similar, however users might be surprised by a table with solid lines rather than a table built with +, -, and | characters.

Large scale content inside tables.

When building tables with a list table role, some items that appear inside the table cells might exceed the 79 character limit. Is there a solution to recreating this large scale content in a table such that it does not affect the character limit?

The :orphan: role and references.

Files with an :orphan: role at the top of the file, not included in the toc tree, will not link to another file when the :ref: role is used to link to the file from a different file. Is there a solution to this linking issue?

Pandoc conversion problems.

When converting files with Pandoc, some entries in the .xml file will not convert accurately. Procedure titles and sub section titles will not parse correctly, and will be deleted from the converted document. Pandoc also removes procedure numbering. Currently, the solution is to compare the complete .rst file to the built .xml version, and check the headings, subheadings, and procedure numbers to make sure they are correct, and line up with original. This is an issue that could also be discussed.

*Contact details for RST issues that we can't solve:
** Author: David Goodger
** Contact: docutils-develop@lists.sourceforge.net

== Migration How To ==

'''Note:''' If you don't want to use tox, install these prereqs locally: pip install sphinx; pip install openstackdocstheme and then switch to the directory containing a conf.py and run sphinx-build /path/to/source/ path/to/build/ to get html output by default.

Because Sphinx builds have dependent requirements it is best to work with in a virtual environment. Fortunately the openstack-manuals project already has tox set up so that you can create a virtualenv that contains the required dependencies. To use it, do this on a Mac or Ubuntu machine with Python and pip already installed:

# Clone the openstack-manuals repository.
# Change directories into openstack-manuals.
# Run this:
#: <pre>tox -e py27</pre>
# When you get a congratulations message, run this:
Mac/Ubuntu:
<pre>source .tox/py27/bin/activate</pre>

Windows:
<pre> source .tox/py27/Scripts/activate</pre>

Your prompt should now have (py27) as a preface.

Now you have all the pre-requisites installed and can run additional tox commands. To see the list of commands, view or edit tox.ini in the openstack-manuals directory. To build the RST docs, run:

tox -e docs

This will run sphinx-build doc/playground-user-guide/source/ doc/playground-user-guide/build/html.

When the build is finished, you can open doc/playground-user-guide/build/html/index.html to view the resulting output.

===Migration Using Oxygen===
# Open DocBook book file in Oxygen.
# Choose Document > Transformation > Configure Transformation Scenario(s).
# Select DocBook XHTML - Chunk.
# Click Apply associated (1).
# Within the /out/xhtml-chunks/ directory that's generated, run the following script:
#: <pre>
#:: for i in *.xhtml
#:: do
#:: # Convert from XHTML to RST
#:: file_name=${i%.*l}.rst
#:: pandoc -s -t rst $i -o $file_name
#:: sed -i -e '4,16d' $file_name
#:: sed -i -e '/+--------------------------+$/,$d' $file_name
#:: sed -i -e '$d' $file_name
#:: sed -i -e '$d' $file_name
#:: # Rename file to second line of new RST content, but lowercase and all non-alphanumeric chars renamed to underscores:
#:: real_file_name=$(sed 's/[^a-zA-Z0-9\-]/_/g;2q;d' $file_name | awk '{print tolower($0)}').rst
#:: mv $file_name $real_file_name<pre><nowiki>
#:: # Replace all cross-refs to xhtml files to renamed rst files:
#:: sed -i '' -e "s/\<$i/fixmefixmefixme/g" *.rst
#:: # sed -i '' -e "s/\ fixmefixmefixme.*\`__//g" *.rst
#:: done</pre>
# Clean up where the fixmefixmefixme is output, it indicates where a cross-reference cannot exist any longer.
# Clean up tables where the pandoc conversion just outputs paragraphs.
# Remove numbering from Example titles and Table titles.
# Rename chapter_ files and ensure they are titled to match the contents of the file, such as "Networking API 2.0 Overview" to networking-api-2.0-overview" for example.
# Remove "programlisting" "screen" and "literallayout" from .. code:: lines.
# When commiting conversion patches, include the related blueprint in your commit message. For example:
#: <pre>
#:: Convert ch_compute_focus.xml to RST
#:: Implements: blueprint archguide-mitaka-rst</pre>

===Migration Using a Text Editor===
# Install [http://pandoc.org/installing.html pandoc].
# Update your openstack-manuals master branch, and create a branch.
# Run the pandoc command to convert the .xml file to .rst. For example:
#: <pre>pandoc -f docbook -t rst -s ch_compute_focus.xml -o compute-focus.rst</pre>
# Move converted files to the <guide>/source folder.
# Rename converted RST files and ensure they are titled to match the contents of the file, such as "Networking API 2.0 Overview" to networking-api-2.0-overview" for example.
# Pandoc has its quirks, so check all the content has been migrated from the source file.
# Use a text editor to complete the following tasks:
## Clean up tables where the pandoc conversion just outputs paragraphs.
## Remove numbering from Example titles and Table titles.
## Remove "programlisting" "screen" and "literallayout" from .. code:: lines.
## Check the converted RST file follow conventions described in the [http://docs.openstack.org/contributor-guide/rst-conv.html OpenStack Documentation Contributor Guide]
# Build the guide locally, to check for errors:
#: <pre>tox -e docs</pre>
# Commit your changes, including the related blueprint in your commit message. For example:
#: <pre>
#:: Convert ch_compute_focus.xml to RST
#:: Implements: blueprint archguide-mitaka-rst</pre>

== Doc Migration Plan ==

For the Mitaka release, we migrated the Configuration Reference Guide and the Architecture Design Guide. Refer to the [http://specs.openstack.org/openstack/docs-specs/index.html detailed specification] for details.

=== API Reference Plan ===

See [http://docs.openstack.org/contributor-guide/api-guides.html http://docs.openstack.org/contributor-guide/api-guides.html] for explanation of the process. Anne has already preprocessed the files, so the other migration steps on this wiki page are not needed at all.

Sign up below for a service, then download the files from this patch: https://review.openstack.org/#/c/311596/. These will require a lot of cleanup manually but gets them as far as the tools can get them.

{| class="wikitable"
|-
! Service name !! Service version !! Project !! Name !! Patch URL !! Status
|-
| Compute || v2.1 || nova || Sean Dague || https://review.openstack.org/#/q/status:merged+project:openstack/nova+branch:master+topic:bp/api-ref-in-rst || In progress
|-
| Identity || v2.0 || keystone || Harry Sutton || ||
|-
| Identity || v3 (and extensions) || keystone || Harry Sutton || ||
|-
| Bare metal || v1 || ironic || Jim Rollenhagen ||https://review.openstack.org/#/c/312181/ and https://review.openstack.org/312184 || In progress
|-
| Block Storage || v1 || cinder || Sheel Rana Insaan || https://review.openstack.org/#/c/312113 || In progress
|-
| Block Storage || v2 || cinder || Sheel Rana Insaan || https://review.openstack.org/#/c/312113 || In progress
|-
| Clustering || v1 || senlin || || ||
|-
| Data Processing || v1.1 || sahara || || ||
|-
| Database || v1.0 || trove || || ||
|-
| Image || v1 || glance || rosmaita || || in progress
|-
| Image || v2 || glance || rosmaita || || in progress
|-
| Networking || v2.0 (and extensions) || neutron || HenryG || ||
|-
| Object Storage || v1 || swift || || ||
|-
| Orchestration || v1 || heat || Jay Dobies (jdob) || ||
|-
| Shared File Systems || v1 || manila || Daniel Gonzalez || || In progress
|-
| Shared File Systems || v2 || manila || Daniel Gonzalez || || In progress
|-
| Telemetry || v2 || ceilometer || || ||
|-

|}

=== Operations Guide ===

Sign up below for a chapter, then create a patch with RST in doc/ops-guide/source for others to review. Contributions are welcome.
Please add "Implements: blueprint ops-guide-rst" in the commit message.

'''''Please make sure this book follows [http://chimera.labs.oreilly.com/books/123000000https://review.openstack.org/#/c/292036/0969/ch02.html O'Reilly conventions].'''''

{| class="wikitable"
|-
! Chapter/Section (old filename) !! Chapter/Section (new filename) !! Name !! Patch URL !! Status
|-
| bk_ops_guide.xml || || || ||
|-
| preface_ops.xml || preface_ops.rst || venkatamahesh || https://review.openstack.org/#/c/292071 || Merged
|-
| part_architecture.xml || part_architecture.rst || venkatamahesh || https://review.openstack.org/#/c/292064 || Merged
|-
| part_operations.xml || operations.rst || KATO Tomoyuki || https://review.openstack.org/#/c/291987/ || Merged
|-
| ch_arch_cloud_controller.xml || ch_arch_cloud_controller.rst || venkatamahesh || https://review.openstack.org/#/c/292061 || Merged
|-
| ch_arch_compute_nodes.xml || ch_arch_compute_nodes.rst || venkatamahesh || https://review.openstack.org/#/c/292059 || Merged
|-
| ch_arch_examples.xml || ch_arch_examples.rst || venkatamahesh || https://review.openstack.org/#/c/292052 || Merged
|-
| section_arch_example-neutron.xml || section_arch_example-neutron.rst || venkatamahesh || https://review.openstack.org/#/c/291965 || Merged
|-
| section_arch_example-nova.xml || section_arch_example-nova.rst || venkatamahesh || https://review.openstack.org/#/c/291783 || Merged
|-
| ch_arch_network_design.xml || ch_arch_network_design.rst || venkatamahesh || https://review.openstack.org/#/c/291974 || Merged
|-
| ch_arch_provision.xml || ch_arch_provision.rst || venkatamahesh || https://review.openstack.org/#/c/291976 || Merged
|-
| ch_arch_scaling.xml || ch_arch_scaling.rst || venkatamahesh || https://review.openstack.org/#/c/291978 || Merged
|-
| ch_arch_storage.xml || ch_arch_storage.rst || venkatamahesh || https://review.openstack.org/#/c/292007 || Merged
|-
| ch_ops_advanced_configuration.xml || ch_ops_advanced_configuration.rst || venkatamahesh || https://review.openstack.org/#/c/292008 || Merged
|-
| ch_ops_backup_recovery.xml || ch_ops_backup_recovery.rst || venkatamahesh || https://review.openstack.org/#/c/292011 || Merged
|-
| ch_ops_customize.xml || ch_ops_customize.rst || venkatamahesh || https://review.openstack.org/#/c/292013 || Merged
|-
| ch_ops_lay_of_land.xml || lay_of_the_land.rst || KATO Tomoyuki || https://review.openstack.org/#/c/291996/ || Merged
|-
| ch_ops_log_monitor.xml || ch_ops_log_monitor.rst || venkatamahesh || https://review.openstack.org/#/c/292015 || Merged
|-
| ch_ops_maintenance.xml || ch_ops_maintenance.rst || venkatamahesh || https://review.openstack.org/#/c/292022 || Merged
|-
| ch_ops_network_troubleshooting.xml || ch_ops_network_troubleshooting.rst || venkatamahesh || https://review.openstack.org/#/c/292027 || Merged
|-
| ch_ops_projects_users.xml || projects_users.rst || KATO Tomoyuki || https://review.openstack.org/#/c/292002/ || Merged
|-
| ch_ops_resources.xml || ch_ops_resources.rst || venkatamahesh || https://review.openstack.org/#/c/292033 || Merged
|-
| ch_ops_upgrades.xml || ch_ops_upgrades.rst || venkatamahesh || https://review.openstack.org/#/c/292035 || Merged
|-
| ch_ops_upstream.xml || ch_ops_upstream.rst || venkatamahesh || https://review.openstack.org/#/c/292036 || Merged
|-
| ch_ops_user_facing.xml || ch_ops_user_facing.rst || venkatamahesh || https://review.openstack.org/#/c/292050 || Merged
|-
|}

== Completing conversion to RST ==

Once we have reviewed the draft guide and think it's ready to publish, we need to do the following steps:

# Create a patch with the following steps (for example, see https://review.openstack.org/#/c/248577/ or https://review.openstack.org/211766)
## Delete the old guide, here security-guide
## Move the RST guide to the location of new guide (security-guide-rst -> security-guide).
## Update tools/build-all-rst.sh for the change
## Delete the entry from doc/pom.xml
## Update RELEASENOTES.rst
## If the repository has no further DocBook guides in it, update tox.ini
## Update doc-tools-check-languages.conf
## Rename localization files to new directory name
## If there is a ".tx/config" file, update it (remove RST guide and update paths)
# If the repository has no further DocBook guides in it:
#* Remove jobs from Jenkins. For example: https://review.openstack.org/211843
#* Cleanup tox.ini. For example: https://review.openstack.org/212127
#* Remove tools/generatepot. For example: https://review.openstack.org/212129
# Update .gitignore. For example: https://review.openstack.org/212685
# If the repository is not the openstack-manuals repo, stop syncing of XML files: https://review.openstack.org/211842 and remove the copied files once that patch is merged: https://review.openstack.org/211904
# Fix links on docs.openstack.org and in other guides: https://review.openstack.org/212044
#* Create redirects from content directory to top-level index.html file
#* Update all links so that they go to new guide (security-guide, not security-guide/content)
#* Remove links to PDF of guide
# Sync translations from old guide with new guide (needs to be done in transifex by Andreas)
# Tell i18n team that conversion is finished and which resource is active.
# Remove old guide and draft RST guides from docs.openstack.org (needs docs.openstack.org admin access)
# Regenerate sitemap.xml after all changes are in: https://review.openstack.org/212689 and blacklist the change: https://review.openstack.org/212690

----
[[Category:Documentation]]

Documentation/Migrate

2016-05-03T15:10:06Z

Jaegerandi: /* API Reference Plan */

== Doc Migration from DocBook to RST Overview ==
Previously, we migrated the <service>-api repos from DocBook to RST. These were API reference documents that were meant for the contributor developer to know what was going into an API. So, the history of that document was forged as a specification. As projects beyond swift and nova were added, projects made similar documents. They're output to HTML at http://docs.openstack.org/api/api-specs.html. However, as we now have a <project>-specs repo, it makes sense to move to those repos. In that move, also it makes sense to migrate to RST rather than DocBook/WADL.

== Migration Conventions ==

Follow the RST markup conventions in the [http://docs.openstack.org/contributor-guide/rst-conv.html OpenStack Documentation Contributor Guide] .

=== Headings ===

First title in an RST file, use equals signs above and below. Second title, use tilde. Third title, use a series of dashes. Try not to need a Heading 4 if you can help it by rewriting or reorganizing.

<pre>
<nowiki>
========
Heading 1
========

Heading 2
~~~~~~~~~

Heading 3
---------
</nowiki>
</pre>

=== File names ===

As a rule, we want to keep the xml:id identical so that the output HTML files do not need redirection. However, we also at the same time want to get rid of ch_ and section_ nomenclatures while going to a page-based, topical approach. So, first use the XML:ID, and if the XML:ID has ch_ or section_ in it, remove the prefix.

=== Cross references ===

Use :ref: when doing cross references so that you don't have to have the exact title. This means you will have to add markup to create anchors, such as:

<nowiki>

.. _dashboard-project-tab:

</nowiki>

Please use the existing XML:Ids if possible for these cross references.

Also, while intersphinx is an enabled extension for many of the contributor developer docs, we don't have an intersphinx requirement yet for the end user guide or admin user guide. We'll investigate that as we add more guides.

=== Figures and images ===

Store the figures in a /figures/ directory with the deliverable itself.

=== Notes and admonitions ===

If the conversion outputs Note as a heading, change it to use the .. note:: directive.

=== Line numbers in code blocks ===

If your file has lots of code blocks, be sure to set up line numbering for the entire file. Each code-block must have :linenos: after the .. code-block:: directive, the code itself must be indented at the same level as the :lineos: line, and you must have at the start of the file this directive:

<pre><nowiki>
.. highlight: python
:linenothreshold: 5</nowiki></pre>

so that any code-blocks longer than five lines long will have line numbers.

== Migration Issues ==

List of bugs or missing features for the Sphinx template, openstackdocstheme: https://bugs.launchpad.net/openstack-manuals/+bugs?field.tag=openstackdocstheme

Can you have line breaks in something with inline semantic markup like :guilabel: at the end of the line? For example:

<pre>
<nowiki>
#. Select the volume to add to an instance and click :guilabel:`Edit Attachments`.
</nowiki>
</pre>

That line is longer than 79 characters, so Attachments`. must be on the second line, but when you do that, the HTML output is incorrect.

Since RST documents impose a 79 character limit when building files in .rst format. When tables exceed that limit, a list table role can help create content in a new table without exceeding the character limit. The issue is when a table is generated by an OpenStack service, and returned as a result of a command. These tables are constructed with +, -, and | characters. The table created by a list table role has solid lines forming rows, columns, and cells. The content is similar, however users might be surprised by a table with solid lines rather than a table built with +, -, and | characters.

Large scale content inside tables.

When building tables with a list table role, some items that appear inside the table cells might exceed the 79 character limit. Is there a solution to recreating this large scale content in a table such that it does not affect the character limit?

The :orphan: role and references.

Files with an :orphan: role at the top of the file, not included in the toc tree, will not link to another file when the :ref: role is used to link to the file from a different file. Is there a solution to this linking issue?

Pandoc conversion problems.

When converting files with Pandoc, some entries in the .xml file will not convert accurately. Procedure titles and sub section titles will not parse correctly, and will be deleted from the converted document. Pandoc also removes procedure numbering. Currently, the solution is to compare the complete .rst file to the built .xml version, and check the headings, subheadings, and procedure numbers to make sure they are correct, and line up with original. This is an issue that could also be discussed.

*Contact details for RST issues that we can't solve:
** Author: David Goodger
** Contact: docutils-develop@lists.sourceforge.net

== Migration How To ==

'''Note:''' If you don't want to use tox, install these prereqs locally: pip install sphinx; pip install openstackdocstheme and then switch to the directory containing a conf.py and run sphinx-build /path/to/source/ path/to/build/ to get html output by default.

Because Sphinx builds have dependent requirements it is best to work with in a virtual environment. Fortunately the openstack-manuals project already has tox set up so that you can create a virtualenv that contains the required dependencies. To use it, do this on a Mac or Ubuntu machine with Python and pip already installed:

# Clone the openstack-manuals repository.
# Change directories into openstack-manuals.
# Run this:
#: <pre>tox -e py27</pre>
# When you get a congratulations message, run this:
Mac/Ubuntu:
<pre>source .tox/py27/bin/activate</pre>

Windows:
<pre> source .tox/py27/Scripts/activate</pre>

Your prompt should now have (py27) as a preface.

Now you have all the pre-requisites installed and can run additional tox commands. To see the list of commands, view or edit tox.ini in the openstack-manuals directory. To build the RST docs, run:

tox -e docs

This will run sphinx-build doc/playground-user-guide/source/ doc/playground-user-guide/build/html.

When the build is finished, you can open doc/playground-user-guide/build/html/index.html to view the resulting output.

===Migration Using Oxygen===
# Open DocBook book file in Oxygen.
# Choose Document > Transformation > Configure Transformation Scenario(s).
# Select DocBook XHTML - Chunk.
# Click Apply associated (1).
# Within the /out/xhtml-chunks/ directory that's generated, run the following script:
#: <pre>
#:: for i in *.xhtml
#:: do
#:: # Convert from XHTML to RST
#:: file_name=${i%.*l}.rst
#:: pandoc -s -t rst $i -o $file_name
#:: sed -i -e '4,16d' $file_name
#:: sed -i -e '/+--------------------------+$/,$d' $file_name
#:: sed -i -e '$d' $file_name
#:: sed -i -e '$d' $file_name
#:: # Rename file to second line of new RST content, but lowercase and all non-alphanumeric chars renamed to underscores:
#:: real_file_name=$(sed 's/[^a-zA-Z0-9\-]/_/g;2q;d' $file_name | awk '{print tolower($0)}').rst
#:: mv $file_name $real_file_name<pre><nowiki>
#:: # Replace all cross-refs to xhtml files to renamed rst files:
#:: sed -i '' -e "s/\<$i/fixmefixmefixme/g" *.rst
#:: # sed -i '' -e "s/\ fixmefixmefixme.*\`__//g" *.rst
#:: done</pre>
# Clean up where the fixmefixmefixme is output, it indicates where a cross-reference cannot exist any longer.
# Clean up tables where the pandoc conversion just outputs paragraphs.
# Remove numbering from Example titles and Table titles.
# Rename chapter_ files and ensure they are titled to match the contents of the file, such as "Networking API 2.0 Overview" to networking-api-2.0-overview" for example.
# Remove "programlisting" "screen" and "literallayout" from .. code:: lines.
# When commiting conversion patches, include the related blueprint in your commit message. For example:
#: <pre>
#:: Convert ch_compute_focus.xml to RST
#:: Implements: blueprint archguide-mitaka-rst</pre>

===Migration Using a Text Editor===
# Install [http://pandoc.org/installing.html pandoc].
# Update your openstack-manuals master branch, and create a branch.
# Run the pandoc command to convert the .xml file to .rst. For example:
#: <pre>pandoc -f docbook -t rst -s ch_compute_focus.xml -o compute-focus.rst</pre>
# Move converted files to the <guide>/source folder.
# Rename converted RST files and ensure they are titled to match the contents of the file, such as "Networking API 2.0 Overview" to networking-api-2.0-overview" for example.
# Pandoc has its quirks, so check all the content has been migrated from the source file.
# Use a text editor to complete the following tasks:
## Clean up tables where the pandoc conversion just outputs paragraphs.
## Remove numbering from Example titles and Table titles.
## Remove "programlisting" "screen" and "literallayout" from .. code:: lines.
## Check the converted RST file follow conventions described in the [http://docs.openstack.org/contributor-guide/rst-conv.html OpenStack Documentation Contributor Guide]
# Build the guide locally, to check for errors:
#: <pre>tox -e docs</pre>
# Commit your changes, including the related blueprint in your commit message. For example:
#: <pre>
#:: Convert ch_compute_focus.xml to RST
#:: Implements: blueprint archguide-mitaka-rst</pre>

== Doc Migration Plan ==

For the Mitaka release, we migrated the Configuration Reference Guide and the Architecture Design Guide. Refer to the [http://specs.openstack.org/openstack/docs-specs/index.html detailed specification] for details.

=== API Reference Plan ===

See [http://docs.openstack.org/contributor-guide/api-guides.html http://docs.openstack.org/contributor-guide/api-guides.html] for explanation of the process. Anne has already preprocessed the files, so the other migration steps on this wiki page are not needed at all.

Sign up below for a service, then download the files from this patch: https://review.openstack.org/#/c/311596/. These will require a lot of cleanup manually but gets them as far as the tools can get them.

{| class="wikitable"
|-
! Service name !! Service version !! Project !! Name !! Patch URL !! Status
|-
| Compute || v2.1 || nova || Sean Dague || https://review.openstack.org/#/q/status:merged+project:openstack/nova+branch:master+topic:bp/api-ref-in-rst || In progress
|-
| Identity || v2.0 || keystone || Harry Sutton || ||
|-
| Identity || v3 (and extensions) || keystone || Harry Sutton || ||
|-
| Bare metal || v1 || ironic || || ||
|-
| Block Storage || v1 || cinder || Sheel Rana Insaan || ||
|-
| Block Storage || v2 || cinder || Sheel Rana Insaan || ||
|-
| Clustering || v1 || senlin || || ||
|-
| Data Processing || v1.1 || sahara || || ||
|-
| Database || v1.0 || trove || || ||
|-
| Image || v1 || glance || rosmaita || || in progress
|-
| Image || v2 || glance || rosmaita || || in progress
|-
| Networking || v2.0 (and extensions) || neutron || HenryG || ||
|-
| Object Storage || v1 || swift || || ||
|-
| Orchestration || v1 || heat || || ||
|-
| Shared File Systems || v1 || manila || Daniel Gonzalez || || In progress
|-
| Shared File Systems || v2 || manila || Daniel Gonzalez || || In progress
|-
| Telemetry || v2 || ceilometer || || ||
|-

|}

=== Operations Guide ===

Sign up below for a chapter, then create a patch with RST in doc/ops-guide/source for others to review. Contributions are welcome.
Please add "Implements: blueprint ops-guide-rst" in the commit message.

'''''Please make sure this book follows [http://chimera.labs.oreilly.com/books/123000000https://review.openstack.org/#/c/292036/0969/ch02.html O'Reilly conventions].'''''

{| class="wikitable"
|-
! Chapter/Section (old filename) !! Chapter/Section (new filename) !! Name !! Patch URL !! Status
|-
| bk_ops_guide.xml || || || ||
|-
| preface_ops.xml || preface_ops.rst || venkatamahesh || https://review.openstack.org/#/c/292071 || Merged
|-
| part_architecture.xml || part_architecture.rst || venkatamahesh || https://review.openstack.org/#/c/292064 || Merged
|-
| part_operations.xml || operations.rst || KATO Tomoyuki || https://review.openstack.org/#/c/291987/ || Merged
|-
| ch_arch_cloud_controller.xml || ch_arch_cloud_controller.rst || venkatamahesh || https://review.openstack.org/#/c/292061 || Merged
|-
| ch_arch_compute_nodes.xml || ch_arch_compute_nodes.rst || venkatamahesh || https://review.openstack.org/#/c/292059 || Merged
|-
| ch_arch_examples.xml || ch_arch_examples.rst || venkatamahesh || https://review.openstack.org/#/c/292052 || Merged
|-
| section_arch_example-neutron.xml || section_arch_example-neutron.rst || venkatamahesh || https://review.openstack.org/#/c/291965 || Merged
|-
| section_arch_example-nova.xml || section_arch_example-nova.rst || venkatamahesh || https://review.openstack.org/#/c/291783 || Merged
|-
| ch_arch_network_design.xml || ch_arch_network_design.rst || venkatamahesh || https://review.openstack.org/#/c/291974 || Merged
|-
| ch_arch_provision.xml || ch_arch_provision.rst || venkatamahesh || https://review.openstack.org/#/c/291976 || Merged
|-
| ch_arch_scaling.xml || ch_arch_scaling.rst || venkatamahesh || https://review.openstack.org/#/c/291978 || Merged
|-
| ch_arch_storage.xml || ch_arch_storage.rst || venkatamahesh || https://review.openstack.org/#/c/292007 || Merged
|-
| ch_ops_advanced_configuration.xml || ch_ops_advanced_configuration.rst || venkatamahesh || https://review.openstack.org/#/c/292008 || Merged
|-
| ch_ops_backup_recovery.xml || ch_ops_backup_recovery.rst || venkatamahesh || https://review.openstack.org/#/c/292011 || Merged
|-
| ch_ops_customize.xml || ch_ops_customize.rst || venkatamahesh || https://review.openstack.org/#/c/292013 || Merged
|-
| ch_ops_lay_of_land.xml || lay_of_the_land.rst || KATO Tomoyuki || https://review.openstack.org/#/c/291996/ || Merged
|-
| ch_ops_log_monitor.xml || ch_ops_log_monitor.rst || venkatamahesh || https://review.openstack.org/#/c/292015 || Merged
|-
| ch_ops_maintenance.xml || ch_ops_maintenance.rst || venkatamahesh || https://review.openstack.org/#/c/292022 || Merged
|-
| ch_ops_network_troubleshooting.xml || ch_ops_network_troubleshooting.rst || venkatamahesh || https://review.openstack.org/#/c/292027 || Merged
|-
| ch_ops_projects_users.xml || projects_users.rst || KATO Tomoyuki || https://review.openstack.org/#/c/292002/ || Merged
|-
| ch_ops_resources.xml || ch_ops_resources.rst || venkatamahesh || https://review.openstack.org/#/c/292033 || Merged
|-
| ch_ops_upgrades.xml || ch_ops_upgrades.rst || venkatamahesh || https://review.openstack.org/#/c/292035 || Merged
|-
| ch_ops_upstream.xml || ch_ops_upstream.rst || venkatamahesh || https://review.openstack.org/#/c/292036 || Merged
|-
| ch_ops_user_facing.xml || ch_ops_user_facing.rst || venkatamahesh || https://review.openstack.org/#/c/292050 || Merged
|-
|}

== Completing conversion to RST ==

Once we have reviewed the draft guide and think it's ready to publish, we need to do the following steps:

# Create a patch with the following steps (for example, see https://review.openstack.org/#/c/248577/ or https://review.openstack.org/211766)
## Delete the old guide, here security-guide
## Move the RST guide to the location of new guide (security-guide-rst -> security-guide).
## Update tools/build-all-rst.sh for the change
## Delete the entry from doc/pom.xml
## Update RELEASENOTES.rst
## If the repository has no further DocBook guides in it, update tox.ini
## Update doc-tools-check-languages.conf
## Rename localization files to new directory name
## If there is a ".tx/config" file, update it (remove RST guide and update paths)
# If the repository has no further DocBook guides in it:
#* Remove jobs from Jenkins. For example: https://review.openstack.org/211843
#* Cleanup tox.ini. For example: https://review.openstack.org/212127
#* Remove tools/generatepot. For example: https://review.openstack.org/212129
# Update .gitignore. For example: https://review.openstack.org/212685
# If the repository is not the openstack-manuals repo, stop syncing of XML files: https://review.openstack.org/211842 and remove the copied files once that patch is merged: https://review.openstack.org/211904
# Fix links on docs.openstack.org and in other guides: https://review.openstack.org/212044
#* Create redirects from content directory to top-level index.html file
#* Update all links so that they go to new guide (security-guide, not security-guide/content)
#* Remove links to PDF of guide
# Sync translations from old guide with new guide (needs to be done in transifex by Andreas)
# Tell i18n team that conversion is finished and which resource is active.
# Remove old guide and draft RST guides from docs.openstack.org (needs docs.openstack.org admin access)
# Regenerate sitemap.xml after all changes are in: https://review.openstack.org/212689 and blacklist the change: https://review.openstack.org/212690

----
[[Category:Documentation]]

Documentation/WhatsUpDoc

2016-05-02T09:00:55Z

Jaegerandi: /* Your suggestions for content */

= Documentation Newsletters =
This is where I draft the 'What's Up, Doc?' documentation newsletters. The newsletter is distributed every Friday (ish), to the openstack-docs mailing list. If you want to be added to the distribution list, or have content to add, please edit these sections:

==== Distribution List ====
* OpenStack Docs Mailing List <Openstack-docs@lists.openstack.org>
* OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
* Docs liaisons (from https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation)
* i18n List <openstack-i18n@lists.openstack.org>

==== Your suggestions for content ====
* Your
* Content
* Here
* The operations-guide repository is now frozen. The content is converted to RST and now part of the openstack-manuals repository. Last cleanup edits are ongoing before the RST version gets published.
* The api reference content is moving from api-site to project specific repositories and is now (double check!) frozen. Documentation on how to migrate is available at XXX.
* The docs toolchain is removing DocBook XML support, see spec https://review.openstack.org/311698 for details.
* Mobile apps are now available. Don’t delay - download and build your personal schedule now for the best performance! iOS / Apple: https://itunes.apple.com/us/app/openstack-foundation-summit/id1071261846?mt=8 and Google Play / Android: https://play.google.com/store/apps/details?id=org.openstack.android.summit

==== Looking for older editions? ====
You can see older newsletters here: [[Documentation/WhatsUpDoc_Archive]]

= 1 April 2016 =

Hi everyone,

While it was very tempting to write something something shocking here for April Fools', I thought everyone might have already had their heart rate raised enough by the fact that Mitaka is only five days away! This will be my final docs newsletter before the release, and the docs are in great shape ready to go out.

I would like to sincerely thank Andreas and our release managers Brian and Olga, not only for the hard work they've done so far, but also for holding down the fort over the next few days while I'm out of contact. Please remember to contact them directly if you have any last minute documentation fires that need putting out. I'd also like to mention the hard work that the Installation Guide testers have been putting in over the past couple of weeks. The testing matrix is looking very green (https://wiki.openstack.org/wiki/Documentation/MitakaDocTesting) and I'm confident that we'll get the Mitaka guide out fully tested and on schedule.

Don't forget you can check release progress on the etherpad here: https://etherpad.openstack.org/p/MitakaRelease

== Progress towards Mitaka ==

5 days to go!

558 bugs closed so far for this release.

Docs Testing
* https://wiki.openstack.org/wiki/Documentation/MitakaDocTesting
* Only a few items left to check off, at this stage we're good to publish the Ubuntu, RDO, and Suse guides on release day.

Release Tasks:
* Release planning occurs in our etherpad here: https://etherpad.openstack.org/p/MitakaRelease
* All tasks that should be completed at this stage are done, and we're on track to start the release process in the 24-48 hours before the release drops.
* Release notes for the docs project are in a "reno-style" directory in the openstack-manuals repo. This directory is not being managed by Reno, however, so please propose patches to it directly.

== The Road to Austin ==

* First of all, thanks for the amazing feedback on what docs sessions you would like to see at the Austin Design Summit! We have filled our entire allocation (and then some), and the schedule so far is here: https://etherpad.openstack.org/p/Newton-DocsSessions
* There's been a really robust and exciting conversation about the Install Guide on the dev list over the past week or so, which I have been following closely. If you're interested in overhauling our Install Guide (and it certainly seems like a lot of people are!), then please make sure you add our Install Guide Design Summit session to your agenda. It is on Wednesday at 11:50, so placed so that it can run over into lunchtime if required.
* A note for those who noticed the Ops guide omission: this should take place in the Ops track, and I'll let you know when that session will be.

== Doc team meeting ==

Next meetings:

The US meeting was held this week, you can read the minutes here: https://wiki.openstack.org/wiki/Documentation/MeetingLogs#2016-03-30

Next meetings:
APAC: No APAC meeting this week
US: Wednesday 13 April, 19:00 UTC (This is after the Mitaka release)

Please go ahead and add any agenda items to the meeting page here: https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#1_April_2016

= 18 March 2016 =

Hi everyone,

It is with great pleasure that I announce that I will be the PTL again for Newton, which will be my third release for openstack-manuals. I'm overwhelmed by the positive messages I've received since announcing my candidacy, and very excited to be leading such a dedicated and innovative group into the fray again. This week I spent some time on the Contributor Guide, working with Brian to get the docs tools documented, which is something we've been wanting to do for some time. Very soon I'll be calling for your ideas on Summit sessions, and beginning to do Design Summit planning. The Install Guide is now in the last push to have everything tested before release, but we can still use your help getting it all done! If you can help, please contact Matt Kassawara, or any docs core.

== Progress towards Mitaka ==

19 days to go!

515 bugs closed so far for this release.

Docs Testing
* Volunteers required!
* https://wiki.openstack.org/wiki/Documentation/MitakaDocTesting

Release Tasks:
* Release planning occurs in our etherpad here: https://etherpad.openstack.org/p/MitakaRelease
* We're now freezing larger changes to the Install Guide, so cores will not be merging anything that changes the architecture of the guide, or significantly changes the technical content (except where that change is as a result of testing). This is to make the Install Guide testers work a little easier, by stopping the book from moving too much from under them.
* We will be publishing release notes for our own projects to

== Docs-tools ==

* Andreas and team have released a new version of the docs theme, which removes the versions information from the sidebar, and also removes the duplicated titles. This should make navigating the CI guides much easier, and reduce confusion over versions.

== The Road to Austin ==

* PTL elections are now open for those projects that have more than one candidate. You should have received an email for elections in which you are eligible to vote.
* I am pleased to announce that I am remaining as docs PTL for Newton (elected unopposed). I would also like to congratulate KATO Tomoyuki on becoming the new PTL for i18n, and to thank Daisy for her hard work in that group for many releases.
* I have requested workrooms and fishbowls for the Austin Design Summit. I'll let you know when we get our allocation. I will send out a note next week to start gathering your ideas for sessions.

== Speciality Teams ==

'''HA Guide - Bogdan Dobrelya'''
New for Mitaka release notes: Improved Pacemaker/Corosync cluster installation and configuration details http://docs.openstack.org/ha-guide/controller-ha-pacemaker.html (kudos Andrew Beekhof). Pacemaker Cluster Manager http://docs.openstack.org/ha-guide/intro-ha-arch-pacemaker.html and Keepalived http://docs.openstack.org/ha-guide/intro-ha-arch-keepalived.html architecture details and limitations (kudos Andrew Beekhof). Detailed Mariadb/Galera cluster installation, configuration and management guide http://docs.openstack.org/ha-guide/controller-ha-galera.html (kudos Kenneth Dyer). Improved RabbitMQ clustering guide http://docs.openstack.org/ha-guide/controller-ha-rabbitmq.html - HAProxy antipattern explained, new A/A option with Pacemaker resource agents (kudos KATO Tomoyuki, Andrew Beekhof). Many more, so read everything carefully ;-)

'''User Guides - Joseph Robinson'''
Larger patch for editing submitted this week, and working within the user guide team to reorganize the command line content in the admin user guide by moving common files into the cloud admin guide.

'''API Docs - Anne Gentle'''
Swagger files now built to developer.openstack.org. Project teams have templates for writing API guides within their project repository .

== Doc team meeting ==

Next meetings:

No meeting was held this week.

Next meetings:
APAC: Wednesday 23 March, 00:30 UTC
US: Wednesday 30 March, 19:00 UTC

Please go ahead and add any agenda items to the meeting page here: https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#18_March_2016

= 11 March 2016 =

Hi everyone,

This week I've been smashing some older bugs from our queue, and can now confirm that as a team we've closed everything older than a year! What a great effort, and a fabulous way to go into our release period. We have less than a month now before release, so I've been briefing our new release managers Brian and Olga, and have also spent some time speaking to various people about what docs will be releasing for Mitaka. Install Guide testing is now well underway, but we can always use more hands, so please consider getting involved. If you need help getting started, please contact Matt Kassawara, or any docs core.

== Progress towards Mitaka ==

26 days to go!

500 bugs closed so far for this release, which means we're about on par with where we were this time last release. Keep squishing those bugs!

Docs Testing
* Volunteers required!
* https://wiki.openstack.org/wiki/Documentation/MitakaDocTesting

Release Managers:
We now have two release managers for Mitaka: Brian Moss, and Olga Gusarenko. They'll be making sure we stay on track as we hurtle towards 7 April, and will be backed up by Anne, Andreas, myself, and of course our lovely core team.

== The Road to Austin ==

* Speaker acceptances have now gone out, and the schedule is available: https://www.openstack.org/summit/austin-2016/summit-schedule/#day=2016-04-24
* PTL nominations for Newton have now opened: https://wiki.openstack.org/wiki/PTL_Elections_March_2016. I'm very pleased to announce that I will be submitting my candidacy for docs.
* I have requested workrooms and fishbowls for the Austin Design Summit. I'll let you know when we get our allocation.
* You should be starting to think about booking travel and accommodation soon! If you need a visa to travel to the United States, there's more info here: https://www.openstack.org/summit/austin-2016/austin-and-travel/#visa

== Speciality Teams ==

'''HA Guide - Bogdan Dobrelya'''
No update this week.

'''Installation Guide - Matt Kassawara'''
No update this week.

'''Networking Guide - Edgar Magana'''
Progress towards the missing features and new ones for Mitaka. DSCP for QoS section is in good shape: https://review.openstack.org/#/c/273638/ Last Networking Guide meeting: http://eavesdrop.openstack.org/meetings/networking_guide/2016/networking_guide.2016-03-03-16.03.log.html Still missing a lot of attendence to the IRC meeting but we are happy with more contributions to the guide. Matt provided a short overview on how to contribute during the Neutron mid-cycle sessions

'''Security Guide - Nathaniel Dillon'''
No update this week.

'''User Guides - Joseph Robinson'''
User Guide APAC and US meetings this week - discussed merging the CLI reorganization patch, which was merged following the meeting. Becuase of a meetbot error, the APAC meeting did not take place, but I am sending a summary out to the mailing list, which I am still working on.

'''Ops and Arch Guides - Shilla Saebi'''
No update this week.

'''API Docs - Anne Gentle'''
No update this week.

Bug days: Work on api-site bugs: https://bugs.launchpad.net/openstack-api-site Work on these remaining WADL bugs which have patches: https://review.openstack.org/#/c/288315/ https://review.openstack.org/#/c/283114/ Continue to review and work on bootprint patch. Karin Bradshaw working on CSS updates.

'''Config Ref - Gauvain Pocentek'''
No update this week.

'''Training labs - Pranav Salunke, Roger Luethi'''
We merged support for snapshots in the KVM backend. Osbash works now on 32-bit i386 nodes which also makes nested virtualization (creating the whole VM cluster within a VM) possible. There is a new configuration file for users who only want an automated VM cluster setup, but no automated OpenStack installation. Finally, a new feature splits server log files according to cluster build phases, which makes it much easier to identify the origin of a specific log entry.

'''Training Guides - Matjaz Pancur'''
Enabled automatic bug status resolving at merge (https://review.openstack.org/#/c/283453/) WIP - Upstream training - add toolchain info for trainees (https://review.openstack.org/#/c/286941/)

'''Hypervisor Tuning Guide - Joe Topjian'''
I included a bunch of links related to NUMA and large memory pages. It'd be nice if the relevant information was pulled from the links and summarized. I also included some information about virtio-scsi.

'''UX/UI Docs Guidelines - Linette Williams'''
No update this week.

== Doc team meeting ==

Next meetings:

The APAC meeting was held this week. You can read the minutes here: https://wiki.openstack.org/wiki/Documentation/MeetingLogs#2016-03-09

Next meetings:
US: No meeting this week
APAC: Wednesday 23 March, 00:30 UTC

Please go ahead and add any agenda items to the meeting page here: https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#11_March_2016

= 4 March 2016 =

Hi everyone,

This week I've been concentrating on getting ready for the release, and I'm very pleased to announce that we now have not one but two release managers for Mitaka. Please welcome Brian and Olga, thanks to you both for stepping up to the challenge! I'm looking forward to working with you both to get this out the door. We also completed the docs core team review, with no changes for this month. Install Guide testing is now well underway, but we can always use more hands, so please consider getting involved. If you need help getting started, please contact Matt Kassawara, or any docs core.

== Progress towards Mitaka ==

33 days to go!

465 bugs closed so far for this release. There is a global bug smash event next week to try and hit as many Mitaka bugs as possible. You can join an in-person group near you, or participate remotely. Details here: https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka

Docs Testing
* Volunteers required!
* https://wiki.openstack.org/wiki/Documentation/MitakaDocTesting

API Docs
I'm very pleased to announce that Anne and the API docs team have managed to get HTML generation working directly from Swagger now. This is a massive leap forward for the API docs conversion. Well done to everyone involved!

Release Managers:
We now have two release managers for Mitaka: Brian Moss, and Olga Gusarenko. They'll be making sure we stay on track as we hurtle towards 7 April, and will be backed up by Anne, Andreas, myself, and of course our lovely core team.

== The Road to Austin ==

* The final round of ATC passes have now gone out.
* I have requested workrooms and fishbowls for the Austin Design Summit. I'll let you know when we get our allocation.
* You should be starting to think about booking travel and accommodation soon! If you need a visa to travel to the United States, there's more info here: https://www.openstack.org/summit/austin-2016/austin-and-travel/#visa

== Core Team reviews ==

I completed the core team review for March this week, and we decided to make no changes. We did, however, have some discussion about the stats we use to determine the core team membership. I currently use the 30 and 90 day russellbryant stats for determining review participation, and Stackalytics for commit participation, with emphasis being on the top 12 participants in each category. Feedback on the core team selection process is, as always, welcome. It is documented here: http://docs.openstack.org/contributor-guide/docs-review.html#achieving-a-core-reviewer-status

== Speciality Teams ==

'''HA Guide - Bogdan Dobrelya'''
No update this week.

'''Installation Guide - Matt Kassawara'''
More patches and testing for Mitaka.

'''Networking Guide - Edgar Magana'''
No update this week.

'''Security Guide - Nathaniel Dillon'''
No update this week.

'''User Guides - Joseph Robinson'''
A patch for the reorganisation is under review - shifting the command line content in the admin user guide to the cloud admin guide. Following this patch merging, the next step is moving down the task list, and completing edits to the content in the Cloud Admin guide to improve the document.

'''Ops and Arch Guides - Shilla Saebi'''
The work items for the Architecture Design Guide converted to bugs: https://bugs.launchpad.net/openstack-manuals/+bugs?field.tag=arch-guide We still need people to confirm the bugs.
Call for volunteers email went out to the ops and docs ML from Devon Boatwright. We are still looking for help, not getting many responses. Considering doing a swarm or work session at the summit in Austin for the Arch guide

'''API Docs - Anne Gentle'''
Patch fixing three of remaining 7 WADL bugs here: https://review.openstack.org/#/c/283114/
Patch that builds HTML from Swagger files here: https://review.openstack.org/#/c/286659/ This gets us over a big hurdle of making fairy-slipper "feature complete" while also ensuring the migration is complete. Great week, huge shoutout and thanks to Michael Krotscheck for the node/npm solution for building HTML.

'''Config Ref - Gauvain Pocentek'''
No update this week.

'''Training labs - Pranav Salunke, Roger Luethi'''
No update this week.

'''Training Guides - Matjaz Pancur'''
"Getting started" module for Training guides is published (http://docs.openstack.org/draft/training-guides/). Added "Local trainings" chapter to the Upstream training archive (http://docs.openstack.org/upstream-training/upstream-archives.html), cleanup patches (unused extensions, text redundancies and cleanup). Team meetings will be held on 1st and 3rd week in the month.

'''Hypervisor Tuning Guide - Joe Topjian'''
No update this week.

'''UX/UI Docs Guidelines - Linette Williams'''
Reviews continue for proposed UI panels in Invision

== Doc team meeting ==

Next meetings:

The US meeting was held this week, at the new time. You can read the minutes here: https://wiki.openstack.org/wiki/Documentation/MeetingLogs#2016-03-02

Next meetings:
APAC: Wednesday 9 March, 00:30 UTC
US: Wednesday 16 March, 19:00 UTC ***Note the new time!***

Please go ahead and add any agenda items to the meeting page here: https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#4_March_2016

Meetings/InfraTeamMeeting

2016-04-07T15:55:57Z

Jaegerandi: /* Agenda for next meeting */

{{:Header}}

= 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
** [https://etherpad.openstack.org/p/gerrit_server_replacement yolanda draft a maintenance plan for the gerrit server replacement]
** [http://lists.openstack.org/pipermail/openstack-dev/2016-April/091274.html yolanda send maintenance reminder announcement to the mailing list on April 4]
* Specs approval
* Priority Efforts
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/ansible_puppet_apply.html Ansible Puppet Apply]
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/dib-nodepool.html Use Diskimage Builder in Nodepool]
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/infra-cloud.html Infra-cloud]
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/logs-in-swift.html Store Build Logs in Swift]
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/maniphest.html maniphest migration]
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html Common OpenStack CI Solution]
** [http://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html Zuul v3]
* Proposal jobs: (AJaeger) We currently have some reviews for extra proposal jobs, what are our polices for adding them? Those run on the proposal jobs and thus we have to review for security:
** https://review.openstack.org/#/c/301375/
** https://review.openstack.org/#/c/267941/
** https://review.openstack.org/#/c/291514/
** https://review.openstack.org/#/c/291517/
* Open discussion

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

openstack/openstack-ansible-ironic -> openstack/openstack-ansible-os_ironic https://review.openstack.org/299192

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

Documentation/VendorDrivers

2016-04-05T17:38:21Z

Jaegerandi: /* Vendor Driver Documentation */

{{OpenStack_Documentation_Navbar}}

= Vendor Driver Documentation =

As explained in our [http://specs.openstack.org/openstack/docs-specs/specs/kilo/move-driver-docs.html specification for guidelines for vendor drivers], the Documentation team requests a contact person for each driver. At a minimum, driver docs are published in [http://docs.openstack.org/juno/config-reference/content/ the Configuration Reference per release]. The contact person should have a Launchpad account so that bugs can be assigned to the person.

Fill in the table below with details following the example

{| border="1" cellpadding="2" cellspacing="0" class="wikitable"
|-
!colspan="3"|Vendor Driver Contacts
|-
! Vendor
! File (in doc/config-reference)
! Contact person name <email>
|-
| Example: OpenStack Documentation team
| block-storage/drivers/nfs-volume-driver.xml
| Documentation team <openstack-docs@lists.openstack.org>
|-
!colspan="3"|Block Storage (cinder)
|-
| Blockbridge
| block-storage/drivers/blockbridge-eps-driver.xml
| Joshua Huber <jhuber@blockbridge.com>
|-
| Coho Data
| block-storage/drivers/coho-storage-driver.xml
| Bardia Keyoumarsi <bardia.keyoumarsi@cohodata.com>
|-
| Dell Storage (EqualLogic)
| block-storage/drivers/dell-equallogic-driver.xml
| Sean McGinnis <openstack-cinder@dell.com>
|-
| Dell Storage (Storage Center)
| block-storage/drivers/dell-storagecenter-driver.xml
| Sean McGinnis <openstack-cinder@dell.com>
|-
| Dot Hill
| block-storage/drivers/dothill-driver.xml
| Chris Maio <cinder@tristero.net>
|-
| EMC (ScaleIO)
| block-storage/drivers/emc-scaleio-driver.xml
| Xing Yang <xing.yang@emc.com>
|-
| EMC (VMAX)
| block-storage/drivers/emc-vmax-driver.xml
| Xing Yang <xing.yang@emc.com>
|-
| EMC (VNX)
| block-storage/drivers/emc-vnx-direct-driver.xml
| EMC VNX OpenStack <EMC.VNX.OpenStack@emc.com>
|-
| EMC (XtremIO)
| block-storage/drivers/emc-xtremio-driver.xml
| Shay Halsband <shay.halsband@emc.com>
|-
| Fujitsu (ETERNUS DX)
| doc/config-reference/source/block-storage/drivers/fujitsu-eternus-dx-driver.rst
| Yusuke Hayashi <hayashi-yusuke@jp.fujitsu.com>
|-
| HDS (HNAS)
| block-storage/drivers/hds-hnas-driver.xml
| HNAS Openstack Team <OpenstackDevelopment@hds.com>
|-
| HPE (3PAR/StoreServ)
| block-storage/drivers/hpe-3par-driver.xml
| MSDU OpenStack <msdu-openstack@groups.ext.hpe.com>
|-
| HPE (LeftHand/StoreVirtual)
| block-storage/drivers/hpe-lefthand-driver.xml
| MSDU OpenStack <msdu-openstack@groups.ext.hpe.com>
|-
| HP MSA
| block-storage/drivers/hp-msa-driver.xml
| Chris Maio <cinder@tristero.net>
|-
|Huawei
| block-storage/drivers/huawei-storage-driver.xml
| liuxinguo <liuxinguo@huawei.com>
|-
| IBM (FlashSystem)
| block-storage/drivers/ibm-flashsystem-volume-driver.xml
| Yanlin Ren <renylin@cn.ibm.com>
|-
| IBM (Storwize)
| block-storage/drivers/ibm-storwize-volume-driver.xml
| Ivy Zhang <shzyu@cn.ibm.com>
|-
| ITRI (DISCO)
|
| Thelo Gaultier <thelo.gaultier@itri.org.tw>
|-
| Lenovo
| block-storage/drivers/lenovo-driver.xml
| Chris Maio <cinder@tristero.net>
|-
| NetApp
| block-storage/drivers/netapp-volume-driver.xml
| Alex Meade <alex.meade@netapp.com>
|-
| Nexenta
| block-storage/drivers/nexenta*
| Alexey Khodos <alexey.khodos@nexenta.com>, Ilya Grafutko <ilya.grafutko@nexenta.com>
|-
| Nimble Storage
| block-storage/drivers/nimble-volume-driver.xml
| Nimble OpenStack Team <openstack-ci@nimblestorage.com>
|-
| Oracle
| block-storage/drivers/zfssa-nfs-driver.xml,
block-storage/drivers/zfssa-iscsi-driver.xml
| Kedar Vidvans <kedar.vidvans@oracle.com>,
Alka Deshpande <alka.deshpande@oracle.com>
|-
| Pure Storage
| block-storage/drivers/pure-storage-driver.xml
| Openstack Dev <openstack-dev@purestorage.com>
|-
|Quobyte
| block-storage/drivers/quobyte.xml
| Silvan Kaiser <silvan@quobyte.com>, kaisers @IRC
|-
| RedHat (GlusterFS Storage)
| block-storage/drivers/glusterfs-driver.xml
| Bharat Kumar Kobagana <bharat.kobagana@redhat.com>
|-
| Scality (SOFS)
| block-storage/drivers/scality-sofs-driver.xml
| Openstack Eng <openstack-eng@scality.com>
|-
| SolidFire
| block-storage/drivers/solidfire-driver.xml
| John Griffith <john.griffith@solidfire.com>
|-
| Tintri
| block-storage/drivers/tintri-volume-driver.xml
| OpenStack Dev <openstack-dev@tintri.com>
|-
| Violin Memory (V7000)
| block-storage/drivers/violin-v7000-driver.xml
| Garfield Freeman <gfreeman@vmem.com>
|-
| Violin Memory (V6000)
| block-storage/drivers/violin-v6000-driver.xml
| Garfield Freeman <gfreeman@vmem.com>
|-
| VMware
| block-storage/drivers/vmware-vmdk-driver.xml
| Vipin Balachandran <vbala@vmware.com>
|-
| X-IO technologies
| block-storage/drivers/xio-volume-driver.xml
| Richard Hedlind <openstack-dev@x-io.com>
|-
!colspan="3"|Fibre Channel Zone Manager (Cinder)
|-
|-
| Brocade
| block-storage/section_fc-zoning.xml
| Angela Smith <Angela.Smith@brocade.com>
|-
| Cisco
| block-storage/section_fc-zoning.xml
| Yamini Umapathy <yumapath@cisco.com>,
Midun Kumar <mneelame@cisco.com>
|-
!colspan="3"|Shared File Systems (manila)
|-
|-
| EMC (Isilon)
| shared-file-systems/drivers/emc-isilon-driver.xml
| Xing Yang <xing.yang@emc.com>
|-
| EMC (VNX)
| shared-file-systems/drivers/emc-vnx-driver.xml
| EMC VNX OpenStack <EMC.VNX.OpenStack@emc.com>
|-
| Generic Driver
| shared-file-systems/drivers/generic-driver.xml
| Valeriy Ponomaryov <vponomaryov@mirantis.com>
|-
| RedHat (GlusterFS)
| shared-file-systems/drivers/glusterfs-driver.xml
| Ramana Raja <rraja@redhat.com>
|-
| RedHat (GlusterFS Native)
| shared-file-systems/drivers/glusterfs-native-driver.xml
| Ramana Raja <rraja@redhat.com>
|-
| Intel
| shared-file-systems/drivers/hdfs-native-driver.xml
| Weiting Chen <weiting.chen@intel.com>
|-
| Hitachi (HNAS)
| shared-file-systems/drivers/hitachi-hnas-driver.xml
| HNAS Openstack Team <OpenstackDevelopment@hds.com>
|-
| HPE (3PAR/StoreServ)
| shared-file-systems/drivers/hpe-3par-share-driver.xml
| Mark Sturdevant <mark.sturdevant@hpe.com>
|-
| Huawei
| shared-file-systems/drivers/huawei-nas-driver.xml
| zhongjun <jun.zhongjun@huawei.com>
|-
| IBM (GPFS)
| shared-file-systems/drivers/ibm-gpfs-driver.xml
| Gaurang Tapase <gaurang.tapase@in.ibm.com>
|-
| NetApp (Clustered Data ONTAP)
| shared-file-systems/drivers/netapp-cluster-mode-driver.xml
| Clinton Knight <cknight@netapp.com>
|-
| Quobyte
| TBD
| Silvan Kaiser <silvan@quobyte.com>, kaisers @IRC
|-
!colspan="3"|Networking (Neutron)
|-
| Brocade Vyatta
| doc/common/tables/neutron-brocade_vyatta_l3.xml
| Harkirat Singh <harkirat@brocade.com>
|-
!colspan="3"|Compute (Nova)
|-
| Hyper-V
| doc/config-reference/source/compute/hypervisor-hyper-v.rst
| ???
|-|}

----
[[Category:Documentation]]

Documentation/VendorDrivers

2016-04-05T17:35:21Z

Jaegerandi: /* Vendor Driver Documentation */ Add Nexenta as requested on IRC

{{OpenStack_Documentation_Navbar}}

= Vendor Driver Documentation =

As explained in our [http://specs.openstack.org/openstack/docs-specs/specs/kilo/move-driver-docs.html specification for guidelines for vendor drivers], the Documentation team requests a contact person for each driver. At a minimum, driver docs are published in [http://docs.openstack.org/juno/config-reference/content/ the Configuration Reference per release]. The contact person should have a Launchpad account so that bugs can be assigned to the person.

Fill in the table below with details following the example

{| border="1" cellpadding="2" cellspacing="0" class="wikitable"
|-
!colspan="3"|Vendor Driver Contacts
|-
! Vendor
! File (in doc/config-reference)
! Contact person name <email>
|-
| Example: OpenStack Documentation team
| block-storage/drivers/nfs-volume-driver.xml
| Documentation team <openstack-docs@lists.openstack.org>
|-
!colspan="3"|Block Storage (cinder)
|-
| Blockbridge
| block-storage/drivers/blockbridge-eps-driver.xml
| Joshua Huber <jhuber@blockbridge.com>
|-
| Coho Data
| block-storage/drivers/coho-storage-driver.xml
| Bardia Keyoumarsi <bardia.keyoumarsi@cohodata.com>
|-
| Dell Storage (EqualLogic)
| block-storage/drivers/dell-equallogic-driver.xml
| Sean McGinnis <openstack-cinder@dell.com>
|-
| Dell Storage (Storage Center)
| block-storage/drivers/dell-storagecenter-driver.xml
| Sean McGinnis <openstack-cinder@dell.com>
|-
| Dot Hill
| block-storage/drivers/dothill-driver.xml
| Chris Maio <cinder@tristero.net>
|-
| EMC (ScaleIO)
| block-storage/drivers/emc-scaleio-driver.xml
| Xing Yang <xing.yang@emc.com>
|-
| EMC (VMAX)
| block-storage/drivers/emc-vmax-driver.xml
| Xing Yang <xing.yang@emc.com>
|-
| EMC (VNX)
| block-storage/drivers/emc-vnx-direct-driver.xml
| EMC VNX OpenStack <EMC.VNX.OpenStack@emc.com>
|-
| EMC (XtremIO)
| block-storage/drivers/emc-xtremio-driver.xml
| Shay Halsband <shay.halsband@emc.com>
|-
| Fujitsu (ETERNUS DX)
| doc/config-reference/source/block-storage/drivers/fujitsu-eternus-dx-driver.rst
| Yusuke Hayashi <hayashi-yusuke@jp.fujitsu.com>
|-
| HDS (HNAS)
| block-storage/drivers/hds-hnas-driver.xml
| HNAS Openstack Team <OpenstackDevelopment@hds.com>
|-
| HPE (3PAR/StoreServ)
| block-storage/drivers/hpe-3par-driver.xml
| MSDU OpenStack <msdu-openstack@groups.ext.hpe.com>
|-
| HPE (LeftHand/StoreVirtual)
| block-storage/drivers/hpe-lefthand-driver.xml
| MSDU OpenStack <msdu-openstack@groups.ext.hpe.com>
|-
| HP MSA
| block-storage/drivers/hp-msa-driver.xml
| Chris Maio <cinder@tristero.net>
|-
|Huawei
| block-storage/drivers/huawei-storage-driver.xml
| liuxinguo <liuxinguo@huawei.com>
|-
| IBM (FlashSystem)
| block-storage/drivers/ibm-flashsystem-volume-driver.xml
| Yanlin Ren <renylin@cn.ibm.com>
|-
| IBM (Storwize)
| block-storage/drivers/ibm-storwize-volume-driver.xml
| Ivy Zhang <shzyu@cn.ibm.com>
|-
| ITRI (DISCO)
|
| Thelo Gaultier <thelo.gaultier@itri.org.tw>
|-
| Lenovo
| block-storage/drivers/lenovo-driver.xml
| Chris Maio <cinder@tristero.net>
|-
| NetApp
| block-storage/drivers/netapp-volume-driver.xml
| Alex Meade <alex.meade@netapp.com>
|-
| Nexenta
| block-storage/drivers/nexenta*
| lexey Khodos <alexey.khodos@nexenta.com>, Ilya Grafutko <ilya.grafutko@nexenta.com>
|-
| Nimble Storage
| block-storage/drivers/nimble-volume-driver.xml
| Nimble OpenStack Team <openstack-ci@nimblestorage.com>
|-
| Oracle
| block-storage/drivers/zfssa-nfs-driver.xml,
block-storage/drivers/zfssa-iscsi-driver.xml
| Kedar Vidvans <kedar.vidvans@oracle.com>,
Alka Deshpande <alka.deshpande@oracle.com>
|-
| Pure Storage
| block-storage/drivers/pure-storage-driver.xml
| Openstack Dev <openstack-dev@purestorage.com>
|-
|Quobyte
| block-storage/drivers/quobyte.xml
| Silvan Kaiser <silvan@quobyte.com>, kaisers @IRC
|-
| RedHat (GlusterFS Storage)
| block-storage/drivers/glusterfs-driver.xml
| Bharat Kumar Kobagana <bharat.kobagana@redhat.com>
|-
| Scality (SOFS)
| block-storage/drivers/scality-sofs-driver.xml
| Openstack Eng <openstack-eng@scality.com>
|-
| SolidFire
| block-storage/drivers/solidfire-driver.xml
| John Griffith <john.griffith@solidfire.com>
|-
| Tintri
| block-storage/drivers/tintri-volume-driver.xml
| OpenStack Dev <openstack-dev@tintri.com>
|-
| Violin Memory (V7000)
| block-storage/drivers/violin-v7000-driver.xml
| Garfield Freeman <gfreeman@vmem.com>
|-
| Violin Memory (V6000)
| block-storage/drivers/violin-v6000-driver.xml
| Garfield Freeman <gfreeman@vmem.com>
|-
| VMware
| block-storage/drivers/vmware-vmdk-driver.xml
| Vipin Balachandran <vbala@vmware.com>
|-
| X-IO technologies
| block-storage/drivers/xio-volume-driver.xml
| Richard Hedlind <openstack-dev@x-io.com>
|-
!colspan="3"|Fibre Channel Zone Manager (Cinder)
|-
|-
| Brocade
| block-storage/section_fc-zoning.xml
| Angela Smith <Angela.Smith@brocade.com>
|-
| Cisco
| block-storage/section_fc-zoning.xml
| Yamini Umapathy <yumapath@cisco.com>,
Midun Kumar <mneelame@cisco.com>
|-
!colspan="3"|Shared File Systems (manila)
|-
|-
| EMC (Isilon)
| shared-file-systems/drivers/emc-isilon-driver.xml
| Xing Yang <xing.yang@emc.com>
|-
| EMC (VNX)
| shared-file-systems/drivers/emc-vnx-driver.xml
| EMC VNX OpenStack <EMC.VNX.OpenStack@emc.com>
|-
| Generic Driver
| shared-file-systems/drivers/generic-driver.xml
| Valeriy Ponomaryov <vponomaryov@mirantis.com>
|-
| RedHat (GlusterFS)
| shared-file-systems/drivers/glusterfs-driver.xml
| Ramana Raja <rraja@redhat.com>
|-
| RedHat (GlusterFS Native)
| shared-file-systems/drivers/glusterfs-native-driver.xml
| Ramana Raja <rraja@redhat.com>
|-
| Intel
| shared-file-systems/drivers/hdfs-native-driver.xml
| Weiting Chen <weiting.chen@intel.com>
|-
| Hitachi (HNAS)
| shared-file-systems/drivers/hitachi-hnas-driver.xml
| HNAS Openstack Team <OpenstackDevelopment@hds.com>
|-
| HPE (3PAR/StoreServ)
| shared-file-systems/drivers/hpe-3par-share-driver.xml
| Mark Sturdevant <mark.sturdevant@hpe.com>
|-
| Huawei
| shared-file-systems/drivers/huawei-nas-driver.xml
| zhongjun <jun.zhongjun@huawei.com>
|-
| IBM (GPFS)
| shared-file-systems/drivers/ibm-gpfs-driver.xml
| Gaurang Tapase <gaurang.tapase@in.ibm.com>
|-
| NetApp (Clustered Data ONTAP)
| shared-file-systems/drivers/netapp-cluster-mode-driver.xml
| Clinton Knight <cknight@netapp.com>
|-
| Quobyte
| TBD
| Silvan Kaiser <silvan@quobyte.com>, kaisers @IRC
|-
!colspan="3"|Networking (Neutron)
|-
| Brocade Vyatta
| doc/common/tables/neutron-brocade_vyatta_l3.xml
| Harkirat Singh <harkirat@brocade.com>
|-
!colspan="3"|Compute (Nova)
|-
| Hyper-V
| doc/config-reference/source/compute/hypervisor-hyper-v.rst
| ???
|-|}

----
[[Category:Documentation]]

Documentation/Release

2016-03-10T06:06:53Z

Jaegerandi: /* Release Notes */

= Overview =

The first release activity is to start testing on the Install Guide, because this takes the longest time. It depends on getting packages from the various distros, and finding people willing to test the guide against those packages. We won't publish the Install Guide for a particular distro until we're satisfied that it has been thoroughly and successfully tested. During this time, we limit the patches we will accept against the install guide to ensure only critical changes go in (this helps to avoid having the guide change while it's being tested).

During this time, we also work on release notes. These are largely compiled by the PTL or CPL of the project team involved, but we are responsible for reviewing and copyediting.

On the days immediately before release day, and on release day itself, we do the infra tasks required to update the front page of docs.openstack.org to reflect the new release name and docs. After that, we keep publishing to Master until the branch is cut, which happens a couple of weeks after the actual release day (usually shortly after Summit).

= Timeline =

* Two to four weeks before testing (T-60 days): ping packagers to locate pre-release packages to test against
* When testing opens (T-30 days): Ping CPLs to check their chapters, ping packagers to check on availability.
* Two weeks before release: Release notes
* Some days before release: Publish versioned guides to /RELEASENAME and create /RELEASENAME/index.html page.
* 12-24 hours before release day: https://wiki.openstack.org/wiki/Documentation/Release
* On release day: Change the front page so the new release is the default.
* After release day (usually a couple of weeks): cut the branch for Install Guide and Config Ref

= Testing the Install Guide =

* TBD

= Updating the Config Ref =

The scripts need to manually run before release day to ensure we've picked up all the latest changes in the source repos.

= Cut the stable branch =

Note that this description is current for liberty and uses liberty as example.

OpenStack continuously publishes docs from the master branch. It doesn't track with milestone releases, as there are not enough contributors to make that happen. When the number of doc bugs for a specific release seems tolerable (that is, publishing the "release" documents won't cause more questions than it answers), we follow these steps to create a stable branch that is published to a named release directory on the docs site, such as docs.openstack.org/liberty. However, only certain documents are "released", currently those are the Installation Guides and the Configuration Reference.

== Preparation for releasing ==
* Publish the versioned guides to both /draft and /liberty, this needs adopting of the file tools/publishdocs.sh.
* Create a /liberty/index.html page
* Update the menus in openstackdocstheme to include liberty - and then release openstackdocstheme in time for the release
* Check manuals for release:
** Update all manuals in all repos so that they link to latest version of versioned guides (to liberty version of Install Guide and Configuration Reference).
** Configuration reference: Regenerate all option tables as well as the tables showing difference between releases.
** Command-Line reference: Check that all client packages are documented and up-to-date.
** Operations Guide: Add upgrade information for new release.
** All continuously published manuals should document current release and the two previous ones, so update text on the index page saying "This guide documents the Juno, Kilo, and Liberty releases."
* Final review of release notes (file RELEASENOTES.rst in openstack-manuals).

== On the day of the release ==

* Update the /index.html page so that it has the new release as current (https://review.openstack.org/233583)
* Update drop-down menu on for current release (https://review.openstack.org/233582)
* Update redirects in .htaccess to point to current release (https://review.openstack.org/#/c/233555)
* Update the sitemap.xml files for docs.openstack.org and developer.openstack.org.

== Branch creation ==

Here are the checklist steps for creating a stable branch of the Documentation from the http://git.openstack.org/cgit/openstack/openstack-manuals/ repository.

# Ask the CI team to create a stable branch for openstack-manuals
# Update file <code>gerritbot/channels.yaml</code> in repository openstack-infra/project-config for notifications of the new branch.
# After the branch is created, do the following on the branch in openstack-manuals so that git review works automatically:
#* Update the .gitreview file in openstack-manuals to add <code>defaultbranch=stable/liberty</code> to indicate the branch that git review will use
#* Setup building to disable all non-translated and non-versioned guides for translation, oinly build backported guides (install-guide and config-reference), and do not publish web pages (liberty patch: https://review.openstack.org/245851)
#** Update doc-test.conf to publish to publish to /liberty
#** Update doc-tools-check-languages.conf to disable unwanted translated guides
#** Update tools/build-all-rst.sh to disable publishing of unwanted guides
#** Update tools/publishdocs.sh to disable publishing of www files
#** Update tools/build-install-guides-rst.sh for publishing to /liberty
#* Disable syncing of files from liberty branch of openstack-manuals to other repos (https://review.openstack.org/246195)
#* Move translated guides to /liberty for publishing (https://review.openstack.org/246205 )
# On master, stop publishing to both /draft and /liberty, adjust tools/publishdocs.sh.
# On master, change version info in versioned guides to next release (mitaka).
# Create a branch on our translation server so that translators can translate the versioned guide (Install Guide for Liberty). This needs a Zanata admin (AJaeger, Daisy, Pleia2, etc)
# Enable periodic translation jobs for liberty in project-config repository (https://review.openstack.org/246201)

== Translation resource minimization ==
# To minimize the translation resouces, change the common-rst generation method (https://review.openstack.org/#/c/246751/)

= Retire old release branches =

Before retiring a branch, add an "unmainted notice" to the guides that are published from the branch and publish these guides

= Updating Google =

Update Google site map and Google Custom Search Engine

* Build a sitemap using openstack-doc-tools.
* Ensure that the sitemap.xml stored on the web server contains links to the latest release.
* Ensure that the most recently End-Of-Life release is not listed in sitemap.xml, by deleting the content and adding a redirect to the root / of the site.

----
[[Category:Documentation]]