OpenStack - User contributions [en]

Meetings/TechnicalCommittee

2026-03-17T18:16:49Z

Dan Smith:

__NOTOC__

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

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

Although we don't hold office hours, you can find various members of the TC at various times throughout the week in the [http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ #openstack-tc] IRC channel. We also meet formally [http://eavesdrop.openstack.org/#Technical_Committee_Meeting each week] in #openstack-tc.

=== Next Meeting ===

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

==== Agenda ====

* Roll call
** courtesy-ping: gouthamr, noonedeadpunk, tonyb, frickler, spotz[m], dansmith, cardoe, mnasiadka, bauzas
* Last Week's AIs
* PTG
** #link https://etherpad.opendev.org/p/apr2026-ptg-os-tc (TC PTG Etherpad)
* Releases for Venus, Vitrage
** #link https://review.opendev.org/c/openstack/releases/+/979621 (Release vitrage RC1 for 2026.1 Gazpacho)
** #link https://review.opendev.org/c/openstack/releases/+/979616 (Release venus-dashboard RC1 for 2026.1 Gazpacho)
** #link https://review.opendev.org/c/openstack/releases/+/979617 (Release venus RC1 for 2026.1 Gazpacho)
* A check on gate health
* TC Tracker, PTG Follow up
** #link https://etherpad.opendev.org/p/tc-2026.1-tracker (Technical Committee activity tracker - 2026.1)
** #link https://etherpad.opendev.org/p/oct2025-ptg-os-tc-summary
** #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/RX3MZE33GEDV5JDHORZKRUKVDP47UMLJ/ (OS/PTG Summary)
* Open Discussion and Reviews

==== Absence ====
* dansmith will be out for 24-Mar and 31-Mar meetings

=== Past meetings logs ===

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

[[Category: meetings]]

Meetings/TechnicalCommittee

2024-07-08T16:39:06Z

Dan Smith:

__NOTOC__

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

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

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

=== Next Meeting ===

* Date: 2024 Jul 09
* Time: 18.00 UTC: http://eavesdrop.openstack.org/#Technical_Committee_Meeting
* Chair: Goutham Pacha Ravi (gouthamr)
* Agenda to be published on the OpenStack-discuss mailing list before the meeting
* Location: IRC (OFTC): #openstack-tc

==== Agenda ====

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

==== Absence ====
* dansmith
=== Past meetings logs ===

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

[[Category: meetings]]

Meetings/TechnicalCommittee

2024-07-08T16:38:16Z

Dan Smith:

__NOTOC__

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

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

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

=== Next Meeting ===

* Date: 2024 Jul 09
* Time: 18.00 UTC: http://eavesdrop.openstack.org/#Technical_Committee_Meeting
* Chair: Goutham Pacha Ravi (gouthamr)
* Agenda to be published on the OpenStack-discuss mailing list before the meeting
* Location: IRC (OFTC): #openstack-tc

==== Agenda ====

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

==== Absence ====
* dansmith
=== Past meetings logs ===

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

[[Category: meetings]]

Meetings/TechnicalCommittee

2023-09-25T21:25:50Z

Dan Smith: /* Absence */

__NOTOC__

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

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

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

=== Next Meeting ===

* Date: 2023 September 26
* Time: 18.00 UTC: http://eavesdrop.openstack.org/#Technical_Committee_Meeting
* Chair: Kristi Nikolla (knikolla)
* Agenda to be published on the OpenStack-discuss mailing list before the meeting
* Location: OFTC IRC of #openstack-tc

==== Agenda Suggestions ====

* Roll call
* Follow up on past action items
** No action items from Sept 19, 2023 meeting.
* Gate health check
* Leaderless projects
* Open Discussion and Reviews
** Register for the PTG
*** #link https://openinfra.dev/ptg/
** #link https://review.opendev.org/q/projects:openstack/governance+is:open

==== Absence ====

* dansmith

=== Past meetings logs ===

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

[[Category: meetings]]

Meetings/TechnicalCommittee

2021-11-23T20:01:06Z

Dan Smith:

__NOTOC__

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

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

