OpenStack - User contributions [en]

Meetings/Nova

2015-08-07T08:34:55Z

Matthew Gilliard: /* 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:
* August 6th 2015 1400 UTC, #openstack-meeting (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150806T140000)
* August 13th 2015 2100 UTC, #openstack-meeting (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150813T210000)

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
irina_pov krtaylor danpb alexpilotti flip214 jaypipes garyk edleafe dims
moshele anteaya Nisha sileht claudiub lxsli neiljerram markus_z swamireddy alevine
tonyb andreykurilin ndipanov sc68cal akuriata artom jlvillal mnestratov kashyap
aloga rgeragnov bauzas xyang tpatil med_ nic scottda
</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
** liberty-2 was tagged on Tuesday
** July 30: non-priority feature freeze
*** more details on exception process here: https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Non-priority_Feature_Freeze
*** for details see: https://etherpad.openstack.org/p/liberty-nova-non-priority-feature-proposal-freeze
* Bugs (stuck/critical)
** Gate status
*** http://status.openstack.org/elastic-recheck/index.html
** Critical bugs
*** ?
** Stable branch status
*** stable/kilo: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo,n,z
*** stable/juno: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/juno,n,z
* Regular Review Reminders
** all please look here for what patches to review: https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
** we have a list of actions: https://etherpad.openstack.org/p/YVR-nova-liberty-summit-action-items
** midcyle notes: https://etherpad.openstack.org/p/liberty-nova-midcycle
* 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:
*** https://review.openstack.org/#/c/202605/ Could we use rpc call() method for injecting NMI? When a driver doesn't support the API, we need to report it to the user.
*** ?
* Open discussion
** Cinder wants to change it's API which would impact Nova so Nova peeps should be reviewing this spec: https://review.openstack.org/#/c/149894/
*** mriedem joined the cinder midcycle hangout to talk through this a bit; ideally cinder would use microversions to do this and mimic the old locked behavior in the v1 and v2 APIs for backward compatibility.
** Needed input on a spec related to dynamic quota resources which would provide support for quota per flavor, AZ or flavor and AZ. - https://review.openstack.org/#/c/206160/
*** It is for mitaka but I am planning to work on an implementation internally for my company and want to do it in an upstreamable way. So, need your inputs.
** Need review for Improve performance of UnShelve api specs - https://review.openstack.org/135387 (abhishekk)
*** I have moved this spec under backlog as per discussion in the previous meeting
** snapshot and cloning for NFS backend - abhishekk
*** http://lists.openstack.org/pipermail/openstack-dev/2015-July/070736.html
** API requests that go all the way to the virt driver before responding. yay or nay? (alaski)

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

Meetings/NovaAPI

2015-06-12T11:32:53Z

Matthew Gilliard: /* Next Meeting */

= Weekly OpenStack Nova API Meeting =

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

* People to keep up with what work is going on with the Nova API and where it is headed
* Cloud providers, SDK maintainers and direct users of the REST API to provide feedback about the API and what they want out of it
* Help coordinate ongoing development work on the API

== Meetings ==

* Meeting Time: Weekly, Fridays at 12:00 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by: Kenichi Oomichi (oomichi)

=== Next Meeting ===
Friday 2015/06/12 at 1200 UTC

==== Agenda ====

Please feel free to add items to the Agenda

* Liberty work items and priority
** https://etherpad.openstack.org/p/liberty-api-working-list

* Removing "v3" from the code
** https://review.openstack.org/#/c/189218/

* Open Discussion

=== Previous Meetings (most recent first) ===
* 2014/09/12
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-09-12-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-09-12-00.00.log.html Log]
* 2014/06/20
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-20-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-20-00.01.log.html Log]
* 2014/06/06
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-06-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-06-00.01.log.html Log]
* 2014/05/30
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-30-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-30-00.00.log.html Log]
* 2014/05/09
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-09-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-09-00.00.log.html Log]
* 2014/04/25
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-25-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-25-00.00.log.html Log]
* 2014/04/18
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-18-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-18-00.00.log.html Log]
* 2014/04/11
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-11-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-11-00.01.log.html Log]
* 2014/04/04
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-04-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-04-00.01.log.html Log]
* 2014/03/28
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-28-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-28-00.00.log.html Log]
* 2014/03/21
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-21-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-21-00.00.log.html Log]
* 2014/03/14
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-14-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-14-00.01.log.html Log] (note log looks like it's missing parts probably due to netsplit)

Meetings/NovaAPI

2015-06-12T11:32:20Z

Matthew Gilliard: /* Meetings */

= Weekly OpenStack Nova API Meeting =

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

* People to keep up with what work is going on with the Nova API and where it is headed
* Cloud providers, SDK maintainers and direct users of the REST API to provide feedback about the API and what they want out of it
* Help coordinate ongoing development work on the API

== Meetings ==

* Meeting Time: Weekly, Fridays at 12:00 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by: Kenichi Oomichi (oomichi)

=== Next Meeting ===
Friday 2015/06/05 at 1200 UTC

==== Agenda ====

Please feel free to add items to the Agenda

* Liberty work items and priority
** https://etherpad.openstack.org/p/liberty-api-working-list

* Removing "v3" from the code
** https://review.openstack.org/#/c/189218/

* Open Discussion

=== Previous Meetings (most recent first) ===
* 2014/09/12
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-09-12-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-09-12-00.00.log.html Log]
* 2014/06/20
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-20-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-20-00.01.log.html Log]
* 2014/06/06
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-06-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-06-00.01.log.html Log]
* 2014/05/30
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-30-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-30-00.00.log.html Log]
* 2014/05/09
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-09-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-09-00.00.log.html Log]
* 2014/04/25
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-25-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-25-00.00.log.html Log]
* 2014/04/18
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-18-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-18-00.00.log.html Log]
* 2014/04/11
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-11-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-11-00.01.log.html Log]
* 2014/04/04
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-04-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-04-00.01.log.html Log]
* 2014/03/28
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-28-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-28-00.00.log.html Log]
* 2014/03/21
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-21-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-21-00.00.log.html Log]
* 2014/03/14
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-14-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-14-00.01.log.html Log] (note log looks like it's missing parts probably due to netsplit)

Meetings/NovaAPI

2015-06-05T11:32:08Z

Matthew Gilliard: /* Agenda */

= Weekly OpenStack Nova API Meeting =

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

* People to keep up with what work is going on with the Nova API and where it is headed
* Cloud providers, SDK maintainers and direct users of the REST API to provide feedback about the API and what they want out of it
* Help coordinate ongoing development work on the API

== Meetings ==

* Meeting Time: Weekly, Fridays at 12:00 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by: Kenichi Oomichi (oomichi)

=== Next Meeting ===
Friday 2015/06/05 at 1200 UTC

==== Agenda ====

Please feel free to add items to the Agenda

* Liberty work items and priority
** https://etherpad.openstack.org/p/liberty-api-working-list
** https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
** https://review.openstack.org/187272

* Patch Review
** Policy document https://review.openstack.org/162912 https://review.openstack.org/162913 https://review.openstack.org/187896
** Microversion in python-novaclient https://review.openstack.org/188410
** API policy cleanup https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nova-api-policy-final-part,n,z

* API-WG patches
** https://review.openstack.org/#/q/project:openstack/api-wg+status:open,n,z
** Microversion https://review.openstack.org/187112 https://review.openstack.org/187896
** tag limited length https://review.openstack.org/181784

* Open Discussion
** https://bugs.launchpad.net/nova/+bug/1426241 Still valid?
** https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/ << just published.

=== Previous Meetings (most recent first) ===
* 2014/09/12
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-09-12-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-09-12-00.00.log.html Log]
* 2014/06/20
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-20-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-20-00.01.log.html Log]
* 2014/06/06
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-06-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-06-00.01.log.html Log]
* 2014/05/30
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-30-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-30-00.00.log.html Log]
* 2014/05/09
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-09-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-09-00.00.log.html Log]
* 2014/04/25
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-25-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-25-00.00.log.html Log]
* 2014/04/18
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-18-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-18-00.00.log.html Log]
* 2014/04/11
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-11-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-11-00.01.log.html Log]
* 2014/04/04
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-04-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-04-00.01.log.html Log]
* 2014/03/28
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-28-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-28-00.00.log.html Log]
* 2014/03/21
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-21-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-21-00.00.log.html Log]
* 2014/03/14
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-14-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-14-00.01.log.html Log] (note log looks like it's missing parts probably due to netsplit)

Meetings/NovaAPI

2015-06-05T11:23:50Z

Matthew Gilliard: /* Next Meeting */

= Weekly OpenStack Nova API Meeting =

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

* People to keep up with what work is going on with the Nova API and where it is headed
* Cloud providers, SDK maintainers and direct users of the REST API to provide feedback about the API and what they want out of it
* Help coordinate ongoing development work on the API

== Meetings ==

* Meeting Time: Weekly, Fridays at 12:00 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by: Kenichi Oomichi (oomichi)

=== Next Meeting ===
Friday 2015/06/05 at 1200 UTC

==== Agenda ====

Please feel free to add items to the Agenda

* Liberty work items and priority
** https://etherpad.openstack.org/p/liberty-api-working-list
** https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
** https://review.openstack.org/187272

* Review
** policy document
** API policy cleanup

* API-WG patches
** https://review.openstack.org/#/q/project:openstack/api-wg+status:open,n,z

* Open Discussion
** https://bugs.launchpad.net/nova/+bug/1426241 Still valid?

=== Previous Meetings (most recent first) ===
* 2014/09/12
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-09-12-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-09-12-00.00.log.html Log]
* 2014/06/20
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-20-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-20-00.01.log.html Log]
* 2014/06/06
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-06-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-06-00.01.log.html Log]
* 2014/05/30
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-30-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-30-00.00.log.html Log]
* 2014/05/09
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-09-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-09-00.00.log.html Log]
* 2014/04/25
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-25-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-25-00.00.log.html Log]
* 2014/04/18
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-18-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-18-00.00.log.html Log]
* 2014/04/11
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-11-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-11-00.01.log.html Log]
* 2014/04/04
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-04-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-04-00.01.log.html Log]
* 2014/03/28
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-28-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-28-00.00.log.html Log]
* 2014/03/21
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-21-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-21-00.00.log.html Log]
* 2014/03/14
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-14-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-14-00.01.log.html Log] (note log looks like it's missing parts probably due to netsplit)

GitCommitMessages

2015-06-04T09:37:08Z

Matthew Gilliard: /* Including external references */

= Git Commit Good Practice =
__TOC__

The following document is based on experience doing code development, bug troubleshooting and code review across a number of projects using Git, including libvirt, QEMU and [[OpenStack]] Nova. Examination of other open source projects such as the Kernel, [[CoreUtils]], GNULIB and more suggested they all follow a fairly common practice. It is motivated by a desire to improve the quality of the Nova Git history. Quality is a hard term to define in computing; one person's "Thing of Beauty" is another's "Evil Hack". We can, however, come up with some general guidelines for what to do, or conversely what not to do, when publishing Git commits for merge with a project, in this case, [[OpenStack]].

This topic can be split into two areas of concern

# The structured set/split of the code changes
# The information provided in the commit message

== Executive Summary ==
The points and examples that will be raised in this document ought to clearly demonstrate the value in splitting up changes into a sequence of individual commits, and the importance in writing good commit messages to go along with them. If these guidelines were widely applied it would result in a significant improvement in the quality of the [[OpenStack]] Git history. Both a carrot & stick will be required to effect changes. This document intends to be the carrot by alerting people to the benefits, while anyone doing Gerrit code review can act as the stick ;-P

In other words, when reviewing a change in Gerrit, do not simply look at the correctness of the code. Review the commit message itself and request improvements to its content. Look out for commits which are mixing multiple logical changes and require the submitter to split them into separate commits. Ensure whitespace changes are not mixed in with functional changes. Ensure no-op code refactoring is done separately from functional changes. And so on.

It might be mentioned that Gerrit's handling of patch series is not entirely perfect. This is not a valid reason to avoid creating patch series. The tools being used should be subservient to developers needs, and since they are open source they can be fixed / improved. Software source code is "read mostly, write occassionally" and thus the most important criteria is to improve the long term maintainability by the large pool of developers in the community, and not to sacrifice too much for the sake of the single author who may never touch the code again.

And now the long detailed guidelines & examples of good & bad practice

== Structural split of changes ==
The cardinal rule for creating good commits is to ensure there is only one "logical change" per commit. There are many reasons why this is an important rule:

* The smaller the amount of code being changed, the quicker & easier it is to review & identify potential flaws.
* If a change is found to be flawed later, it may be necessary to revert the broken commit. This is much easier to do if there are not other unrelated code changes entangled with the original commit.
* When troubleshooting problems using Git's bisect capability, small well defined changes will aid in isolating exactly where the code problem was introduced.
* When browsing history using Git annotate/blame, small well defined changes also aid in isolating exactly where & why a piece of code came from.

=== Things to avoid when creating commits ===
With that in mind, there are some commonly encountered examples of bad things to avoid

* '''Mixing whitespace changes with functional code changes.'''
The whitespace changes will obscure the important functional changes, making it harder for a reviewer to correctly determine whether the change is correct.
'''Solution''': Create 2 commits, one with the whitespace changes, one with the functional changes. Typically the whitespace change would be done first, but that need not be a hard rule.
* '''Mixing two unrelated functional changes.'''
Again the reviewer will find it harder to identify flaws if two unrelated changes are mixed together. If it becomes necessary to later revert a broken commit, the two unrelated changes will need to be untangled, with further risk of bug creation.
* '''Sending large new features in a single giant commit.'''
It may well be the case that the code for a new feature is only useful when all of it is present. This does not, however, imply that the entire feature should be provided in a single commit. New features often entail refactoring existing code. It is highly desirable that any refactoring is done in commits which are separate from those implementing the new feature. This helps reviewers and test suites validate that the refactoring has no unintentional functional changes. Even the newly written code can often be split up into multiple pieces that can be independently reviewed. For example, changes which add new internal APIs/classes, can be in self-contained commits. Again this leads to easier code review. It also allows other developers to cherry-pick small parts of the work, if the entire new feature is not immediately ready for merge. Addition of new public HTTP APIs or RPC interfaces should be done in commits separate from the actual internal implementation. This will encourage the author & reviewers to think about the generic API/RPC design, and not simply pick a design that is easier for their currently chosen internal implementation. If patch impacts a public HTTP, use the APIImpact flag (see [[GitCommitMessages#Including_external_references | Including external references]]).

The basic rule to follow is

If a code change can be split into a sequence of patches/commits, then it should be split. ''Less is '''not''' more. More is more''.

=== Examples of bad practice ===
Now for some illustrations from Nova history. NB, although commit hashes are quoted for reference, author names are removed, since no single person needs to be blamed/picked on. Almost everybody is guilty of violating these good practice rules at some time or another. In addition the people who reviewed & approved these commits are just as guilty as the person who wrote/submitted them ;-P

==== Example 1 ====

<pre><nowiki>
commit ae878fc8b9761d099a4145617e4a48cbeb390623
Author: [removed]
Date: Fri Jun 1 01:44:02 2012 +0000

Refactor libvirt create calls

* minimizes duplicated code for create
* makes wait_for_destroy happen on shutdown instead of undefine
* allows for destruction of an instance while leaving the domain
* uses reset for hard reboot instead of create/destroy
* makes resume_host_state use new methods instead of hard_reboot
* makes rescue/unrescue not use hard reboot to recreate domain

Change-Id: I2072f93ad6c889d534b04009671147af653048e7
</nowiki></pre>

There are at least two independent changes made in this commit.

# The switch to use the new "reset" API for the "hard_reboot" method
# The adjustment to internal driver methods to not use "hard_reboot"

What is the problem with this

* First there is no compelling reason why these changes needed to be made at the same time. A first commit could have included the changes to stop calling "hard_reboot" in various places. A second commit could have re-written the "hard_reboot" impl.
* Second, as the switch to using the libvirt 'reset' method was buried in the large code refactoring, reviewers missed the fact that this was introducing a dependancy on a newer libvirt API version. This commit was identified as the culprit reasonably quickly, but a trivial revert is not possible, due to the wide variety of unrelated changes included.

==== Example 2 ====

<pre><nowiki>
commit e0540dfed1c1276106105aea8d5765356961ef3d
Author: [removed]
Date: Wed May 16 15:17:53 2012 +0400

blueprint lvm-disk-images

Add ability to use LVM volumes for VM disks.

Implements LVM disks support for libvirt driver.

VM disks will be stored on LVM volumes in volume group
specified by `libvirt_images_volume_group` option.
Another option `libvirt_local_images_type` specify which storage
type will be used. Supported values are `raw`, `lvm`, `qcow2`,
`default`. If `libvirt_local_images_type` = `default`, usual
logic with `use_cow_images` flag is used.
Boolean option `libvirt_sparse_logical_volumes` controls which type
of logical volumes will be created (sparsed with virtualsize or
usual logical volumes with full space allocation). Default value
for this option is `False`.
Commit introduce three classes: `Raw`, `Qcow2` and `Lvm`. They contain
image creation logic, that was stored in
`LibvirtConnection._cache_image` and `libvirt_info` methods,
that produce right `LibvirtGuestConfigDisk` configurations for
libvirt. `Backend` class choose which image type to use.

Change-Id: I0d01cb7d2fd67de2565b8d45d34f7846ad4112c2
</nowiki></pre>

This is introducing one major new feature, so on the surface it seems reasonable to use a single commit, but looking at the patch, it clearly has entangled a significant amount of code refactoring with the new LVM feature code. This makes it hard to identify likely regressions in support for QCow2/Raw images. This should have been split into at least four separate commits

# Replace the 'use_cow_images' config FLAG with the new FLAG 'libvirt_local_images_type', with back-compat code for support of legacy 'use_cow_images' FLAG
# Creation of internal "Image" class and subclasses for Raw & QCow2 image type impls
# Refactor libvirt driver to replace raw/qcow2 image management code, with calls to the new "Image" class APIs
# Introduce the new "LVM" Image class implementation

=== Examples of good practice ===
==== Example 1 ====

<pre><nowiki>
commit 3114a97ba188895daff4a3d337b2c73855d4632d
Author: [removed]
Date: Mon Jun 11 17:16:10 2012 +0100

Update default policies for KVM guest PIT & RTC timers

commit 573ada525b8a7384398a8d7d5f094f343555df56
Author: [removed]
Date: Tue May 1 17:09:32 2012 +0100

Add support for configuring libvirt VM clock and timers
</nowiki></pre>

Together these two changes provide support for configuring the KVM guest timers. The introduction of the new APIs for creating libvirt XML configuration have been clearly separated from the change to the KVM guest creation policy, which uses the new APIs.

==== Example 2 ====

<pre><nowiki>
commit 62bea64940cf629829e2945255cc34903f310115
Author: [removed]
Date: Fri Jun 1 14:49:42 2012 -0400

Add a comment to rpc.queue_get_for().
Change-Id: Ifa7d648e9b33ad2416236dc6966527c257baaf88

commit cf2b87347cd801112f89552a78efabb92a63bac6
Author: [removed]
Date: Wed May 30 14:57:03 2012 -0400

Add shared_storage_test methods to compute rpcapi.
...snip...
Add get_instance_disk_info to the compute rpcapi.
...snip...
Add remove_volume_connection to the compute rpcapi.
...snip...
Add compare_cpu to the compute rpcapi.
...snip...
Add get_console_topic() to the compute rpcapi.
...snip...
Add refresh_provider_fw_rules() to compute rpcapi.
...many more commits...
</nowiki></pre>

This sequence of commits refactored the entire RPC API layer inside nova to allow pluggable messaging implementations. With such a major change in a core piece of functionality, splitting up the work into a large sequence of commits was key to be able to do meaningful code review, and track / identify possible regressions at each step of the process.

== Information in commit messages ==
As important as the content of the change, is the content of the commit message describing it. When writing a commit message there are some important things to remember

* '''Do not assume the reviewer understands what the original problem was.'''
When reading bug reports, after a number of back & forth comments, it is often as clear as mud, what the root cause problem is. The commit message should have a clear statement as to what the original problem is. The bug is merely interesting historical background on /how/ the problem was identified. It should be possible to review a proposed patch for correctness without needing to read the bug ticket.
* '''Do not assume the reviewer has access to external web services/site.'''
In 6 months time when someone is on a train/plane/coach/beach/pub troubleshooting a problem & browsing Git history, there is no guarantee they will have access to the online bug tracker, or online blueprint documents. The great step forward with distributed SCM is that you no longer need to be "online" to have access to all information about the code repository. The commit message should be totally self-contained, to maintain that benefit.
* '''Do not assume the code is self-evident/self-documenting.'''
What is self-evident to one person, might be clear as mud to another person. Always document what the original problem was and how it is being fixed, for any change except the most obvious typos, or whitespace only commits.
* '''Describe ''why'' a change is being made.'''
A common mistake is to just document how the code has been written, without describing /why/ the developer chose to do it that way. By all means describe the overall code structure, particularly for large changes, but more importantly describe the intent/motivation behind the changes.
* '''Read the commit message to see if it hints at improved code structure.'''
Often when describing a large commit message, it becomes obvious that a commit should have in fact been split into 2 or more parts. Don't be afraid to go back and rebase the change to split it up into separate commits.
* '''Ensure sufficient information to decide whether to review.'''
When Gerrit sends out email alerts for new patch submissions there is minimal information included, principally the commit message and the list of files changes. Given the high volume of patches, it is not reasonable to expect all reviewers to examine the patches in detail. The commit message must thus contain sufficient information to alert the potential reviewers to the fact that this is a patch they need to look at.
* '''The first commit line is the most important.'''
In Git commits the first line of the commit message has special significance. It is used as email subject line, git annotate messages, gitk viewer annotations, merge commit messages and many more places where space is at a premium. As well as summarizing the change itself, it should take care to detail what part of the code is affected. eg if it affects the libvirt driver, mention 'libvirt' somewhere in the first line.
* '''Describe any limitations of the current code.'''
If the code being changed still has future scope for improvements, or any known limitations then mention these in the commit message. This demonstrates to the reviewer that the broader picture has been considered and what tradeoffs have been done in terms of short term goals vs. long term wishes.
* '''Do not include patch set-specific comments.'''
In other words, if you rebase your change please don't add "Patch set 2: rebased" to your commit message. That isn't going to be relevant once your change has merged. Please ''do'' make a note of that in Gerrit as a comment on your change, however. It helps reviewers know what changed between patch sets. This also applies to comments such as "Added unit tests", "Fixed localization problems", or any other such patch set to patch set changes that don't affect the overall intent of your commit.

The main rule to follow is:

The commit message must contain all the information required to fully understand & review the patch for correctness. ''Less is '''not''' more. More is more.''

=== Including external references ===
The commit message is primarily targeted towards human interpretation, but there is always some metadata provided for machine use. In the case of OpenStack this includes at least the 'Change-id', but also optional "bug" ID references, "blueprint" name references, a DocImpact flag, an APIImpact flag, and a SecurityImpact flag.

* The 'Change-id' line is a unique hash describing the change, which is generated by a Git commit hook. This should not be changed when rebasing a commit following review feedback, since it is used by Gerrit, to track versions of a patch.
* The 'bug' line can reference a bug in a few ways. Gerrit creates a link to the bug when viewing the patch on review.openstack.org so that reviewers can quickly access the bug on Launchpad.
**Closes-Bug: #1234567 -- use 'Closes-Bug' if the commit is intended to fully fix and close the bug being referenced.
**Partial-Bug: #1234567 -- use 'Partial-Bug' if the commit is only a partial fix and more work is needed.
**Related-Bug: #1234567 -- use 'Related-Bug' if the commit is merely related to the referenced bug.
* The 'blueprint' line should give the name of a Launchpad blueprint, if the commit is intended to implement a feature. Gerrit creates a link to the blueprint when viewing the patch on review.openstack.org so that reviewers can quickly access the blueprint on Launchpad.
* The '''DocImpact''' line contains the string DocImpact, and a comment about why the change impacts documentation. Put DocImpact on a line by itself. Use this flag to indicate that documentation is either contained in the patch or the change causes documentation to be needed to understand the change. Include as much information as possible. When this flag is included in a commit message, Gerrit creates a bug for the openstack-manuals project to triage and track, or move to the openstack-api-site as needed.
* The '''APIImpact''' line contains the string APIImpact, and a comment about why the change impacts a public HTTP API. Put APIImpact on a line by itself. Use this flag to indicate that the patch creates, updates, or deletes a public HTTP API or causes the behavior of a public HTTP API to change. Include as much information as possible. When this flag is included in a commit message, all of the associated reviews can be found using [https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z this report] that the [[API_Working_Group]] can use to help find relevant reviews.
* The '''SecurityImpact''' line simply contains the string SecurityImpact. It is used to indicate that a change has security implications and should be reviewed by the OpenStack Security Group.
* The '''UpgradeImpact''' line contains the string UpgradeImpact and a comment about why the change impacts upgrades. It is used to indicate that a change has upgrade implications for those doing continuous deployment or N to N+1 upgrades. Also consider updating the 'Upgrade Notes' section in the release notes for the affected project.

All machine targeted metadata is of secondary consequence to humans and thus it should all be grouped together at the end of the commit message.

Note: Although it is common practice across many open source projects using Git to include a "Signed-off-by" tag (generated by 'git commit -s'), this is not required for [[OpenStack]]. Prior to gaining the ability to submit code to Gerrit, [[OpenStack]] requires that all contributors sign the CLA, which serves an equivalent purpose.

We encourage the use of Co-Authored-By: name <name@example.com> in commit messages to indicate people who worked on a particular patch. It's a convention for recognizing multiple authors, and our projects would encourage the stats tools to observe it when collecting statistics.

=== Summary of Git commit message structure ===
* Provide a brief description of the change in the first line.
* Insert a single blank line after the first line.
* Provide a detailed description of the change in the following lines, breaking paragraphs where needed.
* The first line should be limited to 50 characters and should not end with a period (commit messages over 72 characters will be rejected by the gate).
* Subsequent lines should be wrapped at 72 characters.
* Put the 'Change-id', 'Closes-Bug #NNNNN' and 'blueprint NNNNNNNNNNN' lines at the very end.

For example

<pre><nowiki>
Switch libvirt get_cpu_info method over to use config APIs

The get_cpu_info method in the libvirt driver currently uses
XPath queries to extract information from the capabilities
XML document. Switch this over to use the new config class
LibvirtConfigCaps. Also provide a test case to validate
the data being returned.

DocImpact
Closes-Bug: #1003373
Implements: blueprint libvirt-xml-cpu-model
Change-Id: I4946a16d27f712ae2adf8441ce78e6c0bb0bb657
</nowiki></pre>

=== Some examples of bad practice ===
Now for some illustrations from Nova history, again with authors names removed since no one person is to blame for these.

==== Example 1 ====

<pre><nowiki>
commit 468e64d019f51d364afb30b0eed2ad09483e0b98
Author: [removed]
Date: Mon Jun 18 16:07:37 2012 -0400

Fix missing import in compute/utils.py

Fixes bug 1014829
</nowiki></pre>

Problem: this does not mention what imports where missing and why they were needed. This info was actually in the bug tracker, and should have been copied into the commit message, so that it would provide a self-contained description. e.g.:

<pre><nowiki>
Add missing import of 'exception' in compute/utils.py

nova/compute/utils.py makes a reference to exception.NotFound,
however exception has not been imported.
</nowiki></pre>

==== Example 2 ====

<pre><nowiki>
commit 2020fba6731634319a0d541168fbf45138825357
Author: [removed]
Date: Fri Jun 15 11:12:45 2012 -0600

Present correct ec2id format for volumes and snaps

Fixes bug 1013765
* Add template argument to ec2utils.id_to_ec2_id() calls

Change-Id: I5e574f8e60d091ef8862ad814e2c8ab993daa366
</nowiki></pre>

Problem: this does not mention what the current (broken) format is, nor what the new fixed format is. Again this info was available in the bug tracker and should have been included in the commit message. Furthermore, this bug was fixing a regression caused by an earlier change, but there is no mention of what the earlier change was. e.g.:

<pre><nowiki>
Present correct ec2id format for volumes and snaps

During the volume uuid migration, done by changeset XXXXXXX,
ec2 id formats for volumes and snapshots was dropped and is
now using the default instance format (i-xxxxx). These need
to be changed back to vol-xxx and snap-xxxx.

Adds a template argument to ec2utils.id_to_ec2_id() calls

Fixes bug 1013765
</nowiki></pre>

==== Example 3 ====

<pre><nowiki>
commit f28731c1941e57b776b519783b0337e52e1484ab
Author: [removed]
Date: Wed Jun 13 10:11:04 2012 -0400

Add libvirt min version check.

Fixes LP Bug #1012689.

Change-Id: I91c0b7c41804b2b25026cbe672b9210c305dc29b
</nowiki></pre>

Problem: This commit message is merely documenting what was done, and not why it was done. It should have mentioned what earlier changeset introduced the new min libvirt version. It should also have mentioned what behaviour is when the check fails. e.g.:

<pre><nowiki>
Add libvirt version check, min 0.9.7

The commit XXXXXXXX introduced use of the 'reset' API
which is only available in libvirt 0.9.7 or newer. Add a check
performed at startup of the compute server against the libvirt
connection version. If the version check fails the compute
service will shutdown.

Fixes LP Bug #1012689.
Change-Id: I91c0b7c41804b2b25026cbe672b9210c305dc29b
</nowiki></pre>

=== Examples of good practice ===
==== Example 1 ====

<pre><nowiki>
commit 3114a97ba188895daff4a3d337b2c73855d4632d
Author: [removed]
Date: Mon Jun 11 17:16:10 2012 +0100

Update default policies for KVM guest PIT & RTC timers

The default policies for the KVM guest PIT and RTC timers
are not very good at maintaining reliable time in guest
operating systems. In particular Windows 7 guests will
often crash with the default KVM timer policies, and old
Linux guests will have very bad time drift

Set the PIT such that missed ticks are injected at the
normal rate, ie they are delayed

Set the RTC such that missed ticks are injected at a
higher rate to "catch up"

This corresponds to the following libvirt XML

<clock offset='utc'>
<timer name='pit' tickpolicy='delay'/>
<timer name='rtc' tickpolicy='catchup'/>
</clock>

And the following KVM options

-no-kvm-pit-reinjection
-rtc base=utc,driftfix=slew

This should provide a default configuration that works
acceptably for most OS types. In the future this will
likely need to be made configurable per-guest OS type.

Closes-Bug: #1011848

Change-Id: Iafb0e2192b5f3c05b6395ffdfa14f86a98ce3d1f
</nowiki></pre>

Some things to note about this example commit message

* It describes what the original problem is (bad KVM defaults)
* It describes the functional change being made (the new PIT/RTC policies)
* It describes what the result of the change is (new the XML/QEMU args)
* It describes scope for future improvement (the possible per-OS type config)
* It uses the Closes-Bug notation

==== Example 2 ====

<pre><nowiki>
commit 31336b35b4604f70150d0073d77dbf63b9bf7598
Author: [removed]
Date: Wed Jun 6 22:45:25 2012 -0400

Add CPU arch filter scheduler support

In a mixed environment of running different CPU architecutres,
one would not want to run an ARM instance on a X86_64 host and
vice versa.

This scheduler filter option will prevent instances running
on a host that it is not intended for.

The libvirt driver queries the guest capabilities of the
host and stores the guest arches in the permitted_instances_types
list in the cpu_info dict of the host.

The Xen equivalent will be done later in another commit.

The arch filter will compare the instance arch against
the permitted_instances_types of a host
and filter out invalid hosts.

Also adds ARM as a valid arch to the filter.

The ArchFilter is not turned on by default.

Change-Id: I17bd103f00c25d6006a421252c9c8dcfd2d2c49b
</nowiki></pre>

Some things to note about this example commit message

* It describes what the problem scenario is (mixed arch deployments)
* It describes the intent of the fix (make the schedular filter on arch)
* It describes the rough architecture of the fix (how libvirt returns arch)
* It notes the limitations of the fix (work needed on Xen)

[[Category: Contribute]]

Nova

2015-05-20T22:36:00Z

Matthew Gilliard: /* People */

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

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

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

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

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

----
[[Category:Nova]]

Meetings/NovaAPI

2015-05-13T08:57:34Z

Matthew Gilliard: /* Next Meeting */

= Weekly OpenStack Nova API Meeting =

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

* People to keep up with what work is going on with the Nova API and where it is headed
* Cloud providers, SDK maintainers and direct users of the REST API to provide feedback about the API and what they want out of it
* Help coordinate ongoing development work on the API

== Meetings ==

* Meeting Time: Weekly, Fridays at 12:00 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by: Kenichi Oomichi (oomichi)

=== Next Meeting ===
Friday 2015/05/15 at 1200 UTC

==== Agenda ====

Please feel free to add items to the Agenda

* Vancouver summit (left on the agenda since last week)
** Suggestion for what we want to discuss at summit: https://etherpad.openstack.org/p/liberty-nova-api

* Bugs
** https://bugs.launchpad.net/nova/+bug/1426241 Still valid?

* API-WG patches
** https://review.openstack.org/#/q/project:openstack/api-wg+status:open,n,z

* Open Discussion

=== Previous Meetings (most recent first) ===
* 2014/09/12
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-09-12-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-09-12-00.00.log.html Log]
* 2014/06/20
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-20-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-20-00.01.log.html Log]
* 2014/06/06
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-06-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-06-00.01.log.html Log]
* 2014/05/30
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-30-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-30-00.00.log.html Log]
* 2014/05/09
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-09-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-09-00.00.log.html Log]
* 2014/04/25
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-25-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-25-00.00.log.html Log]
* 2014/04/18
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-18-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-18-00.00.log.html Log]
* 2014/04/11
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-11-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-11-00.01.log.html Log]
* 2014/04/04
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-04-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-04-00.01.log.html Log]
* 2014/03/28
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-28-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-28-00.00.log.html Log]
* 2014/03/21
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-21-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-21-00.00.log.html Log]
* 2014/03/14
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-14-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-14-00.01.log.html Log] (note log looks like it's missing parts probably due to netsplit)

Meetings/NovaAPI

2015-05-01T07:29:37Z

Matthew Gilliard: /* Meetings */

= Weekly OpenStack Nova API Meeting =

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

* People to keep up with what work is going on with the Nova API and where it is headed
* Cloud providers, SDK maintainers and direct users of the REST API to provide feedback about the API and what they want out of it
* Help coordinate ongoing development work on the API

== Meetings ==

* Meeting Time: Weekly, Fridays at 12:00 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by: Kenichi Oomichi (oomichi)

=== Next Meeting ===
Friday 2015/05/01 at 1200 UTC

==== Agenda ====

Please feel free to add items to the Agenda

* Vancouver summit
** https://etherpad.openstack.org/p/liberty-nova-api

* Urgent reviews
These are not urgent but would be very helpful.
** https://review.openstack.org/#/c/177778/
** https://review.openstack.org/#/c/162913/
** https://review.openstack.org/#/c/162912/

* Nova API meeting time
** How well does this new time suit everyone?

* API-WG representative
** jaypipes wrote up https://wiki.openstack.org/wiki/Nova/APIWGLiaisons - any comments or questions?

* Open Discussion

=== Previous Meetings (most recent first) ===
* 2014/09/12
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-09-12-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-09-12-00.00.log.html Log]
* 2014/06/20
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-20-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-20-00.01.log.html Log]
* 2014/06/06
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-06-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-06-00.01.log.html Log]
* 2014/05/30
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-30-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-30-00.00.log.html Log]
* 2014/05/09
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-09-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-09-00.00.log.html Log]
* 2014/04/25
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-25-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-25-00.00.log.html Log]
* 2014/04/18
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-18-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-18-00.00.log.html Log]
* 2014/04/11
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-11-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-11-00.01.log.html Log]
* 2014/04/04
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-04-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-04-00.01.log.html Log]
* 2014/03/28
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-28-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-28-00.00.log.html Log]
* 2014/03/21
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-21-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-21-00.00.log.html Log]
* 2014/03/14
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-14-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-14-00.01.log.html Log] (note log looks like it's missing parts probably due to netsplit)

Nova/APIWGLiaisons

2015-04-30T14:58:43Z

Matthew Gilliard: /* Liberty release cycle liaisons */

[[Category:Compute]]
= API Working Group Liaisons =

The [[API_Working_Group|API working group]] is a cross-functional team that tries to improve the developer experience of API users by converging the OpenStack API to a consistent and pragmatic RESTful design. The Nova team has individuals that serve as liaisons to the API working group.

= Responsibilities of Liaisons =

Individuals serving as the Nova/API working group liaisons have the following responsibilities:

1.Monitor the active patch queue in nova (and nova-specs) and look out for any patch that adds or changes the REST API

2. For each patch collected in #1, determine if the constructs used in the patch (or proposed spec) match the guidance currently laid out in the API working group repo's guidance documents.

3. If the patch does NOT match the guidance from the API working group, do a code review on the patch pointing to the guidance from the API working group, and ask the author to align with that guidance. Include in your research patches to the API working group that may actually be in review and not merged. (An example of this recently occurred with Sergey Nikitin's
re-proposed instance tagging spec: https://review.openstack.org/#/c/177112/. See Ryan Brown's reference to an in-progress API working group guidance on tagging)

4. If there is NO guidance in the API working group repo for a particular proposed API change or addition, the liaison should **either** create a proposed patch to the API working group with guidance that clarifies the missing functionality that is introduced in the new Nova patch or spec patch, and bring the proposed guidance to the attention of the API working group. **or** the liaison should working with a member of the API working group to draft such a guideline. The liaison should mark the corresponding Nova patch with a -1 Code Review vote with a link to the proposed guideline, noting that the patch should be put on hold (Work In Progress) until the guideline is merged.

= Liberty release cycle liaisons =

* Matthew Gilliard (gilliard)
* Alex Xu (alex_xu)

ReleaseNotes/Kilo

2015-04-28T12:19:52Z

Matthew Gilliard: /* API v2.1 */

{| style="color:#000000; border:solid 1px #A8A8A8; padding:0.5em; margin:0.5em 0; background-color:#FFFFFF;font-size:95%; vertical-align:middle;"
| style="padding:1em;width: 40px" | [[Image:Warning.svg|40px]]
| '''Release Under Development'''
This release of OpenStack is under development and has yet to be completed. It will be released on April 30, 2015

The information on this page may not accurately reflect the state of release at the current point in time.
|}

= OpenStack 2015.1 (Kilo) Release Notes =

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

== General Upgrade Notes ==

* TBD

== OpenStack Object Storage (Swift) ==

=== Key New Features ===

=== Known Issues ===
None

=== Upgrade Notes ===

== OpenStack Compute (Nova) ==

=== Key New Features ===

==== API v2.1 ====

* We have the first release of the next generation of the Nova API, v2.1. The v2.1 is designed to be backwards compatible with v2.0 with the addition of strong API validation. All changes to the API are discoverable via the advertised microversion. For more details see: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html

* For kilo, by default we are still using v2.0 API code to server v2.0 API requests. It is hoped that in liberty that v2.1 will be used to serve requests for both v2.0 and v2.1.

* For liberty v2.0 is now frozen, and all new features will now be added into the v2.1 API using the microversions mechanism. Microversion increments released with kilo are:
** Extending the keypair API to support for x509 certificates, to be used with Windows WinRM, is one of the first API features added as a microversion in the v2.1 API.
** Exposing additional attributes in os-extended-server-attributes

* python-novaclient does not yet have support for the v2.1 API

==== Upgrade Support ====

* We have reduced the data migrations that happen in the DB migration scripts, this now happens in a "lazy" way inside the DB objects code. There is a nova-manage command to help force migration of the data, but there are bugs that limit its usefulness in the current release. For more details see: http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/flavor-from-sysmeta-to-blob.html

* Change https://review.openstack.org/#/c/97946/ adds database migration 267 which scans for null instances.uuid records and will fail if any are found since the migrate ultimately needs to make instances.uuid non-nullable and adds a UniqueConstraint on that column. A helper script is provided to search for null instances.uuid records before running the database migrations. Before running 'nova-manage db sync', run the helper script 'nova-manage db null_instance_uuid_scan' which, by default, will just search and dump results, it does not change anything. Pass the --delete option to the null_instance_uuid_scan command to automatically remove any null records were instances.uuid is null.

==== Scheduler ====

* A selection of performance optimisations
* We are in the process of making structural changes to the scheduler that will help improve our ability to evolve and improve scheduling. This should not be visible from an end user perspective.

==== Cells v2 ====

* There are some initial parts of cell v2 supported added, but this feature is not yet ready to use.
* new 'nova-manage api_db sync' and 'nova-manage api_db version' commands for working with the new api database for cells, but nothing is using this database yet so it is not necessary to set it up.

==== Compute Drivers ====

===== Hyper-V =====

* Support for generation 2 VMs: https://blueprints.launchpad.net/nova/+spec/hyper-v-generation-2-vms
* Support for SMB based volumes, to sit along side existing iSCSI volume support: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/hyper-v-smbfs-volume-support.html
* Support for x509 certificate based key pairs: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/keypair-x509-certificates.html
* Host power actions now work with Hyper-V: https://blueprints.launchpad.net/nova/+spec/hyper-v-host-power-actions

===== Libvirt (KVM) =====

* NFV related features:
** NUMA based scheduling: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/input-output-based-numa-scheduling.html
** Pinning guest vCPUs: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/virt-driver-cpu-pinning.html
** Large page support: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/virt-driver-large-pages.html
* vhostuser VIF driver: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/libvirt_vif_vhostuser.html
* Support for running KVM on IBM System z: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/libvirt-kvm-systemz.html
* Support for parallels: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/pcs-support.html
* Support for SMB based volumes: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/libvirt-smbfs-volume-support.html
* Quiesce using QEMU guest agent: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/quiesced-image-snapshots-with-qemu-guest-agent.html
* Quobyte volume support: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/quobyte-nova-driver.html
* Support for QEMU iSCSI initiator: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/qemu-built-in-iscsi-initiator.html

===== VMware =====

* Support for Ephemeral disks: http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/vmware-ephemeral-disk-support.html
* Support fo vSAN: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/vmware-vsan-support.html
* Support for based OVA images: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/vmware-driver-ova-support.html
* Support for SPBM based storage policies: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/vmware-spbm-support.html

===== Ironic =====

* Support to pass flavor capabilities to ironic: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/pass-flavor-capabilities-to-ironic-virt-driver.html

=== Known Issues ===

* Evacuate recovery code has the potential to destroy data. On nova-compute startup, instances reported by the hypervisor are examined to see if they have moved (i.e. been evacuated) from the current host during the outage. If the determination is made that they were, then they are destroyed locally. This has the potential to choose incorrectly and destroy instances unexpectedly. On libvirt-like nodes, this can be triggered by changing the system hostname. On vmware-like nodes, this can be triggered by attempting to manage a single vcenter deployment from two different hosts (with different hostnames). This will be fixed properly in Liberty, but for now deployments that wish to disable this behavior as a preventive measure can set workarounds.destroy_after_evacuate=False. NOTE: This is not a regression and has been a flaw in the design of the evacuate feature since its introduction. There is no easy fix for this, hence this workaround to limit the potential for damage. The proposed fix in liberty is here: https://review.openstack.org/#/c/161444/.

* Forced flavor data migration misses out some instances: https://launchpad.net/bugs/1447132

* We don't have a RPC pin alias for kilo, just remove all RPC pins when wanting to use kilo level RPC versions: https://launchpad.net/bugs/1444745

* The generate config examples possibly missing some oslo related configuration

=== Upgrade Notes ===

* EC2 API support has been deprecated, and is likely to be removed in kilo, see f098398a836e3671c49bb884b4a1a1988053f4b2
* Websocket proxies need to be upgraded in a lockstep with the API nodes, as older API nodes will not be sending the access_url when authorizing console access, and newer proxy services (this commit and onward) would fail to authorize such requests 9621ccaf05900009d67cdadeb1aac27368114a61
* After fully upgrading to kilo (i.e. all nodes are running kilo code), you should start a background migration of flavor information from its old home to its new home. Kilo conductor nodes will do this on the fly when necessary, but the rest of the idle data needs to be migrated in the the background. This is critical to complete before the Liberty release, where support for the old location will be dropped. Use "nova-manage migrate-flavor-data" to perform this transition.

== OpenStack Image Service (Glance) ==
=== Key New Features ===
* TBD

=== Known Issues ===

=== Upgrade Notes ===

== OpenStack Dashboard (Horizon) ==

=== Key New Features ===
* TBD

=== Known Issues ===

=== Upgrade Notes ===

== OpenStack Identity (Keystone) ==

=== Key New Features ===

* Keystone now supports Hierarchical Multitenancy. Projects can be nested under other projects via the <code>parent_id</code> optional attribute when creating a project.
** TBD - More info.
* Fernet tokens - TBD - More Info
* WebSSO - TBD - More info
* Pluggable Assignment Model - TBD - More Info
* Assignment / Resource Split - TBD - More Info
* Extensions to Core functionality - TBD - More Info
* (Experimental) Per-Domain Identity Backend Configuration can be stored in SQL - TBD More Info
* [http://docs.openstack.org/developer/keystone/configure_federation.html#keystone-as-an-identity-provider-idp Keystone-to-Keystone Identity Federation] is now considered stable.
** IDP Registration - TBD - More Info
** ECP Wrapped Assertions Endpoint - TBD - More Info
* Keystone now supports [http://docs.openstack.org/developer/keystone/extensions/openidc.html OpenID Connect] as a federated identity authentication mechanism.
* Trusts now support redelegation. If allowed when the trust is created, a trustee can redelegate the roles from the trust via another trust.
* It is now possible to request an explicitly unscoped token from Keystone.

=== Known Issues ===

* TBD

=== Upgrade Notes ===

* XML support in Keystone has been removed as of Kilo. When upgrading from Juno to Kilo, it is recommended that references to XML and XmlBodyMiddleware be removed from the [https://github.com/openstack/keystone/blob/master/etc/keystone-paste.ini Keystone Paste configuration]. This includes removing the XML middleware filters and there references from the public_api, admin_api, api_v3, public_version_api, admin_version_api and any other pipelines that may contain the XML filters.
* [http://specs.openstack.org/openstack/openstack-specs/specs/no-downward-sql-migration.html SQL Schema Downgrades are no longer supported]. This change is the result of evaluation that downward SQL migrations are not well tested and become increasingly difficult to support with the volume of data-change that occurs in many of the migrations.

== OpenStack Network Service (Neutron) ==
=== Key New Features ===
* New Plugins supported in Kilo include the following:
** Brocade ML2 driver for MLX and ICX switches
** Brocade L3 routing plugin for MLX switch
** Brocade Vyatta vRouter L3 Plugin
** Brocade Vyatta vRouter Firewall Driver
** Brocade Vyatta vRouter VPN Driver

=== Known Issues ===
* The Firewall-as-a-Service project is still marked as experimental for the Kilo release.

=== Upgrade Notes ===

From Havana, Neutron no longer supported an explicit lease database (https://bugs.launchpad.net/bugs/1202392). This left dead code including unused environment variable. In order to remove the dead code (https://review.openstack.org/#/c/152398/), a change to the dhcp.filter is required, so that line:

'''dnsmasq: EnvFilter, dnsmasq, root, NEUTRON_NETWORK_ID='''

Be replaced by:

'''dnsmasq: CommandFilter, dnsmasq, root'''

After advanced services were split into separate packages and received their own service configuration files (specifically, etc/neutron/neutron_lbaas.conf, etc/neutron/neutron_fwaas.conf and etc/neutron/neutron_vpnaas.conf), active service provider configuration can be different after upgrade (specifically, default load balancer (haproxy) and vpn (openswan) providers can be enabled for you even though you previously disabled them in neutron.conf). Please make sure you review configuration after upgrade so that it reflects the desired state of service providers.

Note: this will have no effect if the related service plugin is not loaded in neutron.conf.

* The default value of api_workers is now equal to the number of CPUs in the host. If you currently use the default, ensure you set api_workers to a reasonable number for your installation. (https://review.openstack.org/#/c/140493/)
* The neutron.allow_duplicate_networks config option is deprecated in Kilo and will be removed in Liberty where the default behavior will be to just allow multiple ports attached to an instance on the same network in Neutron. (https://review.openstack.org/163581)
* The linuxbridge agent now enables VXLAN by default (https://review.openstack.org/160826)
* neutron-ns-metadata-proxy can now be run as non-root (https://review.openstack.org/147437)

=== Other Notes (Deprecation/EOL etc) ===

* Deprecation
** Brocade Classic plugin for Brocade's VDX/VCS series of hardware switches will be deprecated in the L-Release. The functionality provided by this plugin is now addressed by the ML2 Driver available for the VDX series of hardware. The plugin is slated for removal after this release cycle.

== OpenStack Block Storage (Cinder) ==
=== Key New Features ===
* From this point forward any new database schema upgrades will not require restarting Cinder services right away. The services are now independent of schema upgrades. This is part one to Cinder supporting rolling upgrades!
* Ability to add/remove volumes from an existing consistency group. [http://docs.openstack.org/admin-guide-cloud/content/consistency-groups.html Read docs for more info].
* Ability to create a consistency group from an existing consistency group snapshot. [http://docs.openstack.org/admin-guide-cloud/content/consistency-groups.html Read docs for more info].
* Create more fine tuned filters/weighers to set how the scheduler will choose a volume backend. [http://docs.openstack.org/admin-guide-cloud/content/driver_filter_weighing.html Read the docs for more info].
* Encrypted volumes can now be backed up using the Cinder backup service. [http://docs.openstack.org/admin-guide-cloud/content/volume-backup-restore.html Read the docs for more info].
* Ability to create private volume types. This is perfect when you want to make volume types available to only a specific tenant or to test it before making available to your cloud. To do so use the ''cinder type-create <name> --is-public''.
* Oversubscription with thin provision is configurable. [http://docs.openstack.org/admin-guide-cloud/content/over_subscription.html Read docs for more info].
* Ability to add descriptions to volume types. To do so use ''cinder type-create <name> <description>
* Cinder now can return multiple iSCSI paths information so that the connector can attach volumes even when the primary path is down ([https://review.openstack.org/#/c/134681/ when connector's multipath feature is enabled] or [https://review.openstack.org/#/c/140877/ not enabled]).

=== Known Issues ===
None yet

=== Upgrade Notes ===
* The 'host' config option for multiple-storage backends in cinder.conf is renamed to 'backend_host' in order to avoid a naming conflict with the 'host' to locate redis. If you use this option, please ensure your configuration files are updated.

== OpenStack Telemetry (Ceilometer) ==
=== Key New Features ===
* Support to add jitter to polling cycles to ensure pollsters are not querying service's api at the same time
* Ceilometer API RBAC support
* Improved Event support:
** Multi-pipeline support to enable unique processing and publishing of events
** Enabled ability to capture raw notification messages for auditing and postmortem analysis
** Support for persisting events into ElasticSearch
** Publishing support to database, http, file, kafa and oslo.messaging supported message queues
** Option to split off the events persistence into a separate database
** Telemetry now supports to collect and store all the event type meters as events. A new option, ''disable_non_metric_meters'', was added to the configuration in order to provide the possibility to turn off storing these events as samples. For further information please see the [http://docs.openstack.org/trunk/config-reference/content/ch_configuring-openstack-telemetry.html Telemetry Configuration Reference]
** The Administrator Guide in OpenStack Manuals was updated with a new [http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-events.html Events section], where you can find further information about this functionality.
* Improved pipeline publishing support:
** Support to publish events and samples to Kafka or HTTP targets
** Publish data to multiple queues
* Additional meters
** memory and disk meters for Hyper-V
** disk meters for LibVirt
** power and thermal related IPMI meters, more meters from NodeManager
** ability to meter Ceph
* IPv6 support enabled in Ceilometer udp publisher and collector
* [http://launchpad.net/gnocchi Gnocchi] dispatch support for ceilometer-collector
* Self-disabled pollster mechanism

=== Known Issues ===
* TBD

=== Upgrade Notes ===
* Deprecated meters:
** The instance:<flavor> meter is deprecated in the Kilo release. In order to retrieve samples or statistics based on flavor you can use the following queries:
statistics:
ceilometer statistics -m instance -g resource_metadata.instance_type

samples:
ceilometer sample-list -m instance -q metadata.instance_type=<value>
* Middleware used to meter Swift was previously packaged in Ceilometer and is now deprecated. It is now separated into it's own library: ceilometermiddleware.
** Juno configuration: http://docs.openstack.org/juno/install-guide/install/apt/content/ceilometer-swift.html
** Kilo configuration: http://docs.openstack.org/kilo/install-guide/install/apt/content/ceilometer-swift.html

== OpenStack Orchestration (Heat) ==

WIP (will move here) https://etherpad.openstack.org/p/heat-kilo-releasenotes

=== Key New Features ===

=== Known Issues ===
None yet

=== Upgrade Notes ===
None yet

== OpenStack Database service (Trove) ==
=== Key New Features ===

=== Known Issues ===
None yet

=== Upgrade Notes ===
None yet

== OpenStack Data Processing service (Sahara) ==
=== Key New Features ===
TBD

=== Known Issues ===
TBD

=== Upgrade Notes ===
TBD

== OpenStack Documentation ==

=== Key New Features ===

* TBD

=== Known Issues ===

=== Upgrade Notes ===
None yet

ReleaseNotes/Kilo

2015-04-28T12:19:31Z

Matthew Gilliard: /* API v2.1 */

{| style="color:#000000; border:solid 1px #A8A8A8; padding:0.5em; margin:0.5em 0; background-color:#FFFFFF;font-size:95%; vertical-align:middle;"
| style="padding:1em;width: 40px" | [[Image:Warning.svg|40px]]
| '''Release Under Development'''
This release of OpenStack is under development and has yet to be completed. It will be released on April 30, 2015

The information on this page may not accurately reflect the state of release at the current point in time.
|}

= OpenStack 2015.1 (Kilo) Release Notes =

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

== General Upgrade Notes ==

* TBD

== OpenStack Object Storage (Swift) ==

=== Key New Features ===

=== Known Issues ===
None

=== Upgrade Notes ===

== OpenStack Compute (Nova) ==

=== Key New Features ===

==== API v2.1 ====

* We have the first release of the next generation of the Nova API, v2.1. The v2.1 is designed to be backwards compatible with v2.0 with the addition of strong API validation. All changes to the API are discoverable via the advertised microversion. For more details see: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html

* For kilo, by default we are still using v2.0 API code to server v2.0 API requests. It is hoped that in liberty that v2.1 will be used to serve requests for both v2.0 and v2.1.

* For liberty v2.0 is now frozen, and all new features will now be added into the v2.1 API using the microversions mechanism. Microversion increments released with kilo are:

** Extending the keypair API to support for x509 certificates, to be used with Windows WinRM, is one of the first API features added as a microversion in the v2.1 API.
** Exposing additional attributes in os-extended-server-attributes

* python-novaclient does not yet have support for the v2.1 API

==== Upgrade Support ====

* We have reduced the data migrations that happen in the DB migration scripts, this now happens in a "lazy" way inside the DB objects code. There is a nova-manage command to help force migration of the data, but there are bugs that limit its usefulness in the current release. For more details see: http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/flavor-from-sysmeta-to-blob.html

* Change https://review.openstack.org/#/c/97946/ adds database migration 267 which scans for null instances.uuid records and will fail if any are found since the migrate ultimately needs to make instances.uuid non-nullable and adds a UniqueConstraint on that column. A helper script is provided to search for null instances.uuid records before running the database migrations. Before running 'nova-manage db sync', run the helper script 'nova-manage db null_instance_uuid_scan' which, by default, will just search and dump results, it does not change anything. Pass the --delete option to the null_instance_uuid_scan command to automatically remove any null records were instances.uuid is null.

==== Scheduler ====

* A selection of performance optimisations
* We are in the process of making structural changes to the scheduler that will help improve our ability to evolve and improve scheduling. This should not be visible from an end user perspective.

==== Cells v2 ====

* There are some initial parts of cell v2 supported added, but this feature is not yet ready to use.
* new 'nova-manage api_db sync' and 'nova-manage api_db version' commands for working with the new api database for cells, but nothing is using this database yet so it is not necessary to set it up.

==== Compute Drivers ====

===== Hyper-V =====

* Support for generation 2 VMs: https://blueprints.launchpad.net/nova/+spec/hyper-v-generation-2-vms
* Support for SMB based volumes, to sit along side existing iSCSI volume support: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/hyper-v-smbfs-volume-support.html
* Support for x509 certificate based key pairs: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/keypair-x509-certificates.html
* Host power actions now work with Hyper-V: https://blueprints.launchpad.net/nova/+spec/hyper-v-host-power-actions

===== Libvirt (KVM) =====

* NFV related features:
** NUMA based scheduling: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/input-output-based-numa-scheduling.html
** Pinning guest vCPUs: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/virt-driver-cpu-pinning.html
** Large page support: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/virt-driver-large-pages.html
* vhostuser VIF driver: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/libvirt_vif_vhostuser.html
* Support for running KVM on IBM System z: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/libvirt-kvm-systemz.html
* Support for parallels: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/pcs-support.html
* Support for SMB based volumes: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/libvirt-smbfs-volume-support.html
* Quiesce using QEMU guest agent: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/quiesced-image-snapshots-with-qemu-guest-agent.html
* Quobyte volume support: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/quobyte-nova-driver.html
* Support for QEMU iSCSI initiator: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/qemu-built-in-iscsi-initiator.html

===== VMware =====

* Support for Ephemeral disks: http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/vmware-ephemeral-disk-support.html
* Support fo vSAN: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/vmware-vsan-support.html
* Support for based OVA images: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/vmware-driver-ova-support.html
* Support for SPBM based storage policies: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/vmware-spbm-support.html

===== Ironic =====

* Support to pass flavor capabilities to ironic: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/pass-flavor-capabilities-to-ironic-virt-driver.html

=== Known Issues ===

* Evacuate recovery code has the potential to destroy data. On nova-compute startup, instances reported by the hypervisor are examined to see if they have moved (i.e. been evacuated) from the current host during the outage. If the determination is made that they were, then they are destroyed locally. This has the potential to choose incorrectly and destroy instances unexpectedly. On libvirt-like nodes, this can be triggered by changing the system hostname. On vmware-like nodes, this can be triggered by attempting to manage a single vcenter deployment from two different hosts (with different hostnames). This will be fixed properly in Liberty, but for now deployments that wish to disable this behavior as a preventive measure can set workarounds.destroy_after_evacuate=False. NOTE: This is not a regression and has been a flaw in the design of the evacuate feature since its introduction. There is no easy fix for this, hence this workaround to limit the potential for damage. The proposed fix in liberty is here: https://review.openstack.org/#/c/161444/.

* Forced flavor data migration misses out some instances: https://launchpad.net/bugs/1447132

* We don't have a RPC pin alias for kilo, just remove all RPC pins when wanting to use kilo level RPC versions: https://launchpad.net/bugs/1444745

* The generate config examples possibly missing some oslo related configuration

=== Upgrade Notes ===

* EC2 API support has been deprecated, and is likely to be removed in kilo, see f098398a836e3671c49bb884b4a1a1988053f4b2
* Websocket proxies need to be upgraded in a lockstep with the API nodes, as older API nodes will not be sending the access_url when authorizing console access, and newer proxy services (this commit and onward) would fail to authorize such requests 9621ccaf05900009d67cdadeb1aac27368114a61
* After fully upgrading to kilo (i.e. all nodes are running kilo code), you should start a background migration of flavor information from its old home to its new home. Kilo conductor nodes will do this on the fly when necessary, but the rest of the idle data needs to be migrated in the the background. This is critical to complete before the Liberty release, where support for the old location will be dropped. Use "nova-manage migrate-flavor-data" to perform this transition.

== OpenStack Image Service (Glance) ==
=== Key New Features ===
* TBD

=== Known Issues ===

=== Upgrade Notes ===

== OpenStack Dashboard (Horizon) ==

=== Key New Features ===
* TBD

=== Known Issues ===

=== Upgrade Notes ===

== OpenStack Identity (Keystone) ==

=== Key New Features ===

* Keystone now supports Hierarchical Multitenancy. Projects can be nested under other projects via the <code>parent_id</code> optional attribute when creating a project.
** TBD - More info.
* Fernet tokens - TBD - More Info
* WebSSO - TBD - More info
* Pluggable Assignment Model - TBD - More Info
* Assignment / Resource Split - TBD - More Info
* Extensions to Core functionality - TBD - More Info
* (Experimental) Per-Domain Identity Backend Configuration can be stored in SQL - TBD More Info
* [http://docs.openstack.org/developer/keystone/configure_federation.html#keystone-as-an-identity-provider-idp Keystone-to-Keystone Identity Federation] is now considered stable.
** IDP Registration - TBD - More Info
** ECP Wrapped Assertions Endpoint - TBD - More Info
* Keystone now supports [http://docs.openstack.org/developer/keystone/extensions/openidc.html OpenID Connect] as a federated identity authentication mechanism.
* Trusts now support redelegation. If allowed when the trust is created, a trustee can redelegate the roles from the trust via another trust.
* It is now possible to request an explicitly unscoped token from Keystone.

=== Known Issues ===

* TBD

=== Upgrade Notes ===

* XML support in Keystone has been removed as of Kilo. When upgrading from Juno to Kilo, it is recommended that references to XML and XmlBodyMiddleware be removed from the [https://github.com/openstack/keystone/blob/master/etc/keystone-paste.ini Keystone Paste configuration]. This includes removing the XML middleware filters and there references from the public_api, admin_api, api_v3, public_version_api, admin_version_api and any other pipelines that may contain the XML filters.
* [http://specs.openstack.org/openstack/openstack-specs/specs/no-downward-sql-migration.html SQL Schema Downgrades are no longer supported]. This change is the result of evaluation that downward SQL migrations are not well tested and become increasingly difficult to support with the volume of data-change that occurs in many of the migrations.

== OpenStack Network Service (Neutron) ==
=== Key New Features ===
* New Plugins supported in Kilo include the following:
** Brocade ML2 driver for MLX and ICX switches
** Brocade L3 routing plugin for MLX switch
** Brocade Vyatta vRouter L3 Plugin
** Brocade Vyatta vRouter Firewall Driver
** Brocade Vyatta vRouter VPN Driver

=== Known Issues ===
* The Firewall-as-a-Service project is still marked as experimental for the Kilo release.

=== Upgrade Notes ===

From Havana, Neutron no longer supported an explicit lease database (https://bugs.launchpad.net/bugs/1202392). This left dead code including unused environment variable. In order to remove the dead code (https://review.openstack.org/#/c/152398/), a change to the dhcp.filter is required, so that line:

'''dnsmasq: EnvFilter, dnsmasq, root, NEUTRON_NETWORK_ID='''

Be replaced by:

'''dnsmasq: CommandFilter, dnsmasq, root'''

After advanced services were split into separate packages and received their own service configuration files (specifically, etc/neutron/neutron_lbaas.conf, etc/neutron/neutron_fwaas.conf and etc/neutron/neutron_vpnaas.conf), active service provider configuration can be different after upgrade (specifically, default load balancer (haproxy) and vpn (openswan) providers can be enabled for you even though you previously disabled them in neutron.conf). Please make sure you review configuration after upgrade so that it reflects the desired state of service providers.

Note: this will have no effect if the related service plugin is not loaded in neutron.conf.

* The default value of api_workers is now equal to the number of CPUs in the host. If you currently use the default, ensure you set api_workers to a reasonable number for your installation. (https://review.openstack.org/#/c/140493/)
* The neutron.allow_duplicate_networks config option is deprecated in Kilo and will be removed in Liberty where the default behavior will be to just allow multiple ports attached to an instance on the same network in Neutron. (https://review.openstack.org/163581)
* The linuxbridge agent now enables VXLAN by default (https://review.openstack.org/160826)
* neutron-ns-metadata-proxy can now be run as non-root (https://review.openstack.org/147437)

=== Other Notes (Deprecation/EOL etc) ===

* Deprecation
** Brocade Classic plugin for Brocade's VDX/VCS series of hardware switches will be deprecated in the L-Release. The functionality provided by this plugin is now addressed by the ML2 Driver available for the VDX series of hardware. The plugin is slated for removal after this release cycle.

== OpenStack Block Storage (Cinder) ==
=== Key New Features ===
* From this point forward any new database schema upgrades will not require restarting Cinder services right away. The services are now independent of schema upgrades. This is part one to Cinder supporting rolling upgrades!
* Ability to add/remove volumes from an existing consistency group. [http://docs.openstack.org/admin-guide-cloud/content/consistency-groups.html Read docs for more info].
* Ability to create a consistency group from an existing consistency group snapshot. [http://docs.openstack.org/admin-guide-cloud/content/consistency-groups.html Read docs for more info].
* Create more fine tuned filters/weighers to set how the scheduler will choose a volume backend. [http://docs.openstack.org/admin-guide-cloud/content/driver_filter_weighing.html Read the docs for more info].
* Encrypted volumes can now be backed up using the Cinder backup service. [http://docs.openstack.org/admin-guide-cloud/content/volume-backup-restore.html Read the docs for more info].
* Ability to create private volume types. This is perfect when you want to make volume types available to only a specific tenant or to test it before making available to your cloud. To do so use the ''cinder type-create <name> --is-public''.
* Oversubscription with thin provision is configurable. [http://docs.openstack.org/admin-guide-cloud/content/over_subscription.html Read docs for more info].
* Ability to add descriptions to volume types. To do so use ''cinder type-create <name> <description>
* Cinder now can return multiple iSCSI paths information so that the connector can attach volumes even when the primary path is down ([https://review.openstack.org/#/c/134681/ when connector's multipath feature is enabled] or [https://review.openstack.org/#/c/140877/ not enabled]).

=== Known Issues ===
None yet

=== Upgrade Notes ===
* The 'host' config option for multiple-storage backends in cinder.conf is renamed to 'backend_host' in order to avoid a naming conflict with the 'host' to locate redis. If you use this option, please ensure your configuration files are updated.

== OpenStack Telemetry (Ceilometer) ==
=== Key New Features ===
* Support to add jitter to polling cycles to ensure pollsters are not querying service's api at the same time
* Ceilometer API RBAC support
* Improved Event support:
** Multi-pipeline support to enable unique processing and publishing of events
** Enabled ability to capture raw notification messages for auditing and postmortem analysis
** Support for persisting events into ElasticSearch
** Publishing support to database, http, file, kafa and oslo.messaging supported message queues
** Option to split off the events persistence into a separate database
** Telemetry now supports to collect and store all the event type meters as events. A new option, ''disable_non_metric_meters'', was added to the configuration in order to provide the possibility to turn off storing these events as samples. For further information please see the [http://docs.openstack.org/trunk/config-reference/content/ch_configuring-openstack-telemetry.html Telemetry Configuration Reference]
** The Administrator Guide in OpenStack Manuals was updated with a new [http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-events.html Events section], where you can find further information about this functionality.
* Improved pipeline publishing support:
** Support to publish events and samples to Kafka or HTTP targets
** Publish data to multiple queues
* Additional meters
** memory and disk meters for Hyper-V
** disk meters for LibVirt
** power and thermal related IPMI meters, more meters from NodeManager
** ability to meter Ceph
* IPv6 support enabled in Ceilometer udp publisher and collector
* [http://launchpad.net/gnocchi Gnocchi] dispatch support for ceilometer-collector
* Self-disabled pollster mechanism

=== Known Issues ===
* TBD

=== Upgrade Notes ===
* Deprecated meters:
** The instance:<flavor> meter is deprecated in the Kilo release. In order to retrieve samples or statistics based on flavor you can use the following queries:
statistics:
ceilometer statistics -m instance -g resource_metadata.instance_type

samples:
ceilometer sample-list -m instance -q metadata.instance_type=<value>
* Middleware used to meter Swift was previously packaged in Ceilometer and is now deprecated. It is now separated into it's own library: ceilometermiddleware.
** Juno configuration: http://docs.openstack.org/juno/install-guide/install/apt/content/ceilometer-swift.html
** Kilo configuration: http://docs.openstack.org/kilo/install-guide/install/apt/content/ceilometer-swift.html

== OpenStack Orchestration (Heat) ==

WIP (will move here) https://etherpad.openstack.org/p/heat-kilo-releasenotes

=== Key New Features ===

=== Known Issues ===
None yet

=== Upgrade Notes ===
None yet

== OpenStack Database service (Trove) ==
=== Key New Features ===

=== Known Issues ===
None yet

=== Upgrade Notes ===
None yet

== OpenStack Data Processing service (Sahara) ==
=== Key New Features ===
TBD

=== Known Issues ===
TBD

=== Upgrade Notes ===
TBD

== OpenStack Documentation ==

=== Key New Features ===

* TBD

=== Known Issues ===

=== Upgrade Notes ===
None yet

ReleaseNotes/Kilo

2015-04-28T12:15:21Z

Matthew Gilliard: /* API v2.1 */

{| style="color:#000000; border:solid 1px #A8A8A8; padding:0.5em; margin:0.5em 0; background-color:#FFFFFF;font-size:95%; vertical-align:middle;"
| style="padding:1em;width: 40px" | [[Image:Warning.svg|40px]]
| '''Release Under Development'''
This release of OpenStack is under development and has yet to be completed. It will be released on April 30, 2015

The information on this page may not accurately reflect the state of release at the current point in time.
|}

= OpenStack 2015.1 (Kilo) Release Notes =

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

== General Upgrade Notes ==

* TBD

== OpenStack Object Storage (Swift) ==

=== Key New Features ===

=== Known Issues ===
None

=== Upgrade Notes ===

== OpenStack Compute (Nova) ==

=== Key New Features ===

==== API v2.1 ====

* We have the first release of the next generation of the Nova API, v2.1. The v2.1 is designed to be backwards compatible with v2.0 with the addition of strong API validation. All changes to the API are discoverable via the advertised microversion. For more details see: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html

* For kilo, by default we are still using v2.0 API code to server v2.0 API requests. It is hoped that in liberty that v2.1 will be used to serve requests for both v2.0 and v2.1.

* For liberty v2.0 is now frozen, and all new features will now be added into the v2.1 API. Extending the keypair API to support for x509 certificates, to be used with Windows WinRM, is one of the first API features added as a microversion in the v2.1 API.

* python-novaclient does not yet have support for the v2.1 API

==== Upgrade Support ====

* We have reduced the data migrations that happen in the DB migration scripts, this now happens in a "lazy" way inside the DB objects code. There is a nova-manage command to help force migration of the data, but there are bugs that limit its usefulness in the current release. For more details see: http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/flavor-from-sysmeta-to-blob.html

* Change https://review.openstack.org/#/c/97946/ adds database migration 267 which scans for null instances.uuid records and will fail if any are found since the migrate ultimately needs to make instances.uuid non-nullable and adds a UniqueConstraint on that column. A helper script is provided to search for null instances.uuid records before running the database migrations. Before running 'nova-manage db sync', run the helper script 'nova-manage db null_instance_uuid_scan' which, by default, will just search and dump results, it does not change anything. Pass the --delete option to the null_instance_uuid_scan command to automatically remove any null records were instances.uuid is null.

==== Scheduler ====

* A selection of performance optimisations
* We are in the process of making structural changes to the scheduler that will help improve our ability to evolve and improve scheduling. This should not be visible from an end user perspective.

==== Cells v2 ====

* There are some initial parts of cell v2 supported added, but this feature is not yet ready to use.
* new 'nova-manage api_db sync' and 'nova-manage api_db version' commands for working with the new api database for cells, but nothing is using this database yet so it is not necessary to set it up.

==== Compute Drivers ====

===== Hyper-V =====

* Support for generation 2 VMs: https://blueprints.launchpad.net/nova/+spec/hyper-v-generation-2-vms
* Support for SMB based volumes, to sit along side existing iSCSI volume support: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/hyper-v-smbfs-volume-support.html
* Support for x509 certificate based key pairs: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/keypair-x509-certificates.html
* Host power actions now work with Hyper-V: https://blueprints.launchpad.net/nova/+spec/hyper-v-host-power-actions

===== Libvirt (KVM) =====

* NFV related features:
** NUMA based scheduling: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/input-output-based-numa-scheduling.html
** Pinning guest vCPUs: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/virt-driver-cpu-pinning.html
** Large page support: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/virt-driver-large-pages.html
* vhostuser VIF driver: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/libvirt_vif_vhostuser.html
* Support for running KVM on IBM System z: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/libvirt-kvm-systemz.html
* Support for parallels: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/pcs-support.html
* Support for SMB based volumes: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/libvirt-smbfs-volume-support.html
* Quiesce using QEMU guest agent: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/quiesced-image-snapshots-with-qemu-guest-agent.html
* Quobyte volume support: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/quobyte-nova-driver.html
* Support for QEMU iSCSI initiator: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/qemu-built-in-iscsi-initiator.html

===== VMware =====

* Support for Ephemeral disks: http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/vmware-ephemeral-disk-support.html
* Support fo vSAN: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/vmware-vsan-support.html
* Support for based OVA images: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/vmware-driver-ova-support.html
* Support for SPBM based storage policies: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/vmware-spbm-support.html

===== Ironic =====

* Support to pass flavor capabilities to ironic: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/pass-flavor-capabilities-to-ironic-virt-driver.html

=== Known Issues ===

* Evacuate recovery code has the potential to destroy data. On nova-compute startup, instances reported by the hypervisor are examined to see if they have moved (i.e. been evacuated) from the current host during the outage. If the determination is made that they were, then they are destroyed locally. This has the potential to choose incorrectly and destroy instances unexpectedly. On libvirt-like nodes, this can be triggered by changing the system hostname. On vmware-like nodes, this can be triggered by attempting to manage a single vcenter deployment from two different hosts (with different hostnames). This will be fixed properly in Liberty, but for now deployments that wish to disable this behavior as a preventive measure can set workarounds.destroy_after_evacuate=False. NOTE: This is not a regression and has been a flaw in the design of the evacuate feature since its introduction. There is no easy fix for this, hence this workaround to limit the potential for damage. The proposed fix in liberty is here: https://review.openstack.org/#/c/161444/.

* Forced flavor data migration misses out some instances: https://launchpad.net/bugs/1447132

* We don't have a RPC pin alias for kilo, just remove all RPC pins when wanting to use kilo level RPC versions: https://launchpad.net/bugs/1444745

* The generate config examples possibly missing some oslo related configuration

=== Upgrade Notes ===

* EC2 API support has been deprecated, and is likely to be removed in kilo, see f098398a836e3671c49bb884b4a1a1988053f4b2
* Websocket proxies need to be upgraded in a lockstep with the API nodes, as older API nodes will not be sending the access_url when authorizing console access, and newer proxy services (this commit and onward) would fail to authorize such requests 9621ccaf05900009d67cdadeb1aac27368114a61
* After fully upgrading to kilo (i.e. all nodes are running kilo code), you should start a background migration of flavor information from its old home to its new home. Kilo conductor nodes will do this on the fly when necessary, but the rest of the idle data needs to be migrated in the the background. This is critical to complete before the Liberty release, where support for the old location will be dropped. Use "nova-manage migrate-flavor-data" to perform this transition.

== OpenStack Image Service (Glance) ==
=== Key New Features ===
* TBD

=== Known Issues ===

=== Upgrade Notes ===

== OpenStack Dashboard (Horizon) ==

=== Key New Features ===
* TBD

=== Known Issues ===

=== Upgrade Notes ===

== OpenStack Identity (Keystone) ==

=== Key New Features ===

* Keystone now supports Hierarchical Multitenancy. Projects can be nested under other projects via the <code>parent_id</code> optional attribute when creating a project.
** TBD - More info.
* Fernet tokens - TBD - More Info
* WebSSO - TBD - More info
* Pluggable Assignment Model - TBD - More Info
* Assignment / Resource Split - TBD - More Info
* Extensions to Core functionality - TBD - More Info
* (Experimental) Per-Domain Identity Backend Configuration can be stored in SQL - TBD More Info
* [http://docs.openstack.org/developer/keystone/configure_federation.html#keystone-as-an-identity-provider-idp Keystone-to-Keystone Identity Federation] is now considered stable.
** IDP Registration - TBD - More Info
** ECP Wrapped Assertions Endpoint - TBD - More Info
* Keystone now supports [http://docs.openstack.org/developer/keystone/extensions/openidc.html OpenID Connect] as a federated identity authentication mechanism.
* Trusts now support redelegation. If allowed when the trust is created, a trustee can redelegate the roles from the trust via another trust.
* It is now possible to request an explicitly unscoped token from Keystone.

=== Known Issues ===

* TBD

=== Upgrade Notes ===

* XML support in Keystone has been removed as of Kilo. When upgrading from Juno to Kilo, it is recommended that references to XML and XmlBodyMiddleware be removed from the [https://github.com/openstack/keystone/blob/master/etc/keystone-paste.ini Keystone Paste configuration]. This includes removing the XML middleware filters and there references from the public_api, admin_api, api_v3, public_version_api, admin_version_api and any other pipelines that may contain the XML filters.
* [http://specs.openstack.org/openstack/openstack-specs/specs/no-downward-sql-migration.html SQL Schema Downgrades are no longer supported]. This change is the result of evaluation that downward SQL migrations are not well tested and become increasingly difficult to support with the volume of data-change that occurs in many of the migrations.

== OpenStack Network Service (Neutron) ==
=== Key New Features ===
* New Plugins supported in Kilo include the following:
** Brocade ML2 driver for MLX and ICX switches
** Brocade L3 routing plugin for MLX switch
** Brocade Vyatta vRouter L3 Plugin
** Brocade Vyatta vRouter Firewall Driver
** Brocade Vyatta vRouter VPN Driver

=== Known Issues ===
* The Firewall-as-a-Service project is still marked as experimental for the Kilo release.

=== Upgrade Notes ===

From Havana, Neutron no longer supported an explicit lease database (https://bugs.launchpad.net/bugs/1202392). This left dead code including unused environment variable. In order to remove the dead code (https://review.openstack.org/#/c/152398/), a change to the dhcp.filter is required, so that line:

'''dnsmasq: EnvFilter, dnsmasq, root, NEUTRON_NETWORK_ID='''

Be replaced by:

'''dnsmasq: CommandFilter, dnsmasq, root'''

After advanced services were split into separate packages and received their own service configuration files (specifically, etc/neutron/neutron_lbaas.conf, etc/neutron/neutron_fwaas.conf and etc/neutron/neutron_vpnaas.conf), active service provider configuration can be different after upgrade (specifically, default load balancer (haproxy) and vpn (openswan) providers can be enabled for you even though you previously disabled them in neutron.conf). Please make sure you review configuration after upgrade so that it reflects the desired state of service providers.

Note: this will have no effect if the related service plugin is not loaded in neutron.conf.

* The default value of api_workers is now equal to the number of CPUs in the host. If you currently use the default, ensure you set api_workers to a reasonable number for your installation. (https://review.openstack.org/#/c/140493/)
* The neutron.allow_duplicate_networks config option is deprecated in Kilo and will be removed in Liberty where the default behavior will be to just allow multiple ports attached to an instance on the same network in Neutron. (https://review.openstack.org/163581)
* The linuxbridge agent now enables VXLAN by default (https://review.openstack.org/160826)
* neutron-ns-metadata-proxy can now be run as non-root (https://review.openstack.org/147437)

=== Other Notes (Deprecation/EOL etc) ===

* Deprecation
** Brocade Classic plugin for Brocade's VDX/VCS series of hardware switches will be deprecated in the L-Release. The functionality provided by this plugin is now addressed by the ML2 Driver available for the VDX series of hardware. The plugin is slated for removal after this release cycle.

== OpenStack Block Storage (Cinder) ==
=== Key New Features ===
* From this point forward any new database schema upgrades will not require restarting Cinder services right away. The services are now independent of schema upgrades. This is part one to Cinder supporting rolling upgrades!
* Ability to add/remove volumes from an existing consistency group. [http://docs.openstack.org/admin-guide-cloud/content/consistency-groups.html Read docs for more info].
* Ability to create a consistency group from an existing consistency group snapshot. [http://docs.openstack.org/admin-guide-cloud/content/consistency-groups.html Read docs for more info].
* Create more fine tuned filters/weighers to set how the scheduler will choose a volume backend. [http://docs.openstack.org/admin-guide-cloud/content/driver_filter_weighing.html Read the docs for more info].
* Encrypted volumes can now be backed up using the Cinder backup service. [http://docs.openstack.org/admin-guide-cloud/content/volume-backup-restore.html Read the docs for more info].
* Ability to create private volume types. This is perfect when you want to make volume types available to only a specific tenant or to test it before making available to your cloud. To do so use the ''cinder type-create <name> --is-public''.
* Oversubscription with thin provision is configurable. [http://docs.openstack.org/admin-guide-cloud/content/over_subscription.html Read docs for more info].
* Ability to add descriptions to volume types. To do so use ''cinder type-create <name> <description>
* Cinder now can return multiple iSCSI paths information so that the connector can attach volumes even when the primary path is down ([https://review.openstack.org/#/c/134681/ when connector's multipath feature is enabled] or [https://review.openstack.org/#/c/140877/ not enabled]).

=== Known Issues ===
None yet

=== Upgrade Notes ===
* The 'host' config option for multiple-storage backends in cinder.conf is renamed to 'backend_host' in order to avoid a naming conflict with the 'host' to locate redis. If you use this option, please ensure your configuration files are updated.

== OpenStack Telemetry (Ceilometer) ==
=== Key New Features ===
* Support to add jitter to polling cycles to ensure pollsters are not querying service's api at the same time
* Ceilometer API RBAC support
* Improved Event support:
** Multi-pipeline support to enable unique processing and publishing of events
** Enabled ability to capture raw notification messages for auditing and postmortem analysis
** Support for persisting events into ElasticSearch
** Publishing support to database, http, file, kafa and oslo.messaging supported message queues
** Option to split off the events persistence into a separate database
** Telemetry now supports to collect and store all the event type meters as events. A new option, ''disable_non_metric_meters'', was added to the configuration in order to provide the possibility to turn off storing these events as samples. For further information please see the [http://docs.openstack.org/trunk/config-reference/content/ch_configuring-openstack-telemetry.html Telemetry Configuration Reference]
** The Administrator Guide in OpenStack Manuals was updated with a new [http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-events.html Events section], where you can find further information about this functionality.
* Improved pipeline publishing support:
** Support to publish events and samples to Kafka or HTTP targets
** Publish data to multiple queues
* Additional meters
** memory and disk meters for Hyper-V
** disk meters for LibVirt
** power and thermal related IPMI meters, more meters from NodeManager
** ability to meter Ceph
* IPv6 support enabled in Ceilometer udp publisher and collector
* [http://launchpad.net/gnocchi Gnocchi] dispatch support for ceilometer-collector
* Self-disabled pollster mechanism

=== Known Issues ===
* TBD

=== Upgrade Notes ===
* Deprecated meters:
** The instance:<flavor> meter is deprecated in the Kilo release. In order to retrieve samples or statistics based on flavor you can use the following queries:
statistics:
ceilometer statistics -m instance -g resource_metadata.instance_type

samples:
ceilometer sample-list -m instance -q metadata.instance_type=<value>
* Middleware used to meter Swift was previously packaged in Ceilometer and is now deprecated. It is now separated into it's own library: ceilometermiddleware.
** Juno configuration: http://docs.openstack.org/juno/install-guide/install/apt/content/ceilometer-swift.html
** Kilo configuration: http://docs.openstack.org/kilo/install-guide/install/apt/content/ceilometer-swift.html

== OpenStack Orchestration (Heat) ==

WIP (will move here) https://etherpad.openstack.org/p/heat-kilo-releasenotes

=== Key New Features ===

=== Known Issues ===
None yet

=== Upgrade Notes ===
None yet

== OpenStack Database service (Trove) ==
=== Key New Features ===

=== Known Issues ===
None yet

=== Upgrade Notes ===
None yet

== OpenStack Data Processing service (Sahara) ==
=== Key New Features ===
TBD

=== Known Issues ===
TBD

=== Upgrade Notes ===
TBD

== OpenStack Documentation ==

=== Key New Features ===

* TBD

=== Known Issues ===

=== Upgrade Notes ===
None yet

ReleaseNotes/Kilo

2015-04-28T12:09:18Z

Matthew Gilliard: /* OpenStack Object Storage (Nova) */

{| style="color:#000000; border:solid 1px #A8A8A8; padding:0.5em; margin:0.5em 0; background-color:#FFFFFF;font-size:95%; vertical-align:middle;"
| style="padding:1em;width: 40px" | [[Image:Warning.svg|40px]]
| '''Release Under Development'''
This release of OpenStack is under development and has yet to be completed. It will be released on April 30, 2015

The information on this page may not accurately reflect the state of release at the current point in time.
|}

= OpenStack 2015.1 (Kilo) Release Notes =

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

== General Upgrade Notes ==

* TBD

== OpenStack Object Storage (Swift) ==

=== Key New Features ===

=== Known Issues ===
None

=== Upgrade Notes ===

== OpenStack Compute (Nova) ==

=== Key New Features ===

==== API v2.1 ====

* We have the first release of the next generation of the Nova API, v2.1. The v2.1 is designed to be backwards compatible with v2.0 with the addition of strong API validation. All changes to the API are discoverable via the advertised microversion. For more details see: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html

* For kilo, by default we are still using v2.0 API code to server v2.0 API requests. It is hoped that in liberty that v2.1 will be used to server requests for both v2.0 and v2.1.

* For liberty v2.0 is now frozen, and all new features will now be added into the v2.1 API. Extending to the keypair API to support for x509 certificates, to be used with Windows WinRM, is one of the first API features added as a microversion in the v2.1 API.

* python-novaclient does not yet have support for the v2.1 API

==== Upgrade Support ====

* We have reduced the data migrations that happen in the DB migration scripts, this now happens in a "lazy" way inside the DB objects code. There is a nova-manage command to help force migration of the data, but there are bugs that limit its usefulness in the current release. For more details see: http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/flavor-from-sysmeta-to-blob.html

* Change https://review.openstack.org/#/c/97946/ adds database migration 267 which scans for null instances.uuid records and will fail if any are found since the migrate ultimately needs to make instances.uuid non-nullable and adds a UniqueConstraint on that column. A helper script is provided to search for null instances.uuid records before running the database migrations. Before running 'nova-manage db sync', run the helper script 'nova-manage db null_instance_uuid_scan' which, by default, will just search and dump results, it does not change anything. Pass the --delete option to the null_instance_uuid_scan command to automatically remove any null records were instances.uuid is null.

==== Scheduler ====

* A selection of performance optimisations
* We are in the process of making structural changes to the scheduler that will help improve our ability to evolve and improve scheduling. This should not be visible from an end user perspective.

==== Cells v2 ====

* There are some initial parts of cell v2 supported added, but this feature is not yet ready to use.
* new 'nova-manage api_db sync' and 'nova-manage api_db version' commands for working with the new api database for cells, but nothing is using this database yet so it is not necessary to set it up.

==== Compute Drivers ====

===== Hyper-V =====

* Support for generation 2 VMs: https://blueprints.launchpad.net/nova/+spec/hyper-v-generation-2-vms
* Support for SMB based volumes, to sit along side existing iSCSI volume support: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/hyper-v-smbfs-volume-support.html
* Support for x509 certificate based key pairs: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/keypair-x509-certificates.html
* Host power actions now work with Hyper-V: https://blueprints.launchpad.net/nova/+spec/hyper-v-host-power-actions

===== Libvirt (KVM) =====

* NFV related features:
** NUMA based scheduling: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/input-output-based-numa-scheduling.html
** Pinning guest vCPUs: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/virt-driver-cpu-pinning.html
** Large page support: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/virt-driver-large-pages.html
* vhostuser VIF driver: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/libvirt_vif_vhostuser.html
* Support for running KVM on IBM System z: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/libvirt-kvm-systemz.html
* Support for parallels: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/pcs-support.html
* Support for SMB based volumes: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/libvirt-smbfs-volume-support.html
* Quiesce using QEMU guest agent: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/quiesced-image-snapshots-with-qemu-guest-agent.html
* Quobyte volume support: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/quobyte-nova-driver.html
* Support for QEMU iSCSI initiator: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/qemu-built-in-iscsi-initiator.html

===== VMware =====

* Support for Ephemeral disks: http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/vmware-ephemeral-disk-support.html
* Support fo vSAN: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/vmware-vsan-support.html
* Support for based OVA images: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/vmware-driver-ova-support.html
* Support for SPBM based storage policies: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/vmware-spbm-support.html

===== Ironic =====

* Support to pass flavor capabilities to ironic: http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/pass-flavor-capabilities-to-ironic-virt-driver.html

=== Known Issues ===

* Evacuate recovery code has the potential to destroy data. On nova-compute startup, instances reported by the hypervisor are examined to see if they have moved (i.e. been evacuated) from the current host during the outage. If the determination is made that they were, then they are destroyed locally. This has the potential to choose incorrectly and destroy instances unexpectedly. On libvirt-like nodes, this can be triggered by changing the system hostname. On vmware-like nodes, this can be triggered by attempting to manage a single vcenter deployment from two different hosts (with different hostnames). This will be fixed properly in Liberty, but for now deployments that wish to disable this behavior as a preventive measure can set workarounds.destroy_after_evacuate=False. NOTE: This is not a regression and has been a flaw in the design of the evacuate feature since its introduction. There is no easy fix for this, hence this workaround to limit the potential for damage. The proposed fix in liberty is here: https://review.openstack.org/#/c/161444/.

* Forced flavor data migration misses out some instances: https://launchpad.net/bugs/1447132

* We don't have a RPC pin alias for kilo, just remove all RPC pins when wanting to use kilo level RPC versions: https://launchpad.net/bugs/1444745

* The generate config examples possibly missing some oslo related configuration

=== Upgrade Notes ===

* After fully upgrading to kilo (i.e. all nodes are running kilo code), you should start a background migration of flavor information from its old home to its new home. Kilo conductor nodes will do this on the fly when necessary, but the rest of the idle data needs to be migrated in the the background. This is critical to complete before the Liberty release, where support for the old location will be dropped. Use "nova-manage migrate-flavor-data" to perform this transition.

== OpenStack Image Service (Glance) ==
=== Key New Features ===
* TBD

=== Known Issues ===

=== Upgrade Notes ===

== OpenStack Dashboard (Horizon) ==

=== Key New Features ===
* TBD

=== Known Issues ===

=== Upgrade Notes ===

== OpenStack Identity (Keystone) ==

=== Key New Features ===

* Keystone now supports Hierarchical Multitenancy. Projects can be nested under other projects via the <code>parent_id</code> optional attribute when creating a project.
** TBD - More info.
* Fernet tokens - TBD - More Info
* WebSSO - TBD - More info
* Pluggable Assignment Model - TBD - More Info
* Assignment / Resource Split - TBD - More Info
* Extensions to Core functionality - TBD - More Info
* (Experimental) Per-Domain Identity Backend Configuration can be stored in SQL - TBD More Info
* [http://docs.openstack.org/developer/keystone/configure_federation.html#keystone-as-an-identity-provider-idp Keystone-to-Keystone Identity Federation] is now considered stable.
** IDP Registration - TBD - More Info
** ECP Wrapped Assertions Endpoint - TBD - More Info
* Keystone now supports [http://docs.openstack.org/developer/keystone/extensions/openidc.html OpenID Connect] as a federated identity authentication mechanism.
* Trusts now support redelegation. If allowed when the trust is created, a trustee can redelegate the roles from the trust via another trust.
* It is now possible to request an explicitly unscoped token from Keystone.

=== Known Issues ===

* TBD

=== Upgrade Notes ===

* XML support in Keystone has been removed as of Kilo. When upgrading from Juno to Kilo, it is recommended that references to XML and XmlBodyMiddleware be removed from the [https://github.com/openstack/keystone/blob/master/etc/keystone-paste.ini Keystone Paste configuration]. This includes removing the XML middleware filters and there references from the public_api, admin_api, api_v3, public_version_api, admin_version_api and any other pipelines that may contain the XML filters.
* [http://specs.openstack.org/openstack/openstack-specs/specs/no-downward-sql-migration.html SQL Schema Downgrades are no longer supported]. This change is the result of evaluation that downward SQL migrations are not well tested and become increasingly difficult to support with the volume of data-change that occurs in many of the migrations.

== OpenStack Network Service (Neutron) ==
=== Key New Features ===
* New Plugins supported in Kilo include the following:
** Brocade ML2 driver for MLX and ICX switches
** Brocade L3 routing plugin for MLX switch
** Brocade Vyatta vRouter L3 Plugin
** Brocade Vyatta vRouter Firewall Driver
** Brocade Vyatta vRouter VPN Driver

=== Known Issues ===
* The Firewall-as-a-Service project is still marked as experimental for the Kilo release.

=== Upgrade Notes ===

From Havana, Neutron no longer supported an explicit lease database (https://bugs.launchpad.net/bugs/1202392). This left dead code including unused environment variable. In order to remove the dead code (https://review.openstack.org/#/c/152398/), a change to the dhcp.filter is required, so that line:

'''dnsmasq: EnvFilter, dnsmasq, root, NEUTRON_NETWORK_ID='''

Be replaced by:

'''dnsmasq: CommandFilter, dnsmasq, root'''

After advanced services were split into separate packages and received their own service configuration files (specifically, etc/neutron/neutron_lbaas.conf, etc/neutron/neutron_fwaas.conf and etc/neutron/neutron_vpnaas.conf), active service provider configuration can be different after upgrade (specifically, default load balancer (haproxy) and vpn (openswan) providers can be enabled for you even though you previously disabled them in neutron.conf). Please make sure you review configuration after upgrade so that it reflects the desired state of service providers.

Note: this will have no effect if the related service plugin is not loaded in neutron.conf.

* The default value of api_workers is now equal to the number of CPUs in the host. If you currently use the default, ensure you set api_workers to a reasonable number for your installation. (https://review.openstack.org/#/c/140493/)
* The neutron.allow_duplicate_networks config option is deprecated in Kilo and will be removed in Liberty where the default behavior will be to just allow multiple ports attached to an instance on the same network in Neutron. (https://review.openstack.org/163581)
* The linuxbridge agent now enables VXLAN by default (https://review.openstack.org/160826)
* neutron-ns-metadata-proxy can now be run as non-root (https://review.openstack.org/147437)

=== Other Notes (Deprecation/EOL etc) ===

* Deprecation
** Brocade Classic plugin for Brocade's VDX/VCS series of hardware switches will be deprecated in the L-Release. The functionality provided by this plugin is now addressed by the ML2 Driver available for the VDX series of hardware. The plugin is slated for removal after this release cycle.

== OpenStack Block Storage (Cinder) ==
=== Key New Features ===
* From this point forward any new database schema upgrades will not require restarting Cinder services right away. The services are now independent of schema upgrades. This is part one to Cinder supporting rolling upgrades!
* Ability to add/remove volumes from an existing consistency group. [http://docs.openstack.org/admin-guide-cloud/content/consistency-groups.html Read docs for more info].
* Ability to create a consistency group from an existing consistency group snapshot. [http://docs.openstack.org/admin-guide-cloud/content/consistency-groups.html Read docs for more info].
* Create more fine tuned filters/weighers to set how the scheduler will choose a volume backend. [http://docs.openstack.org/admin-guide-cloud/content/driver_filter_weighing.html Read the docs for more info].
* Encrypted volumes can now be backed up using the Cinder backup service. [http://docs.openstack.org/admin-guide-cloud/content/volume-backup-restore.html Read the docs for more info].
* Ability to create private volume types. This is perfect when you want to make volume types available to only a specific tenant or to test it before making available to your cloud. To do so use the ''cinder type-create <name> --is-public''.
* Oversubscription with thin provision is configurable. [http://docs.openstack.org/admin-guide-cloud/content/over_subscription.html Read docs for more info].
* Ability to add descriptions to volume types. To do so use ''cinder type-create <name> <description>
* Cinder now can return multiple iSCSI paths information so that the connector can attach volumes even when the primary path is down ([https://review.openstack.org/#/c/134681/ when connector's multipath feature is enabled] or [https://review.openstack.org/#/c/140877/ not enabled]).

=== Known Issues ===
None yet

=== Upgrade Notes ===
* The 'host' config option for multiple-storage backends in cinder.conf is renamed to 'backend_host' in order to avoid a naming conflict with the 'host' to locate redis. If you use this option, please ensure your configuration files are updated.

== OpenStack Telemetry (Ceilometer) ==
=== Key New Features ===
* Support to add jitter to polling cycles to ensure pollsters are not querying service's api at the same time
* Ceilometer API RBAC support
* Improved Event support:
** Multi-pipeline support to enable unique processing and publishing of events
** Enabled ability to capture raw notification messages for auditing and postmortem analysis
** Support for persisting events into ElasticSearch
** Publishing support to database, http, file, kafa and oslo.messaging supported message queues
** Option to split off the events persistence into a separate database
** Telemetry now supports to collect and store all the event type meters as events. A new option, ''disable_non_metric_meters'', was added to the configuration in order to provide the possibility to turn off storing these events as samples. For further information please see the [http://docs.openstack.org/trunk/config-reference/content/ch_configuring-openstack-telemetry.html Telemetry Configuration Reference]
** The Administrator Guide in OpenStack Manuals was updated with a new [http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-events.html Events section], where you can find further information about this functionality.
* Improved pipeline publishing support:
** Support to publish events and samples to Kafka or HTTP targets
** Publish data to multiple queues
* Additional meters
** memory and disk meters for Hyper-V
** disk meters for LibVirt
** power and thermal related IPMI meters, more meters from NodeManager
** ability to meter Ceph
* IPv6 support enabled in Ceilometer udp publisher and collector
* [http://launchpad.net/gnocchi Gnocchi] dispatch support for ceilometer-collector
* Self-disabled pollster mechanism

=== Known Issues ===
* TBD

=== Upgrade Notes ===
* Deprecated meters:
** The instance:<flavor> meter is deprecated in the Kilo release. In order to retrieve samples or statistics based on flavor you can use the following queries:
statistics:
ceilometer statistics -m instance -g resource_metadata.instance_type

samples:
ceilometer sample-list -m instance -q metadata.instance_type=<value>
* Middleware used to meter Swift was previously packaged in Ceilometer and is now deprecated. It is now separated into it's own library: ceilometermiddleware.
** Juno configuration: http://docs.openstack.org/juno/install-guide/install/apt/content/ceilometer-swift.html
** Kilo configuration: http://docs.openstack.org/kilo/install-guide/install/apt/content/ceilometer-swift.html

== OpenStack Orchestration (Heat) ==

WIP (will move here) https://etherpad.openstack.org/p/heat-kilo-releasenotes

=== Key New Features ===

=== Known Issues ===
None yet

=== Upgrade Notes ===
None yet

== OpenStack Database service (Trove) ==
=== Key New Features ===

=== Known Issues ===
None yet

=== Upgrade Notes ===
None yet

== OpenStack Data Processing service (Sahara) ==
=== Key New Features ===
TBD

=== Known Issues ===
TBD

=== Upgrade Notes ===
TBD

== OpenStack Documentation ==

=== Key New Features ===

* TBD

=== Known Issues ===

=== Upgrade Notes ===
None yet

Meetings/NovaAPI

2015-04-28T11:39:34Z

Matthew Gilliard: /* Next Meeting */

= Weekly OpenStack Nova API Meeting =

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

* People to keep up with what work is going on with the Nova API and where it is headed
* Cloud providers, SDK maintainers and direct users of the REST API to provide feedback about the API and what they want out of it
* Help coordinate ongoing development work on the API

== Meetings ==

* Meeting Time: Weekly, Fridays at 00:00 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by: Kenichi Oomichi (oomichi)

=== Next Meeting ===
Friday 2015/05/01 at 0000 UTC

==== Agenda ====

Please feel free to add items to the Agenda

* Vancouver summit
** https://etherpad.openstack.org/p/liberty-nova-api

* Urgent reviews
These are not urgent but would be very helpful.
** https://review.openstack.org/#/c/177778/
** https://review.openstack.org/#/c/162913/
** https://review.openstack.org/#/c/162912/

* Nova API meeting time
** Is the current 0000UTC/Friday time working for everyone? It is unfriendly to Europeans but perhaps there is no universally-suitable alternative?
** gilliard: I would be able to make 0700-2100UTC any week day
** alex_xu: My prefer time and overlap with you is 0700 - 1000UTC or 1300 - 1400UTC.
** Suggestion (from gilliard): 0800UTC/Fridays => 1600ish Asia, but not good for America.

* API-WG representative

* Open Discussion

=== Previous Meetings (most recent first) ===
* 2014/09/12
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-09-12-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-09-12-00.00.log.html Log]
* 2014/06/20
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-20-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-20-00.01.log.html Log]
* 2014/06/06
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-06-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-06-06-00.01.log.html Log]
* 2014/05/30
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-30-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-30-00.00.log.html Log]
* 2014/05/09
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-09-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-05-09-00.00.log.html Log]
* 2014/04/25
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-25-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-25-00.00.log.html Log]
* 2014/04/18
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-18-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-18-00.00.log.html Log]
* 2014/04/11
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-11-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-11-00.01.log.html Log]
* 2014/04/04
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-04-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-04-04-00.01.log.html Log]
* 2014/03/28
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-28-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-28-00.00.log.html Log]
* 2014/03/21
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-21-00.00.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-21-00.00.log.html Log]
* 2014/03/14
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-14-00.01.html Summary]
** [http://eavesdrop.openstack.org/meetings/nova_api/2014/nova_api.2014-03-14-00.01.log.html Log] (note log looks like it's missing parts probably due to netsplit)

Meetings/API-SIG

2015-02-24T10:58:12Z

Matthew Gilliard: /* Next Meeting */

= Weekly API Working Group Meeting =

This is a weekly meeting to discuss the OpenStack API. It's intended as a forum for:

* Standardizing the OpenStack project APIs and creating guidelines and rules for projects to follow when designing their REST APIs
* Feedback from users as to the usability of OpenStack REST APIs
* Discussion of future directions of OpenStack APIs

== Meetings ==

* Meeting Time: Weekly, Thursday at 16:00UTC/00:00 UTC (alternating)
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* MeetBot Manual http://meetbot.debian.net/Manual.html
* Chaired by: Jay Pipes | Christopher Yeoh | Everett Toews | Any API WG Member

=== Next Meeting ===
Thursday 2015-02-26 at 16:00 UTC

==== Agenda ====

* #startmeeting api wg
* #topic agenda
** #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
* new topics
** #topic versioning
* #topic previous meeting action items
** #link http://eavesdrop.openstack.org/meetings/api_wg/2015/api_wg.2015-02-12-16.00.log.html
** #link http://eavesdrop.openstack.org/meetings/api_wg/2015/api_wg.2015-02-19-00.00.html
* #topic guidelines
** #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
* #topic APIImpact
** #link https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
* #topic open topics
** (gilliard) Any objections to merging https://review.openstack.org/#/c/158179/ as it would allow https://review.openstack.org/#/c/140313/30 to merge unchanged?
* #endmeeting

=== Previous Meetings ===

* [http://eavesdrop.openstack.org/meetings/api_wg/2014/ 2014]
* [http://eavesdrop.openstack.org/meetings/api_wg/2015/ 2015]

Meetings/API-SIG

2015-02-24T10:56:30Z

Matthew Gilliard: /* Agenda */

= Weekly API Working Group Meeting =

This is a weekly meeting to discuss the OpenStack API. It's intended as a forum for:

* Standardizing the OpenStack project APIs and creating guidelines and rules for projects to follow when designing their REST APIs
* Feedback from users as to the usability of OpenStack REST APIs
* Discussion of future directions of OpenStack APIs

== Meetings ==

* Meeting Time: Weekly, Thursday at 16:00UTC/00:00 UTC (alternating)
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* MeetBot Manual http://meetbot.debian.net/Manual.html
* Chaired by: Jay Pipes | Christopher Yeoh | Everett Toews | Any API WG Member

=== Next Meeting ===
Thursday 2015-02-26 at 16:00 UTC

==== Agenda ====

* #startmeeting api wg
* #topic agenda
** #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
* new topics
** #topic versioning
* #topic previous meeting action items
** #link http://eavesdrop.openstack.org/meetings/api_wg/2015/api_wg.2015-02-12-16.00.log.html
** #link http://eavesdrop.openstack.org/meetings/api_wg/2015/api_wg.2015-02-19-00.00.html
* #topic guidelines
** #link https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
* #topic APIImpact
** #link https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
* #topic open topics
Any objections to merging https://review.openstack.org/#/c/158179/ as it would allow https://review.openstack.org/#/c/140313/30 to merge unchanged.
* #endmeeting

=== Previous Meetings ===

* [http://eavesdrop.openstack.org/meetings/api_wg/2014/ 2014]
* [http://eavesdrop.openstack.org/meetings/api_wg/2015/ 2015]

API Special Interest Group

2015-02-24T09:26:10Z

Matthew Gilliard: /* Members */

'''Status''': Active

'''Organizers''': [mailto:jaypipes@gmail.com Jay Pipes], [mailto:cbkyeoh@gmail.com Christopher Yeoh], [mailto:everett.toews@rackspace.com Everett Toews]

==Purpose==

To propose, discuss, review, and advocate for API guidelines for all OpenStack Programs to follow.

Any member of the working group is able to propose API guidelines. These proposals will be discussed by the working group. When a spec for an API schema is up for review (e.g. a [https://github.com/openstack/nova-specs/tree/master/specs Nova spec] for one of the [https://github.com/openstack/nova/tree/master/nova/api/openstack/compute/schemas/v3 Nova API schemas]), the working group members should review the spec and provide feedback with respect to how well it follows the guidelines. The working group members are also responsible for advocating for following the API guidelines within the OpenStack Programs that they work on.

==Communication==

For email, we will use the openstack-dev mailing list and prefix the subject line with [api]. Ideally, any OpenStack developer in any program that is discussing their API will also begin to use the [api] prefix so the working group members can be alerted to relevant discussions.

For IRC, we will use #openstack-dev on Freenode.

For the OpenStack Summit, design summit sessions.

For meetings, the [[Meetings/API-WG|API Working Group meetings]].

For cross-project liaisons (the liaison is the first line of contact for the API WG team members), see [[CrossProjectLiaisons#API_Guidelines|Cross-Project Liaisons]]

==Deliverables==

1. Analyze Current Design

This is essentially a way to record and visualize the current design of the APIs. It allows us to bring together many examples of the way APIs are designed so they can be analyzed and act as a discussion point. These are examples of good design to be emulated or bad design to be avoided. It can be examples of where the APIs are consistent or where there are inconsistencies.

2. Guidelines

Agreed upon and accepted guidelines must be added to version controlled documents in [http://git.openstack.org/cgit/openstack/api-wg/ Git] ([https://github.com/openstack/api-wg GitHub mirror]). Currently proposed changes to the documents can be found in this [https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z review report].

3. Reviews

Review comments and +1 or -1 votes on code changes and specs that affect any OpenStack Program API.

Identifying code changes and specs that affect APIs will require some vigilance on the part of members. Previously identified changes should carry the '''APIImpact''' flag, which allows them to be discovered by [https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z searching for the APIImpact flag within gerrit]. If they find a review that affects an API, they can email the openstack-dev list (using the [api] prefix) to notify the rest of the members of the review.

We should encourage all OpenStack Programs to adopt the use of an '''APIImpact''' flag in their commit messages.

4. Announcement Email

When a new guideline has been accepted, it must be announced to openstack-dev (without the [api] prefix for more visibility). The email must include a link to the guideline and the history (links to the wiki and review) of how it came to be.

5. Bugs (DO NOT start doing this yet)

''Let's not run around creating bugs for everyone just yet. How and when we start doing this should be determined in discussions in the meetings and on the list.''

When a new guideline has been accepted, bugs can be filed against APIs that do not follow the guideline. If the bug forces a backwards incompatible change, it would have to be fixed in the next version or microversion of the API. The bug must include a link to the guideline.

==How to Contribute==

Contributions come in the form of the deliverables above. For deliverables 2 and 3, you'll first have to go through the ''If you're a developer'' section of [[How_To_Contribute]].

1. To contribute to analyzing current design:

# Start at [[API_Working_Group/Current_Design|Current Design]].
# Find the category of the API design you want to analyze. If it doesn't exist, create it.
# Edit the wiki page and do the analysis.

For example, you want to analyze the consistency of all of the APIs that do pagination. In the Pagination category, create a table that lists all of the ways APIs do pagination side by side.

2. To contribute to the guidelines:

# Follow the [http://docs.openstack.org/infra/manual/developers.html#development-workflow Development Workflow]
# When you get to [http://docs.openstack.org/infra/manual/developers.html#starting-work-on-a-new-project Project Setup]], start with a <code>git clone git://git.openstack.org/openstack/api-wg.git</code>
# Continue with the workflow for your change

3. To contribute to reviews:

# Find a review on [https://review.openstack.org/ review.openstack.org] that impacts any API (this [https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z review report]).
# When commenting on the review:
## Add comments to the review according to the [https://github.com/openstack/api-wg guidelines].
## Link to the guidelines so the contributor can better understand your reasoning.
## Feel free to let the contributor know you are a member of the API Working Group.
## If the contributor disagrees with your review comments, invite them to start a thread on the openstack-dev mailing list with the prefix [api]
# Vote +1 or -1 on the review

4. To contribute announcement emails:

If you've proposed a guideline and it has been accepted, send an email to openstack-dev to announce it (read #4 above).

5. To contribute bugs (DO NOT start doing this yet):

# Find the project in [https://launchpad.net/openstack Launchpad].
# Go to the bug tracker for that project
# Report the bug and be sure to click on Extra Options and include the tag "api"

6. Participate in the discussions at the weekly [[Meetings/API-WG|API Working Group meetings]].

==Scope==

===In Scope===

The API Working Group is focused on creating guidelines for the HTTP APIs that expose the features to the application developers/operators using those APIs. It is not concerned with the implementation of those APIs.

These are guidelines for both going forward and for providing input (bugs) into the current version of existing APIs. When reporting bugs to the current version of existing APIs, the intent isn't to actually change the current version but to improve the next version of the API.

Recommending the use of an API definition format (e.g. Swagger, RAML, API Blueprint) to drive both the implementation of the service and the client.

===Out of Scope===

Third-party apis (e.g. EC2, S3, OCCI, etc.) are out of scope.

There is the related [[Application_Ecosystem_Working_Group]] (AE WG). The API Working Group (API WG) is complementary to the End User Working Group. The API WG is focused on creating guidelines for the APIs whereas AE WG is focused on creating applications that consume the APIs. The place where these groups meet in the middle is the API, which forms the contract between the two. Members of the AE WG are encouraged to be members of the API WG and vice versa.

==How to Join==

Join the [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev openstack-dev mailing list], watch for emails that are prefixed by [api], and join the discussion.

==FAQ==

Q. My OpenStack Program doesn't have an API schema or a spec review process (like [https://github.com/openstack/nova-specs Nova's]). What do I do?

A. Propose that your OpenStack Program adopt an API schema language and spec review process. The best way to give the API Working Group some teeth is by reviewing specs of API schemas. Commenting on reviews and giving a +1 or -1 to APIs that follow or don't follow the API guidelines will give this working group the potential to affect real change in OpenStack.

==Members==

Please add yourself to this list if you are committed to making the OpenStack APIs better.

* [mailto:mr.alex.meade@gmail.com Alex Meade]
* [mailto:jaypipes@gmail.com Jay Pipes]
* [mailto:cbkyeoh@gmail.com Christopher Yeoh]
* [mailto:everett.toews@rackspace.com Everett Toews]
* [mailto:dtroyer@gmail.com Dean Troyer]
* [http://www.openstack.org/community/members/profile/2535 Salvatore Orlando]
* [mailto:lbragstad@gmail.com Lance Bragstad]
* [mailto:anne.gentle@rackspace.com Anne Gentle]
* [mailto:ian.cordasco@rackspace.com Ian Cordasco]
* [mailto:huangzhipeng@huawei.com Zhipeng Huang]
* [mailto:ed@leafe.com Ed Leafe]
* [mailto:maty.grosz@alcatel-lucent.com Maty Grosz]
* [mailto:taget@linux.vnet.ibm.com Eli Qiao]
* [mailto:soulxu@gmail.com Alex Xu]
* [mailto:chdent@redhat.com Chris Dent]
* [mailto:constanze.kratel@rackspace.com Constanze Kratel]
* [mailto:sam.harwell@rackspace.com Sam Harwell]
* [mailto:ghanshyammann@gmail.com Ghanshyam Mann]
* [mailto:lisa.clark@rackspace.com Lisa Clark]
* [mailto:kevin.mitchell@rackspace.com Kevin Mitchell]
* [mailto:shaunak.kashyap@rackspace.com Shaunak Kashyap]
* [mailto:oomichi@mxs.nes.nec.co.jp Ken'ichi Ohmichi]
* [mailto:dstanek@dstanek.com David Stanek]
* [mailto:msm@redhat.com Michael McCune]
* [mailto:dolph.mathews@gmail.com Dolph Mathews]
* [http://www.openstack.org/community/members/profile/1778 Brian Rosmaita]
* [mailto:zack.shoylev@rackspace.com Zack Shoylev]
* [mailto:miguel.grinberg@gmail.com Miguel Grinberg]
* [mailto:graham.hayes@hp.com Graham Hayes]
* [mailto:christopher.lefelhoc@rackspace.com Christopher Lefelhocz]
* [mailto:lucasagomes@gmail.com Lucas Alvares Gomes]
* [http://www.openstack.org/community/members/profile/8436 Jason Zhang]
* [mailto:steve.lewis@rackspace.com Steve Lewis]
* [mailto:kaufer@us.ibm.com Steven Kaufer]
* [mailto:ryansb@redhat.com Ryan Brown]
* [http://www.openstack.org/community/members/profile/1657 Adrian Otto]
* [mailto:maishsk@gmail.com Maish Saidel-Keesing]
* [mailto:eglynn@redhat.com Eoghan Glynn]
* [http://www.openstack.org/community/members/profile/14334 Matthew Gilliard]

[[Category: Working_Groups]]
[[Category:UserCommittee]]

Meetings/Nova

2015-02-19T12:30:19Z

Matthew Gilliard: /* Agenda for next meeting */

Meetings/Nova

2015-02-19T12:27:59Z

Matthew Gilliard: /* Agenda for next meeting */

Meetings/Nova

2015-01-05T09:46:13Z

Matthew Gilliard:

Meetings/Nova

2014-12-18T16:39:02Z

Matthew Gilliard: /* Agenda for next meeting */

= Weekly Nova team meeting =
'''MEETING TIME: Thursdays alternating 14:00 UTC (#openstack-meeting-alt) 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.

== Agenda for next meeting ==

Scheduled for:
* December 11, 2014 14:00 UTC, #openstack-meeting-alt (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20141211T140000)

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 jcook ekhugen irina_pov krtaylor danpb alexpilotti flip214 raildo jaypipes gilliard garyk edleafe</code>

* Kilo Specs
** All blueprints and specs for juno need to be approved by kilo-1 (December 18th)
** Non-priority Feature Freeze is kilo-2 (February 5th)
** re-approve blueprint fast-track
*** anything needing approval?
** spec free blueprint evaluation (http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html#kilo)
* Kilo Priorities
** https://etherpad.openstack.org/p/kilo-nova-priorities
** https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
* Gate status
** http://status.openstack.org/elastic-recheck/gate.html
* Bugs
** ..
* Stuck reviews
** Pacemaker service group driver -- what level of CI do we require given that we have poor CI coverage of other drivers (such as zookeeper)?
** Neutron API Refactor: https://review.openstack.org/#/q/status:open+project:openstack/nova-specs+branch:master+topic:bp/nova-neutron-refactor,n,z
** Host health monitoring (https://review.openstack.org/#/c/137768/) -- should Nova provide information on the host condition, and how?
** Remove server group members -- https://review.openstack.org/#/c/136487/ -- would be good to get johnthetubaguy's input on this since it's stalled and the k-1 deadline is approaching.
* Open discussion
** https://wiki.openstack.org/wiki/Summit/Kilo/Etherpads
** Blueprint without a spec (was originally a wishlist bug), does this need a spec (don't think so)? https://blueprints.launchpad.net/nova/+spec/network-template-routes-injection
** Libvirt meetings. https://wiki.openstack.org/wiki/Meetings/Libvirt - Do they happen any more? Someone else was in that meeting room at the time mentioned there, and no minutes for months.

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

Meetings

2014-12-11T17:37:06Z

Matthew Gilliard: /* Nova team Meeting */

The OpenStack project holds its various public meetings on '''IRC''', in the <code><nowiki>#openstack-meeting</nowiki></code>, <code><nowiki>#openstack-meeting-alt</nowiki></code>, <code><nowiki>#openstack-meeting-3</nowiki></code>, and <code><nowiki>#openstack-meeting-4</nowiki></code> channels on Freenode. Everyone is encouraged to attend.

You can also access the [https://www.google.com/calendar/ical/bj05mroquq28jhud58esggqmh4@group.calendar.google.com/public/basic.ics iCal feed for all OpenStack meetings].

== OpenStack Cross-Project meeting ==
* Weekly on Tuesdays at 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): [[ThierryCarrez]]
* See [[Meetings/CrossProjectMeeting]] for details

== Technical Committee meeting ==
* Weekly on Tuesdays at 2000 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): [[ThierryCarrez]]
* See [[Meetings/TechnicalCommittee]] for details

== OpenStack Compute (Nova) ==
=== Nova team Meeting ===
* Weekly on Thursdays, alternating times - 1400 UTC and 2100 UTC
** For 2014 - odd weeks at 1400, even weeks at 2100 (date "+%U")
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): Michael Still (even weeks), Andrew Laski (odd weeks)
* See [[Meetings/Nova]] for an agenda

=== Nova Bug Scrub Meeting ===
* Weekly on Wednesday at 1630 UTC
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair (to contact for more information): Tracy Jones
* See [[Meetings/NovaBugScrub]] for an agenda

=== XenAPI team meeting ===
* Weekly on Wednesdays at 1500 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by: [[JohnGarbutt]]
* See [[Meetings/XenAPI]] for agenda

=== Nova Hyper-V team meeting ===
* Weekly on Tuesdays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by primeministerp (Peter Pouliot)
* See [[Meetings/Hyper-V|Meetings/Hyper-V]] for agenda and details

=== Gantt (Scheduler) team meeting ===
* Weekly on Tuesdays at 1500 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): n0ano (Don Dugger)
* See [[Meetings/Scheduler]] for details

=== VMwareAPI team meeting ===
* Weekly on Wednesdays at 1700 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: [[TracyJones]]
* See [[Meetings/VMwareAPI]] for details

=== PCI Passthrough Meeting ===
* Weekly on Tuesday at [http://www.worldclock.com/world_clock.html 1300 UTC]
* Will change back to once weekly after agreements are reached.
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: baoli (Robert Li)
* See [[Meetings/Passthrough]] for details

=== Nova API meeting ===
* Weekly on Friday at 00:00 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: Chris Yeoh
* See [[Meetings/NovaAPI]] for details

=== Libvirt Meeting ===
* Weekly on Tuesday at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=00&sec=0p1=0 15:00 UTC]
* IRC channel <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair: Daniel Berrange (IRC: danpb)
* See [[Meetings/Libvirt]] for details

=== Nova Cellsv2 Meeting ===
* Weekly on Wednesdays, alternating times - [http://www.timeanddate.com/worldclock/fixedtime.html?hour=17&min=00&sec=0p1=0 17:00 UTC] and [http://www.timeanddate.com/worldclock/fixedtime.html?hour=22&min=00&sec=0p1=0 22:00 UTC]
* IRC channel <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair: Andrew Laski (IRC: alaski)
* See [[Meetings/NovaCellsv2]] for details

== Documentation team meeting ==
* Every other Wednesday at alternating times, see [[Meetings/DocTeamMeeting]]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): [[AnneGentle]]
* See [[Meetings/DocTeamMeeting]] for an agenda

== Project Infrastructure team meeting ==
* Weekly on Tuesdays at 1900 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): [[User:Corvus|James E. Blair (jeblair)]]
* See [[Meetings/InfraTeamMeeting]] for an agenda

== QA team meeting ==
* Weekly on Thursdays at 1700/2200 UTC (alternating)
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): Matt Treinish
* See [[Meetings/QATeamMeeting]] for an agenda

== DefCore / RefStack Development Meeting ==
* Weekly on Mondays at 1100 Pacific / 1900 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* PTL: David Lenwell
* DefCore Chairs (to contact for more information): Rob "zehicle" Hirschfeld & Joshua McKenty
* See [[Meetings/DefCore]] for an agenda

== DefCore Progress Update Meeting ==
* 4/1 DefCore meeting, 2pm PST, 90 minutes
* Agenda & Connection Details at https://etherpad.openstack.org/p/DefCoreElephant.7
* Chairs (to contact for more information): Rob "@zehicle" Hirschfeld & Joshua McKenty
* 6/12/2014 DefCore.lighthouseF2F 10am-3pm Details at https://etherpad.openstack.org/p/DefCoreLighthouse.F2F

== State management team meeting ==
* Weekly on Thursdays at 1900 UTC (http://weatherarc.com/utc-time-conversion)
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): [[Harlowja]]
* See [[Meetings/StateManagement]] for an agenda

== Keystone team meeting ==
* Weekly on Tuesdays at 1800 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): Morgan Fainberg (morganfainberg)
* See [[Meetings/KeystoneMeeting]] for an agenda

== Ironic (Bare Metal) team meeting ==
* Alternating weeks on Mondays at 1700 UTC or Tuesday at 0500 UTC
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair (to contact for more infomation) Devananda van der Veen (devananda)
* see [[Meetings/Ironic]] for agenda

== TripleO team meeting ==
* Weekly on Tuesdays at 1900 UTC or Wednesdays at 0800 UTC (alternate weeks) (see the [https://www.google.com/calendar/ical/bj05mroquq28jhud58esggqmh4@group.calendar.google.com/public/basic.ics iCal feed] to check the time this week)
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more infomation) Clint Byrum (spamaps)
* see [[Meetings/TripleO]] for agenda

== TripleO/Kolla team meeting ==
* Weekly on Mondays at 2000 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more infomation) Steven Dake (sdake)
* see [[Meetings/Kolla]] for agenda

== OpenStack Networking (Neutron) ==
=== Neutron team meeting ===
* Weekly alternating between Mondays at 2100 UTC and Tuesdays at 1400 UTC.
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code> Mondays, <code><nowiki>#openstack-meeting</nowiki></code> Tuesdays
* Chair (to contact for more infomation) Kyle Mestery (mestery)
* see [[Network/Meetings]] for agenda

=== LBaaS meeting ===
* Weekly on Tuesdays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-meeting-4</nowiki></code>
* Chair (to contact for more infomation) mestery (Kyle Mestery)
* see [[Network/LBaaS]] for agenda

=== Octavia meeting ===
* Weekly on Wednesdays at 2000 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more infomation) sbalukoff (Stephen Balukoff)
* see [[Octavia/Weekly Meeting Agenda]] for agenda

=== ML2 Network sub-team meeting ===
* Weekly on Wednesdays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more information): rkukura/Suhkdev (Bob Kukura / Sukhdev Kapur)
* See [[Meetings/ML2]] for details

=== Firewall as a Service (FWaaS) team meeting ===
* Weekly on Wednesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenStack+Neutron+FWaaS+IRC&iso=20140326T1830&p1=1440&ah=1 1830 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair: snaiksat (Sumit Naiksatam)
* See [[Meetings/FWaaS]] for details

=== Neutron Advanced Services' team meeting ===
* Weekly on Tuesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=Neutron+Advanced+Services&iso=20141111T17&p1=1440 1700 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-4</nowiki></code>
* Chair: snaiksat (Sumit Naiksatam)
* See [[Meetings/AdvancedServices]] for details

=== Neutron IPv6 sub-team Meeting ===
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1500 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: sc68cal (Sean M. Collins)
* See [[Meetings/Neutron-IPv6-Subteam]] for details

=== Neutron Group Policy Sub-Team Meeting ===
* Weekly on Thursdays at 1800 UTC
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair: SumitNaiksatam (Sumit Naiksatam)
* See [[Meetings/Neutron_Group_Policy]] for details

=== Neutron Distributed Virtual Router meeting ===
* Weekly on Wednesdays at [http://www.worldclock.com/world_clock.html 1500 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair:Swami (Swaminathan Vasudevan)
* See [[Meetings/Distributed-Virtual-Router]] for details

=== Neutron blueprint ovs-firewall-driver Meeting ===
* Tentative: Monday, December 16 at 2000 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: asadoughi (Amir Sadoughi)
* Agenda: See [[Meetings/Neutron_blueprint_ovs-firewall-driver]]

=== Neutron L3 Sub Team Meeting ===
* Weekly on Thursday at 1500 UTC
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair: carl_baldwin (Carl Baldwin)
* Agenda: See [[Meetings/Neutron-L3-Subteam]]

=== Neutron ServiceVM framework Sub Team Meeting ===
* Weekly on Wednesdays at 1700UTC from Nov 19, 2014
(Time slot/channel was changed from Nov 19, 2014.)
* IRC channel: <code><nowiki>#openstack-meeting-4</nowiki></code>
* Chair: yamahata (Isaku Yamahata)
* Agenda: See [[Meetings/ServiceVM]]

=== neutron-drivers weekly IRC meeting ===
* Weekly on Wednesdays at 1530-1630 UTC
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair: mestery (Kyle Mestery)
* Agenda: See [[Meetings/NeutronDrivers]]

=== VPN as a Service (VPNaaS) team meeting ===
* Weekly on Tuesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenStack+Neutron+VPNaaS+IRC&iso=20140326T1500&p1=1440&ah=1 1500 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair: pc_m (Paul Michali)
* See [[Meetings/VPNaaS]] for details

== Cinder team meeting ==
* Weekly on Wednesdays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by [[JohnGriffith]]
* see [[CinderMeetings]] for agenda

== Ceilometer team meeting ==
* '''Every''' week on Thursdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=0&sec=0 1500 UTC].
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by eglynn (Eoghan Glynn)
* see [[Meetings/Ceilometer]] for details

== Designate (DNSaaS) meeting ==
* Weekly Wednesdays at 1700 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more information): Kiall Mac Innes (kiall)
* See [[Meetings/Designate]] for details

== Trove (DBaaS) meeting ==
* Weekly on Wednesdays at 1800 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more information): [https://launchpad.net/~slicknik Nikhil Manchanda] (SlickNik) / [https://launchpad.net/~hubcap Michael Basnight] (hub_cap) / [https://launchpad.net/~vipuls Vipul Sabhaya] (vipul) / [https://launchpad.net/~tim-simpson Tim Simpson] (grapex) / [https://launchpad.net/~amcrn Auston McReynolds] (amcrn) / [https://launchpad.net/~cp16net Craig Vyvial] (cp16net)
* See [[Meetings/TroveMeeting]] for details
* For BP Meeting, please see [[Meetings/TroveBPMeeting]] for more details

== Zaqar (Messaging and Notification) team meeting ==
* Weekly on Mondays, alternating between 2100 UTC and 1500 UTC (starting with 2100 UTC on 8/4)
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair (to contact for more information): Flavio Percoco (flaper87), Kurt Griffiths (kgriffs)
* See [[Meetings/Zaqar]] for details

== OpenStack Data Processing (Sahara) team meeting ==
* Weekly on Thursdays at 1800 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more info): SergeyLukjanov (Sergey Lukjanov)
* See [[Meetings/SaharaAgenda]] for details

== Mistral meeting ==
* Weekly on Mondays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: rakhmerov (Renat Akhmerov)
* See [[Meetings/MistralAgenda]] for details

== Murano meeting ==
* Weekly on Tuesday at 1700 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: Serg Melikyan (sergmelikyan)
* See [[Meetings/MuranoAgenda]] for details

== Heat (orchestration) team meeting ==
* Weekly on Wednesdays at 2000 UTC or 1200 UTC (on alternate weeks)
* IRC Channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): Zane Bitter (zaneb)
* See [[Meetings/HeatAgenda]] for details

== Horizon team meeting ==
* Weekly on Wednesdays at 2000 UTC or 1200 UTC (on alternate weeks)
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair: David Lyle (david-lyle)
* See [[Meetings/Horizon]] for details

== Swift team meeting ==
* Weekly on Wednesdays at 1900 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: notmyname (John Dickinson)
* See [[Meetings/Swift]] for details

== OpenStack Security Group (OSSG) meeting ==
* Weekly on Thursdays at 1700 UTC (1 hour duration)
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more information): hyakuhei (Rob Clark)
* See [[Meetings/OpenStackSecurity]] for an agenda

== Python3 Compatibility Team meeting ==
* Not planned anymore
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): jd_ (Julien Danjou)
* See [[Meetings/Python3]] for details

== Glance Team meeting ==
* Weekly on Thursdays at 1400/1500 UTC (alternating)
* IRC channel: <code><nowiki>#openstack-meeting-4</nowiki></code>
* Chair (to contact for more information): nikhil_k (Nikhil Komawar)
* See [[Meetings/Glance]] for details

== Oslo Team meeting ==

* Juno
** Every Friday at 1600 UTC ([http://www.timeanddate.com/worldclock/converted.html?iso=20140425T16&p1=0&p2=2133&p3=195&p4=224 timeanddate.com])
** IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
** Chair (to contact for more information): dhellmann (Doug Hellmann)
** See [[Meetings/Oslo]] for details
* Kilo (beginning 17 Nov 2014)
** Every Monday at 1600 UTC ([http://www.timeanddate.com/worldclock/converted.html?iso=20141117T16&p1=0&p2=2133&p3=195&p4=224 timeanddate.com])
** IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
** Chair (to contact for more information): dhellmann (Doug Hellmann)
** See [[Meetings/Oslo]] for details

== OpenStack Community Office Hours ==
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 0800 UTC] and on Fridays at [http://www.worldclock.com/world_clock.html 1800 UTC]
* IRC channel: <code><nowiki>#openstack-community</nowiki></code>
* Chair: fifieldt ([http://www.openstack.org/community/members/profile/369 Tom Fifield]) and reed ([http://www.openstack.org/community/members/profile/1372 Stefano Maffulli])
* See [[Meetings/Community]] for details

== I18N Team meeting ==
* Bi-weekly on Thursday, at 0800 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: daisy
* See [[Meetings/I18nTeamMeeting]] for details

== Training-guides Team meeting ==
* Weekly on Monday at [http://www.timeanddate.com/time/zone/usa/san-francisco 1700 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: sarob
* See [[Meetings/training-guides]] for details

== Trainers Team meeting ==
* Weekly on Wednesday at [http://www.timeanddate.com/time/zone/usa/san-francisco 1800 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: sarob
* See [[Meetings/trainers]] for details

== Manila Team meeting ==
* Weekly on Thursday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 1500 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: bswartz
* See [[Manila/Meetings]] for details

== Blazar (Reservations) team meeting ==
* Weekly on Fridays at [http://www.worldclock.com/world_clock.html 1500 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: bauzas (Sylvain Bauza), DinaBelova (Dina Belova)
* See [[Meetings/Blazar]] for details

== Rally meeting ==
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1700 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair:boris-42 (Boris Pavlovic)
* See [[Meetings/Rally]] for details

== Solum Team Meeting ==
* Weekly on Tuesdays at 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: adrian_otto (Adrian Otto)
* See [[Meetings/Solum]] for details

== Congress Team Meeting ==
* Weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1700 UTC], e.g. Feb 25, 2014
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair: pballand (Pete Balland) or thinrichs (Tim Hinrichs)
* See [[Meetings/Congress]] for details

== Barbican Meeting ==
* Weekly on Mondays at [http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130502T2000 2000 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more information): jraim (#openstack-barbican @ Freenode)
* See [[Meetings/Barbican]] for an agenda

== Chef Cookbook meetings ==
* Google Hangout Weekly on Mondays at 1530 UTC
* IRC channel Weekly on Fridays at 1530 UTC: <code><nowiki>#openstack-chef</nowiki></code>
* Chair: JJ Asghar
* See [[Meetings/ChefCookbook]] for details

== StoryBoard Meeting ==
* Weekly on Mondays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair: krotscheck, ttx, or NikitaKonovalov
* See [[StoryBoard]] for details

== Hierarchical Multitenancy Meeting ==
* Weekly on Friday at 1600 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: vishy/schwicke
* See [[Meetings/HierarchicalMultitenancyMeeting]] for details

== python-openstacksdk Meeting ==
* Weekly on Tuesdays at [http://www.worldtimebuddy.com/?qm=1&lid=6,0,4726206,100&h=6&date=2014-2-11&sln=13-14 1900 UTC] starting 2/19/2014
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair: jnoller
* See [[PythonOpenStackSDK]] for details

== Satori Team Meeting ==
* Weekly on Mondays at [http://www.worldtimebuddy.com/?qm=1&lid=6,0,4726206,100&h=6&date=2014-2-11&sln=9-10 1500 UTC] starting Feb 24, 2014
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: Ziad_Sawalha
* See [[Meetings/Satori]] for details

== Fuel Team Meeting ==
* Weekly on Thursdays at [http://www.worldtimebuddy.com/?qm=1&lid=100&h=100&date=2014-3-27&sln=16-17 1600 UTC] starting Feb 27, 2014
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: vkozhukalov
* See [[Meetings/Fuel]] for details

== Third Party Meeting ==
* Twice weekly: Mondays at 1800 UTC as well as Tuesdays at 0800 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chairs: anteaya, krtaylor
* See [[Meetings/ThirdParty]] for details

== MagnetoDB Team meeting ==
* Weekly on Thursdays at 1400 UTC
* IRC channel: <code><nowiki>#magnetodb</nowiki></code>
* Chair: isviridov

== Telco Working Group Meeting ==
* Weekly alternating on Wednesdays alternating between 1400 UTC and 2200 UTC.
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> (@ 1400 UTC) and <code><nowiki>#openstack-meeting</nowiki></code> (@ 2200 UTC)
* Chair: Stephen Gordon (steveg)
* See [[https://wiki.openstack.org/wiki/TelcoWorkingGroup]] or join #openstack-nfv for details.

== Containers Team Meeting ==
* Weekly on Tuesdays at 1600/2200 UTC (alternating)
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: adrian_otto (Adrian Otto)
* See [[Meetings/Containers]] for details

== User Experience (UX) Team Meeting ==
* Every second week on Mondays at 1700 UTC starting July 7th, 2014 (even weeks)
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair: jcoufal (Jaromir Coufal)
* See [[Meetings/UX]] for details

== Tetris Team Meeting ==
* Bi-Weely at 0100 UTC
* IRC channel: <code><nowiki>#tetris</nowiki></code>
* Chair: Jay (liugya@cn.ibm.com jay.lau.513@gmail.com)
* See [[Meetings/Tetris]] for details

== Poppy Team Meeting ==
* Weekly on Thursdays at 1900 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> starting August 7, 2014
* Chair: amitgandhinz (amit.gandhi@rackspace.com)
* See [[Meetings/Poppy]] for details

== Puppet OpenStack Team Meeting ==
* Weekly on Monday at 1400 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code> starting October 27, 2014
* Chair: crinkle (colleen@puppetlabs.com)
* See [[Meetings/PuppetOpenStack]] for details

== API Work Group Team Meeting ==
* Weekly on Thursdays at 16:00UTC/00:00 UTC (alternating)
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code> starting October 30, 2014
* Chair:
* See [[Meetings/API-WG]] for details

== Swift-on-File ==
* Weekly on Thursday at 1400 UTC
* IRC channel: <code><nowiki>#swiftonfile</nowiki></code>
* Chair: tdasilva (Thiago da Silva)
* See [[Meetings/swiftonfile]] for details

== Openstack Operators Team Meeting ==
* Weekly on Wednesday at 1800 UTC (first meeting is December 17)
* IRC channel: <code><nowiki>#openstack-meeting-4</nowiki></code>
* Chair: mfisch (Matt Fischer)
* See [[Meetings/openstack-operators]] for details

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

Meetings/Nova

2014-12-10T21:10:36Z

Matthew Gilliard: /* Agenda for next meeting */

People

2014-12-10T20:35:47Z

Matthew Gilliard:

The best place to find out about the people of OpenStack (including their IRC handle) is by looking them up in the [http://www.openstack.org/community/members/ OpenStack Foundation Membership Directory].

[[Category:OpenStackFoundation]]

People

2014-12-10T20:33:33Z

Matthew Gilliard: /* Translation for IRC nicknames */

= Translation for IRC nicknames =

The best place to find someone's IRC handle is by looking them up in the [http://www.openstack.org/community/members/ OpenStack Foundation Membership Directory].

[[Category:OpenStackFoundation]]

Meetings/Nova

2014-12-09T10:14:17Z

Matthew Gilliard: /* Agenda for next meeting */

Meetings/Nova

2014-12-09T09:53:31Z

Matthew Gilliard: /* Agenda for next meeting */

= Weekly Nova team meeting =
'''MEETING TIME: Thursdays alternating 14:00 UTC (#openstack-meeting-alt) 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.

== Agenda for next meeting ==

Scheduled for:
* December 11, 2014 14:00 UTC, #openstack-meeting-alt (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20141211T140000)

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 jcook ekhugen irina_pov krtaylor danpb alexpilotti flip214 raildo jaypipes gilliard</code>

* Kilo Specs
** All blueprints and specs for juno need to be approved by kilo-1 (December 18th)
** Non-priority Feature Freeze is kilo-2 (February 5th)
** if your code reviews are being blocked on a "procedural -2", please ping the reviewer (in email) and remind them to reconsider
** re-approve blueprint fast-track
** spec free blueprint evaluation (http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html#kilo)
*** https://blueprints.launchpad.net/nova/+spec/hw-iscsi-device-name-support
* Kilo Priorities
** https://etherpad.openstack.org/p/kilo-nova-priorities
** https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
* Gate status
** ..
* Bugs
** ..
* Stuck reviews
** An example for discussion -- [https://review.openstack.org/#/c/123957/ reviews on 123957]
** SSL options - do we make them per-project or global, or both? Neutron and Cinder have config-group specific SSL options, Glance is using oslo sslutils global options since Juno which was contentious for a time in a separate review in Icehouse (https://review.openstack.org/#/c/84522/). Now https://review.openstack.org/#/c/131066/ wants to break that out for Glance, but we also have a patch for Keystone to use the global oslo SSL options, https://review.openstack.org/#/c/124296/ - we should be consistent, but does that require a blueprint now? (mriedem)
** [https://review.openstack.org/#/c/129235/ Hyper-V: attach volumes via SMB]
** [https://review.openstack.org/#/c/136484/ Adds keypair type database migration]
** [https://review.openstack.org/#/c/131734/ Libvirt: SMB volume driver]
** zookeeper servicegroup driver issues: nova-conductor processes share zookeeper handle and which causes have lock and race: https://review.openstack.org/#/c/133479/ and https://review.openstack.org/#/c/133500/
** [https://review.openstack.org/#/c/131413/ Neutron API refactor]
* Open discussion
** https://wiki.openstack.org/wiki/Summit/Kilo/Etherpads
** Tidying up https://wiki.openstack.org/wiki/People

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

People

2014-12-09T09:51:38Z

Matthew Gilliard: /* Translation for IRC nicknames */

= Translation for IRC nicknames =
Each name is linked to a bio page for that individual. Please add yourself
{| border="1" cellpadding="2" cellspacing="0"
| '''IRC Nickname'''
| '''Real Name'''
| '''Company or Role'''
|-
| _0x44
| [[_0x44|Christopher MacGown]]
| Piston Cloud Founder, Nova Core Team member, Former Ozone developer
|-
| adiantum
| [[IlyaAlekseyev]]
| Nova Developer
|-
| adrian17od
| [[Adrian Smith]]
| Software Engineer - Workday
|-
| AJaeger
| Andreas Jaeger
| SUSE Product Manager, OpenStack Documentation and Infra team member
|-
| akrivoka
| [[User:Akrivokapic1|Ana Krivokapić]]
| Red Hat
|-
| akscram
| Ilya Kharin
| Software Engineer, Mirantis
|-
| alexpilotti
| Alessandro Pilotti
| CEO, Cloudbase Solutions
|-
| ameade
| Alex Meade
| Ozone Developer
|-
| amotoki
| Akihiro Motoki
| Quantum developer, NEC
|-
|anand_ts
|[[Anand T S]]
|OpenStack Engineer-Accel Frontline Limited
|-
| andrewbogott
| [[andrewbogott|Andrew Bogott]]
| Developer, Wikimedia Foundation
|-
| annegentle
| [[AnneGentle|Anne Gentle]]
| [[OpenStack]] Technical Writer, Casual nick arriety
|-
| anotherjesse
| [[JesseAndrews|Jesse Andrews]]
| [[AnsoLabs]] co-founder, Nebula chief architect
|-
| anteaya
| Anita Kuno
| Monty's Team
|-
| alekibango
| [[David Pravec]]
| Free and Open Source Software Specialist
|-
| [[ArseneRei]]
| Stephon Striplin
| Developer, DreamHost
|-
| [http://adam.younglogic.com ayoung]
| Adam Young
| Senior Software Engineer, Red Hat
|-
| cleverdevil
| [[JonathanLaCour|Jonathan LaCour]]
| Vice President, Software Development, DreamHost
|-
| bauzas
| [[SylvainBauza|Sylvain Bauza]]
| Nova Developer
|-
| bcwaldon
| Brian Waldon
| Rackspace Cloud Builders Developer
|-
| bencherian
| [[BenCherian|Ben Cherian]]
| General Manager, Emerging Technologies, DreamHost
|-
| berendt
| [[ChristianBerendt|Christian Berendt]]
| Consultant/Developer, B1 Systems
|-
| BK_man
| [[AndreyBrindeyev|Andrey Brindeyev]]
| Grid Dynamics International
|-
| blamar
| Brian Lamar
| Ozone Developer
|-
| bobmel
| Bob Melander
| Neuron & Tacker developer
|-
| btorch
| [[btorch|Marcelo Martins]]
| Swift System Engineer
|-
| carlp
| [[carlp|Carl Perry]]
| System Administrator, DreamHost (New Dream Network)
|-
| cerberus
| [[cerberus|Matt Dietz]]
| Ozone Developer
|-
| chemikadze
| [[NikolaySokolov|Nikolay Sokolov]]
| [[GridDynamics]] Developer
|-
| chidical
| [[chidical|Chidi Alams]]
| Systems Engineer
|-
| chmouel
| [[Chmouel|Chmouel Boudjnah]]
| Rackspace Developer
|-
| colinnich
| Colin Nicholson
| Software Developer, iomart group
|-
| comstud
| [[comstud|Chris Behrens]]
| Ozone Developer
|-
| creiht
| [[creiht|Chuck Thier]]
| Swift Developer
|-
| cwright
| [[CoryWright|Cory Wright]]
| Rackspace Operations
|-
| dabo
| [[dabo|Ed Leafe]]
| Ozone Developer
|-
| dachary
| [[dachary|Loic Dachary]]
| [http://enovance.com/ eNovance] CRO and [https://alioth.debian.org/projects/openstack/ Debian GNU/Linux packager]
|-
| davidhadas
| David Hadas
| Swift, IBM Research
|-
| danwent
| Dan Wendlandt
| Quantum developer, PTL
|-
| dendrobates
| [[RickClark|Rick Clark]]
| [[OpenStack]] Project Lead & Chief Architect
|-
| devananda
| [[Devananda|Devananda van der Veen]]
| Nova Baremetal Driver, Openstack-on-Openstack, HP Cloud
|-
| devcamcar
| [[DevinCarlen|Devin Carlen]]
| Founder of Nebula Inc, Nova Core Member, PTL Horizon, [[OpenStack]] POC
|-
| DinaBelova
| [[DinaBelova| Dina Belova]]
| Software Engineer at Mirantis, Ceilometer core-team member
|-
| dhellmann
| [[DougHellmann|Doug Hellmann]]
| HP
|-
| dtroyer
| Dean Troyer
| Rackspace Cloudbuilders
|-
| DuncanT
| Duncan Thomas
| HP - Nova and Nova-volume team
|-
| eday
| [[eday|Eric Day]]
| Open Source Architect / Developer
|-
| egallen
| [[egallen|Erwan Gallen]]
| Cloudwatt
|-
| eharney
| [[eharney|Eric Harney]]
| Red Hat
|-
| emagana
| [[EdgarMagana|Edgar Magana]]
| Neutron Core Developer - Cloud Operations Architect at Workday
|-
| exlt
| [[exlt|Michael Shuler]]
| Swift Systems Engineer
|-
| fifieldt
| [[User:Fifieldt|Tom Fifield]]
| NeCTAR, OpenStack Foundation
|-
| fungi
| [[User:fungi|Jeremy Stanley]]
| project infrastructure, developer community resources and continuous integration systems
|-
| garyk
| Gary Kotton
| VMware
|-
| gholt
| [[gholt|Greg Holt]]
| Swift Developer
|-
| gilliard
| Matthew Gilliard
| Nova Developer - HP - UK timezone.
|-
| glange
| [[glange|Greg Lange]]
| Swift Developer
|-
| glenc
| [[GlenCampbell|Glen Campbell]]
| Architect/Analyst
|-
| gongys
| Yong Sheng Gong
| IBM
|-
| guitarzan
| Cory Stone
| Rackspace
|-
| gundlach
| [[gundlach|Michael Gundlach]]
| Ozone Developer
|-
| h1nch
| [[h1nch|John Hincher]]
| Systems Engineer
|-
| heckj
| [[JosephHeck|Joe Heck]]
| Developer / Systems Engineer
|-
| hemna
| [[walter-boring|Walter A. Boring IV]]
| HP - Cinder core member
|-
| huichun lu
| [[huichun lu|huichun lu]]
| Software Engineer, Intel
|-
| ironcamel
| Naveed Massjouni
| Ozone Developer
|-
| jaypipes
| [[jaypipes|Jay Pipes]]
| Open Source Architect / Developer
|-
| jc_smith
| [[jcsmith|Jean-Christophe "JC" Smith]]
| Architect
|-
| jeblair
| [[JamesBlair|James Blair]]
| Developer and CI Infrastructure
|-
| jgriffith
| [[JohnGriffith|John Griffith]]
| BlockStorage Technical Lead
|-
| jk0
| [[jk0|Josh Kearney]]
| Ozone Developer
|-
| jmeridth
| [[jmeridth|Jason Meridth (JM)]]
| Ozone Developer
|-
| johnthetubaguy
| [[johngarbutt|John Garbutt]]
| Senior Software Developer, Citrix Systems
|-
| johnpur
| [[JohnPurrier|John Purrier]]
| [[OpenStack]]/Rackspace liaison
|-
| joshuamckenty
| [[joshuamckenty|Joshua McKenty]]
| Piston Cloud Founder, Nova Core Team member, [[OpenStack]] POC, formerly NASA Nebula Architect
|-
| k4n0
| [[k4n0|Rohan Rhishikesh Kanade]]
| Izel Technologies, Senior Software Engineer
|-
| kchen
| Ken Chen
| Software Engineer, Intel
|-
| koolhead17
| Atul Jha
| App Specialist, Csscorp
|-
| kpepple
| [[KenPepple|Ken Pepple]]
| Consultant / Architect / Developer
|-
| KMarsh
| Kyle Marsh
| Developer, DreamHost
|-
| krtaylor
| Kurt Taylor
| IBM
|-
| lblanchard
| [http://uxd-stackabledesign.rhcloud.com/?page_id=2 Liz Blanchard]
| User Interaction Designer, Red Hat
|-
| [[LinuxJedi]]
| [[LinuxJedi|Andrew Hutchings]]
| Developer Infrastructure and Software Engineer, HP
|-
| littleidea
| [[littleidea|Andrew Clay Shafer]]
| Cloudscaling
|-
| letterj
| [[letterj|Jay Payne]]
| Data Catalyst
|-
| lloydde
| [[lloydde|Lloyd Dewolf]]
| Piston Cloud, Director of Customer Care
|-
| lorin1
| [[LorinHochstein|Lorin Hochstein]]
| Lead Architect, Nimbis Services
|-
| maishsk
| [[maishsk|Maish Saidel-Keesing]]
| Cisco, Platform Architect
|-
| Mandell
| [[mdegerne|Mandell Degerness]]
| Piston Cloud, Systems Analyst
|-
| maoy
| [[maoy|Yun Mao]]
| AT&T Labs - Research, Researcher
|-
| markmc
| [[markmc|Mark McLoughlin]]
| Principal Software Engineer, Red Hat
|-
| [[MarkAtwood]]
| [[MarkAtwood|Mark Atwood]]
| Director - Open Source Evangelism, HP
|-
| markvoelker
| [[markvoelker|Mark Voelker]]
| Software Development Manager, Cisco
|-
| markwash
| Mark Washenberger
| Ozone Developer
|-
| masayukig
| Masayuki Igawa
| Software Engineer, NEC Solution Innovators, Ltd.
|-
| matiu
| [[matiu|Matthew Sherborne]]
| Nova Dev - Rackspace
|-
| mattt
| [[mattt|Matt Thompson]]
| Systems Engineer
|-
| mattray
| [[Matt Ray]]
| Senior Technical Evangelist, Opscode
|-
| mestery
| Kyle Mestery
| Quantum developer
|-
| mikal
| [[Michael Still]]
| Rackspace Australia
|-
| mnot
| [[mnottingham|Mark Nottingham]]
| Rackspace
|-
| morellon
| [[Thiago Morello]]
| Locaweb
|-
| mtaylor
| [[MontyTaylor|Monty Taylor]]
| Developer Infrastructure and CI Manager, HP
|-
| murkk
| [[murkk|Chris Blumentritt]]
| Ozone Systems Engineer
|-
| n0ano
| [[n0ano|Don Dugger]]
| Software engineer, Intel
|-
| ncode
| [[Juliano Martinez]]
| Locaweb
|-
| ndipanov
| Nikola Đipanov
| Red Hat
|-
| notmyname
| [[notmyname|John Dickinson]]
| Swift Developer
|-
| nelson
| [[nelson|Russ Nelson]]
| Wikipedia Contractor
|-
| oubiwann
| [[oubiwann|Duncan McGreggor]]
| Cloud Engineering Manager, DreamHost
|-
| ozstacker
| [[ozstacker|Tristan Goode]]
| Australian [[OpenStack]] User Group Co-Ordinator, CEO Aptira
|-
| pandemicsyn
| [[pandemicsyn|Florian Hines]]
| Swift Engineering Monkey
|-
| patrocinio
| Eduardo Patrocinio
| IBM
|-
| pixelbeat
| [[p-draigbrady|Pádraig Brady]]
| Red Hat, Nove core team member
|-
| pknouff
| Philip Knouff
| Ozone Developer
|-
| [[PotHix]]
| Willian Molinari
| Locaweb
|-
| pvo
| [[pvo|Paul Voccio]]
| Ozone Manager
|-
| blakeyeager
| [[blakeyeager|Blake Yeager]]
| Product Manager, Rackspace Cloud
|-
| rackerhacker
| [[major|Major Hayden]]
| Systems Engineer
|-
| rahmu
| [[rahmu|Joe Hakim Rahme]]
| eNovance
|-
| rainya
| Rainya Mosher
| Ozone SDLC Project Manager
|-
| Razique
| [[RaziqueMahroua|Razique Mahroua]]
| Nevrotic Openstacker and Technical Writer
|-
| rbergeron
| [[RobynBergeron|Robyn Bergeron]]
| Fedora Marketing & Cloud Person
|-
| redbo
| [[redbo|Michael Barton]]
| Swift Developer
|-
| reed
| [[StefanoMaffulli|Stefano Maffulli]]
| OpenStack Community Manager
|-
| reldan
| [[reldan|Eldar Nugaev]]
| Software Developer
|-
| rgerganov
| [[rgerganov|Radoslav Gerganov]]
| VMware
|-
| rohitk
| [[rohitk|Rohit Karajgi]]
| Technical Lead, NTT Data
|-
| russellb
| [[russellb|Russell Bryant]]
| Red Hat
|-
| salv-orlando
| [[SalvatoreOrlando|Salvatore Orlando]]
| Quantum Core Dev
|-
| sandywalsh
| [[sandywalsh|Sandy Walsh]]
| Core developer (Rackspace - Ozone)
|-
| sarob
| [[sarob|Sean Roberts]]
| Infrastructure Strategy Yahoo!
|-
| sdague
| [[sdague|Sean Dague]]
| Developer, IBM
|-
| sirp
| [[sirp|Rick Harris]]
| Ozone Developer
|-
| s0mik
| [[s0mik|Somik Behera]]
| [[OpenStack]] Quantum Founding Member, Quantum Core Developer, Product@Nicira, Former VMware Core Developer
|-
| SergeyLukjanov
| [[User:Sergey_Lukjanov|Sergey Lukjanov]]
| Tech Lead / Senior Software Engineer / Mirantis
|-
| soren
| [[soren|Soren Hansen]]
| Open Source Architect / Developer
|-
| spy
| [[ant|Antony Messerli]]
| Ozone Systems Engineer
|-
| Sukhdev
| Sukhdev Kapur
| Arista Networks
|-
| termie
| [[termie|Andy Smith]]
| Nova Developer
|-
|thimble
| André Nähring
| Consultant, Developer, B1 Systems
|-
| thingee
| Mike Perez
| Developer, DreamHost
|-
| toanster
| Toan Nguyen
| [[OpenStack]] Software Development Manager, Rackspace
|-
| tonywolf
| [[Wolf|Tony Wolf]]
| Ozone Business Analyst
|-
| ttx
| [[ThierryCarrez|Thierry Carrez]]
| OpenStack Release Manager
|-
| tylesmit
| Tyler Smith
| Cisco Developer
|-
| vishy
| [[vishy|Vish Ishaya]]
| Nova Project Technical Lead
|-
| vitola
| [[Vitola|Alex Vitola]]
| System Administrator - DevOps , [http://www.deserv.eti.br/ Deserv - Tecnologia & Serviços]
|-
| Vivek / VivekVC
| [[Vivek / VivekVC|Vivek Varghese Cherian]]
| Technical Specialist / Senior Project Lead - Syntel Inc, OpenStack Cloud Architect, DevOps Architect
|-
| weiting
| [[weiting|Weiting Chen]]
| Software Engineer, Intel
|-
| winston-d
| Zhiteng Huang
| Performance Engineer, Intel
|-
| wowdd1
| Zhao Dan
| Developer
|-
| loquacity
| Lana Brindley
| Technical Writer, Rackspace
|-
| osier
| Osier Yang
| Software Engineer, Red Hat
|-
| vrovachev
| Vadim Rovachev
| QA Engineer, Mirantis
|-
| ylobankov
| Yaroslav Lobankov
| QA Engineer, Mirantis
|-
| zyluo
| [[Zyluo|Zhongyue Luo]]
| Software Engineer, Intel
|}

[[Category:OpenStackFoundation]]

People

2014-12-09T09:45:56Z

Matthew Gilliard: /* Translation for IRC nicknames */

= Translation for IRC nicknames =
Each name is linked to a bio page for that individual. Please add yourself
{| border="1" cellpadding="2" cellspacing="0"
| '''IRC Nickname'''
| '''Real Name'''
| '''Company or Role'''
|-
| _0x44
| [[_0x44|Christopher MacGown]]
| Piston Cloud Founder, Nova Core Team member, Former Ozone developer
|-
| adiantum
| [[IlyaAlekseyev]]
| Nova Developer
|-
| adrian17od
| [[Adrian Smith]]
| Software Engineer - Workday
|-
| AJaeger
| Andreas Jaeger
| SUSE Product Manager, OpenStack Documentation and Infra team member
|-
| akrivoka
| [[User:Akrivokapic1|Ana Krivokapić]]
| Red Hat
|-
| akscram
| Ilya Kharin
| Software Engineer, Mirantis
|-
| alexpilotti
| Alessandro Pilotti
| CEO, Cloudbase Solutions
|-
| ameade
| Alex Meade
| Ozone Developer
|-
| amotoki
| Akihiro Motoki
| Quantum developer, NEC
|-
|anand_ts
|[[Anand T S]]
|OpenStack Engineer-Accel Frontline Limited
|-
| andrewbogott
| [[andrewbogott|Andrew Bogott]]
| Developer, Wikimedia Foundation
|-
| annegentle
| [[AnneGentle|Anne Gentle]]
| [[OpenStack]] Technical Writer, Casual nick arriety
|-
| anotherjesse
| [[JesseAndrews|Jesse Andrews]]
| [[AnsoLabs]] co-founder, Nebula chief architect
|-
| anteaya
| Anita Kuno
| Monty's Team
|-
| alekibango
| [[David Pravec]]
| Free and Open Source Software Specialist
|-
| [[ArseneRei]]
| Stephon Striplin
| Developer, DreamHost
|-
| [http://adam.younglogic.com ayoung]
| Adam Young
| Senior Software Engineer, Red Hat
|-
| cleverdevil
| [[JonathanLaCour|Jonathan LaCour]]
| Vice President, Software Development, DreamHost
|-
| bauzas
| [[SylvainBauza|Sylvain Bauza]]
| Nova Developer
|-
| bcwaldon
| Brian Waldon
| Rackspace Cloud Builders Developer
|-
| bencherian
| [[BenCherian|Ben Cherian]]
| General Manager, Emerging Technologies, DreamHost
|-
| berendt
| [[ChristianBerendt|Christian Berendt]]
| Consultant/Developer, B1 Systems
|-
| BK_man
| [[AndreyBrindeyev|Andrey Brindeyev]]
| Grid Dynamics International
|-
| blamar
| Brian Lamar
| Ozone Developer
|-
| bobmel
| Bob Melander
| Neuron & Tacker developer
|-
| btorch
| [[btorch|Marcelo Martins]]
| Swift System Engineer
|-
| carlp
| [[carlp|Carl Perry]]
| System Administrator, DreamHost (New Dream Network)
|-
| cerberus
| [[cerberus|Matt Dietz]]
| Ozone Developer
|-
| chemikadze
| [[NikolaySokolov|Nikolay Sokolov]]
| [[GridDynamics]] Developer
|-
| chidical
| [[chidical|Chidi Alams]]
| Systems Engineer
|-
| chmouel
| [[Chmouel|Chmouel Boudjnah]]
| Rackspace Developer
|-
| colinnich
| Colin Nicholson
| Software Developer, iomart group
|-
| comstud
| [[comstud|Chris Behrens]]
| Ozone Developer
|-
| creiht
| [[creiht|Chuck Thier]]
| Swift Developer
|-
| cwright
| [[CoryWright|Cory Wright]]
| Rackspace Operations
|-
| dabo
| [[dabo|Ed Leafe]]
| Ozone Developer
|-
| dachary
| [[dachary|Loic Dachary]]
| [http://enovance.com/ eNovance] CRO and [https://alioth.debian.org/projects/openstack/ Debian GNU/Linux packager]
|-
| davidhadas
| David Hadas
| Swift, IBM Research
|-
| danwent
| Dan Wendlandt
| Quantum developer, PTL
|-
| dendrobates
| [[RickClark|Rick Clark]]
| [[OpenStack]] Project Lead & Chief Architect
|-
| devananda
| [[Devananda|Devananda van der Veen]]
| Nova Baremetal Driver, Openstack-on-Openstack, HP Cloud
|-
| devcamcar
| [[DevinCarlen|Devin Carlen]]
| Founder of Nebula Inc, Nova Core Member, PTL Horizon, [[OpenStack]] POC
|-
| DinaBelova
| [[DinaBelova| Dina Belova]]
| Software Engineer at Mirantis, Ceilometer core-team member
|-
| dhellmann
| [[DougHellmann|Doug Hellmann]]
| HP
|-
| dtroyer
| Dean Troyer
| Rackspace Cloudbuilders
|-
| DuncanT
| Duncan Thomas
| HP - Nova and Nova-volume team
|-
| eday
| [[eday|Eric Day]]
| Open Source Architect / Developer
|-
| egallen
| [[egallen|Erwan Gallen]]
| Cloudwatt
|-
| eharney
| [[eharney|Eric Harney]]
| Red Hat
|-
| emagana
| [[EdgarMagana|Edgar Magana]]
| Neutron Core Developer - Cloud Operations Architect at Workday
|-
| exlt
| [[exlt|Michael Shuler]]
| Swift Systems Engineer
|-
| fifieldt
| [[User:Fifieldt|Tom Fifield]]
| NeCTAR, OpenStack Foundation
|-
| fungi
| [[User:fungi|Jeremy Stanley]]
| project infrastructure, developer community resources and continuous integration systems
|-
| garyk
| Gary Kotton
| VMware
|-
| gholt
| [[gholt|Greg Holt]]
| Swift Developer
|-
| gilliard
| [[gilliard|Matthew Gilliard]]
| Nova Developer - HP
|-
| glange
| [[glange|Greg Lange]]
| Swift Developer
|-
| glenc
| [[GlenCampbell|Glen Campbell]]
| Architect/Analyst
|-
| gongys
| Yong Sheng Gong
| IBM
|-
| guitarzan
| Cory Stone
| Rackspace
|-
| gundlach
| [[gundlach|Michael Gundlach]]
| Ozone Developer
|-
| h1nch
| [[h1nch|John Hincher]]
| Systems Engineer
|-
| heckj
| [[JosephHeck|Joe Heck]]
| Developer / Systems Engineer
|-
| hemna
| [[walter-boring|Walter A. Boring IV]]
| HP - Cinder core member
|-
| huichun lu
| [[huichun lu|huichun lu]]
| Software Engineer, Intel
|-
| ironcamel
| Naveed Massjouni
| Ozone Developer
|-
| jaypipes
| [[jaypipes|Jay Pipes]]
| Open Source Architect / Developer
|-
| jc_smith
| [[jcsmith|Jean-Christophe "JC" Smith]]
| Architect
|-
| jeblair
| [[JamesBlair|James Blair]]
| Developer and CI Infrastructure
|-
| jgriffith
| [[JohnGriffith|John Griffith]]
| BlockStorage Technical Lead
|-
| jk0
| [[jk0|Josh Kearney]]
| Ozone Developer
|-
| jmeridth
| [[jmeridth|Jason Meridth (JM)]]
| Ozone Developer
|-
| johnthetubaguy
| [[johngarbutt|John Garbutt]]
| Senior Software Developer, Citrix Systems
|-
| johnpur
| [[JohnPurrier|John Purrier]]
| [[OpenStack]]/Rackspace liaison
|-
| joshuamckenty
| [[joshuamckenty|Joshua McKenty]]
| Piston Cloud Founder, Nova Core Team member, [[OpenStack]] POC, formerly NASA Nebula Architect
|-
| k4n0
| [[k4n0|Rohan Rhishikesh Kanade]]
| Izel Technologies, Senior Software Engineer
|-
| kchen
| Ken Chen
| Software Engineer, Intel
|-
| koolhead17
| Atul Jha
| App Specialist, Csscorp
|-
| kpepple
| [[KenPepple|Ken Pepple]]
| Consultant / Architect / Developer
|-
| KMarsh
| Kyle Marsh
| Developer, DreamHost
|-
| krtaylor
| Kurt Taylor
| IBM
|-
| lblanchard
| [http://uxd-stackabledesign.rhcloud.com/?page_id=2 Liz Blanchard]
| User Interaction Designer, Red Hat
|-
| [[LinuxJedi]]
| [[LinuxJedi|Andrew Hutchings]]
| Developer Infrastructure and Software Engineer, HP
|-
| littleidea
| [[littleidea|Andrew Clay Shafer]]
| Cloudscaling
|-
| letterj
| [[letterj|Jay Payne]]
| Data Catalyst
|-
| lloydde
| [[lloydde|Lloyd Dewolf]]
| Piston Cloud, Director of Customer Care
|-
| lorin1
| [[LorinHochstein|Lorin Hochstein]]
| Lead Architect, Nimbis Services
|-
| maishsk
| [[maishsk|Maish Saidel-Keesing]]
| Cisco, Platform Architect
|-
| Mandell
| [[mdegerne|Mandell Degerness]]
| Piston Cloud, Systems Analyst
|-
| maoy
| [[maoy|Yun Mao]]
| AT&T Labs - Research, Researcher
|-
| markmc
| [[markmc|Mark McLoughlin]]
| Principal Software Engineer, Red Hat
|-
| [[MarkAtwood]]
| [[MarkAtwood|Mark Atwood]]
| Director - Open Source Evangelism, HP
|-
| markvoelker
| [[markvoelker|Mark Voelker]]
| Software Development Manager, Cisco
|-
| markwash
| Mark Washenberger
| Ozone Developer
|-
| masayukig
| Masayuki Igawa
| Software Engineer, NEC Solution Innovators, Ltd.
|-
| matiu
| [[matiu|Matthew Sherborne]]
| Nova Dev - Rackspace
|-
| mattt
| [[mattt|Matt Thompson]]
| Systems Engineer
|-
| mattray
| [[Matt Ray]]
| Senior Technical Evangelist, Opscode
|-
| mestery
| Kyle Mestery
| Quantum developer
|-
| mikal
| [[Michael Still]]
| Rackspace Australia
|-
| mnot
| [[mnottingham|Mark Nottingham]]
| Rackspace
|-
| morellon
| [[Thiago Morello]]
| Locaweb
|-
| mtaylor
| [[MontyTaylor|Monty Taylor]]
| Developer Infrastructure and CI Manager, HP
|-
| murkk
| [[murkk|Chris Blumentritt]]
| Ozone Systems Engineer
|-
| n0ano
| [[n0ano|Don Dugger]]
| Software engineer, Intel
|-
| ncode
| [[Juliano Martinez]]
| Locaweb
|-
| ndipanov
| Nikola Đipanov
| Red Hat
|-
| notmyname
| [[notmyname|John Dickinson]]
| Swift Developer
|-
| nelson
| [[nelson|Russ Nelson]]
| Wikipedia Contractor
|-
| oubiwann
| [[oubiwann|Duncan McGreggor]]
| Cloud Engineering Manager, DreamHost
|-
| ozstacker
| [[ozstacker|Tristan Goode]]
| Australian [[OpenStack]] User Group Co-Ordinator, CEO Aptira
|-
| pandemicsyn
| [[pandemicsyn|Florian Hines]]
| Swift Engineering Monkey
|-
| patrocinio
| Eduardo Patrocinio
| IBM
|-
| pixelbeat
| [[p-draigbrady|Pádraig Brady]]
| Red Hat, Nove core team member
|-
| pknouff
| Philip Knouff
| Ozone Developer
|-
| [[PotHix]]
| Willian Molinari
| Locaweb
|-
| pvo
| [[pvo|Paul Voccio]]
| Ozone Manager
|-
| blakeyeager
| [[blakeyeager|Blake Yeager]]
| Product Manager, Rackspace Cloud
|-
| rackerhacker
| [[major|Major Hayden]]
| Systems Engineer
|-
| rahmu
| [[rahmu|Joe Hakim Rahme]]
| eNovance
|-
| rainya
| Rainya Mosher
| Ozone SDLC Project Manager
|-
| Razique
| [[RaziqueMahroua|Razique Mahroua]]
| Nevrotic Openstacker and Technical Writer
|-
| rbergeron
| [[RobynBergeron|Robyn Bergeron]]
| Fedora Marketing & Cloud Person
|-
| redbo
| [[redbo|Michael Barton]]
| Swift Developer
|-
| reed
| [[StefanoMaffulli|Stefano Maffulli]]
| OpenStack Community Manager
|-
| reldan
| [[reldan|Eldar Nugaev]]
| Software Developer
|-
| rgerganov
| [[rgerganov|Radoslav Gerganov]]
| VMware
|-
| rohitk
| [[rohitk|Rohit Karajgi]]
| Technical Lead, NTT Data
|-
| russellb
| [[russellb|Russell Bryant]]
| Red Hat
|-
| salv-orlando
| [[SalvatoreOrlando|Salvatore Orlando]]
| Quantum Core Dev
|-
| sandywalsh
| [[sandywalsh|Sandy Walsh]]
| Core developer (Rackspace - Ozone)
|-
| sarob
| [[sarob|Sean Roberts]]
| Infrastructure Strategy Yahoo!
|-
| sdague
| [[sdague|Sean Dague]]
| Developer, IBM
|-
| sirp
| [[sirp|Rick Harris]]
| Ozone Developer
|-
| s0mik
| [[s0mik|Somik Behera]]
| [[OpenStack]] Quantum Founding Member, Quantum Core Developer, Product@Nicira, Former VMware Core Developer
|-
| SergeyLukjanov
| [[User:Sergey_Lukjanov|Sergey Lukjanov]]
| Tech Lead / Senior Software Engineer / Mirantis
|-
| soren
| [[soren|Soren Hansen]]
| Open Source Architect / Developer
|-
| spy
| [[ant|Antony Messerli]]
| Ozone Systems Engineer
|-
| Sukhdev
| Sukhdev Kapur
| Arista Networks
|-
| termie
| [[termie|Andy Smith]]
| Nova Developer
|-
|thimble
| André Nähring
| Consultant, Developer, B1 Systems
|-
| thingee
| Mike Perez
| Developer, DreamHost
|-
| toanster
| Toan Nguyen
| [[OpenStack]] Software Development Manager, Rackspace
|-
| tonywolf
| [[Wolf|Tony Wolf]]
| Ozone Business Analyst
|-
| ttx
| [[ThierryCarrez|Thierry Carrez]]
| OpenStack Release Manager
|-
| tylesmit
| Tyler Smith
| Cisco Developer
|-
| vishy
| [[vishy|Vish Ishaya]]
| Nova Project Technical Lead
|-
| vitola
| [[Vitola|Alex Vitola]]
| System Administrator - DevOps , [http://www.deserv.eti.br/ Deserv - Tecnologia & Serviços]
|-
| Vivek / VivekVC
| [[Vivek / VivekVC|Vivek Varghese Cherian]]
| Technical Specialist / Senior Project Lead - Syntel Inc, OpenStack Cloud Architect, DevOps Architect
|-
| weiting
| [[weiting|Weiting Chen]]
| Software Engineer, Intel
|-
| winston-d
| Zhiteng Huang
| Performance Engineer, Intel
|-
| wowdd1
| Zhao Dan
| Developer
|-
| loquacity
| Lana Brindley
| Technical Writer, Rackspace
|-
| osier
| Osier Yang
| Software Engineer, Red Hat
|-
| vrovachev
| Vadim Rovachev
| QA Engineer, Mirantis
|-
| ylobankov
| Yaroslav Lobankov
| QA Engineer, Mirantis
|-
| zyluo
| [[Zyluo|Zhongyue Luo]]
| Software Engineer, Intel
|}

[[Category:OpenStackFoundation]]

Meetings/Nova

2014-12-09T09:25:26Z

Matthew Gilliard: /* Agenda for next meeting */

= Weekly Nova team meeting =
'''MEETING TIME: Thursdays alternating 14:00 UTC (#openstack-meeting-alt) 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.

== Agenda for next meeting ==

Scheduled for:
* December 11, 2014 14:00 UTC, #openstack-meeting-alt (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20141211T140000)

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 jcook ekhugen irina_pov krtaylor danpb alexpilotti flip214 raildo jaypipes gilliard</code>

* Kilo Specs
** All blueprints and specs for juno need to be approved by kilo-1 (December 18th)
** Non-priority Feature Freeze is kilo-2 (February 5th)
** if your code reviews are being blocked on a "procedural -2", please ping the reviewer (in email) and remind them to reconsider
** re-approve blueprint fast-track
** spec free blueprint evaluation (http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html#kilo)
*** https://blueprints.launchpad.net/nova/+spec/hw-iscsi-device-name-support
* Kilo Priorities
** https://etherpad.openstack.org/p/kilo-nova-priorities
** https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
* Gate status
** ..
* Bugs
** ..
* Stuck reviews
** An example for discussion -- [https://review.openstack.org/#/c/123957/ reviews on 123957]
** SSL options - do we make them per-project or global, or both? Neutron and Cinder have config-group specific SSL options, Glance is using oslo sslutils global options since Juno which was contentious for a time in a separate review in Icehouse (https://review.openstack.org/#/c/84522/). Now https://review.openstack.org/#/c/131066/ wants to break that out for Glance, but we also have a patch for Keystone to use the global oslo SSL options, https://review.openstack.org/#/c/124296/ - we should be consistent, but does that require a blueprint now? (mriedem)
** [https://review.openstack.org/#/c/129235/ Hyper-V: attach volumes via SMB]
** [https://review.openstack.org/#/c/136484/ Adds keypair type database migration]
** [https://review.openstack.org/#/c/131734/ Libvirt: SMB volume driver]
** zookeeper servicegroup driver issues: nova-conductor processes share zookeeper handle and which causes have lock and race: https://review.openstack.org/#/c/133479/ and https://review.openstack.org/#/c/133500/
** [https://review.openstack.org/#/c/131413/ Neutron API refactor]
* Open discussion
** https://wiki.openstack.org/wiki/Summit/Kilo/Etherpads

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