We hold office hours at [https://governance.openstack.org/tc/#office-hours various times] during the week on the [http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ #openstack-tc] IRC channel. We meet formally [http://eavesdrop.openstack.org/#Technical_Committee_Meeting each week] in #openstack-tc

=== Next Meeting ===

* Date: Nov 25th, 2021
* Time: 15.00 UTC: http://eavesdrop.openstack.org/#Technical_Committee_Meeting
* Chair: Ghanshyam Mann
* Agenda to be published on the OpenStack-discuss mailing list before the meeting
* Location: IRC #openstack-tc

==== Agenda Suggestions ====

* Roll call
* Follow up on past action items
* Gate health check
** Fixing Zuul config error in OpenStack
*** https://etherpad.opendev.org/p/zuul-config-error-openstack
* Updates on community-wide goal
** RBAC goal rework
*** https://review.opendev.org/c/openstack/governance/+/815158
*** https://review.opendev.org/c/openstack/governance/+/818817
** Proposed community goal for FIPS compatibility and compliance
*** https://review.opendev.org/c/openstack/governance/+/816587
* Magnum project health
* Adjutant need PTLs and maintainers
** http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025555.html
* Pain Point targeting
** https://etherpad.opendev.org/p/pain-point-elimination
* Open Reviews
** https://review.opendev.org/q/projects:openstack/governance+is:open

==== Apologies for Absence ====
<Please write your name if you are not able to attend the meeting>
* Jay Bryant (jungleboyj) -- Thanksgiving Holiday in the US
* dansmith

=== Past meetings logs ===

Logs of past TC meetings can be accessed at: http://eavesdrop.openstack.org/meetings/tc

[[Category: meetings]]

Meetings/Nova

2021-11-02T15:37:02Z

Dan Smith:

= Weekly Nova team meeting =

''' Regular MEETING TIME: '''Tuesdays''' 16:00 UTC (#openstack-nova on OFTC)'''

This meeting is a weekly gathering of developers working on [[Nova|OpenStack Compute (Nova)]]. We cover topics such as release planning and status, bugs, reviews, and other current topics worthy of real-time discussion.

== Project Heartbeat ==

This information will be updated weekly but not mentioned in the meeting unless specifically called out on the agenda.

* #topic Release News
** #link Nova Yoga schedule https://releases.openstack.org/yoga/schedule.html

* #topic Stable branch status

** #link stable/xena: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/nova)+branch:stable/xena
** #link stable/wallaby: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/nova)+branch:stable/wallaby
** #link stable/victoria: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/nova)+branch:stable/victoria
** #link stable/ussuri: https://review.openstack.org/#/q/status:open+(project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/nova)+branch:stable/ussuri
** stable/train is EM

* #topic Bugs (stuck/critical)
** #link bug triage how-to: https://wiki.openstack.org/wiki/Nova/BugTriage#Tags
** #help need help with bug triage

* #topic Gate status
** #link check queue gate status http://status.openstack.org/elastic-recheck/index.html
** #link 3rd party CI status (not so dead) http://ciwatch.mmedvede.net/project?project=nova

* #topic Review status page
** #link http://status.openstack.org/reviews/#nova
** Count: 438 (+20); Top score: 2303 (+21) (last refresh was 09-03)
** #help Pick a patch near the top, shepherd it to closure

== Agenda for next meeting ==

Next meetings scheduled for:

* Nov 2 2021 16:00 UTC #openstack-nova (http://www.timeanddate.com/worldclock/fixedtime.html?iso=2021-11-02T16:00:00)
* Nov 9 2021 16:00 UTC #openstack-nova (http://www.timeanddate.com/worldclock/fixedtime.html?iso=2021-11-09T16:00:00)
* Nov 16 2021 16:00 UTC #openstack-nova (http://www.timeanddate.com/worldclock/fixedtime.html?iso=2021-11-16T16:00:00)
* Nov 23 2021 16:00 UTC #openstack-nova (http://www.timeanddate.com/worldclock/fixedtime.html?iso=2021-11-23T16:00:00)

Where you see "?" feel free to just edit the wiki and add your item.

Here is the agenda for the next meeting:

* #topic Bugs (stuck/critical)
** No [https://bugs.launchpad.net/nova/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress Critical bug]
** #link 22 new untriaged bugs (-2 since the last meeting): #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
** 32 open stories (+0 since the last meeting) in Storyboard for Placement #link https://storyboard.openstack.org/#!/project/openstack/placement

* #topic Gate status
** Nova gate bugs #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure
** Placement periodic job status #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly
** Please look at the gate failures, file a bug, and add an elastic-recheck signature in the opendev/elastic-recheck repo (example: #link https://review.opendev.org/#/c/759967)

* #topic Release Planning
** Yoga-1 is due Nova 18th #link https://releases.openstack.org/yoga/schedule.html#y-1
** #startvote Spec review day proposal on Tuesday Nova 16th ?

* #topic Review priorities
** https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement)+label:Review-Priority%252B1
** #action bauzas to propose a documentation change by this week as agreed on the PTG

* #topic Stable Branches
** ?

* #topic Sub/related team Highlights
** Libvirt (lyarwood)

* #topic Open discussion
** Bring default overcommit ratios into sanity (dansmith / yuriys)
(add your own items here)

== Sub-teams ==

There are also some Nova subteam meetings. See [[Nova#Nova_subteams]] for details.

== Previous meetings ==

* [http://eavesdrop.openstack.org/meetings/nova/ All other meetings are here]

[[category: compute]]
[[category: meetings]]

Meetings/TechnicalCommittee

2021-01-19T16:00:15Z

Dan Smith:

__NOTOC__

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

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

We hold office hours at [https://governance.openstack.org/tc/#office-hours various times] during the week on the [http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ #openstack-tc] IRC channel. We meet formally [http://eavesdrop.openstack.org/#Technical_Committee_Meeting each week] in #openstack-tc

=== Next Meeting ===

* Date: January 21, 2021
* Time: 15.00 UTC: http://eavesdrop.openstack.org/#Technical_Committee_Meeting
* Chair: Mohammed Naser
* Agenda to be published on the OpenStack-discuss mailing list before the meeting

==== Agenda Suggestions ====

* Follow up on past action items
* Audit SIG list and chairs (diablo_rojo)
* Add Resolution of TC stance on the OpenStackClient (diablo_rojo)
** https://review.opendev.org/c/openstack/governance/+/759904
* Gate performance and heavy job configs (dansmith)
** http://paste.openstack.org/show/jD6kAP9tHk7PZr2nhv8h/
* Audit and clean-up tags (gmann)
** 'supports-api-interoperability' tag
*** http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019814.html
* Farewell Andreas (diablo_rojo)
** Stepping up to help with review load that will be new to everyone
* Dropping lower-constraints testing from all projects (gmann)
** http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019672.html
* Decide on OpenSUSE in testing runtime (gmann)
** Devstack dropping the opensuse job because it is failing for a long time and no maintainer to fix it.
*** https://review.opendev.org/c/openstack/devstack/+/769884
* Open Reviews
** https://review.opendev.org/q/project:openstack/governance+is:open

==== Apologies for Absence ====

=== Past meetings logs ===

Logs of past TC meetings can be accessed at: http://eavesdrop.openstack.org/meetings/tc

[[Category: meetings]]

Meetings/TechnicalCommittee

2021-01-19T00:36:11Z

Dan Smith:

__NOTOC__

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

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

We hold office hours at [https://governance.openstack.org/tc/#office-hours various times] during the week on the [http://eavesdrop.openstack.org/irclogs/%23openstack-tc/ #openstack-tc] IRC channel. We meet formally [http://eavesdrop.openstack.org/#Technical_Committee_Meeting each week] in #openstack-tc

=== Next Meeting ===

* Date: January 21, 2021
* Time: 15.00 UTC: http://eavesdrop.openstack.org/#Technical_Committee_Meeting
* Chair: Mohammed Naser
* Agenda to be published on the OpenStack-discuss mailing list before the meeting

==== Agenda Suggestions ====

* Follow up on past action items
* Audit SIG list and chairs (diablo_rojo)
* Add Resolution of TC stance on the OpenStackClient (diablo_rojo)
** https://review.opendev.org/c/openstack/governance/+/759904
* Gate performance and heavy job configs (dansmith)
* Audit and clean-up tags (gmann)
** 'supports-api-interoperability' tag
*** http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019814.html
* Farewell Andreas (diablo_rojo)
** Stepping up to help with review load that will be new to everyone
* Dropping lower-constraints testing from all projects (gmann)
** http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019672.html
* Decide on OpenSUSE in testing runtime (gmann)
** Devstack dropping the opensuse job because it is failing for a long time and no maintainer to fix it.
*** https://review.opendev.org/c/openstack/devstack/+/769884
* Open Reviews
** https://review.opendev.org/q/project:openstack/governance+is:open

==== Apologies for Absence ====

=== Past meetings logs ===

Logs of past TC meetings can be accessed at: http://eavesdrop.openstack.org/meetings/tc

[[Category: meetings]]

Meetings/Nova

2018-06-21T20:48:06Z

Dan Smith:

= Weekly Nova team meeting =
'''MEETING TIME: Thursdays alternating 14:00 UTC (#openstack-meeting) and 21:00 UTC (#openstack-meeting)'''

This meeting is a weekly gathering of developers working on [[Nova|OpenStack Compute (Nova)]]. We cover topics such as release planning and status, bugs, reviews, and other current topics worthy of real-time discussion.

NOTE: this wiki page should be 'emptied' at the end of each meeting.

== Agenda for next meeting ==

Next meetings scheduled for:

* June 21st 2018 2100 UTC, #openstack-meeting (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20180621T210000)
* June 28th 2018 1400 UTC, #openstack-meeting (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20180628T140000)
<br>

Where you see "?" feel free to just edit the wiki and add your item.

Here is the agenda for the next meeting:
* Release News
** #link Rocky release schedule: https://wiki.openstack.org/wiki/Nova/Rocky_Release_Schedule
** #link Rocky review runways: https://etherpad.openstack.org/p/nova-runways-rocky
** #link runway #1: Optional placement db connection string (cdent) [END DATE: 2018-07-03]
** #link runway #2: Neutron new port binding API for live migration: https://blueprints.launchpad.net/nova/+spec/neutron-new-port-binding-api (mriedem) [END DATE: 2018-06-20] Starts here: https://review.openstack.org/#/c/558001/
** #link runway #3: Libvirt file backed memory: https://blueprints.launchpad.net/nova/+spec/libvirt-file-backed-memory (zcornelius) [END DATE: 2018-06-26] starts here https://review.openstack.org/571030

* Bugs (stuck/critical)
** [https://bugs.launchpad.net/nova/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress Critical bugs]
** #link 47 new untriaged bugs (up 3 since the last meeting): https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New
** #link 14 untagged untriaged bugs: https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW
** #link bug triage how-to: https://wiki.openstack.org/wiki/Nova/BugTriage#Tags
** #help need help with bug triage
** Gate status
*** #link check queue gate status http://status.openstack.org/elastic-recheck/index.html
** 3rd party CI
*** #link 3rd party CI status http://ci-watch.tintri.com/project?project=nova&time=7+days

* Reminders
** #link Rocky Subteam Patches n Bugs https://etherpad.openstack.org/p/rocky-nova-priorities-tracking

* Stable branch status:
** #link stable/queens: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/queens,n,z
** #link stable/pike: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike,n,z
** #link stable/ocata: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata,n,z

* Subteam Highlights
** Cells v2 (dansmith)
** Scheduler (edleafe)
** Notification (gibi) [2018.06.21]
*** I have some update top of the latest status mail #link http://lists.openstack.org/pipermail/openstack-dev/2018-June/131589.html
*** The implementation of the bp add-full-traceback-to-error-notifications has been merged and the bp has been set to Implemented. \o/
*** yikun picked up the implementation of the bp trigger-notifications-when-lock-unlock-instances and made a good job. I'm +2 on the patches
*** On the weekly meeting we talked a lot about https://bugs.launchpad.net/nova/+bug/1777157 and https://bugs.launchpad.net/nova/+bug/1777540 as it seem to be notification related. So far we don't see how can this happen and we are not able to reproduce what the original problem.
*** EOM
* Stuck Reviews
** Please note "stuck review" means a review where there is some disagreement that needs resolving. Its not for reviews that just haven't had attention, except for exceptional cases. Where you see "?" feel free to just edit the wiki and add your item.
** ?

* Open discussion
** ?

== Sub-teams ==

There are also some Nova subteam meetings. See [[Nova#Active_Sub-teams:]] for details.

== Previous meetings ==

* [http://eavesdrop.openstack.org/meetings/nova/ All other meetings are here]

[[category: compute]]
[[category: meetings]]

Meetings/NovaCellsv2

2018-03-13T21:31:19Z

Dan Smith:

= Weekly OpenStack Nova Cells v2 Meeting =

This is a weekly meeting to discuss the Nova Cells v2 effort. It's intended as a forum for:

* People to keep up with what work is going on with the Nova Cells v2 and where it is headed
* Helping coordinate ongoing development work
* [https://wiki.openstack.org/wiki/Nova-Cells-v2 Wiki page for Cell v2]

== Meetings ==

* Meeting Time: Weekly, Wednesdays alternating between 1700 and 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chaired by: Dan Smith

=== Next Meeting ===

==== Agenda ====

Please feel free to add items to the Agenda

* Bugs
** #link https://bugs.launchpad.net/nova/+bug/1755602 Ironic computes may not be discovered when node count is less than compute count
** #link https://bugs.launchpad.net/nova/+bug/1742649 map_instances default batch size is too small. (tssurya)
** #link https://bugs.launchpad.net/nova/+bug/1745358 Marker reset option for nova-manage map_instances (tssurya)
*** https://review.openstack.org/#/c/539501/
** #link https://bugs.launchpad.net/nova/+bug/1747936 Host is not unmapped when the host_mapping is deleted during delete_cell operation (tssurya)
*** https://review.openstack.org/#/c/542964/
** #link https://bugs.launchpad.net/nova/+bug/1749734 Purge comp_node and res_prvdr records during deletion of cells/hosts (tssurya)
*** https://review.openstack.org/#/c/546660/
** #link https://bugs.launchpad.net/nova/+bug/1753833 archive_deleted_rows --until-complete stops if api database is not configured (tssurya)
*** https://review.openstack.org/#/c/550967/
* Cells testing
* Open Reviews
* Open Discussion

=== Previous Meetings ===

http://eavesdrop.openstack.org/meetings/nova_cells/

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

Meetings/Nova

2018-03-13T16:36:34Z

Dan Smith:

= Weekly Nova team meeting =
'''MEETING TIME: Thursdays alternating 14:00 UTC (#openstack-meeting) and 21:00 UTC (#openstack-meeting)'''

This meeting is a weekly gathering of developers working on [[Nova|OpenStack Compute (Nova)]]. We cover topics such as release planning and status, bugs, reviews, and other current topics worthy of real-time discussion.

NOTE: this wiki page should be 'emptied' at the end of each meeting.

== Agenda for next meeting ==

Next meetings scheduled for:

* February 22nd 2018 1400 UTC, #openstack-meeting (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20180208T140000)
* No meeting the week of the PTG
* March 8th 2018 1400 UTC, #openstack-meeting (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20180208T140000)
<br>

Where you see "?" feel free to just edit the wiki and add your item.

Here is the agenda for the next meeting:
* Release News
** #link Queens release schedule: https://wiki.openstack.org/wiki/Nova/Queens_Release_Schedule
** #info Queens RC3 was released on 2018-02-22: https://review.openstack.org/#/c/547031
** #link Rocky release schedule: https://wiki.openstack.org/wiki/Nova/Rocky_Release_Schedule

* Bugs (stuck/critical)
** [https://bugs.launchpad.net/nova/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress Critical bugs]
** #info N new untriaged bugs (down N since the last meeting)
** #link bug triage how-to: https://wiki.openstack.org/wiki/Nova/BugTriage#Tags
** #link untagged untriaged bugs: https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW
** #help tag untagged untriaged bugs with appropriate tags to categorize them
** #help consider signing up as a bug tag owner and help determine the validity and severity of bugs with your tag
** Gate status
*** #link check queue gate status http://status.openstack.org/elastic-recheck/index.html
** 3rd party CI
*** #link 3rd party CI status http://ci-watch.tintri.com/project?project=nova&time=7+days

* Reminders
** #link Rocky PTG topics with actions and agreements recorded: https://etherpad.openstack.org/p/nova-ptg-rocky
** #info Rocky PTG nova session summaries to be sent out to the dev ML the week of March 12

* Stable branch status:
** #link stable/queens: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/queens,n,z
*** #info mriedem will propose a 17.0.1 queens patch release soon for a high severity multiattach bug
** #link stable/pike: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike,n,z
** #link stable/ocata: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata,n,z

* Subteam Highlights
** Cells v2 (dansmith)
** Scheduler (edleafe)
** Notification (gibi)

* Stuck Reviews
** Please note "stuck review" means a review where there is some disagreement that needs resolving. Its not for reviews that just haven't had attention, except for exceptional cases. Where you see "?" feel free to just edit the wiki and add your item.
** Any stuck code reviews to discuss:
** ?

* Open discussion
** (stephenfin) Specless blueprint for CPU weigher needs approval:
*** #link https://blueprints.launchpad.net/nova/+spec/vcpu-weighter
** (mriedem): blueprint for adding granular policy code to placement: https://blueprints.launchpad.net/nova/+spec/granular-placement-policy - does this need a spec?
** (mriedem): specless blueprint for tracking nova-network removal: https://blueprints.launchpad.net/nova/+spec/remove-nova-network
** (gibi): specless blueprint for including traceback in versioned error notifications: https://blueprints.launchpad.net/nova/+spec/add-full-traceback-to-error-notifications
** (dansmith): specless blueprint for xenapi aggregate removal (and related alternate pool implementation): https://blueprints.launchpad.net/nova/+spec/live-migration-in-xapi-pool

== Sub-teams ==

There are also some Nova subteam meetings. See [[Nova#Active_Sub-teams:]] for details.

== Previous meetings ==

* [http://eavesdrop.openstack.org/meetings/nova/ All other meetings are here]

[[category: compute]]
[[category: meetings]]

Meetings/Nova

2018-03-06T17:54:31Z

Dan Smith: /* Agenda for next meeting */

= Weekly Nova team meeting =
'''MEETING TIME: Thursdays alternating 14:00 UTC (#openstack-meeting) and 21:00 UTC (#openstack-meeting)'''

This meeting is a weekly gathering of developers working on [[Nova|OpenStack Compute (Nova)]]. We cover topics such as release planning and status, bugs, reviews, and other current topics worthy of real-time discussion.

NOTE: this wiki page should be 'emptied' at the end of each meeting.

== Agenda for next meeting ==

Next meetings scheduled for:

* February 22nd 2018 1400 UTC, #openstack-meeting (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20180208T140000)
* No meeting the week of the PTG
* March 8th 2018 1400 UTC, #openstack-meeting (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20180208T140000)
<br>

Where you see "?" feel free to just edit the wiki and add your item.

Here is the agenda for the next meeting:
* Release News
** #link Queens release schedule: https://wiki.openstack.org/wiki/Nova/Queens_Release_Schedule
** #info Queens RC3 was released on 2018-02-22: https://review.openstack.org/#/c/547031
** #link Rocky release schedule: https://wiki.openstack.org/wiki/Nova/Rocky_Release_Schedule
* Bugs (stuck/critical)
** [https://bugs.launchpad.net/nova/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress Critical bugs]
** #info N new untriaged bugs (down N since the last meeting)
** #link bug triage how-to: https://wiki.openstack.org/wiki/Nova/BugTriage#Tags
** #link untagged untriaged bugs: https://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW
** #help tag untagged untriaged bugs with appropriate tags to categorize them
** #help consider signing up as a bug tag owner and help determine the validity and severity of bugs with your tag
** Gate status
*** #link check queue gate status http://status.openstack.org/elastic-recheck/index.html
** 3rd party CI
*** #link 3rd party CI status http://ci-watch.tintri.com/project?project=nova&time=7+days
* Reminders
** #link Rocky PTG topics with actions and agreements recorded: https://etherpad.openstack.org/p/nova-ptg-rocky
** #info Rocky PTG nova session summaries to be sent out to the dev ML the week of March 12
* Stable branch status:
** #link stable/queens: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/queens,n,z
** #link stable/pike: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/pike,n,z
** #link stable/ocata: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata,n,z
* Subteam Highlights
** Cells v2 (dansmith)
** Scheduler (edleafe)
** Notification (gibi) - no meetings until after the PTG
* Stuck Reviews
** Please note "stuck review" means a review where there is some disagreement that needs resolving. Its not for reviews that just haven't had attention, except for exceptional cases. Where you see "?" feel free to just edit the wiki and add your item.
** Any stuck code reviews to discuss:
** ?
* Open discussion
** Spec-less blueprint for DB purging needs approval: (discussed informally at PTG):
*** #link https://blueprints.launchpad.net/nova/+spec/purge-db

== Sub-teams ==

There are also some Nova subteam meetings. See [[Nova#Active_Sub-teams:]] for details.

== Previous meetings ==

* [http://eavesdrop.openstack.org/meetings/nova/ All other meetings are here]

[[category: compute]]
[[category: meetings]]

Meetings/NovaCellsv2

2018-01-10T19:28:06Z

Dan Smith: /* Agenda */

= Weekly OpenStack Nova Cells v2 Meeting =

This is a weekly meeting to discuss the Nova Cells v2 effort. It's intended as a forum for:

* People to keep up with what work is going on with the Nova Cells v2 and where it is headed
* Helping coordinate ongoing development work
* [https://wiki.openstack.org/wiki/Nova-Cells-v2 Wiki page for Cell v2]

== Meetings ==

* Meeting Time: Weekly, Wednesdays alternating between 1700 and 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chaired by: Dan Smith

=== Next Meeting ===

==== Agenda ====

Please feel free to add items to the Agenda

* Bugs
** #link https://bugs.launchpad.net/nova/+bug/1735353 build_request not deleted when using cellsV1 and local nova_api DB (dansmith)
*** https://review.openstack.org/#/c/523187/
** #link https://bugs.launchpad.net/nova/+bug/1729806 nova-manage update_cell does not check if the same combination of transport_url and database_connection already exists (tssurya)
*** https://review.openstack.org/#/c/518556/
** #link https://bugs.launchpad.net/nova/+bug/1727266 archive_deleted_instances is not atomic for insert/delete (tssurya)
*** https://review.openstack.org/#/c/526065/
* Cells testing
* Open Reviews
* Open Discussion

=== Previous Meetings ===

http://eavesdrop.openstack.org/meetings/nova_cells/

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

Meetings/NovaCellsv2

2018-01-10T19:27:46Z

Dan Smith: /* Agenda */

= Weekly OpenStack Nova Cells v2 Meeting =

This is a weekly meeting to discuss the Nova Cells v2 effort. It's intended as a forum for:

* People to keep up with what work is going on with the Nova Cells v2 and where it is headed
* Helping coordinate ongoing development work
* [https://wiki.openstack.org/wiki/Nova-Cells-v2 Wiki page for Cell v2]

== Meetings ==

* Meeting Time: Weekly, Wednesdays alternating between 1700 and 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chaired by: Dan Smith

=== Next Meeting ===

==== Agenda ====

Please feel free to add items to the Agenda

* Bugs
** #link https://bugs.launchpad.net/nova/+bug/1735353 build_request not deleted when using cellsV1 and local nova_api DB (dansmith)
*** https://review.openstack.org/#/c/523187/
** #link https://bugs.launchpad.net/nova/+bug/1729806 nova-manage update_cell does not check if the same combination of transport_url and database_connection already exists (tssurya)
*** https://review.openstack.org/#/c/518556/
** #link https://bugs.launchpad.net/nova/+bug/1727266 archive_deleted_instances is not atomic for insert/delete (tssurya)
*** https://review.openstack.org/#/c/526065/
** #link https://bugs.launchpad.net/nova/+bug/1736946 Conductor: fails to clean up networking resources due to _destroy_build_request CantStartEngineError (mriedem)
*** https://review.openstack.org/#/c/528835/
* Cells testing
* Open Reviews
* Open Discussion

=== Previous Meetings ===

http://eavesdrop.openstack.org/meetings/nova_cells/

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

Meetings/NovaCellsv2

2018-01-10T19:21:38Z

Dan Smith: /* Agenda */

= Weekly OpenStack Nova Cells v2 Meeting =

This is a weekly meeting to discuss the Nova Cells v2 effort. It's intended as a forum for:

* People to keep up with what work is going on with the Nova Cells v2 and where it is headed
* Helping coordinate ongoing development work
* [https://wiki.openstack.org/wiki/Nova-Cells-v2 Wiki page for Cell v2]

== Meetings ==

* Meeting Time: Weekly, Wednesdays alternating between 1700 and 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chaired by: Dan Smith

=== Next Meeting ===

==== Agenda ====

Please feel free to add items to the Agenda

* Bugs
** #link https://bugs.launchpad.net/nova/+bug/1735353 build_request not deleted when using cellsV1 and local nova_api DB (dansmith)
*** https://review.openstack.org/#/c/523187/
** #link https://bugs.launchpad.net/nova/+bug/1729806 nova-manage update_cell does not check if the same combination of transport_url and database_connection already exists (tssurya)
*** https://review.openstack.org/#/c/518556/
** #link https://bugs.launchpad.net/nova/+bug/1727266 archive_deleted_instances is not atomic for insert/delete (tssurya)
*** https://review.openstack.org/#/c/526065/
** #link https://bugs.launchpad.net/nova/+bug/1737856 Listing instances with a marker doesn't nix the marker if it's found in build_requests (mriedem)
*** https://review.openstack.org/#/c/527564/
** #link https://bugs.launchpad.net/nova/+bug/1736946 Conductor: fails to clean up networking resources due to _destroy_build_request CantStartEngineError (mriedem)
*** https://review.openstack.org/#/c/528835/
* Cells testing
* Open Reviews
* Open Discussion

=== Previous Meetings ===

http://eavesdrop.openstack.org/meetings/nova_cells/

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

Forum/Boston2017

2017-05-08T02:26:26Z

Dan Smith:

The grand list of all of the Boston 2017 Forum etherpads. Please include Date, Time, and links to etherpads when adding new content. An [https://etherpad.openstack.org/p/BOS-forum-moderator-template etherpad template] (optional) is available if you need one.

'''See also - [https://www.openstack.org/summit/boston-2017/summit-schedule/#track=146 Full Forum Schedule]'''

'''See also - [[Forum/Boston2017#Thursday_Afternoon_session_sign-up|Thursday Afternoon session signup]]'''

'''See also - [https://ethercalc.openstack.org/Boston_Forum_Hacking_Rooms Hacking Rooms Schedule]'''

<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3">
__NOTOC__
</div>

= Event intro/closure =
* Forum 101 - https://etherpad.openstack.org/p/BOS-forum-101
* Boston feedback session - https://etherpad.openstack.org/p/BOS-summit-feedback

= Monday =
* [11:15am-11:55am] - Operating the VM and Baremetal platform (1/2) - https://etherpad.openstack.org/p/BOS-forum-operating-vm-and-baremetal
* [11:15am-12:45pm] - Nova - Project Onboarding - https://etherpad.openstack.org/p/BOS-forum-nova-project-onboarding
* [12:05pm-12:45pm] - OpenStack documentation: The future depends on all of us -
* [12:05pm-12:45pm] - WG chairs collaboration and WG overviews - https://etherpad.openstack.org/p/BOS-forum-wg-chairs-collaboration-and-WG-overviews
* [2:00pm-2:40pm] - Evolving the Community Generated Roadmap - https://etherpad.openstack.org/p/BOS-forum-evolving-the-community-generated-roadmap
* [2:50pm-3:30pm] - Evolving the User Survey - https://etherpad.openstack.org/p/BOS-forum-evolving-the-user-survey
* [2:50pm-3:30pm] - Future of Configuration Management - https://etherpad.openstack.org/p/BOS-forum-future-of-configuration-management
* [3:40pm-4:20pm] - Making keystone consumable outside of OpenStack - https://etherpad.openstack.org/p/BOS-forum-consumable-keystone
* [4:40pm-5:20pm] - Next steps for RBAC and policy - https://etherpad.openstack.org/p/BOS-forum-next-steps-for-rbac-and-policy
* [4:40pm-5:20pm] - Should we kill Stackalytics? - https://etherpad.openstack.org/p/BOS-forum-should-we-kill-stackalytics
* [4:40pm-5:20pm] - CellsV2 Developer/Operator/Community Coordination - https://etherpad.openstack.org/p/BOS-forum-cellsv2-developer-community-coordination
* [5:30pm-6:10pm] - How do you use Glance? - https://etherpad.openstack.org/p/BOS-forum-how-do-you-use-glance
* [5:30pm-6:10pm] - Using Searchlight to list instances across cells in nova-api - https://etherpad.openstack.org/p/BOS-forum-using-searchlight-to-list-instances

= Tuesday =
* [11:15am-11:55am] Feedback from Users for I18n & Translation - Important Part? - https://etherpad.openstack.org/p/BOS-forum-i18n-translation-feedback-from-users
* [12:05pm-12:45pm] Enhancing Log Message Headers for RT Debug and Traceability - https://etherpad.openstack.org/p/BOS-forum-log-messages
* [12:05pm-12:45pm] LCOO Roadmap Working Session - https://etherpad.openstack.org/p/BOS-forum-LCOORoadmap
* [2:00pm-2:40pm] ETSI NFV Specs’ Requirements vs OpenStack Reality - https://etherpad.openstack.org/p/BOS-ETSI-NFV-Specs-Reqs-vs-OpenStack-Reality
* [2:00pm-2:40pm] Swift ops feedback session - https://etherpad.openstack.org/p/BOS-Swift-ops-feedback-session
* [2:00pm-3:30pm] Barbican and Security Projects Onboarding - https://etherpad.openstack.org/p/BOS-forum-barbican-onboarding
* [2:50pm-3:30pm] Skip-level upgrading - jumping ahead to catch up - https://etherpad.openstack.org/p/BOS-forum-skip-level-upgrading
* [4:40pm-5:20pm] Using Cinder for Nova Ephemeral Storage Backend - https://etherpad.openstack.org/p/BOS-forum-using-cinder-for-nova-ephemeral-storage
* [5:30pm-6:10pm] Features missing in OpenStack core for Public Cloud provider - https://etherpad.openstack.org/p/BOS-forum-Features-Missing-For-Public-Clouds

= Wednesday =
* [9:00am-9:40am] Oslo developer/operator feedback - https://etherpad.openstack.org/p/BOS-Oslo-brainstorming
* [9:00am-9:40am] Special hardware - https://etherpad.openstack.org/p/BOS-forum-special-hardware
* [9:00am-9:40am] Collaboration between Telecom/NFV related groups - https://etherpad.openstack.org/p/BOS-forum-telecom-nfv-collaboration
* [9:50am-10:30am] oslo.messaging: Recommendations for Non-RabbitMQ Backends - https://etherpad.openstack.org/p/BOS_Forum_Oslo.Messaging_driver_recommendations
* [9:50am-10:30am] Vitrage Usability and New Insights: Where Do We Go Next? - https://etherpad.openstack.org/p/BOS-forum-vitrage-usability-and-new-insights
* [11:00am-11:40am] Compliance/Security Certification for upstream OpenStack - https://etherpad.openstack.org/p/BOS-forum-Compliance-Security-Certification
* [11:00am-11:40am] - Operating the VM and Baremetal platform (2/2) - https://etherpad.openstack.org/p/BOS-forum-operating-vm-and-baremetal
* [1:50pm-2:30pm] Kubernetes Ops on OpenStack - https://etherpad.openstack.org/p/BOS-forum-kubernetes-ops-on-openstack
* [1:50pm-2:30pm] App Developer Enablement - https://etherpad.openstack.org/p/BOS-forum-app-dev-enablement
* [1:50pm-2:30pm] Keystone Operator Feedback - https://etherpad.openstack.org/p/BOS-forum-keystone-operator-feedback
* [2:40pm-3:20pm] Product WG Working Session - https://etherpad.openstack.org/p/BOS-forum-product-wg-working-session
* [2:40pm-3:20pm] Key Management Developer/Operator/Community Coordination - https://etherpad.openstack.org/p/BOS-forum-key-management
* [3:30pm-4:10pm] Compute Instance/Volume Affinity for HPC - https://etherpad.openstack.org/p/BOS-forum-compute-instance-volume-affinity-hpc
* [4:30pm-5:10pm] Moving Resource Claims from nova-compute to nova-scheduler - https://etherpad.openstack.org/p/BOS-forum-move-claims-from-compute-to-scheduler
* [4:30pm-5:10pm] Ops Tags WG session - https://etherpad.openstack.org/p/BOS-forum-ops-tags-wg-session
* [5:20pm-6:00pm] Large Heat Stacks (users/ops/developers) - https://etherpad.openstack.org/p/BOS-forum-Large-Heat-stacks

= Thursday =
* [9:00am-9:40am] Users/Operators: Contributing Multi-Project Requirements - https://etherpad.openstack.org/p/BOS-forum-contributing-multi-project-requirements
* [9:00am - 9:40am] Users / Operators adoption of QA tools / plugins - https://etherpad.openstack.org/p/BOS-forum-qa-tools-plugins
* [9:50am-10:30am] - Writing Applications for the VM and Baremetal Platform - https://etherpad.openstack.org/p/BOS-forum-using-vm-and-baremetal
* [11:00am-12:30pm] Queens Goals - https://etherpad.openstack.org/p/BOS-forum-Queens-Goals
* [11:00am - 11:40] Zun Developer/Operator Feedback - https://etherpad.openstack.org/p/BOS-forum-zun-developer-operator-feedback
* [11:00am - 11:40] High Availability in OpenStack - https://etherpad.openstack.org/p/BOS-forum-HA-in-openstack
* [11:50am-12:30pm] Shared Commercial Goals for OpenStack Public Cloud Providers - https://etherpad.openstack.org/p/BOS-forum-Shared-Commercial-Goals-Public-Clouds
* [1:30pm-2:10pm] User Committee Session - https://etherpad.openstack.org/p/BOS-forum-user-committee-session
* [2:20pm-3:00pm] Cloud-aware Application Support - https://etherpad.openstack.org/p/pike-forum-cloud-applications
* [5:00pm-5:40pm] UC Governance and Support of WGs - https://etherpad.openstack.org/p/BOS-forum-uc-governance-and-support-of-wgs

==Thursday Afternoon session sign-up==
If something new comes up during the week, or a session runs over and you need more time, please sign up for another Fishbowl slot on Thursday Afternoon here:

<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3">
* 1:30-2:10 MR102 - available
* 2:20-3:00 MR102 - available
* 3:10-3:50 MR102 - available
* 3:50-4:10 MR102 - available
* 4:10-4:50 MR102 - available
* 5:00-5:40 MR102 - available
* 1:30-2:10 MR103 - available
* 2:20-3:00 MR103 - [https://etherpad.openstack.org/p/pike-forum-cloud-applications Cloud-aware Application Support]
* 3:10-3:50 MR103 - available
* 3:50-4:10 MR103 - available
* 4:10-4:50 MR103 - available
* 5:00-5:40 MR103 - available
* 1:30-2:10 MR104 - available
* 2:20-3:00 MR104 - available
* 3:10-3:50 MR104 - available
* 3:50-4:10 MR104 - available
* 4:10-4:50 MR104 - available
* 5:00-5:40 MR104 - [https://etherpad.openstack.org/p/pike-forum-tc-gathering TC members open gathering]
</div>

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

==(old) Brainstorming==
Below here were the etherpads used during the agenda brainstorming process...

====Catch-alls====
* [https://etherpad.openstack.org/p/BOS-TC-brainstorming TC Catch-all]
* [https://etherpad.openstack.org/p/BOS-UC-brainstorming UC Catch-all]

====Project Teams====

=====Barbican=====
Brainstorming: https://etherpad.openstack.org/p/BOS-Barbican-brainstorming

=====Cinder=====
Brainstorming: https://etherpad.openstack.org/p/BOS-Cinder-brainstorming

=====Freezer=====
Brainstorming: https://etherpad.openstack.org/p/BOS-Freezer-brainstorming

=====Glance=====
Brainstorming: https://etherpad.openstack.org/p/BOS-Glance-brainstorming

=====Heat=====
Brainstorming: https://etherpad.openstack.org/p/BOS-Heat-brainstorming

=====I18n=====
Brainstorming: https://etherpad.openstack.org/p/BOS-I18n-brainstorming

=====Ironic=====
Brainstorming: https://etherpad.openstack.org/p/BOS-ironic-brainstorming

=====Keystone=====
Brainstorming: https://etherpad.openstack.org/p/BOS-Keystone-brainstorming

=====Nova=====
Brainstorming: https://etherpad.openstack.org/p/BOS-Nova-brainstorming

=====Oslo=====
Brainstorming: https://etherpad.openstack.org/p/BOS-Oslo-brainstorming

=====Watcher=====
Brainstorming: https://etherpad.openstack.org/p/BOS-Watcher-brainstorming

=====QA=====
Brainstorming: https://etherpad.openstack.org/p/BOS-QA-brainstorming

=====Swift=====
Brainstorming: https://etherpad.openstack.org/p/BOS-Swift-brainstorming

====UC Working Groups ====

=====Telecom/NFV Requirements=====
https://etherpad.openstack.org/p/BOS-UC-brainstorming-Telecom&NFV

=====Scientific WG=====
https://etherpad.openstack.org/p/BOS-UC-brainstorming-scientific-wg

=====Massively Distributed (Fog/Edge) WG=====
https://etherpad.openstack.org/p/BOS-UC-brainstorming-MassivelyDistributed-Fog-Edge

=====Public Cloud WG=====
https://etherpad.openstack.org/p/publiccloud-boston-forum-session

====Other Working Groups====

=====VM and Bare-metal platform group=====

Developer lead group looking for user and operator feedback around the user experience across Nova, Ironic, Cinder and Neutron. Looking at both humans using the system, those operating the system, and projects building on the "VM and Bare-metal" platform. Main activity will be ranking the relative priority of current efforts, and looking to identify any gaps.

https://etherpad.openstack.org/p/BOS-TC-vm-baremetal-platform

Meetings/Nova

2017-03-06T22:11:31Z

Dan Smith:

Forum/Boston2017

2017-03-06T21:55:02Z

Dan Smith: /* Nova */

The grand list of all of the Boston Forum etherpads. Please include the name of the team that started the pad.

==Catch-alls==
* [https://etherpad.openstack.org/p/BOS-TC-brainstorming TC Catch-all]
* [https://etherpad.openstack.org/p/BOS-UC-brainstorming UC Catch-all]

==Team-specific==

===Nova===
Brainstorming: https://etherpad.openstack.org/p/BOS-Nova-brainstorming

===Telecom/NFV Requirements===
https://etherpad.openstack.org/p/BOS-UC-brainstorming-Telecom&NFV

===Scientific WG===
https://etherpad.openstack.org/p/BOS-UC-brainstorming-scientific-wg

Meetings/NovaCellsv2

2016-12-14T20:34:49Z

Dan Smith:

Meetings/NovaCellsv2

2016-12-14T20:21:44Z

Dan Smith: All participants expected to have a calendar

Meetings/NovaCellsv2

2016-11-16T19:04:25Z

Dan Smith: /* Next Meeting */

Nova

2016-11-08T17:45:26Z

Dan Smith: /* Developer Contacts */

[[Category:Compute]]

== Projects ==

=== Nova ===

{| border="1" cellpadding="2"
| Official name
| '''OpenStack Compute'''
|-
| Source code
| https://github.com/openstack/nova
|-
| Bug tracker
| https://bugs.launchpad.net/nova
|-
| Feature tracker
| https://blueprints.launchpad.net/nova
|-
| Developer doc
| http://docs.openstack.org/developer/nova/
|}

We align with what was the integrated release schedule, with three milestones. For Mitaka this means: [[Mitaka_Release_Schedule]]

But we do have some Nova specific process deadlines, please see [[Nova/Mitaka_Release_Schedule]] and [http://docs.openstack.org/developer/nova/process.html Nova Process]

=== Python Nova client ===
{| border="1" cellpadding="2"
| Source code
| https://github.com/openstack/python-novaclient
|-
| Bug tracker
| https://bugs.launchpad.net/python-novaclient
|-
| Feature tracker
| https://blueprints.launchpad.net/python-novaclient
|}

== People ==

* PTL
** Matt Riedemann (mriedem)
* [[Blueprints|Feature Drivers]]
** [https://launchpad.net/~nova-drivers/+members#active nova-drivers team]
* [[Nova/CoreTeam|Code Reviewers]]
** [https://review.openstack.org/#/admin/groups/25,members nova-core team]
* Blueprint Czar (responsible for maintenance of Nova's blueprint lists)
** TBC
* Bug Czar (responsible for organizing Nova's bug team that maintains Nova's bug list)
** Markus Zoeller (markus_z)
* Stable Branch Czar (works with stable maintenance team around Nova things)
** Matt Riedemann (mriedem)
* Security Czar (responsible for working with VMT and leading nova-coresec)
** Michael Still (mikal)
* Gate Czar (on top of the status of Nova in the CI gate)
** Matt Riedemann (mriedem)
* [[Nova/APIWGLiaisons|API Working Group Liaisons]]
** Alex Xu (alex_xu)
* [[Nova-Ironic|Ironic Liaison]]
** John Villalovos (jlvillal)
** Michael Davies (mrda) (backup)
* python-novaclient Czar
** TBC
* [[Nova/Mentoring|Mentoring]] Czar
** Augustina Ragwitz (auggy)
* Answers Czar
**
* Release Czar
** Sylvain Bauza (bauzas)
* Docs Czar
** TBC

For bug tag owners, please see: [[Nova/BugTriage | Nova Bug Triage ]]

For other folks, please see: [[CrossProjectLiaisons| Cross Project Liaisons (CPLs)]]

== General Resources ==

=== Documentation ===
* [http://docs.openstack.org/api/openstack-compute/2/content/ Compute API (v2) specification]
* [http://docs.openstack.org/trunk/openstack-compute/admin/content/ Administration Guide]

=== Release Process ===
* Nova releases are now done by providing the Release Manager with a git SHA to tag
* Client releases are done by following [[Nova/Client Release Process]]

=== Code Review Dashboards ===
* Many Nova reviewers use dashboards to help them decide what to review. [[Nova/GerritDashboards]] tracks some of our favorites.

=== Other resources ===
* Details about the [http://docs.openstack.org/developer/nova/support-matrix.html hypervisor support matrix]

== Resources for Contributors ==

=== Contributor Documentation ===

* [http://docs.openstack.org/infra/manual/developers.html General Developer's Guide]
* [http://docs.openstack.org/developer/nova/devref/index.html Nova Architecture and long term plan Docs]
* [http://docs.openstack.org/developer/nova/blueprints.html When you need a spec vs a blueprint]
* [http://specs.openstack.org/openstack/nova-specs/readme.html nova-spec process]
* [https://wiki.openstack.org/wiki/Nova/BugTriage Bug Triage Process and Bug tag owners]
* [[Nova/ReleaseChecklist]]

=== Nova subteams ===

The Nova team meets weekly: [[Meetings/Nova]].

In addition to a project-wide Nova gathering each week, there are some sub-teams. These sub-teams get together to discuss work going on in a focused area of Nova.

==== Code Review Subteam ====

Sub-teams don't need permission. They can be around for short or long periods of time.

A common pattern is an ad-hoc group of people, focusing on a sub set of reviews. They generally co-ordinate on here:
https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking

For each sub-team, the etherpad usually includes:
* list of people in the group (IRC nicks)
* list of patches the sub-team have reviewed, and think are ready for nova-core to approve
* list of patches the sub-team are focusing their reviews on
* May link to a regular meeting, but that is strictly optional

Over time, it is hoped, some sub-teams may become trusted enough to count as a +2. Even without counting as a +2, the review focus and implied prioritisation is still very valuable.

==== Sub-team Meetings ====

Some subteams are more formal, with a regular meeting and a wiki page.

* The linked wiki page should include:
** The mission of the team
** A regular meeting time
** A coordinator / point of contact
** Meeting Agenda
** Links to logs from previous meetings
* A sub-team representative should regularly attend the main Nova meeting to provide a sub-team status report.
* A sub-team is *not* exclusively responsible for an area of code. Anyone is welcome to contribute anywhere. However, you are encouraged to communicate regularly with others working in the same area as you and sub-teams help encourage that.
* A sub-team is about organizing development efforts, but not necessarily setting direction for the project in a given area. Approval of patches is still done by the nova-core team and it is beneficial to publish designs to the openstack-dev mailing list for vetting in advance.

===== Active Sub-teams: =====

TODO - this list is very out of date, need a better approach.

* [[Meetings/EC2API|EC2 API]]
* [[Meetings/Hyper-V|Hyper-V]]
* [[Meetings/NovaBugScrub|Nova Bugs]]
* [[Meetings/Scheduler|Scheduler]]
* [[Meetings/VMwareAPI|VMwareAPI]]
* [[Meetings/XenAPI|XenAPI]]
* [[Meetings/Libvirt|Libvirt]]
* [[Meetings/Containers|Containers]]
* Docker
* [[Meetings/NovaCellsv2|Cellsv2]]
* Virtuozzo
* SR-IOV - [http://eavesdrop.openstack.org/#SR-IOV/PCI_Passthrough_Meeting meeting times]
* [[Meetings/NovaAPI|NovaAPI]]
* [[Meetings/NovaNotification|NovaNotification]]
* [[Meetings/NovaLiveMigration|NovaLiveMigration]]

== History ==

* Previous PTLs
** Vish Ishaya (vishy), project beginning until Grizzly release
** Russell Bryant (russellb), Havana and Icehouse releases
** Michael Still (mikal), Juno and Kilo releases
** John Garbutt (johnthetubaguy), Liberty and Mitaka releases

* Previous or current core reviewers:
** Alex Xu
** Andrew Laski
** Brian D. Elliott
** Brian Lamar
** Brian Waldon
** Chris Behrens
** Chris Yeoh
** Dan Prince
** Dan Smith
** Daniel Berrange
** Devananda van der Veen
** Jay Pipes
** Joe Gordon
** Johannes Erdfelt
** John Garbutt
** Ken'ichi Ohmichi
** Kevin L. Mitchell
** Lorin Hochstein
** Mark McLoughlin
** Matt Dietz
** Matt Riedemann
** Melanie Witt
** Michael Still
** Nikola Dipanov
** Pádraig Brady
** Paul Voccio
** Rick Harris
** Russell Bryant
** Sandy Walsh
** Sean Dague
** Soren Hansen
** Sylvain Bauza
** Trey Morris
** Vishvananda Ishaya
** Yun Mao

== Developer Contacts ==
'''Work In Progress'''
The following is a list of major subsystems within Nova and people that you
can approach on IRC or email if you have questions about that particular
subsystem. IRC nicks are in parentheses.

Nova Objects Framework
- Dan Smith (dansmith)
- Jay Pipes (jaypipes)

libvirt virt driver
- Dan Berrange (danpb)

Hyper-V virt driver
- Claudiu Belu (claudiub)

VMWare/vCenter virt driver

- Gary Kotton (garyk)
- Radoslav Gerganov (rgerganov)

XenAPI virt driver

- Bob Ball (BobBall)
- John Garbutt (johnthetubaguy)

Ironic/bare metal

- Jim Rollenhagen (jroll)

Scheduling and resource tracking

- Sylvain Bauza (bauzas)
- Jay Pipes (jaypipes)

Block device mapping and volume attachments

- Matthew Booth (mdbooth)
- Feodor Tersin (ftersin)
- Lee Yarwood (lyarwood)

REST API

- Sean Dague (sdague)
- Alex Xu (alex_xu)

Database
- Jay Pipes (jaypipes)

Cells (v1 and v2)

- Dan Smith (dansmith)
- Melanie Witt (melwitt)

nova-network
- Dan Smith (dansmith)

Neutron
- Matt Riedemann (mriedem)

RPC
- Dan Smith (dansmith)

Notification system
- Balázs Gibizer (gibi)

PCI Devices / SRIOV
- Moshe Levi (moshele)
- Stephen Finucane (sfinucan)

== So, you want to learn more about Nova? ==

To learn more about Nova, please read out about [http://docs.openstack.org/developer/nova/how_to_get_involved.html Nova Mentoring]

----
[[Category:Nova]]

Nova

2016-11-08T17:43:08Z

Dan Smith: /* Developer Contacts */

[[Category:Compute]]

== Projects ==

=== Nova ===

{| border="1" cellpadding="2"
| Official name
| '''OpenStack Compute'''
|-
| Source code
| https://github.com/openstack/nova
|-
| Bug tracker
| https://bugs.launchpad.net/nova
|-
| Feature tracker
| https://blueprints.launchpad.net/nova
|-
| Developer doc
| http://docs.openstack.org/developer/nova/
|}

We align with what was the integrated release schedule, with three milestones. For Mitaka this means: [[Mitaka_Release_Schedule]]

But we do have some Nova specific process deadlines, please see [[Nova/Mitaka_Release_Schedule]] and [http://docs.openstack.org/developer/nova/process.html Nova Process]

=== Python Nova client ===
{| border="1" cellpadding="2"
| Source code
| https://github.com/openstack/python-novaclient
|-
| Bug tracker
| https://bugs.launchpad.net/python-novaclient
|-
| Feature tracker
| https://blueprints.launchpad.net/python-novaclient
|}

== People ==

* PTL
** Matt Riedemann (mriedem)
* [[Blueprints|Feature Drivers]]
** [https://launchpad.net/~nova-drivers/+members#active nova-drivers team]
* [[Nova/CoreTeam|Code Reviewers]]
** [https://review.openstack.org/#/admin/groups/25,members nova-core team]
* Blueprint Czar (responsible for maintenance of Nova's blueprint lists)
** TBC
* Bug Czar (responsible for organizing Nova's bug team that maintains Nova's bug list)
** Markus Zoeller (markus_z)
* Stable Branch Czar (works with stable maintenance team around Nova things)
** Matt Riedemann (mriedem)
* Security Czar (responsible for working with VMT and leading nova-coresec)
** Michael Still (mikal)
* Gate Czar (on top of the status of Nova in the CI gate)
** Matt Riedemann (mriedem)
* [[Nova/APIWGLiaisons|API Working Group Liaisons]]
** Alex Xu (alex_xu)
* [[Nova-Ironic|Ironic Liaison]]
** John Villalovos (jlvillal)
** Michael Davies (mrda) (backup)
* python-novaclient Czar
** TBC
* [[Nova/Mentoring|Mentoring]] Czar
** Augustina Ragwitz (auggy)
* Answers Czar
**
* Release Czar
** Sylvain Bauza (bauzas)
* Docs Czar
** TBC

For bug tag owners, please see: [[Nova/BugTriage | Nova Bug Triage ]]

For other folks, please see: [[CrossProjectLiaisons| Cross Project Liaisons (CPLs)]]

== General Resources ==

=== Documentation ===
* [http://docs.openstack.org/api/openstack-compute/2/content/ Compute API (v2) specification]
* [http://docs.openstack.org/trunk/openstack-compute/admin/content/ Administration Guide]

=== Release Process ===
* Nova releases are now done by providing the Release Manager with a git SHA to tag
* Client releases are done by following [[Nova/Client Release Process]]

=== Code Review Dashboards ===
* Many Nova reviewers use dashboards to help them decide what to review. [[Nova/GerritDashboards]] tracks some of our favorites.

=== Other resources ===
* Details about the [http://docs.openstack.org/developer/nova/support-matrix.html hypervisor support matrix]

== Resources for Contributors ==

=== Contributor Documentation ===

* [http://docs.openstack.org/infra/manual/developers.html General Developer's Guide]
* [http://docs.openstack.org/developer/nova/devref/index.html Nova Architecture and long term plan Docs]
* [http://docs.openstack.org/developer/nova/blueprints.html When you need a spec vs a blueprint]
* [http://specs.openstack.org/openstack/nova-specs/readme.html nova-spec process]
* [https://wiki.openstack.org/wiki/Nova/BugTriage Bug Triage Process and Bug tag owners]
* [[Nova/ReleaseChecklist]]

=== Nova subteams ===

The Nova team meets weekly: [[Meetings/Nova]].

In addition to a project-wide Nova gathering each week, there are some sub-teams. These sub-teams get together to discuss work going on in a focused area of Nova.

==== Code Review Subteam ====

Sub-teams don't need permission. They can be around for short or long periods of time.

A common pattern is an ad-hoc group of people, focusing on a sub set of reviews. They generally co-ordinate on here:
https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking

For each sub-team, the etherpad usually includes:
* list of people in the group (IRC nicks)
* list of patches the sub-team have reviewed, and think are ready for nova-core to approve
* list of patches the sub-team are focusing their reviews on
* May link to a regular meeting, but that is strictly optional

Over time, it is hoped, some sub-teams may become trusted enough to count as a +2. Even without counting as a +2, the review focus and implied prioritisation is still very valuable.

==== Sub-team Meetings ====

Some subteams are more formal, with a regular meeting and a wiki page.

* The linked wiki page should include:
** The mission of the team
** A regular meeting time
** A coordinator / point of contact
** Meeting Agenda
** Links to logs from previous meetings
* A sub-team representative should regularly attend the main Nova meeting to provide a sub-team status report.
* A sub-team is *not* exclusively responsible for an area of code. Anyone is welcome to contribute anywhere. However, you are encouraged to communicate regularly with others working in the same area as you and sub-teams help encourage that.
* A sub-team is about organizing development efforts, but not necessarily setting direction for the project in a given area. Approval of patches is still done by the nova-core team and it is beneficial to publish designs to the openstack-dev mailing list for vetting in advance.

===== Active Sub-teams: =====

TODO - this list is very out of date, need a better approach.

* [[Meetings/EC2API|EC2 API]]
* [[Meetings/Hyper-V|Hyper-V]]
* [[Meetings/NovaBugScrub|Nova Bugs]]
* [[Meetings/Scheduler|Scheduler]]
* [[Meetings/VMwareAPI|VMwareAPI]]
* [[Meetings/XenAPI|XenAPI]]
* [[Meetings/Libvirt|Libvirt]]
* [[Meetings/Containers|Containers]]
* Docker
* [[Meetings/NovaCellsv2|Cellsv2]]
* Virtuozzo
* SR-IOV - [http://eavesdrop.openstack.org/#SR-IOV/PCI_Passthrough_Meeting meeting times]
* [[Meetings/NovaAPI|NovaAPI]]
* [[Meetings/NovaNotification|NovaNotification]]
* [[Meetings/NovaLiveMigration|NovaLiveMigration]]

== History ==

* Previous PTLs
** Vish Ishaya (vishy), project beginning until Grizzly release
** Russell Bryant (russellb), Havana and Icehouse releases
** Michael Still (mikal), Juno and Kilo releases
** John Garbutt (johnthetubaguy), Liberty and Mitaka releases

* Previous or current core reviewers:
** Alex Xu
** Andrew Laski
** Brian D. Elliott
** Brian Lamar
** Brian Waldon
** Chris Behrens
** Chris Yeoh
** Dan Prince
** Dan Smith
** Daniel Berrange
** Devananda van der Veen
** Jay Pipes
** Joe Gordon
** Johannes Erdfelt
** John Garbutt
** Ken'ichi Ohmichi
** Kevin L. Mitchell
** Lorin Hochstein
** Mark McLoughlin
** Matt Dietz
** Matt Riedemann
** Melanie Witt
** Michael Still
** Nikola Dipanov
** Pádraig Brady
** Paul Voccio
** Rick Harris
** Russell Bryant
** Sandy Walsh
** Sean Dague
** Soren Hansen
** Sylvain Bauza
** Trey Morris
** Vishvananda Ishaya
** Yun Mao

== Developer Contacts ==
'''Work In Progress'''
The following is a list of major subsystems within Nova and people that you
can approach on IRC or email if you have questions about that particular
subsystem. IRC nicks are in parentheses.

Nova Objects Framework
- Dan Smith (dansmith)
- Jay Pipes (jaypipes)

libvirt virt driver
- Dan Berrange (danpb)

Hyper-V virt driver
- Claudiu Belu (claudiub)

VMWare/vCenter virt driver

- Gary Kotton (garyk)
- Radoslav Gerganov (rgerganov)

XenAPI virt driver

- Bob Ball (BobBall)
- John Garbutt (johnthetubaguy)

Ironic/bare metal

- Jim Rollenhagen (jroll)

Scheduling and resource tracking

- Sylvain Bauza (bauzas)
- Jay Pipes (jaypipes)

Block device mapping and volume attachments

- Matthew Booth (mdbooth)
- Feodor Tersin (ftersin)
- Lee Yarwood (lyarwood)

REST API

- Sean Dague (sdague)
- Alex Xu (alex_xu)

Database
- Jay Pipes (jaypipes)

Cells (v1 and v2)

- Dan Smith (dansmith)
- Melanie Witt (melwitt)

nova-network
- Dan Smith (dansmith)

Neutron
- Matt Riedemann (mriedem)

RPC and notification system
- Dan Smith (dansmith)

PCI Devices / SRIOV
- Moshe Levi (moshele)
- Stephen Finucane (sfinucan)

== So, you want to learn more about Nova? ==

To learn more about Nova, please read out about [http://docs.openstack.org/developer/nova/how_to_get_involved.html Nova Mentoring]

----
[[Category:Nova]]

Nova

2016-11-08T17:40:59Z

Dan Smith: /* Developer Contacts */

[[Category:Compute]]

== Projects ==

=== Nova ===

{| border="1" cellpadding="2"
| Official name
| '''OpenStack Compute'''
|-
| Source code
| https://github.com/openstack/nova
|-
| Bug tracker
| https://bugs.launchpad.net/nova
|-
| Feature tracker
| https://blueprints.launchpad.net/nova
|-
| Developer doc
| http://docs.openstack.org/developer/nova/
|}

We align with what was the integrated release schedule, with three milestones. For Mitaka this means: [[Mitaka_Release_Schedule]]

But we do have some Nova specific process deadlines, please see [[Nova/Mitaka_Release_Schedule]] and [http://docs.openstack.org/developer/nova/process.html Nova Process]

=== Python Nova client ===
{| border="1" cellpadding="2"
| Source code
| https://github.com/openstack/python-novaclient
|-
| Bug tracker
| https://bugs.launchpad.net/python-novaclient
|-
| Feature tracker
| https://blueprints.launchpad.net/python-novaclient
|}

== People ==

* PTL
** Matt Riedemann (mriedem)
* [[Blueprints|Feature Drivers]]
** [https://launchpad.net/~nova-drivers/+members#active nova-drivers team]
* [[Nova/CoreTeam|Code Reviewers]]
** [https://review.openstack.org/#/admin/groups/25,members nova-core team]
* Blueprint Czar (responsible for maintenance of Nova's blueprint lists)
** TBC
* Bug Czar (responsible for organizing Nova's bug team that maintains Nova's bug list)
** Markus Zoeller (markus_z)
* Stable Branch Czar (works with stable maintenance team around Nova things)
** Matt Riedemann (mriedem)
* Security Czar (responsible for working with VMT and leading nova-coresec)
** Michael Still (mikal)
* Gate Czar (on top of the status of Nova in the CI gate)
** Matt Riedemann (mriedem)
* [[Nova/APIWGLiaisons|API Working Group Liaisons]]
** Alex Xu (alex_xu)
* [[Nova-Ironic|Ironic Liaison]]
** John Villalovos (jlvillal)
** Michael Davies (mrda) (backup)
* python-novaclient Czar
** TBC
* [[Nova/Mentoring|Mentoring]] Czar
** Augustina Ragwitz (auggy)
* Answers Czar
**
* Release Czar
** Sylvain Bauza (bauzas)
* Docs Czar
** TBC

For bug tag owners, please see: [[Nova/BugTriage | Nova Bug Triage ]]

For other folks, please see: [[CrossProjectLiaisons| Cross Project Liaisons (CPLs)]]

== General Resources ==

=== Documentation ===
* [http://docs.openstack.org/api/openstack-compute/2/content/ Compute API (v2) specification]
* [http://docs.openstack.org/trunk/openstack-compute/admin/content/ Administration Guide]

=== Release Process ===
* Nova releases are now done by providing the Release Manager with a git SHA to tag
* Client releases are done by following [[Nova/Client Release Process]]

=== Code Review Dashboards ===
* Many Nova reviewers use dashboards to help them decide what to review. [[Nova/GerritDashboards]] tracks some of our favorites.

=== Other resources ===
* Details about the [http://docs.openstack.org/developer/nova/support-matrix.html hypervisor support matrix]

== Resources for Contributors ==

=== Contributor Documentation ===

* [http://docs.openstack.org/infra/manual/developers.html General Developer's Guide]
* [http://docs.openstack.org/developer/nova/devref/index.html Nova Architecture and long term plan Docs]
* [http://docs.openstack.org/developer/nova/blueprints.html When you need a spec vs a blueprint]
* [http://specs.openstack.org/openstack/nova-specs/readme.html nova-spec process]
* [https://wiki.openstack.org/wiki/Nova/BugTriage Bug Triage Process and Bug tag owners]
* [[Nova/ReleaseChecklist]]

=== Nova subteams ===

The Nova team meets weekly: [[Meetings/Nova]].

In addition to a project-wide Nova gathering each week, there are some sub-teams. These sub-teams get together to discuss work going on in a focused area of Nova.

==== Code Review Subteam ====

Sub-teams don't need permission. They can be around for short or long periods of time.

A common pattern is an ad-hoc group of people, focusing on a sub set of reviews. They generally co-ordinate on here:
https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking

For each sub-team, the etherpad usually includes:
* list of people in the group (IRC nicks)
* list of patches the sub-team have reviewed, and think are ready for nova-core to approve
* list of patches the sub-team are focusing their reviews on
* May link to a regular meeting, but that is strictly optional

Over time, it is hoped, some sub-teams may become trusted enough to count as a +2. Even without counting as a +2, the review focus and implied prioritisation is still very valuable.

==== Sub-team Meetings ====

Some subteams are more formal, with a regular meeting and a wiki page.

* The linked wiki page should include:
** The mission of the team
** A regular meeting time
** A coordinator / point of contact
** Meeting Agenda
** Links to logs from previous meetings
* A sub-team representative should regularly attend the main Nova meeting to provide a sub-team status report.
* A sub-team is *not* exclusively responsible for an area of code. Anyone is welcome to contribute anywhere. However, you are encouraged to communicate regularly with others working in the same area as you and sub-teams help encourage that.
* A sub-team is about organizing development efforts, but not necessarily setting direction for the project in a given area. Approval of patches is still done by the nova-core team and it is beneficial to publish designs to the openstack-dev mailing list for vetting in advance.

===== Active Sub-teams: =====

TODO - this list is very out of date, need a better approach.

* [[Meetings/EC2API|EC2 API]]
* [[Meetings/Hyper-V|Hyper-V]]
* [[Meetings/NovaBugScrub|Nova Bugs]]
* [[Meetings/Scheduler|Scheduler]]
* [[Meetings/VMwareAPI|VMwareAPI]]
* [[Meetings/XenAPI|XenAPI]]
* [[Meetings/Libvirt|Libvirt]]
* [[Meetings/Containers|Containers]]
* Docker
* [[Meetings/NovaCellsv2|Cellsv2]]
* Virtuozzo
* SR-IOV - [http://eavesdrop.openstack.org/#SR-IOV/PCI_Passthrough_Meeting meeting times]
* [[Meetings/NovaAPI|NovaAPI]]
* [[Meetings/NovaNotification|NovaNotification]]
* [[Meetings/NovaLiveMigration|NovaLiveMigration]]

== History ==

* Previous PTLs
** Vish Ishaya (vishy), project beginning until Grizzly release
** Russell Bryant (russellb), Havana and Icehouse releases
** Michael Still (mikal), Juno and Kilo releases
** John Garbutt (johnthetubaguy), Liberty and Mitaka releases

* Previous or current core reviewers:
** Alex Xu
** Andrew Laski
** Brian D. Elliott
** Brian Lamar
** Brian Waldon
** Chris Behrens
** Chris Yeoh
** Dan Prince
** Dan Smith
** Daniel Berrange
** Devananda van der Veen
** Jay Pipes
** Joe Gordon
** Johannes Erdfelt
** John Garbutt
** Ken'ichi Ohmichi
** Kevin L. Mitchell
** Lorin Hochstein
** Mark McLoughlin
** Matt Dietz
** Matt Riedemann
** Melanie Witt
** Michael Still
** Nikola Dipanov
** Pádraig Brady
** Paul Voccio
** Rick Harris
** Russell Bryant
** Sandy Walsh
** Sean Dague
** Soren Hansen
** Sylvain Bauza
** Trey Morris
** Vishvananda Ishaya
** Yun Mao

== Developer Contacts ==
'''Work In Progress'''
The following is a list of major subsystems within Nova and people that you
can approach on IRC or email if you have questions about that particular
subsystem. IRC nicks are in parentheses.

Nova Objects Framework
- Dan Smith (dansmith)
- Jay Pipes (jaypipes)

libvirt virt driver
- Dan Berrange (danpb)

Hyper-V virt driver
- Claudiu Belu (claudiub)

VMWare/vCenter virt driver

- Gary Kotton (garyk)
- Radoslav Gerganov (rgerganov)

XenAPI virt driver

- Bob Ball (BobBall)
- John Garbutt (johnthetubaguy)

Ironic/bare metal

- Jim Rollenhagen (jroll)

Scheduling and resource tracking

- Sylvain Bauza (bauzas)
- Jay Pipes (jaypipes)

Block device mapping and volume attachments

- Matthew Booth (mdbooth)
- Feodor Tersin (ftersin)
- Lee Yarwood (lyarwood)

REST API

- Sean Dague (sdague)
- Alex Xu (alex_xu)

Database
- Jay Pipes (jaypipes)

Cells (v1 and v2)

- Dan Smith (dansmith)
- Melanie Witt (melwitt)

nova-network
- Dan Smith (dansmith)

Neutron
- Matt Riedemann (mriedem)

RPC and notification system
- Dan Smith (dansmith)

PCI Devices
- Moshe Levi (moshele)

== So, you want to learn more about Nova? ==

To learn more about Nova, please read out about [http://docs.openstack.org/developer/nova/how_to_get_involved.html Nova Mentoring]

----
[[Category:Nova]]

Obsolete:UnifiedServiceArchitecture

2016-05-11T23:03:30Z

Dan Smith: Dan Smith moved page UnifiedServiceArchitecture to Obsolete:UnifiedServiceArchitecture

* '''Launchpad Entry''': NovaSpec:unified-service-architecture
* '''Created''': 2010-10-25
* '''Contributors''': termie

== Summary ==

The approaches to launching a long-running service in Nova are currently disparate, relying on a variety of underlying platforms and libraries and creating an abundance of integration and adaptation issues.

Currently in use are:
* Twisted's Application/Service, along with `twistd` (maintaining custom version of Twisted)
* Twisted's Application/Service using alternate custom approaches
* Twisted's Web
* eventlet's wsgi
* the python-daemon library

This proposal suggests standardizing on eventlet only and providing a common toolset for all services. It also suggests standardizing the interface provided to the system by the services to directly interact with common supervisor tools.

== Release Note ==

Dependencies on Twisted and python-daemon have been removed as of this release, services are now all based on eventlet and are expected to be managed by a supervisor process (e.g. initd, upstart or daemontools) on your production systems.

Additionally, for use in testing and development, `bin/nova-combined` has been added to support running the entire nova system in a single process.

== Rationale ==

=== eventlet vs Twisted ===

Multiple underlying platforms has led to considerable duplication of effort and many sections of code that have fallen into legacy status despite being such a young project.

As frequent development hurdles have been run into directly related to the complexity of doing most of the simple operations with Twisted's patterns, Twisted should be removed in favor of eventlet, whose patterns more consistently meet the expectations of developers for simple tasks.

For more complex tasks there will still be no substitute for deep understanding of the platform, but eventlet is expected to lower the learning curve significantly.

Additionally, while Twisted's twistd tool and current usage of it provided many useful features during initial development (uid management, logging, pidfiles and daemonization to name a few), those features are either better handled by a supervisor (uid management, daemonization, pidfiles), or easily available in eventlet (logging) without the overhead or hacks required to use twistd.

Nova is also maintaining a custom version of Twisted to make use of patches in Twisted's core that have not made it into released packages resulting in wasted time for developers and end-users who have to install this custom package.

In a quick investigation into the extent of such a change, it was found that in almost all cases code was switched to eventlet simply by the removal of boilerplate code used by Twisted.

=== supervisors vs daemonization ===

There are a variety of powerful, common and reliable supervisor systems in use and all of them handle the initialization, setting uid, dealing with output, starting, stopping and restarting of services in standard ways that are already well integrated with the underlying operating system with no need for Nova to maintain its own tools or depend on libraries to handle the same use cases.

Providing a simple wrapper for use in testing and development is all Nova needs to do.

== User stories ==

== Assumptions ==

* Twisted is not providing any desired and used features that cannot be implemented reasonably quickly in eventlet.
* eventlet's patterns for handling non-blocking calls are intuitively closer than Twisted's to what most developers expect to write in the vast majority of cases.

== Design ==

There are two fundamental types of services involved in Nova, System services and Web services, however the code required to launch either can be roughly the same.

This design will walk through the various stages at which a developer interacts with the service layer. All in all it very similar to the majority of the current modern services and is simply requiring that all services conform.

=== The Binary ===

As is the case in a majority of System services already, the actual code required to 'run' the service in the bin/nova-* script can be the same in all cases with the appropriate flag being looked up to determine which Manager class the Service wrapper will use.

Web services will use a similar pattern but with a simplified Service wrapper that is only meant to deal with WSGI.

=== The Service Wrappers ===

These will remain largely as they exist now and follow the form:

* <classmethod> Service.create(): Determine service to run based on given flags and binary, and return the Service instance.
* Service.start(): Instantiate the manager class, and push its main loop, (which for a System service is listening to the queue and for a Web service is listening to the web) and set up the monitoring interfaces (currently using a heartbeat mechanism).
* Service.stop(): Disconnect from queue and attempt a clean shutdown of the service.
* Proxying messages from the queue to the Manager.
* Signal handling to detect hard and soft shutdowns.

In most cases the developer will have no interaction with the Service wrapper, all the interaction will take place on the Manager level and by setting a flag of the form `<servicename>_manager`

=== The Manager ===

This is basically freeform with a minimal interface consisting of a couple optional hooks the Service can use to allow the Manager to register periodic tasks when the Manager is loaded in a Service context.

A System Manager consists of methods triggered by the queue in the Service context or by another Manager outside of the Service context.

A Web Manager consists of WSGI handlers triggered off of web requests.

=== Soft Shutdowns ===

Some functionality involves calling methods that may take a long time to complete, it is suggested that the Service layer track calls taking place in the Manager layer and wait to exit until they have completed.

=== Idempotent Restarts ===

Being managed by a supervisor has the benefit of being able to restart your process should it die for any reason, the Service layer and the Manager layer should do their best to recover from any failures by ensuring the system is in a sane state when restarting.

== Implementation ==

=== UI Changes ===

The UI in this case is the command-line.

Various twistd and daemonization related flags will be removed, for example --guid and --pidfile, as that functionality will be expected from the supervisor.

=== Code Changes ===

In almost all cases the move from Twisted to eventlet involves simply removing `yield` and `@defer.inlineCallbacks` wherever they are present, along with replacing `defer.returnValue(x)` with `return x`.

In a few cases there is use of twisted.task.[[LoopingCall]] which is easily replaced with an eventlet version (see nova.utils.[[LoopingCall]] in the related branch)

The larger pieces of work will be:

* Replacing the nova.process.[[ProcessPool]] pieces simply because its return signature and error conditions are fairly varied, but eventlet's subprocess module should handle the basic functionality fine.
* Moving Objectstore off of twisted.web and onto an eventlet/wsgi based system. It should be noted however that Objectstore is very nearly deprecated so this may not be required.
* Various testing code uses Twisted's Trial's [[SkipTest]] feature of which there is no specific eventlet feature, however the feature is largely superfluous and could be handled conditionally if `nosetests` were being used.
* Testing code in nova.test would generally have to be mildly adapted not to expect Deferreds.

Related branch: http://code.launchpad.net/~termie/nova/eventlet_merge

=== Migration ===

Code only change, no data migration.

While it is possible to run eventlet and Twisted side by side, the goal of this proposal is to standardize _all_ the services and would preferably take place all at once so that no time is wasted writing code to adapt twisted's defer.inlineCallback results to eventlet.

== Test/Demo Plan ==

Normal unit tests are expected to run.

If smoketests are still applicable they should be functional as well without changes.

== Unresolved issues ==

* It is unclear whether subprocesses, multiple processes, multiple threads or multiple greenthreads will be the preferred way to handle some kinds of long tasks. Eventlet does provide straightforward ways of handling all but the multiple processes solution, and will probably be sufficient.
* Existing integration testing via smoketests may be insufficient to locate all bugs related to the transition so it may take longer to verify that the transition is complete.

== BoF agenda and discussion ==

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

----
[[Category:Spec]]

UnifiedServiceArchitecture

2016-05-11T23:03:30Z

Dan Smith: Dan Smith moved page UnifiedServiceArchitecture to Obsolete:UnifiedServiceArchitecture

#REDIRECT [[Obsolete:UnifiedServiceArchitecture]]

Obsolete:Cinder/EMCVolumeDriver

2016-05-11T19:26:49Z

Dan Smith: Dan Smith moved page Cinder/EMCVolumeDriver to Obsolete:Cinder/EMCVolumeDriver

* '''Launchpad Entry''':
* '''Created''': 12 December 2012
* '''Contributors''': Xing Yang

== Summary ==
We would like to introduce support for EMC storage in the Cinder-Volume service. This blueprint proposes a driver based on the existing ISCSIDriver, with the ability to create/delete and attach/detach volumes and create/delete snapshots, etc.

The Cinder Driver executes the volume operations by communicating with the backend EMC storage. It uses a CIM client in python called PyWBEM to make CIM operations over HTTP.

EMC CIM Object Manager (ECOM) is packaged with the SMI-S Provider. It is a CIM server that allows CIM clients to make CIM operations over HTTP, using SMI-S in the backend for EMC storage operations.

SMI-S Provider supports the SNIA Storage Management Initiative (SMI), an ANSI standard for storage management. It supports VMAX/VMAXe and VNX storage systems.

== Release Note ==
For the initial implementation we would like to provide the ability to create, delete, attach, and detach VMAX/VMAXe and VNX volumes to nova-compute VM's via iSCSI.

The following operations will be supported on both VMAX/VMAXe and VNX arrays:
* Create volume
* Delete volume
* Attach volume
* Detach volume
Snapshot is not supported on VMAXe with SMI-S 4.5.0. Support will be added in SMI-S 4.5.1 which is scheduled to release in Q1 2013. The following operations will be supported on VMAX and VMAX arrays.
* Create snapshot
* Delete snapshot
The following operations will be supported on VNX only:
* Create volume from snapshot

Only thin provisioning is supported by EMC Cinder Plugin.

== Rationale ==
== User stories ==
User needs to install pyWBEM on the cinder-volume node. pyWBEM is opensource and can be downloaded from http://sourceforge.net.

User also needs to set flags in /etc/cinder.conf, and starts/restarts cinder-volume service.

Example cinder.conf entries:

--iscsi_target_prefix = iqn.2001-07.com.vnx

--iscsi_ip_address = 10.10.61.35

--volume_driver = cinder.volume.emc.EMCISCSIDriver

--cinder_emc_config_file = /opt/stack/cinder/etc/cinder/cinder_emc_config.xml

Cinder-volume doesn't need to be restarted if you changed cinder_emc_config.xml. Example cinder_emc_config.xml entries is in the following. [[MaskingView]] is only needed for VMAX/VMAXe arrays.

<?xml version='1.0' encoding='UTF-8'?>

<EMC>

<[[StorageType]]>gold</StorageType>

<[[MaskingView]]>openstack</MaskingView>

<[[EcomServerIp]]>x.x.x.x</EcomServerIp>

<[[EcomServerPort]]>xxxx</EcomServerPort>

<[[EcomUserName]]>xxxxxxxx</EcomUserName>

<[[EcomPassword]]>xxxxxxxx</EcomPassword>

</EMC>

EMC VMAX/VMAXe or VNX storage should now be available for use by [[OpenStack]] for additional block storage.

This has been tested with the Folsom release using Horizon and Cinder CLI.

== Assumptions ==
== Notes ==
== Design ==
Subclass implementation of the ISCSIDriver in cinder/volume/driver.py

create-volume:

* In create_volume, one SMI-S method call is invoked to create a volume of the specified size.

Class: EMC_StorageConfigurationService

Method: [[CreateOrModifyElementFromStoragePool]]

delete-volume:

* In delete_volume, one SMI-S method call is invoked to delete the specified volume.

Class: EMC_StorageConfigurationService

Method: EMCReturnToStoragePool

create-volume-from-snapshot:

* In create_volume_from_snapshot, two SMI-S method calls are involved. First a target volume is created from a source snapshot. Then the clone relationship will be removed so the new volume can be used independently from the source snapshot.
Class: EMC_ReplicationService
Method: [[CreateElementReplica]]

create-snapshot:

* In create_snapshot, one SMI-S method call is invoked to create a target snapshot from a source volume. This will create a target element (the snapshot) as well as a snap session. For VNX, a new VNX snapshot will be created, not the Snapview snapshot.
Class: EMC_ReplicationService
Method: [[CreateElementReplica]]

delete-snapshot:
* In delete_snapshot, one SMI-S method call is invoked to delete both the target element and the snap session.
Class: EMC_ReplicationService
Method: [[ModifyReplicaSynchronization]]

ensure-export:
* Ensure_export finds the DeviceID of an EMC_StorageVolume object and writes it in provider_location field of a volume entry in the Cinder database.

create-export:
* Create_export finds the DeviceID of an EMC_StorageVolume object and writes it in provider_location field of a volume entry in the Cinder database.

delete-export:
* No operation is performed in this method as it is not necessary.

initialize-connection:
* In initialize_connection, a volume is mapped to a compute node, then an iSCSI discovery is done, and the volume’s iscsi property including the IQN of the iSCSI target, the portal of the iSCSI target, the lun of the iSCSI target, and the id of the volume, will be returned to the caller.
* VNX and VMAX/VMAXe have different implementations for lun mapping. Masking and Mapping subprofile in SMI-S is available for VNX lun mapping. Masking and Mapping profile in SMI-S is available to use groups of Initiators, Target Ports, and Volumes on Symmetrix arrays running Enginuity 5874 and higher. The Cinder Plugin implementation only supports Symmetrix arrays running Enginuity 5874 and higher.
* For VNX, the following SMI-S method call is invoked to map a lun to a host.
Class: EMC_ControllerConfigurationService
Method: [[ExposePaths]]

* For VMAX, the following SMI-S method call is invoked to map a lun to a host.
Class: EMC_ControllerConfigurationService
Method: [[AddMembers]]

terminate-connection:
* In terminate_connection, a volume is unmapped from a compute node.
* VNX and VMAX/VMAXe have different implementations for lun mapping. Masking and Mapping subprofile in SMI-S is available for VNX lun mapping. Masking and Mapping profile in SMI-S is available to use groups of Initiators, Target Ports, and Volumes on Symmetrix arrays running Enginuity 5874 and higher. The Cinder Plugin implementation only support Symmetrix arrays running Enginuity 5874 and higher.
* For VNX, the following SMI-S method call is invoked to unmap a lun from a host.
Class: EMC_ControllerConfigurationService
Method: [[HidePaths]]
* For VMAX, the following SMI-S method call is invoked to unmap a lun from a host.
Class: EMC_ControllerConfigurationService
Method: [[RemoveMembers]]

Cinder/EMCVolumeDriver

2016-05-11T19:26:49Z

Dan Smith: Dan Smith moved page Cinder/EMCVolumeDriver to Obsolete:Cinder/EMCVolumeDriver

#REDIRECT [[Obsolete:Cinder/EMCVolumeDriver]]

Obsolete:GlanceSwiftTenantSpecificStorage

2016-05-11T19:22:15Z

Dan Smith: Dan Smith moved page GlanceSwiftTenantSpecificStorage to Obsolete:GlanceSwiftTenantSpecificStorage

= Glance Tenant Specific Storage =

== Goal ==

Store image data in the authenticated user's swift account.

== Existing behaviour (as of Essex) ==

Currently Glance swift stores public and private images in a single swift account. The username and password credentials for this account are stored both in the Glance API config file and in the 'location' field within the database. This password is duplicated in the 'location' field for every single image within the database. A typical location URL which is stored in the database when using single tenant Swift storage may look like this:

`swift+http://user:pass@authurl.com/container/obj-id`

Glance manages access to public images and per user image membership internally. Access to the backend swift store always requires a username:password which is typically obtained from the 'location' URI and/or the Glance config file.

It is also important to note that Glance currently stores images within a single Swift container.

== New behavior ==

When using Glance with swift in multi-tenant storage mode the username/password for the Swift account is not stored in the database. The auth token for the authenticated user is used to access swift images from the backend store.

A typical 'location' URI in the Glance database might look like this when using multi-tenant storage:

`swift+https://storage_url.com/container/obj-id`

Note: In this form the storage_url is used instead of the auth_url which is used in the single tenant format.

Glance will need to set permissions on individual images in the backend Swift store to allow either public or per member/tenant access.

Implementation changes:

* Update Glance so that it uses the service catalog for each user to obtain the Swift storage URL.
* Provide backend stores access to the context. Glance Essex doesn't give stores access to the [[RequestContext]] (auth token). We'll need this information for tenant specific storage if we want to be able to access individual swift accounts.
* Store images in separate containers. Swift only allows individual ACL's to be set per container... not per object. As such it appears we'll need to store each image in a separate container in order to support setting public and/or individual read/write access on each image.
* Set 'public' access for images in Swift.
* Set 'private' read and/or write access for Glance image members which have been granted access to specific images.
* Delayed delete (scrubber) will require an authenticated context in order to delete Swift images from the backend. Glance can either be make to grant write access to this account (for all images) or an administrative Swift account could be used to run the delayed delete operation.
* Maintain full support with the existing single tenant Glance swift storage scheme.

-----

To be done:

* Config options to select a specific service_type and/or endpoint URL from the service catalog for the swiftclient connections. Swiftclient doesn't support these options yet so we'll need to add them there first... These options would be useful if a deployer wanted to have two installations of Swift (one for Glance, and one for General use). It might also be uesful to use an alternate internal swift endpoint by default.

GlanceSwiftTenantSpecificStorage

2016-05-11T19:22:15Z

Dan Smith: Dan Smith moved page GlanceSwiftTenantSpecificStorage to Obsolete:GlanceSwiftTenantSpecificStorage

#REDIRECT [[Obsolete:GlanceSwiftTenantSpecificStorage]]

Obsolete:GlanceZone

2016-05-11T19:16:58Z

Dan Smith: Dan Smith moved page GlanceZone to Obsolete:GlanceZone

= Glance Zones =

== Assumptions ==

# We need to use integer IDs to maintain backwards compatability with [[OpenStack]] API v1.X

== Problem ==

How do we organize Glance within Zones so that we can:

# Discover available images for a customer
# Efficiently and reliably backup instances
# Support globally available images

Currently, region-level Nova zones contain a Glance API, Glance Registry, and
Swift instance. Base install and snapshot data reside within Swift while the
metadata exists in the Glance Registry.

Storing the backup data in a zone local Swift makes a lot of sense in terms of
isolation and performance. Assuming that this Swift instance is publicly
accessible, this will mean that image data is available globally.

The problem lies with the metadata. While a region-level Glance Registry has
the same benefits in terms of performance and isolation as the region-level
Swift, it introduces several large problems:

# Image discovery is difficult because there is no clear way for discovering which zones are present globally and what images they possess
# Base install data and metadata needs to be replicated into the zone which creates a burden on Ops to keep the images in sync
# The [[OpenStack]] API requires images to have a single globally unique integer ID. Since each zone would possess its own Glance Registry database, it's not clear who would be the arbiter of this ID.

== Proposed Solution ==

To solve the problems mentioned above, we propose replacing the region-level
Glance Registries with a single global Glance Registry.

In this plan, each region would maintain its own Swift and Glance API servers
which would keep the heavy traffic--the image data--within the zone. But, the
metadata would be pushed up to this central location.

This has a number of benefits:

# Image discovery is trivial: we just query the global Registry for the available images for a given customer
# Base install management is easy: the metadata is stored in the registry just like any other image and we serve the data out of a single base install Swift instance.
# We get the globally unique ID for free by using the databases AUTOINCREMENT ID column

Of course, there is one potentially large drawback to this approach: we're
introducing a single point of failure. This has important performance and
availability implications which are addressed below.

== Analysis ==

=== Performance ===

The first question to ask is: can a single global Glance Registry provide the
performance characteristics we need?

The Glance Registry is really two components, a small web server exposing a
REST interface and a traditional RDBMS storing the metadata. Given that the
web servers can scale horizontally, the bottleneck is really the database.

For a first approximation, assume we're trying to scale to 1 million
instances. For backups, in the worst case, each instance has daily backups
turned on, meaning we'll have to accommodate 10**6/86400 or about 12 write
transactions per second [2]. This volume is low enough to be a non-issue.

Read performance can be scaled as well. First, we can use read-only
slaves to increase the throughput (as well as geographically dispersing them
to reduce latency). Second, we can avoid round-trips to the global
registry entirely by caching the responses within each region. This will mean
that many requests (in particular base installs), will be able to satisfied
without having to go outside of the zone (giving us back the isolation and
performance we want).

=== Availability ===

Another critical question is: what happens when (not if) the Glance Registry
goes off-line? Will this cause instance-builds and backups to fail across the entire
[[OpenStack]] deployment?

=== Builds ===

Since the region-level zone is caching image-metadata, it is very likely that
the base install metadata will be present in the cache. This means that base
installs, even with the global registry down, will still build.

Customer backups, however, will likely not be available for building during
the period when the Glance Registry is down since they are unlikely to be
cached.

=== Backup Jobs ===

The Glance Registry being down imposes two problem for backup jobs:

# There is no place to write the image-metadata
# There is no way to obtain the globally unique image identifier

The first problem can be mitigated by queuing writes until the Glance Registry
becomes available again.

The second problem can be addressed by generating non-overlapping blocks of
IDs and handing them off to each Zone. The zone-level Glance APIs can then use
the ID blocks to return image IDs until the block is exhausted, at which point
they request another. By having these IDs present within the zone, backups
will be able to continue in the face of Glance-Registry downtime.

== Conclusions ==

# Make the Glance Registry global
# Scale master database vertically to improve write throughput (if needed), use read-only slaves to increase read throughput and reduce latency (by dispersing them geographically)
# Use image-metadata caching to avoid round-trips to the Glance Registry as well as provide image availability in the face of downtime
# Queue writes within the zone so that that backup jobs can finish even if the Glance Registry is down
# Allocate blocks of image-IDs to each zone to allow the [[OpenStack]] API to return from a snapshot request without having to make a round-trip to the Glance Registry as well as allowing the backup job to complete in the event of Glance Registry downtime.Or use UUIDs.

== Open Questions ==

# Since customer-backups and snapshots are much less likely to be cached at the region level, this approach doesn't allow customers to build from backups and snapshots when the Glance Registry is down. Is this acceptable for a first cut? What are the potential solutions here?
# At what point can we transition to something more scalable than integer IDs for images?

Diagrams

[[attachment:GlanceZones.png]]

== Footnotes ==

# In order to do so, we would need either a central zone registry or use a peer-to-peer zone discovery protocol.
# Assuming a uniform distribution of backup jobs over the 24 hour period.

GlanceZone

2016-05-11T19:16:58Z

Dan Smith: Dan Smith moved page GlanceZone to Obsolete:GlanceZone

#REDIRECT [[Obsolete:GlanceZone]]

Obsolete:Cinder/FibreChannelSupport

2016-05-11T19:13:52Z

Dan Smith: Dan Smith moved page Cinder/FibreChannelSupport to Obsolete:Cinder/FibreChannelSupport

* '''Launchpad Entry''': https://blueprints.launchpad.net/cinder/+spec/fibre-channel-block-storage
* '''Created''': 15 Nov 2012
* '''Contributors''': Gary Thunquest, Kurt Martin, Walter Boring

== Summary ==

Currently block storage volumes can be attached to hosts via iSCSI. This blueprint adds support for block storage attaching to hosts via Fibre Channel SANs as well. Support for Fibre Channel (FC) including Fibre Channel over Ethernet (FCoE) is planned.

iSCSI and FC will be able to be used simultaneously within the infrastructure, and adding FC can’t break existing iSCSI cinder volume drivers.

The scope of changes intended by this blueprint includes:
* Handling FC endpoint addressing (WWN’s vs. iqn’s + IP addresses), and allow FC endpoints to be passed through the system
* Reading of the host initiator WWNs
* Defining a new [[FibreChannelDriver]] superclass to facilitate the creation of Fibre Channel based cinder volume drivers
* Adding support for the nova host commands necessary to initialize a connection between a VM and a FC volume. (separate blueprint will be added to nova for this work - https://blueprints.launchpad.net/nova/+spec/libvirt-fibre-channel)
* Intending to implement for KVM only. Support for other hypervisors will be handled in subsequent blueprints. (separate blueprint will be added to nova for this work - https://blueprints.launchpad.net/nova/+spec/libvirt-fibre-channel)
* Typical Fibre Channel arrays support exporting volumes via multiple ports, so multipath support is highly desirable for redundancy and fault tolerance. If multipath is install and available, the new [[FibreChannel]] libvirt volume driver will take advantage of it. (separate blueprint will be added to nova for this work - https://blueprints.launchpad.net/nova/+spec/libvirt-fibre-channel)

FC support immediately raises the question of how FC SAN zoning will be performed. The scope of this blueprint does not include SAN zone management. A separate blueprint defining automated zone management is being submitted which will work together with this blueprint. This blueprint, however, does stand alone, in that FC SAN based deployments which require no zoning (open-zoned or pre-zoned SANs) can be fully supported with the changes defined in this blueprint.

== Release Note ==

This feature supports Fibre Channel attached cinder volumes. Require a Fibre Channel cinder driver talking to a backend Fibre Channel array & SAN.

== Rationale ==

FC support is required by enterprise data centers with Fibre Channel storage investments wanting to deploy private clouds using [[OpenStack]].

== User stories ==

To use:
* Infrastructure setup requires FC SAN connectivity between hosts and storage device(s)
* Backend cinder volume provider supporting FC storage attachment capability

User level volume operations (create/delete/snapshot/attach, etc.) will function the same for FC volumes as with iSCSI volumes.

It is intended that Cinder volume drivers supporting FC storage will publish a driver FC “capability” that will work with the Grizzly “volume types” facility to allow types to be defined to use FC vs. iSCSI if they choose.

== Assumptions ==

Security – iSCSI volumes use CHAP security to control access to volumes from hosts. FC doesn’t have an equivalent mechanism. With FC, access control is provided though SAN zoning and LUN masking on the arrays. However, both of these mechanisms rely on trusted initiator WWNs. This design assumes initiator WWNs logging into the SAN are trusted.

== Design ==

Attached is a diagram detailing the areas of change anticipated by this blueprint:
[[attachment:FibreChannelChanges.png]]

== Implementation ==

=== Code Changes ===
Cinder changes
* A new Fibre Channel driver that extends the cinder.volume.driver.[[FibreChannelDriver]]
* FC DRIVER NOTES: If multipath is enabled, the new Fibre Channel volume driver detects each of the attached devices for the volume, and properly removes every one of them on detach.
* In order to use this, the cinder volume driver's initialize_connection will simply return a dictionary with a new driver_volume_type called 'fibre_channel'.
* The target_wwn can be a single entry or a list of wwns that correspond to the list of remote wwn(s) that will export the volume.

return {'driver_volume_type': 'fibre_channel', 'data': {'target_lun', 1, 'target_wwn': '1234567890123'}}

- or -

return {'driver_volume_type': 'fibre_channel', 'data': {'target_lun', 1, 'target_wwn': ['1234567890123', '0987654321321']}}

Nova changes
* Added a new class [[LibvirtFibreChannelVolumeDriver]] to nova/virt/libvirt/volume.py. This class implements connect_volume and disconnect_volume, it also has a private method that runs the rescan to make the kernal aware of the new storage.
* Modified the get_volume_connector method in the nova/virt/libvirt/driver.py to return any WWNs(both WWNN -node name and WWPN - port name) from fibre channel HBAs that may be on the system.
* Added a new method get_fc_wwns to the nova/virt/libvirt/utils.py that is called by get_volume_connector above. This method returns a list of WWNs for any Fibre Channel HBAs that are on the system by calling the new method get_fc_hbas.
* The sg3-utils package (required for scsi device discovery) and systool(required for returning HBA info - WWNs) commands were added to the list of commands in nova/rootwrap.d/compute.filters file.
* The multipath package is needed for multipath support and was added to the list of commands in nova/rootwrap.d/compute.filters file.

=== Migration ===
NA

== Test/Demo Plan ==

== Unresolved issues ==

== BoF agenda and discussion ==

----
[[Category:Spec]]

Cinder/FibreChannelSupport

2016-05-11T19:13:52Z

Dan Smith: Dan Smith moved page Cinder/FibreChannelSupport to Obsolete:Cinder/FibreChannelSupport

#REDIRECT [[Obsolete:Cinder/FibreChannelSupport]]

Obsolete:CinderAPIv2

2016-05-11T19:13:13Z

Dan Smith: Dan Smith moved page CinderAPIv2 to Obsolete:CinderAPIv2

* '''Launchpad Entry''': cinder-apiv2
* '''Created''': 4 Nov 2012
* '''Contributors''': Mike Perez

== Summary ==
The future release of Cinder's Restful API has many feature and response changes that it requires splitting into a new version of the interface. There was a general consensus from the Cinder team in a previous meeting to model Glance's implementation in versioning api endpoints: http://eavesdrop.openstack.org/meetings/cinder/2012/cinder.2012-10-24-16.13.log.html

== Release Note ==
Will be available in Cinder G1 so that the rest of the team is not blocked by features/improvements they want to implement in v2.

== Rationale ==
To keep the users' knowledge and systems compatible with Cinder while the team paves the future for a new API, we're required to leave their previously used endpoint working just the same. Meanwhile, development of new features and other improvements are done on a v2 endpoint that users' and systems can switch to when ready.

== User stories ==
* As a user I want to manage my volumes using either v1 or v2 of the Cinder API endpoint.
* As a system administrator I can choose to serve either v1 and/or v2 of the Cinder API.

== Assumptions ==
== Design ==
== Implementation ==
Using paste's composite factory, we can route requests to different endpoints. (e.g. v1 and v2)

There will be:

cinder.api.v1 and cinder.api.v2 which contain routes and their own implementations.

Middleware code will be moved out of cinder.api.openstack.volumes into cinder.api.middleware

There will be config options to enable the endpoints that are available.

== Test/Demo Plan ==
== Unresolved issues ==
== BoF agenda and discussion ==
----
[[Category:Spec]]

CinderAPIv2

2016-05-11T19:13:13Z

Dan Smith: Dan Smith moved page CinderAPIv2 to Obsolete:CinderAPIv2

#REDIRECT [[Obsolete:CinderAPIv2]]

Obsolete:Glance-common-image-properties-os distro

2016-05-11T19:09:30Z

Dan Smith: Dan Smith moved page Glance-common-image-properties-os distro to Obsolete:Glance-common-image-properties-os distro

''[This is a mock-up of what the page at the URL in the 'description' field would look like. Please comment on how it could be better organized and structured!]''

= [[OpenStack]] Common Image Properties: os_distro =

The value of this property is ''the common name of the operating system distribution in all-lowercase''.

This page lists the recognized values for the 'os_distro' image property. In the interest of interoperability, please use only the recognized value for this field. The deprecated values are listed to assist you in searching for the recognized value.

== arch ==
Do ''not'' use:
* archlinux
* org.archlinux
----
== centos ==
Do ''not'' use:
* org.centos
* CentOS
----
== debian ==
Do ''not'' use:
* Debian
* org.debian
----
== fedora ==
Do ''not'' use:
* Fedora
* org.fedora
* org.fedoraproject
----
== freebsd ==
Do ''not'' use:
* org.freebsd
* freeBSD
* FreeBSD
----
== gentoo ==
Do ''not'' use:
* Gentoo
* org.gentoo
----
== opensuse ==
Do ''not'' use:
* suse
* SUSE
* org.opensuse
----
== rhel ==
Do ''not'' use:
* redhat
* RedHat
* com.redhat
----
== ubuntu ==
Do ''not'' use:
* Ubuntu
* com.ubuntu
* org.ubuntu
* canonical
----
== windows ==
Do ''not'' use:
* com.microsoft.server
* windoze

Glance-common-image-properties-os distro

2016-05-11T19:09:30Z

Dan Smith: Dan Smith moved page Glance-common-image-properties-os distro to Obsolete:Glance-common-image-properties-os distro

#REDIRECT [[Obsolete:Glance-common-image-properties-os distro]]

Obsolete:CactusReleaseSchedule

2016-05-11T19:08:57Z

Dan Smith: Dan Smith moved page CactusReleaseSchedule to Obsolete:CactusReleaseSchedule

= Cactus Release schedule =

* Status: Confirmed
* Chief Architect: [https://launchpad.net/~dendrobates Rick Clark (dendrobates)]
* Release Manager: [https://launchpad.net/~ttx Thierry Carrez (ttx)]

{| border="1" cellpadding="2" cellspacing="0"
| '''Week''' <span style="font-size: smaller">(Thursday)</span>
| '''Freezes'''
|-
|-
| February 3rd
|<#CCFFCC>| /!\ [[SpecsSubmissionDeadline]] (Feb 3)
|-
| February 10th
|<#FFFFCC>|
|-
| February 17th
|<#FFFFCC>|
|-
| February 24th
|<#FFFFCC>|
|-
|-
| March 3rd
|<#FFFFCC>|
|-
| March 10th
| <#FFFFCC>
|-
| March 17th
|<#FFFFCC>| /!\ [[BranchMergeProposalFreeze]] (Mar 17)
|-
| March 24th
|<#FFEBBB>| /!\ [[FeatureFreeze]] (Mar 24)
|-
| March 31st
|<#FFCCCC>|
|-
|-
| April 7th
|<#E47A7A>| /!\ [[GammaFreeze]] (Apr 7)
|-
| April 14th
|<#BB3333>| /!\ [[RCFreeze]] (Apr 13)
|}

* The [[ReleaseCycle]] explained
* Import the OpenStack release schedule in your calendar using this [http://www.google.com/calendar/ical/hst59hig71jjk88879lmhm2e8c%40group.calendar.google.com/public/basic.ics ICAL link] [[attachment:Cactus.ics|Cactus Release iCal]]
* OpenStack [[BexarReleaseSchedule]]
* Ubuntu 11.04 [https://wiki.ubuntu.com/NattyReleaseSchedule Release schedule]

CactusReleaseSchedule

2016-05-11T19:08:57Z

Dan Smith: Dan Smith moved page CactusReleaseSchedule to Obsolete:CactusReleaseSchedule

#REDIRECT [[Obsolete:CactusReleaseSchedule]]

Obsolete:Ceilometer/blueprints/APIv2

2016-05-11T19:07:21Z

Dan Smith: Dan Smith moved page Ceilometer/blueprints/APIv2 to Obsolete:Ceilometer/blueprints/APIv2

* '''Launchpad Entry''': [[CeilometerSpec]]:API v2
* '''Created''': 6 December 2012
* '''Contributors''': Angus Salkeld

== Summary ==

Our current API is very nested and looks great as a link, but makes it a bit
painful to add new features as they need to be added in so many places. Also
the test case blow out too. So lets use optional arguments for filters instead
of resource ownership.

<pre><nowiki>
So:
/resources?source=elsewhere
rather than
/sources/elsewhere/resources
</nowiki></pre>

Note I started with this:
https://github.com/asalkeld/ceilometer/commit/c678ff8abd2a91c4404657748b9ed9b31c1541df

== Release Note ==

== Rationale ==

== Terminology ==

* '''Meter''' == definition of the measurement (name,ownership,resource,metadata) - synonyms (metric)
* '''Sample''' == the actual data values (value,unit,timestamp) synonyms (measurement) (replaces "Event")
* '''Resource''' is an openstack object created for a user (eg. instance, volume)
* '''User''' is an openstack user auth'ed by keystone
* '''Source''' is the origin for the User and Project/Tenant (usually "openstack").
* '''Gauge''' is a type of Meter absolute measurement (car: revs per minute)
* '''Counter''' is a type of Meter that counts upwards (car: distance travelled - assume you don't reverse a lot:-)

== User stories ==

== Assumptions ==

* Resources are implicitly created by creating new Meters
* Passing arrays needs to be done like this ''class[index].property=value''
* The relationship between objects does not change (resource -> meter -> sample)
So the same db schema (at least in mongo)

== Design ==

{| border="1" cellpadding="2" cellspacing="0"
| Query Type
| Resource
|-
| GET
| /resources
|-
| GET
| /resources/<resource_id>
|-
| GET
| /meters
|-
| GET
| /meters/<meter>
|-
| GET
| /meters/<meter>/statistics
|-
| POST
| /meters
|-
| PUT
| /meters/<meter>
|-
| DELETE
| /meters/<meter>
|}

=== Generic optional arguments ===

Query:

<pre><nowiki>
q[].field=name
q[].op=eq
q[].value=56
</nowiki></pre>

''op'' is the comparison operation (eq, gt, lt, etc)

Field Selection

<pre><nowiki>
s[]=field
</nowiki></pre>

This is a way to choose the field that get returned. If you leave this out we default to returning all field.

=== Resource Resources ===

Same as currently, but we support the following actions
* listing with the common Query mechanism
* get a single resource

So just a resource_id makes the resource unique.

=== Meter Resources ===

'''GET /v2/meters'''

Returns a list of available meters that match the Query (if given).

'''POST /v2/meters'''

The body:

'''GET /v2/meters/<meter>'''

Get the meter samples match the Query (if given) and return the raw samples.

'''GET /v2/meters/<meter>/statistics'''
Get the derived statistics

<pre><nowiki>
{
'min': 3,
'max': 20,
'avg': 8,
'sum': 45,
'duration': <actual difference between the first and last sample that the stats were calulated from>
}
</nowiki></pre>

The period is to define the time period over which to calculate the above values.

<pre><nowiki>
Period
</nowiki></pre>

Example:

<pre><nowiki>
/v2/meters/cpu_util/statistics?
q[0].field=metadata.autoscale_group&
q[0].op=eq&
q[0].value=all_mine&
q[1].field=timestamp&
q[1].op=lt&
q[1].value=<now>&
q[2].field=timestamp&
q[2].op=gt&
q[2].value=<now - 5 hours>&
period=360
</nowiki></pre>

The above gets all the ''cpu_util'' samples with metadata.autoscale_group=all_mine
between 5hours ago and now. Then calulates the min, max and avg for each hour.
This would return something like this:

<pre><nowiki>
{[
{min=12, max=34, avg=23},
{min=14, max=41, avg=26},
{min=15, max=43, avg=29},
{min=16, max=44, avg=34},
{min=18, max=47, avg=33},
]}
</nowiki></pre>

== Implementation ==

=== UI Changes ===

=== Code Changes ===

=== Migration ===

== Test/Demo Plan ==

== Unresolved issues ==
'''QU: Do we need to keep the following queries:'''

<pre><nowiki>
/sources
/projects
/users
</nowiki></pre>

Basically are these queries been used at the moment?

ANS: The DUDE lists resources in a project and then asks questions about the meters reporting data for the resource. We do not use these queries. - dhellmann

'''QU: The API includes passing a period over which Calculations are done'''

This produces output like:

<pre><nowiki>
{[
{min=12, max=34, avg=23},
{min=14, max=41, avg=26},
...
</nowiki></pre>

Is this neat/super useful or unnecessary?

Do you have ideas for how to implement this? I think I can envision how to do it in a clumsy way with mapreduce, but I don't know about the SQL. - dhellmann

Well we could split up the periods in the api, then the db could return all statistical calculations for that one period.

So the db api could look like:

<pre><nowiki>
def get_samples(meter, query):
'''just return the raw samples that match the query'''
def get_statistics(meter, query):
'''return (max,min,avg,len,duration) for the given query'''
</nowiki></pre>

== BoF agenda and discussion ==

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

----
[[Category:Spec]]

Ceilometer/blueprints/APIv2

2016-05-11T19:07:21Z

Dan Smith: Dan Smith moved page Ceilometer/blueprints/APIv2 to Obsolete:Ceilometer/blueprints/APIv2

#REDIRECT [[Obsolete:Ceilometer/blueprints/APIv2]]

Obsolete:Glance-api-v2-links

2016-05-11T19:06:43Z

Dan Smith: Dan Smith moved page Glance-api-v2-links to Obsolete:Glance-api-v2-links

= Glance v2 api links =

== Rationale ==

The jsonschema draft document specifies link description objects as part of a schema document. A link description object defines a format for inferring link relations from the attributes of a document that is an instance of such a schema. Instead of following this format, the present glance v2 api follows the openstack compute api example of embedding link description objects directly in non-schema documents. This blueprint proposes changing version two of the glance api to adopt the jsonschema canonical approach.

== Schemas and Examples ==

The following schemas are missing the property description attributes. Many of these exist in the current code but some will need to be added.

=== Images Schema ===

<pre><nowiki>
GET /images/schema
{
"name": "images",
"properties": {
"images": {
"type": "array",
"items": {
<COPY IMAGE SCHEMA FROM BELOW>
}
},
"first": {"type": "string"},
"prev": {"type": "string"},
"next": {"type": "string"},
"last": {"type": "string"},
"schema": {"type": "string"}
},
"links": [
{
"rel": "first",
"href": "{first}"
},
{
"rel": "prev",
"href": "{prev}"
},
{
"rel": "next",
"href": "{next}"
},
{
"rel": "last",
"href": "{last}"
},
{
"rel": "describedby",
"href": "{schema}"
}
]
}
</nowiki></pre>

=== Images Response Example ===

<pre><nowiki>
GET /images?marker=20&limit=10
{
"images": [
...
],
"first": "?limit=10",
"prev": "?marker=10&limit=10",
"next": "?marker=30&limit=10",
"last": "?limit=10&sort_dir=desc",
"schema": "/images/schema"
}
</nowiki></pre>

=== Image Schema ===

<pre><nowiki>
GET /schemas/image

{
"name": "image",
"properties": {
"id": {
"type": "string",
"maxLength": 36
},
"name": {
"type": "string",
"maxLength": 255
},
"visibility": {
"type": "string",
"enum": ["public", "private"]
},
"self": {"type": "string"},
"file": {"type": "string"},
"schema": {"type": "string"},
"access": {"type": "string"},
<MAYBE ADDITIONAL PROPERTIES - DEPLOYER DETERMINED>
},
"additionalProperties": {"type": "string"} <OR FALSE>
"links": [
{
"rel": "describedby",
"href": "{schema}"
},
{
"rel": "self",
"href": "{self}"
},
{
"rel": "enclosure",
"href": "{file}"
},
{
"rel": "related",
"href": "{access}"
}
]
}
</nowiki></pre>

TODO: Update the above with the schema parameters that have been recently added to glance.schema.API.

=== Image Response Example ===

<pre><nowiki>
GET /images/abcd

{
"id": "abcd",
"name": "Ubuntu 12.04",
"visibility": "public",
"self": "/images/abcd",
"file": "/images/abcd/file",
"access": "/images/abcd/access",
"schema": "/schemas/image",
<other properties outside of the scope of this proposal>
}
</nowiki></pre>

What is to be done about tags? Original spec has them in links, but that would cause a naming conflict and it seems a bit unnecessary if the tags are in-line anyway.

=== Image Access Records Schema ===

<pre><nowiki>
GET /schemas/access_records
{
"name": "access_records",
"properties": {
"access_records": {
"type": "array",
"items": {
<COPY IMAGE ACCESS RECORD SCHEMA FROM BELOW>
}
},
"first": {"type": "string"},
"prev": {"type": "string"},
"next": {"type": "string"},
"last": {"type": "string"},
"schema": {"type": "string"}
},
"links": [
{
"rel": "first",
"href": "{first}"
},
{
"rel": "prev",
"href": "{prev}"
},
{
"rel": "next",
"href": "{next}"
},
{
"rel": "last",
"href": "{last}"
},
{
"rel": "describedby",
"href": "{schema}"
}
]
}
</nowiki></pre>

=== Image Access Records Response Example ===

=== Image Access Record Schema ===

<pre><nowiki>
GET /schemas/access_record
{
"name": "access_record",
"properties": {
"tenant_id": {
"type": "string"
},
"can_share": {
"type": "boolean",
"default": False
},
"schema": {
"type": "string"
},
"self": {
"type": "string"
},
"image": {
"type": "string"
}
},
"additionalProperties": False,
"links": [
{
"rel": "describedby",
"href": "{schema}"
},
{
"rel": "self",
"href": "{self}"
},
{
"rel": "up",
"href": "{image}"
}
]
}
</nowiki></pre>

=== Image Access Record Response Example ===

=== Image Tags Schema ===

<pre><nowiki>
GET /schemas/tags
{
"name": "tags",
"properties": {
"tags": {
"type": "array",
"items": {
"type": "string",
"maxLength": 255
}
},
"image": {
"type": "string"
}
},
"additionalProperties": False,
"links": [
{
"rel": "up",
"href": "{image}"
}
]
}
</nowiki></pre>

This approach assumes we will not do pagination for tags.

=== Image Tags Response Example ===

Glance-api-v2-links

2016-05-11T19:06:43Z

Dan Smith: Dan Smith moved page Glance-api-v2-links to Obsolete:Glance-api-v2-links

#REDIRECT [[Obsolete:Glance-api-v2-links]]

Obsolete:GlanceAPISpec

2016-05-11T19:06:25Z

Dan Smith: Dan Smith moved page GlanceAPISpec to Obsolete:GlanceAPISpec

= Glance API Specification =

Glance <=> Nova Integration requires these components:

* Glance - VM Image Management Service
** Parallax - Image Registry service
** Teller - Image Delivery service
* Client Classes
** `glance.client.[[GlanceClient]]` - A client used in Nova to query Glance about images
*** `glance.client.[[ParallaxClient]]` - A client tool for querying Parallax about available images
*** `glance.client.[[TellerClient]]` - A client tool for the chunked retrieval of an image

__TOC__

== Parallax API Commands ==

This section describes the Parallax REST API for creating, listing, modifying, and deleting image metadata.

=== Fetch id/name basic information on all public images ===

<pre><nowiki>
GET http://parallax.openstack.org/images
</nowiki></pre>

Returns a mapping containing a list of mappings containing details information about the public images encoded in JSON:

<pre><nowiki>
{
"images":
[
{"id": 1, "name": "My Image 1"},
{"id": 2, "name": "My Image 2"},
]
}
</nowiki></pre>

=== Fetch detailed information on all public images ===

<pre><nowiki>
GET http://parallax.openstack.org/images/detail
</nowiki></pre>

Returns a mapping containing a list of mappings containing details information about the public images encoded in JSON:

<pre><nowiki>
{
"images":
[
{
"id": 1,
"name": "My Image",
"status": "available",
"image_type": "kernel"
"is_public": true,
"properties": { "mykey": "myvalue" },
"files": [ { "location": "swift://user:passwd@acct/container/obj.tar.gz.0",
"size": 101 } ]
}
]
}
</nowiki></pre>

==== Notes ====

The `properties` element is a mapping of custom key/value pairs the image may have saved with it.

The `files` element is a list of mappings containing the chunks comprising an image along with the chunk's size

=== Fetch a single image's metadata ===

<pre><nowiki>
GET http://parallax.openstack.org/images/<ID>
</nowiki></pre>

Returns the image's metadata encoded in JSON:

<pre><nowiki>
{
"image":
{
"id": 1,
"name": "My Image",
"status": "available",
"image_type": "kernel"
"is_public": true,
"properties": { "mykey": "myvalue" },
"files": [ { "location": "swift://user:passwd@acct/container/obj.tar.gz.0",
"size": 101 } ]
}
}
</nowiki></pre>

==== Notes ====

The reason the returned dict contains only a single element, 'image', is for XML conversion purposes, where the root element will be `<image>` and not the root XML namespace.

The `properties` element is a mapping of custom key/value pairs the image may have saved with it.

The `files` element is a list of mappings containing the chunks comprising an image along with the chunk's size

==== Exceptions ====

404:: Image was not found

=== Register/create a new image ===

<pre><nowiki>
POST http://parallax.openstack.org/images
</nowiki></pre>

The body of the request shall be a JSON encoded mapping of the image's metadata:

<pre><nowiki>
{
"image":
{
"name": "My Image",
"status": "available",
"image_type": "kernel"
"is_public": true,
"properties": { "mykey": "myvalue" },
"files": [ { "location": "swift://user:passwd@acct/container/obj.tar.gz.0",
"size": 101 } ]
}
}
</nowiki></pre>

The returned response, is successful, will be a JSON encoded mapping of the newly-created image in Parallax, including a populated `id` column with the new image's internal identifier:

<pre><nowiki>
{
"image":
{
"id": 1,
"name": "My Image",
"status": "available",
"image_type": "kernel"
"is_public": true,
"properties": { "mykey": "myvalue" },
"files": [ { "location": "swift://user:passwd@acct/container/obj.tar.gz.0",
"size": 101 } ]
}
}
</nowiki></pre>

==== Notes ====

The reason the body dict and result dict contains only a single element, 'image', is for XML conversion purposes, where the root element will be `<image>` and not the root XML namespace.

The `properties` element is a mapping of custom key/value pairs the image may have saved with it.

The `files` element is a list of mappings containing the chunks comprising an image along with the chunk's size

=== Update an existing image's metadata ===

<pre><nowiki>
PUT http://parallax.openstack.org/images/<ID>
</nowiki></pre>

The body of the request shall be a JSON encoded mapping of the image's metadata:

<pre><nowiki>
{
"image":
{
"id": 2349823,
"name": "My Image",
"status": "disabled",
"image_type": "kernel"
"is_public": true,
"properties": { "mykey": "myvalue" },
"files": [ { "location": "swift://user:passwd@acct/container/obj.tar.gz.0",
"size": 101 } ]
}
}
</nowiki></pre>

The returned response, if successful, will be a JSON encoded mapping of the updated image metadata in Parallax:

<pre><nowiki>
{
"image":
{
"id": 2349823,
"name": "My Image",
"status": "disabled",
"image_type": "kernel"
"is_public": true,
"metadata": { "mykey": "myvalue" },
"files": [ { "location": "swift://user:passwd@acct/container/obj.tar.gz.0",
"size": 101 } ]
}
}
</nowiki></pre>

==== Notes ====

The reason the body dict and result dict contains only a single element, 'image', is for XML conversion purposes, where the root element will be `<image>` and not the root XML namespace.

The `properties` element is a mapping of custom key/value pairs the image may have saved with it.

The `files` element is a list of mappings containing the chunks comprising an image along with the chunk's size

==== Exceptions ====

404:: Image was not found

=== Delete an existing image from the registry ===

<pre><nowiki>
DELETE http://parallax.openstack.org/images/<ID>
</nowiki></pre>

The body of the request will be ignored.

==== Exceptions ====

404:: Image was not found

== Teller API Commands ==

This section describes the Teller REST API.

=== Fetch an Image ===

<pre><nowiki>
GET http://teller.openstack.org/images/<ID>
</nowiki></pre>

Returns the virtual machine image data as response body.

==== Exceptions ====

404:: Image was not found

=== Store an Image ===

<pre><nowiki>
POST http://teller.openstack.org/images/<ID>
</nowiki></pre>

The body of the POST request shall be a mime-encoded blob of data representing the image to be stored.

Note: All this does is store the raw image data in Teller's backend. If you are responsible for storing the metadata about the image, you should do that with a similar call to Parallax's API.

Immediately returns a mapping of image information indicating status of the image:

<pre><nowiki>
{
'image':
{
'id': identifier for image,
'status': 'pending'
}
}
</nowiki></pre>

=== Update an Image ===

There is no operation for updating an image. All images are immutable once created.

=== Delete an Image ===

<pre><nowiki>
DELETE http://teller.openstack.org/images/<ID>
</nowiki></pre>

Returns 200 OK on success

Returns 404 when image with URI does not exist

GlanceAPISpec

2016-05-11T19:06:25Z

Dan Smith: Dan Smith moved page GlanceAPISpec to Obsolete:GlanceAPISpec

#REDIRECT [[Obsolete:GlanceAPISpec]]

Meetings/Nova

2016-02-03T18:07:03Z

Dan Smith:

= Weekly Nova team meeting =
'''MEETING TIME: Thursdays alternating 14:00 UTC (#openstack-meeting) and 21:00 UTC (#openstack-meeting)'''

This meeting is a weekly gathering of developers working on [[Nova|OpenStack Compute (Nova)]]. We cover topics such as release planning and status, bugs, reviews, and other current topics worthy of real-time discussion.

NOTE: this wiki page should be 'emptied' at the end of each meeting.

== Agenda for next meeting ==

Next meetings scheduled for:
* February 4th 2016 2100 UTC, #openstack-meeting (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160204T210000)
* February 11th 2016 1400 UTC, #openstack-meeting (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160211T140000)

Add your IRC nick to this list to be pinged at the start of the meeting:
<code>

mikal tjones cburgess jgrimm adrian_otto funzo mjturek jcookekhugen
</code>
<code>
irina_pov krtaylor danpb alexpilotti flip214 jaypipes garyk edleafe dims
</code>
<code>
moshele anteaya Nisha sileht claudiub lxsli neiljerram markus_z swamireddy alevine
</code>
<code>
tonyb andreykurilin ndipanov sc68cal akuriata artom jlvillal mnestratov kashyap
</code>
<code>
aloga rgeragnov bauzas xyang tpatil med_ nic scottda nagyz belliott
</code>
<code>
dguitarbite sdague jroll diana_clarke _diana_ raildo jichen gjayavelu mdorman klindgren
</code>
<code>
sorrison belmoreira mrda auggy PaulMurray gcb thorst duncant macsz thomasem tpatzig
</code>

Please note "stuck review" means a review where there is some disagreement that needs resolving.
Its not for reviews that just haven't had attention, except for exceptional cases.
Where you see "?" feel free to just edit the wiki and add your item.

Here is the agenda for the next meeting:
* Release Status
** Final date for non-priority features is Friday Feb 5th 2016
*** Summary of Non-priority feature freeze: https://etherpad.openstack.org/p/mitaka-nova-non-priority-ff-tracking
*** http://lists.openstack.org/pipermail/openstack-dev/2016-February/085455.html
** Mar 1-3, Mitaka-3 and feature freeze, Final release for client libraries, Soft String Freeze, etc.
** http://docs.openstack.org/releases/schedules/mitaka.html
* Regular Reminders
** Review focus list: https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking
* Bugs (stuck/critical)
** Gate status
*** http://status.openstack.org/elastic-recheck/index.html
*** Time to review the jobs Nova uses on every commit, given the node reduction lately (dansmith)
**** Currently we require 21 nodes in check for all the tests we run
**** Reconsider things like the v2.0 API, postgres, etc jobs?
**** Maybe make ceph our default job (90% of our customers use it, apparently it's not very stable currently)?
** 3rd party CI status
*** http://ci-watch.tintri.com/project?project=nova&time=7+days
** Critical bugs
*** ?
** Reminders:
*** volunteers for 1 week of bug skimming duty? [[Nova/BugTriage#Weekly_bug_skimming_duty|Weekly_bug_skimming_duty]]
*** Nova bugs team IRC meeting will start at February the 9th http://lists.openstack.org/pipermail/openstack-dev/2016-January/084543.html
** Stable branch status: https://etherpad.openstack.org/p/stable-tracker
*** stable/liberty: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/liberty,n,z
*** stable/kilo: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo,n,z
* Stuck Reviews
** Please note "stuck review" means a review where there is some disagreement that needs resolving. Its not for reviews that just haven't had attention, except for exceptional cases. Where you see "?" feel free to just edit the wiki and add your item.
** Any stuck code reviews to discuss:
*** ?
* Open discussion
** DocImpact bugs to get generated into the Nova bug queue
*** docs team find it hard to triage with current level of details in commit messages
*** trying to not have tests on git commits due to the various issues that creates
** python-novaclient not supporting keystone v3 is causing issues for Cinder
*** https://bugs.launchpad.net/python-novaclient/+bug/1522402
** Midcycle details
*** https://etherpad.openstack.org/p/mitaka-nova-midcycle

== Sub-teams ==

There are also some Nova subteam meetings. See [[Nova#Active_Sub-teams:]] for details.

== Previous meetings ==

* [http://eavesdrop.openstack.org/meetings/nova/ All other meetings are here]
* [http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-16-21.01.html 2012-08-16]
* [http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-09-21.00.html 2012-08-09]
* [http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-08-02-21.40.html 2012-08-02]

[[category: compute]]
[[category: meetings]]

Design Summit/Mitaka/Etherpads

2015-10-27T05:33:02Z

Dan Smith: /* Cross-Project workshops */

[[Category:Summit]]
[[Category:Liberty]]
[[Category:Etherpad]]

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

==App Catalog==
* Wed 14:00: [https://etherpad.openstack.org/p/TYO-ops-delivering-apps Ops: Delivering Apps To Your Users]
* Thur 14:40: [https://etherpad.openstack.org/p/TYO-app-catalog App Catalog Working Session]

== Barbican ==
*Fishbowls
**Fishbowl 1: Wednesday, 12:05pm - Barbican Roadmap and Cross-Project Integration Status
**Fishbowl 2: Wednesday, 2:00pm - Barbican Key Federation
*Working Sessions
**Working Session 1: Wednesday, 4:40pm
**Working Session 2: Wednesday, 5:30pm
**Working Session 3: Thursday, 9:00am
**Working Session 4: Thursday, 9:50am
**Working Session 5:Thursday, 11:00am
**Working Session 6:Thursday, 5:20pm
*Meetup
**Contributors Meetup: Friday, 2:00pm
*Etherpad
**https://etherpad.openstack.org/p/barbican-m-design-sessions

== Cinder ==
* Wed 14.00: Will the real Block Storage Service please stand up [https://etherpad.openstack.org/p/mitaka-cinder-direction]
* Wed 14.50: Availability zones in Cinder [https://etherpad.openstack.org/p/mitaka-cinder-az]
* Thur 9.00: Experimental APIs and Microversions [https://etherpad.openstack.org/p/mitaka-cinder-experimental-apis]
* Thur 9.50: Cinder Nova Interaction [https://etherpad.openstack.org/p/mitaka-cinder-nova-interaction]
* Thur 13.50: Cinder driver interface [https://etherpad.openstack.org/p/mitaka-cinder-driver-interface]
* Thur 14.40: API Microversions [https://etherpad.openstack.org/p/mitaka-cinder-api-microversions]
* Thur 15.30: ABC work [https://etherpad.openstack.org/p/mitaka-cinder-abc-work]
* Thur 15.30: Driver deadlines [https://etherpad.openstack.org/p/mitaka-cinder-driver-deadlines]
* Thur 16.30: C-Vol Active/Active HA [https://etherpad.openstack.org/p/mitaka-cinder-cvol-aa]
* Thur 17.20: Volume manager locks [https://etherpad.openstack.org/p/mitaka-cinder-volmgr-locks]
* Fri: Contributor Meetup [https://etherpad.openstack.org/p/mitaka-cinder-contributor-meetup]

== CloudKitty ==
* Wed 16.40: Gnocchi support [https://etherpad.openstack.org/p/mitaka-cloudkitty-gnocchi]
* Thur 14.40: CloudKitty introduction and future perspectives [https://etherpad.openstack.org/p/mitaka-cloudkitty-session]

== Congress ==
* Wed 2:00: [https://etherpad.openstack.org/p/congress-mitaka-arch Distributed architecture and additional features for Mitaka]
* Wed 2:50: [https://etherpad.openstack.org/p/congress-mitaka-integrations Integration with other projects: congress gating (murano, nova, neutron, etc.), keystone]
* Wed 3:40: [https://etherpad.openstack.org/p/congress-mitaka-external Discussions with external teams: OPNFV, Monasca]

== Cross-Project workshops ==

All sessions are on Tuesday 2015-10-27

* 11:15
** Service Catalog TNG (double session) [https://etherpad.openstack.org/p/mitaka-service-catalog-session]
** Cycle themes [https://etherpad.openstack.org/p/mitaka-crossproject-themes]
* 12:05
** Supporting DefCore and Interoperability Testing [https://etherpad.openstack.org/p/mitaka-crossproject-defcore]
** Tags today and tomorrow [https://etherpad.openstack.org/p/mitaka-crossproject-next-tags]
* 14:00
** Standard Deprecation Policy [https://etherpad.openstack.org/p/mitaka-deprecation-policy]
** Documentation Team [https://etherpad.openstack.org/p/mitaka-cross-project-documentation-team]
** Performance Team Kick-off [https://etherpad.openstack.org/p/mitaka-cross-project-performance-team-kick-off]
* 14:50
** Role Assignments for Service users [https://etherpad.openstack.org/p/mitaka-cross-project-role-assignment-service-user]
** Python 3 [https://etherpad.openstack.org/p/mitaka-cross-project-python-3]
** Distributed Lock manager in OpenStack [https://etherpad.openstack.org/p/mitaka-cross-project-dlm]
* 15:40
** Documenting the OpenStack way [https://etherpad.openstack.org/p/mitaka-crossproject-doc-the-way]
* 16:40
** Troubleshooting cross-project comms [https://etherpad.openstack.org/p/mitaka-crossproject-comms]
** Live Upgrades Discussion [https://etherpad.openstack.org/p/mitaka-crossproject-upgrades]
* 17:30
** Serving extreme use cases [https://etherpad.openstack.org/p/mitaka-crossproject-extreme-usecases]

== Ceilometer ==
* Wednesday, 2015-10-28
** 11:15 - [https://etherpad.openstack.org/p/mitaka-telemetry-alarms alams]
** 12:05 - [https://etherpad.openstack.org/p/mitaka-telemetry-ui visualising data]
** 14:50 - [https://etherpad.openstack.org/p/mitaka-telemetry-upgrades rolling upgrades]
** 15:40 - [https://etherpad.openstack.org/p/mitaka-telemetry-split componentisation]

* Thursday, 2015-10-29
** 09:00 - [https://etherpad.openstack.org/p/mitaka-telemetry-testing functional and integration testing]
** 09ː50 - [https://etherpad.openstack.org/p/mitaka-telemetry-bi business intelligence]
** 11ː00 - [https://etherpad.openstack.org/p/mitaka-telemetry-polling refined polling]
** 11ː50 - [https://etherpad.openstack.org/p/mitaka-telemetry-cross-project project data ownership]
** 13ː50 - [https://etherpad.openstack.org/p/mitaka-telemetry-alarms event alarms]

* Friday, 2015-10-30
** 09:00 - [https://etherpad.openstack.org/p/mitaka-telemetry-contributors-meetup contributors meetup]

== Cue ==

* Thu 09:00: Cue - Multi Broker Support https://etherpad.openstack.org/p/mitaka-cue-multi-broker
* Thu 09:50: Cue - Work Session https://etherpad.openstack.org/p/mitaka-cue-work-session

== Designate ==

* Wed 11:15: Roadmap https://etherpad.openstack.org/p/mitaka-designate-summit-roadmap
* Wed 12:05: Alias Records https://etherpad.openstack.org/p/mitaka-designate-summit-alias
* Wed 14:00: Batch API Actions https://etherpad.openstack.org/p/mitaka-designate-summit-batch-api
* Wed 14:50: Embedable Services https://etherpad.openstack.org/p/mitaka-designate-summit-embeddable-services
* Wed 16:40: Incremental Zone Transfer (IFXR) https://etherpad.openstack.org/p/mitaka-designate-summit-ifxr
* Fri 14:00: Contributors Meetup https://etherpad.openstack.org/p/mitaka-designate-summit-meetup

== Documentation ==

* Thu 9:00: https://etherpad.openstack.org/p/Mitaka-Docs-IA
* Thu 9:50: https://etherpad.openstack.org/p/Mitaka-Docs-ContributorGuide
* Thu 11:00: https://etherpad.openstack.org/p/Mitaka-Docs-Infra
* Thu 11:50: https://etherpad.openstack.org/p/Mitaka-Docs-API
* Thu 16:30: https://etherpad.openstack.org/p/Mitaka-Docs-ReleasePlan
* Thu 17:20: https://etherpad.openstack.org/p/Mitaka-Docs-Process
* Fri 9:00: https://etherpad.openstack.org/p/Mitaka-Docs-Meetup

== Glance ==

* Wed:
** 14:00 - 14:40: Trusts implementation (mfedosin) https://etherpad.openstack.org/p/mitaka-glance-trusts
* Thur:
** 09:00 - 09:40 (fishbowl): Cross-project image protection (rosmaita) https://etherpad.openstack.org/p/mitaka-glance-xp-property-protections-support
** 09:50 - 10:30: Image Signature Verification Improvements (bpoulos) https://etherpad.openstack.org/p/mitaka-glance-image-signing-and-encryption
** 11:50 - 12:30: Defcore Updates and joint effort (flaper87) https://etherpad.openstack.org/p/mitaka-glance-defcore
** 14:40 - 15:20 (fishbowl): Glance image import reloaded (rosmaita, mclaren) https://etherpad.openstack.org/p/Mitaka-glance-image-import-reloaded
** 15:30 - 16:10 (fisbowl): Artifacts Review (ativelkov) https://etherpad.openstack.org/p/mitaka-glance-artifacts-review
** 16:30 - 17:10: Glance image import (follow-up working session) (flaper87) https://etherpad.openstack.org/p/Mitaka-glance-image-import-reloaded
** 17:20 - 18:00: Finalize Glance priorities (flaper87)

== Heat ==
* The everything etherpad: https://etherpad.openstack.org/p/mitaka-heat-sessions
'''Wed'''
* 11:15 - 11:55: [https://etherpad.openstack.org/p/mitaka-heat-documentation (W) Documentation improvements]
* 12:05 - 12:45: [https://etherpad.openstack.org/p/mitaka-heat-tests (W) Heat tests]
* 14:00 - 14:40: [https://etherpad.openstack.org/p/mitaka-heat-convergence-migration (W) Tool to migrate stacks to/from convergence]
* 14:50 - 15:30: [https://etherpad.openstack.org/p/mitaka-heat-large-stacks (F) Issues from deploying very large stacks]
* 15:40 - 16:20: [https://etherpad.openstack.org/p/mitaka-heat-user-ops (F) User/ops session for summit ]
'''Thu'''
* 09:00 - 09:40: [https://etherpad.openstack.org/p/mitaka-heat-autoscaling (W) AutoScaling/Group architecture/roadmap]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/mitaka-heat-break-stack-barrier (W) Breaking the stack barrier]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/mitaka-heat-composition-improvements (F) Composition improvements ]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/mitaka-heat-openstackclient (F) Complete heat support in python-openstackclient ]
* 13:50 - 14:30: [https://etherpad.openstack.org/p/mitaka-heat-hooks-notifications (W) Hooks & Notifications ]
* 14:40 - 15:20: [https://etherpad.openstack.org/p/mitaka-heat-convergence-ph1 (W) Convergence Phase 1 results]
* 15:30 - 16:10: [https://etherpad.openstack.org/p/mitaka-heat-convergence-ph2 (W) Convergence Phase 2 start]
'''Fri'''
* 09:00 - 12:30: [https://etherpad.openstack.org/p/mitaka-heat-summit-meetup Contributor Meetup]

== Horizon ==
[https://etherpad.openstack.org/p/horizon-mitaka-summit Planning etherpad]
* Wed October 28
** 16:40-17:20 [https://etherpad.openstack.org/p/mitaka-horizon-plugins Plugins]
** 17:30-18:10 [https://etherpad.openstack.org/p/mitaka-horizon-theming Theming/UX]
* Thursday October 29
** 9:00-9:40 [https://etherpad.openstack.org/p/mitaka-horizon-angular Existential AngularJS]
** 9:50-10:30 [https://etherpad.openstack.org/p/mitaka-horizon-ops Ops Feedback]
** 11:00-11:40 [https://etherpad.openstack.org/p/mitaka-horizon-angular-progress AngularJS Plan]
** 11:50-12:30 [https://etherpad.openstack.org/p/mitaka-horizon-async async]
** 13:50-14:30 [https://etherpad.openstack.org/p/mitaka-horizon-scale Scale]
** 14:40-15:20 [https://etherpad.openstack.org/p/mitaka-horizon-identity Identity]
** 15:30-16:10 [https://etherpad.openstack.org/p/mitaka-horizon-priorities Priorities]
* Friday October 30
** 9:00-12:30 & 14:00-17:30 [https://etherpad.openstack.org/p/mitaka-horizon-meetup Contributors Meetup]

== I18N ==
http://mitakadesignsummit.sched.org/type/I18N

* Fri: 09:00 - 12:30: I18N contributors meetup https://etherpad.openstack.org/p/tokyo-i18n-meetup

== Infrastructure ==
http://mitakadesignsummit.sched.org/type/Infrastructure

'''Wednesday:'''
* '''Work Session: Masterless Puppet part I''', Ho-O Room, 11:15am-11:55am (02:15-02:55 UTC)
** https://etherpad.openstack.org/p/mitaka-infra-masterlesspuppet
* '''Work Session: Masterless Puppet part II''', Ho-O Room, 12:05pm-12:45pm (03:05-03:45 UTC)
** https://etherpad.openstack.org/p/mitaka-infra-masterlesspuppet
* '''Extending Nodepool With Plug-Ins''', Suzuran Room, 5:30pm-6:10pm (08:30-09:10 UTC)
** https://etherpad.openstack.org/p/mitaka-infra-nodepoolplugins

'''Thursday:'''
* '''Work Session: Gerrit Planning and Development''', Kinkei Room, 9:00am-9:40am (00:00-00:40 UTC)
** https://etherpad.openstack.org/p/mitaka-infra-gerritdevelopment
* '''Work Session: Nodepool Image Workers''', Kinkei Room, 9:50am-10:30am (00:50-01:30 UTC)
** https://etherpad.openstack.org/p/mitaka-infra-nodepoolimageworkers
* '''Scaling New Project Creation''', Suzuran Room, 11:00am-11:40am (02:00-02:40 UTC)
** https://etherpad.openstack.org/p/mitaka-infra-scalingnewprojectcreation
* '''Task Tracking: Mitaka Edition''', Suzuran Room, 11:50am-12:30pm (02:50-03:30 UTC)
** https://etherpad.openstack.org/p/mitaka-infra-tasktracking

'''Friday:'''
* '''Ironic/Infrastructure contributors meetup''', Jako Room, 9:00am-12:30pm (00:00-03:30 UTC)
** https://etherpad.openstack.org/p/summit-mitaka-ironic-contributors-meetup
* '''Infra/QA/Release management contributors meetup''', Kusunoki Room, 2:00pm-5:30pm (05:00-08:30 UTC)
** https://etherpad.openstack.org/p/summit-mitaka-qa-contributors-meetup

== Ironic ==
* The everything etherpad: https://etherpad.openstack.org/p/summit-mitaka-ironic
* Wednesday fishbowl DS3 2:00-2:40 https://etherpad.openstack.org/p/summit-mitaka-ironic-third-party-ci
* Wednesday fishbowl DS3 2:50-3:30 https://etherpad.openstack.org/p/summit-mitaka-ironic-group-management
* Thursday workroom DS10 9:00-9:40 https://etherpad.openstack.org/p/summit-mitaka-ironic-notifications-bus
* Thursday workroom DS10 9:50-10:30 https://etherpad.openstack.org/p/summit-mitaka-ironic-driver-composition
* Thursday fishbowl DS3 11:00-11:40 https://etherpad.openstack.org/p/summit-mitaka-ironic-driver-api
* Thursday fishbowl DS3 11:50-12:30 https://etherpad.openstack.org/p/summit-mitaka-ironic-nova-driver (joint session with Nova)
* Thursday workroom DS11 4:30-5:10 https://etherpad.openstack.org/p/summit-mitaka-ironic-lock-manager
* Thursday workroom DS11 5:20-6:00 https://etherpad.openstack.org/p/summit-mitaka-ironic-gate-improvements
* Friday workroom DS15 9:00-12:30 https://etherpad.openstack.org/p/summit-mitaka-ironic-contributors-meetup (shared space with Infra)

== Kolla ==

[http://etherpad.openstack.org/kolla-mitaka-all-sessions All Kolla Design Summit Sessions]

Wednesday:
* 11:15 - 11:55: [http://etherpad.openstack.org/kolla-mitaka-documentation (W) Documentation]
* 12:05 - 12:45: [http://etherpad.openstack.org/kolla-mitaka-diagnostics (W) Diagnostics]
* 14:00 - 14:40: [http://etherpad.openstack.org/kolla-mitaka-bare-metal-deployment (W) Bare Metal Deployment]
* 15:40 - 16:20: [http://etherpad.openstack.org/kolla-mitaka-roadmap (F) Mitaka Roadmap]
* 16:40 - 17:20: [http://etherpad.openstack.org/kolla-mitaka-operator-requirements-gathering (F) Mitaka Operator Requirements Gathering]
* 17:40 - 18:20: [http://etherpad.openstack.org/kolla-mitaka-upgrade (F) Integrating Kolla Containers with Third Party Projects]

Thursday
* 14:40 - 15:20: [http://etherpad.openstack.org/kolla-mitaka-gating (W) Gating Commits]
* 15:30 - 16:10: [http://etherpad.openstack.org/kolla-mitaka-upgrade (W) Upgrading from Liberty to Mitaka]

== Keystone ==
* Wed 2:50 - 3:30: tokens and tokenless auth https://etherpad.openstack.org/p/keystone-mitaka-summit-tokens
* Wed 3:40 - 4:20: hierarchical multitenancy https://etherpad.openstack.org/p/keystone-mitaka-summit-multitenancy
* Wed 4:40 - 5:20: policy https://etherpad.openstack.org/p/keystone-mitaka-summit-policy
* Thu 9:00 - 9:40: deprecations https://etherpad.openstack.org/p/keystone-mitaka-summit-deprecations
* Thu 9:50 - 10:30: federation https://etherpad.openstack.org/p/keystone-mitaka-summit-federation
* Thu 11:00 - 11:40: keystone server https://etherpad.openstack.org/p/keystone-mitaka-summit-server (workshop)
* Thu 11:50 - 12:30: testing https://etherpad.openstack.org/p/keystone-mitaka-summit-testing (workshop)
* Thu 1:50 - 2:30: oslo and doc https://etherpad.openstack.org/p/keystone-mitaka-summit-oslo-and-docs (workshop)
* Thu 4:30 - 5:10: keystone libraries https://etherpad.openstack.org/p/keystone-mitaka-summit-libraries
* Thu 5:20 - 6:00: more cross-project https://etherpad.openstack.org/p/keystone-mitaka-summit-x-project

== Neutron ==

* Wed 11:15 - 11:55: Completing the Liberty backlog https://etherpad.openstack.org/p/mitaka-neutron-core-liberty-backlog
* Wed 12:05 - 12:45: Cross Project integration: tempest and 3rd party validation https://etherpad.openstack.org/p/mitaka-neutron-core-cross-project-integration

* Wed 15:40 - 16:20: Cross Project integration: devstack, nova, heat, ... https://etherpad.openstack.org/p/mitaka-neutron-core-cross-project-integration
* Wed 16:40 - 17:20: API and Server extensibility mechanisms https://etherpad.openstack.org/p/mitaka-neutron-core-extensibility
* Wed 17:30 - 18:10: Plugin and Agent extensibility mechanisms https://etherpad.openstack.org/p/mitaka-neutron-core-extensibility

* Thu 11:00 - 11:40: LBaaS/Octavia/FWaaS https://etherpad.openstack.org/p/mitaka-neutron-next-adv-services
* Thu 11:50 - 12:30: LBaaS/Octavia/FWaaS https://etherpad.openstack.org/p/mitaka-neutron-next-adv-services

* Thu 13:50 - 14:30: Scalability, operability and reliability pain points https://etherpad.openstack.org/p/mitaka-neutron-next-ops-painpoints
* Thu 14:40 - 15:20: Extending the existing networking logical model and protocols support https://etherpad.openstack.org/p/mitaka-neutron-next-network-model
* Thu 15:30 - 16:10: Lightning talks https://etherpad.openstack.org/p/mitaka-neutron-labs-lighting-talks
* Thu 16:30 - 17:10: NFV foundation elements https://etherpad.openstack.org/p/mitaka-neutron-labs-nfv-foundation
* Thu 17:20 - 18:00: Integration between orchestration platforms and Neutron https://etherpad.openstack.org/p/mitaka-neutron-labs-orchestration

* Fri 09:00 - 12:30: Neutron contributors meetup https://etherpad.openstack.org/p/mitaka-neutron-unplugged-track
* 14:00 - 17:30: Neutron contributors meetup https://etherpad.openstack.org/p/mitaka-neutron-unplugged-track

== Nova ==

* Wed 11:15: REST API https://etherpad.openstack.org/p/mitaka-nova-api
* Wed 12:05: Upgrade https://etherpad.openstack.org/p/mitaka-nova-upgrade

* Wed 14:00: Unconference https://etherpad.openstack.org/p/mitaka-nova-unconference
* Wed 14:50: OS VIF lib https://etherpad.openstack.org/p/mitaka-nova-os-vif-lib
* Wed 15:40: Resources and Flavors https://etherpad.openstack.org/p/mitaka-nova-resource-modeling
* Wed 16:40: Resources and Flavors (continued) https://etherpad.openstack.org/p/mitaka-nova-resource-modeling
* Wed 17:30: SR-IOV https://etherpad.openstack.org/p/mitaka-nova-sr-iov

* Thurs 09:00: Cells v2 https://etherpad.openstack.org/p/mitaka-nova-cells
* Thurs 9:50: see Cinder track
* Thurs 11:00: Scheduler https://etherpad.openstack.org/p/mitaka-nova-scheduler
* Thurs 11:50: see Ironic track

* Thurs 13:50: Unconference https://etherpad.openstack.org/p/mitaka-nova-unconference
* Thurs 14:40: Error handling https://etherpad.openstack.org/p/mitaka-nova-error-handling
* Thurs 15:30: Cross Service issues: Server locking, token refresh, Instance users https://etherpad.openstack.org/p/mitaka-nova-service-users
* Thurs 16:30: Mitaka Priorities https://etherpad.openstack.org/p/mitaka-nova-priorities
* Thurs 17:20: Unconference https://etherpad.openstack.org/p/mitaka-nova-unconference

* Fri: 09:00 and 14:00: Nova contributors meetup https://etherpad.openstack.org/p/mitaka-nova-summit-meetup

== Manila ==
* Wed 11:15 - 11:55: (WS) Migration Improvements https://etherpad.openstack.org/p/mitaka-manila-migration-improvements
* Wed 12:05 - 12:45: (WS) Access Allow/Deny Driver Interface https://etherpad.openstack.org/p/mitaka-manila-allow-deny
* Thu 11:00 - 11:40: (FB) Share Replication https://etherpad.openstack.org/p/mitaka-manila-replication
* Thu 11:50 - 12:30: (FB) Alternative Snapshot Semantics https://etherpad.openstack.org/p/mitaka-manila-snapshot-semantics
* Thu 14:40 - 15:20: (WS) Export Location Metadata https://etherpad.openstack.org/p/mitaka-manila-export-location-metadata
* Thu 15:30 - 16:10: (WS) Interactions Between New Features https://etherpad.openstack.org/p/mitaka-manila-feature-interactions
* Fri 09:00 - 12:30: (CM) Contributor Meetup https://etherpad.openstack.org/p/mitaka-manila-contributor-meetup

==Murano==
'''Wed'''

* 11:15am (W) [https://etherpad.openstack.org/p/murano-mitaka-work-session-1 Multi-Region in Murano]
* 12:05pm (W) [https://etherpad.openstack.org/p/murano-mitaka-work-session-2 Actions]

'''Fri'''

* 9am - 5:30pm [https://etherpad.openstack.org/p/murano-mitaka-contributors-meetup Contributors Meetup]

== OpenStack-Ansible ==
* [https://etherpad.openstack.org/p/openstack-ansible-mitaka-summit Summary View]
* Wed 14:50-15:30 : [https://etherpad.openstack.org/p/openstack-ansible-mitaka-image-based-deployment Image-based deployments]
* Wed 15:40-16:20 : [https://etherpad.openstack.org/p/openstack-ansible-mitaka-upgrades Production-ready Upgrades]
* Wed 17:30-18:10 : [https://etherpad.openstack.org/p/openstack-ansible-mitaka-inventory Dynamic Inventory Refactor]
* Fri 14:00-17:00 : [https://etherpad.openstack.org/p/openstack-ansible-mitaka-meetup Contributor's Day]

== OpenStack Chef ==
* [https://etherpad.openstack.org/p/mitaka-openstack-chef-general general discussion]
* Thurs 13:00-15:00 : [https://etherpad.openstack.org/p/mitaka-openstack-chef-refactoring defining the refactoring process]

== OpenStackClient ==
* Wed 16:40 - 17:20: [https://etherpad.openstack.org/p/tokyo-osc-session Near-term Roadmap]
* Fri 09:00 - 12:30: [https://etherpad.openstack.org/p/tokyo-osc-meetup Meetup]

== Ops ==
Use https://etherpad.openstack.org/p/TYO-ops-meetup in the meantime.

== Oslo ==

* Wed 16:40: Work session: Tasks task tasks tisk-a-task [https://etherpad.openstack.org/p/mitaka-oslo-taskflow]
* Wed 17:30: Work session: Review recommendations from Security and Logging WG [https://etherpad.openstack.org/p/mitaka-oslo-security-logging]
* Thu 09:50: Mitaka and beyond - New libraries, drivers in Oslo [https://etherpad.openstack.org/p/mitaka-oslo-new-stuff]
* Thu 13:50: Work session: Better Developer Documentation [https://etherpad.openstack.org/p/mitaka-oslo-better-documentation]
* Thu 14:40: Work session: Strategy, CI, Functional testing, Releases, etc. [https://etherpad.openstack.org/p/mitaka-oslo-strategy-ci-functional]
* Thu 15:30: Work session: oslo.messaging HA, performance, future plans [https://etherpad.openstack.org/p/mitaka-oslo-mesaging-ha-performance]
* Thu 16:30: Oslo: Plans/updates to existing libraries [https://etherpad.openstack.org/p/mitaka-oslo-library-updates]
* Thu 17:20: Oslo: State of oslo.messaging Drivers [https://etherpad.openstack.org/p/mitaka-oslo-messaging-zmq-pika-kafka]

== Puppet OpenStack ==
* General etherpadː https://etherpad.openstack.org/p/HND-puppet
* Wed 2 pm: Code design sessionː https://etherpad.openstack.org/p/HND-puppet-code
* Wed 2.50 pm: Code design sessionː https://etherpad.openstack.org/p/HND-puppet-code
* Thu 1.50 pm: Community feedbackː https://etherpad.openstack.org/p/HND-puppet-community
* Thu 2.40 pm: CI and documentationː https://etherpad.openstack.org/p/HND-puppet-ci and https://etherpad.openstack.org/p/HND-puppet-doc
* Thu 4.30 pm: Code design sessionː https://etherpad.openstack.org/p/HND-puppet-code

== QA ==
* Wed 14:50-15:30: [https://etherpad.openstack.org/p/mitaka-qa-openstack-health OpenStack Health Dashboard Next Steps]
* Wed 15:40-16:20: [https://etherpad.openstack.org/p/mitaka-qa-tempest-microversions Tempest Microversion Support and Testing]
* Wed 16:40-17:20: [https://etherpad.openstack.org/p/mitaka-qa-testr-datastore-layering Testr datastore layering and architecture cleanup]
* Wed 17:30-18:10: [https://etherpad.openstack.org/p/mitaka-qa-tempest-run-cli Tempest command line runner options/enhancements]
* Thurs 09:00-09:40: [https://etherpad.openstack.org/p/mitaka-qa-tempest-resource-config Tempest Existing Resource Configuration (aka resources.yaml)]
* Thurs 09:50-10:30: [https://etherpad.openstack.org/p/mitaka-qa-tempest-lib-service-clients Tempest-lib expansion and service client plugins]
* Thurs 16:30-17:10: [https://etherpad.openstack.org/p/mitaka-qa-devstack-roadmap Devstack/Grenade in Mitaka]
* Thurs 17:20-18:00: [https://etherpad.openstack.org/p/mitaka-qa-priorities Mitaka QA Priorities]

== Release management ==
* Thu 15:30: Mitaka process changes [https://etherpad.openstack.org/p/mitaka-relmgt-process-changes]
* Thu 16:30: Work session: the Mitaka plan [https://etherpad.openstack.org/p/mitaka-relmgt-plan]

== Searchlight ==
* Thu 4ː30: (Fishbowl) Prioritizing Search Integrations and Capabilities https://etherpad.openstack.org/p/searchlight-mitaka-summit-priorities-integrations
* Thu 5ː20: Cross Region Searching https://etherpad.openstack.org/p/searchlight-mitaka-summit-multi-region

== Sahara ==
* Thu 9:00: (Fishbowl) UX improvements http://etherpad.openstack.org/p/sahara-mitaka-ux
* Thu 9:50: (Fishbowl) Future plugins and EDP jobs https://etherpad.openstack.org/p/sahara-mitaka-future-plugins-edp
* Thu 11:00: Security https://etherpad.openstack.org/p/sahara-mitaka-security
* Thu 11:50: UI tech http://etherpad.openstack.org/p/sahara-mitaka-ui
* Thu 13:50: Image generation http://etherpad.openstack.org/p/sahara-mitaka-images
* Thu 14:40: Deprecation policies and plugins decoupling https://etherpad.openstack.org/p/sahara-mitaka-deprecation-policies
* Thu 15:30: Tests http://etherpad.openstack.org/p/sahara-mitaka-tests
* Fri 14:00-17:30: Contributors Meetup https://etherpad.openstack.org/p/sahara-mitaka-meetup

== Swift ==
* Wed 11:15am -12:54pm: Work session 1:
** Production Keymaster: https://etherpad.openstack.org/p/swift_production_keymaster_issues
** Ouststanding encryption issues: https://etherpad.openstack.org/p/swift_encryption_issues

* Wed 2:00pm - 4:20pm: Work session 2:
** container sync: https://etherpad.openstack.org/p/tokyo-swift-container-sync
** hummingbird status and unifying the sync protocol: https://etherpad.openstack.org/p/tokyo-swift-hummingbird
** global clusters: https://etherpad.openstack.org/p/tokyo-swift-global-clusters

* Wed 4:40pm - 5:20pm: Ops Feedback Session:
** https://etherpad.openstack.org/p/tokyo-swift-ops-feedback

* Wed 5:30pm - 6:10pm: Inbound cross-project issues:
** https://etherpad.openstack.org/p/tokyo-swift-cross-project

* Thurs 11:am - 12:30pm: Work session 3:
** Keystone session in swiftclient: https://etherpad.openstack.org/p/keystone-auth-session
** swiftclient docs: https://etherpad.openstack.org/p/swiftclient-docs
** Other issues: https://etherpad.openstack.org/p/tokyo-swiftclient-other

* Thurs 1:50pm - 4:10pm: Work session 4:
** rings (data placement):
** EC topics:
** symlinks: https://etherpad.openstack.org/p/swift_symlinks

* Thurs 4:30pm - 6:00pm: Work session 5:
** container sharding: https://etherpad.openstack.org/p/tokyo-swift-container-sharding
** fast-POST: https://etherpad.openstack.org/p/tokyo-swift-fast-post

* Fri all day: Swift contributors meetup:
** https://etherpad.openstack.org/p/tokyo-swift-contributors-meetup

== TripleO ==
* Wed 4:40pm - 5:20pm: (Fishbowl) Container Integration https://etherpad.openstack.org/p/tripleo-mitaka-containers
* Wed 5:30pm - 6:10pm: (Fishbowl) Upgrades https://etherpad.openstack.org/p/tripleo-mitaka-upgrades
* Thu 5:20pm - 6:00pm: (Workroom) tripleo-common, REST API https://etherpad.openstack.org/p/tripleo-mitaka-restapi
* Fri 9:00am - 12:30pm: (meetup) https://etherpad.openstack.org/p/tripleo-mitaka-meetup
* Fri 2:00pm - 5:30pm: (meetup) https://etherpad.openstack.org/p/tripleo-mitaka-meetup

== Trove ==
* Wednesday, 2015-08-28
** 15:40 - [https://etherpad.openstack.org/p/trove-mitaka-multiple-storage-options multiple storage options]
** 16:40 - [https://etherpad.openstack.org/p/trove-mitaka-managing-trove-upgrades managing trove upgrades]

* Thursday, 2015-08-29
** 11:00 - [https://etherpad.openstack.org/p/trove-mitaka-user-op-session User Op Session]
** 11ː50 - [https://etherpad.openstack.org/p/trove-mitaka-toggle-instance-status toggle instance status]
** 13ː50 - [https://etherpad.openstack.org/p/trove-mitaka-distribution-agnostic distribution agnostic]
** 14ː40 - [https://etherpad.openstack.org/p/trove-mitaka-building-guest-images building guest images]
** 15ː30 - [https://etherpad.openstack.org/p/mitaka-nova-service-users Nova Cross Project issues]

* Friday, 2015-08-30
** 14:00 - [https://etherpad.openstack.org/p/trove-mitaka-contributors-meetiup contributors meetup]

== Watcher ==
* Tuesday, 2015-10-27
** 10:45-11:45 - [https://etherpad.openstack.org/p/watcher--mitaka-contributors-meetup contributors meetup]

== Zaqar ==
* Wed 15:40-16:20 (W) https://etherpad.openstack.org/p/mitaka-zaqar-sahara
* Wed 17:30-18:10 (F) https://etherpad.openstack.org/p/mitaka-zaqar-on-horizon-and-misc
* Thu 09:00-9:40 (W) https://etherpad.openstack.org/p/mitaka-zaqar-client
* Thu 13:50-14:30 (W) https://etherpad.openstack.org/p/mitaka-zaqar-realtime-horizon

ReleaseNotes/Liberty

2015-07-17T18:25:59Z

Dan Smith:

<languages />
<translate>

[[Category:Kilo|Release Note]]
[[Category:Release Note|Liberty]]

= OpenStack Liberty Release Notes =

<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3">
__TOC__
</div>

== OpenStack Networking (Neutron) ==

=== Deprecated Plugins and Drivers ===
* The metaplugin is marked as deprecated in the Liberty release and will be removed from the source tree during the following release.

== OpenStack Compute (Nova) ==

=== Upgrade Notes ===
* If you are coming from Kilo stable, please make sure you have fully upgraded to the latest release of that lineage before deploying Liberty. Due to bug https://bugs.launchpad.net/nova/+bug/1474074 versions of Kilo from before the fix will be problematic when talking to Liberty nodes.

== OpenStack Telemetry (Ceilometer) ==

=== Key New Features ===

=== Upgrade Notes ===

* The name of some middleware used by ceilometer changed in a backwards-incompatible way. Before upgrading, edit the paste.ini file for ceilometer to change "oslo.middleware" to "oslo_middleware". For example using <nowiki>sed -ri 's/oslo\.middleware/oslo_middleware/' api_paste.ini</nowiki>

</translate>

Nova

2015-05-22T17:57:42Z

Dan Smith: /* Developer Contacts */

[[Category:Compute]]

== Projects ==

=== Nova ===

{| border="1" cellpadding="2"
| Official name
| '''OpenStack Compute'''
|-
| Source code
| https://github.com/openstack/nova
|-
| Bug tracker
| https://bugs.launchpad.net/nova
|-
| Feature tracker
| https://blueprints.launchpad.net/nova
|-
| Developer doc
| http://docs.openstack.org/developer/nova/
|}

=== Python Nova client ===
{| border="1" cellpadding="2"
| Source code
| https://github.com/openstack/python-novaclient
|-
| Bug tracker
| https://bugs.launchpad.net/python-novaclient
|-
| Feature tracker
| https://blueprints.launchpad.net/python-novaclient
|}

== People ==

* PTL
** John Garbutt (johnthetubaguy)
* [[Blueprints|Feature Drivers]]
** [https://launchpad.net/~nova-drivers/+members#active nova-drivers team]
* [[Nova/CoreTeam|Code Reviewers]]
** [https://review.openstack.org/#/admin/groups/25,members nova-core team]
* Blueprint Czar (responsible for maintenance of Nova's blueprint lists)
** TBC
* Bug Czar (responsible for organizing Nova's bug team that maintains Nova's bug list)
** TBC
* Stable Branch Czar (works with stable maintenance team around Nova things)
** Matt Riedemann (mriedem)
* Security Czar (responsible for working with VMT and leading nova-coresec)
** Michael Still (mikal)
* Gate Czar (on top of the status of Nova in the CI gate)
** Matt Riedemann (mriedem)
* APAC/US Meeting Czar (runs the 2100 UTC Nova meeting)
** Michael Still (mikal)
* [[Nova/APIWGLiaisons|API Working Group Liaisons]]
** Matthew Gilliard (gilliard) and Alex Xu (alex_xu)
* [[Nova-Ironic|Ironic Liaison]]
** John Villalovos (jlvillal)
** Michael Davies (mrda) (backup)
* python-novaclient Czar
** TBC
* [[Nova/Mentoring|Mentoring]] Czar
** John Garbutt (johnthetubaguy)
* Answers Czar
**
* Release Czar
** TBC
* Docs Czar
** TBC

For bug tag owners, please see: [[Nova/BugTriage | Nova Bug Triage ]]

For other folks, please see: [[CrossProjectLiaisons| Cross Project Liaisons (CPLs)]]

== General Resources ==

=== Documentation ===
* [http://docs.openstack.org/api/openstack-compute/2/content/ Compute API (v2) specification]
* [http://docs.openstack.org/trunk/openstack-compute/admin/content/ Administration Guide]

=== Release Process ===
* Nova releases are now done by providing the Release Manager with a git SHA to tag
* Client releases are done by following [[Nova/Client Release Process]]

=== Other resources ===
* Details about the [http://docs.openstack.org/developer/nova/support-matrix.html hypervisor support matrix]

== Resources for Contributors ==

=== Contributor Documentation ===

* [http://docs.openstack.org/infra/manual/developers.html General Developer's Guide]
* [http://docs.openstack.org/developer/nova/devref/index.html Nova Architecture and long term plan Docs]
* [http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html#when-is-a-blueprint-needed When you need a spec vs a blueprint]
* [http://specs.openstack.org/openstack/nova-specs/readme.html nova-spec process]
* [https://wiki.openstack.org/wiki/Nova/BugTriage Bug Triage Process and Bug tag owners]
* [[Nova/ReleaseChecklist]]

=== Nova subteams ===
The Nova team meets weekly: [[Meetings/Nova]]. In addition to a project-wide Nova gathering each week, there are some sub-teams. These sub-teams get together to discuss work going on in a focused area of Nova.

===== Notes on Sub-teams: =====

* The linked wiki page should include:
** The mission of the team
** A regular meeting time
** A coordinator / point of contact
** Meeting Agenda
** Links to logs from previous meetings
* A sub-team representative should regularly attend the main Nova meeting to provide a sub-team status report.
* A sub-team is *not* exclusively responsible for an area of code. Anyone is welcome to contribute anywhere. However, you are encouraged to communicate regularly with others working in the same area as you and sub-teams help encourage that.
* A sub-team is about organizing development efforts, but not necessarily setting direction for the project in a given area. Review of patches is still done by the nova-core team and it is beneficial to publish designs to the openstack-dev mailing list for vetting in advance.

===== Active Sub-teams: =====

* [[Meetings/EC2API|EC2 API]]
* [[Meetings/Hyper-V|Hyper-V]]
* [[Meetings/NovaBugScrub|Nova Bugs]]
* [[Gantt]] (ex-Scheduler) ([[Meetings/Scheduler|Meetings]])
* [[Meetings/VMwareAPI|VMwareAPI]]
* [[Meetings/XenAPI|XenAPI]]
* [[Meetings/Libvirt|Libvirt]]
* [[Meetings/Containers|Containers]]
* Docker
* [[Meetings/NovaCellsv2|Cellsv2]]

== History ==

* Previous PTLs
** Vish Ishaya (vishy), project beginning until Grizzly release
** Russell Bryant (russellb), Havana and Icehouse releases
** Michael Still (mikal), Juno and Kilo releases

* Previous or current core reviewers:
** Andrew Laski
** Brian D. Elliott
** Brian Lamar
** Brian Waldon
** Chris Behrens
** Chris Yeoh
** Dan Prince
** Dan Smith
** Daniel Berrange
** Devananda van der Veen
** Jay Pipes
** Joe Gordon
** Johannes Erdfelt
** John Garbutt
** Ken'ichi Ohmichi
** Kevin L. Mitchell
** Lorin Hochstein
** Mark McLoughlin
** Matt Dietz
** Matt Riedemann
** Melanie Witt
** Michael Still
** Nikola Dipanov
** Pádraig Brady
** Paul Voccio
** Rick Harris
** Russell Bryant
** Sandy Walsh
** Sean Dague
** Soren Hansen
** Trey Morris
** Vishvananda Ishaya
** Yun Mao

== Developer Contacts ==
'''Work In Progress'''
The following is a list of major subsystems within Nova and people that you
can approach on IRC or email if you have questions about that particular
subsystem. IRC nicks are in parentheses.

Nova Objects Framework
- Dan Smith (dansmith)
- Jay Pipes (jaypipes)

libvirt virt driver
- Dan Berrange (danpb)

Hyper-V virt driver
- Claudiu Belu (claudiub)

VMWare/vCenter virt driver

- Gary Kotton (garyk)

XenAPI virt driver

- John Garbutt (johnthetubaguy)

Ironic/bare metal

- Devananda van der Veen (devananda)

Scheduling and resource tracking

- Sylvain Bauza (bauzas)
- Jay Pipes (jaypipes)

Block device mapping and volume attachments
- Nikola Dipanov (ndipanov)

REST API

- Sean Dague (sdague)
- Alex Xu (alex_xu)

Database
- Andrew Laski (alaski)

Cells (v1 and v2)

- Andrew Laski (alaski)
- Melanie Witt (melwitt)

nova-network
- ?

Neutron
- Brent Eagles (beagles)

RPC and notification system
- Dan Smith (dansmith)

== So, you want to learn more about Nova? ==

To learn more about Nova, please read out about [[Nova/Mentoring|Nova Mentoring]]

----
[[Category:Nova]]