OpenStack - User contributions [en]

API Special Interest Group/Current Design/State vs Status

2015-01-22T00:45:27Z

Shaunak Kashyap: Fixing links

= Analysis =

13 calls that take a param with the word '''state''' in it

20 call that take a param with the word '''status''' in it

Nova and Neutron have calls with both state and status

= Current Design =

== Methodology ==

<pre><nowiki>
git clone https://github.com/openstack/api-site.git
cd api-ref/src/wadls/
grep -nR "param .*state.*" *
grep -nR "param .*status.*" *
</nowiki></pre>

== State ==

{| class="wikitable"
|-
! WADL !! Line !! Param
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/compute-api/src/v2/ext/os-admin-actions.wadl#L527 compute-api/src/v2/ext/os-admin-actions.wadl] || 527 || state
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/compute-api/src/v2/ext/os-interface.wadl#L109 compute-api/src/v2/ext/os-interface.wadl] || 109 || port_state
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/compute-api/src/v2/ext/os-interface.wadl#L134 compute-api/src/v2/ext/os-interface.wadl] || 134 || port_state
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/common.ent#L220 netconn-api/src/common.ent] || 220 || admin_state_up
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl#L217 netconn-api/src/os-networks.wadl] || 217 || admin_state_up
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl#L291 netconn-api/src/os-networks.wadl] || 291 || admin_state_up
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl#L345 netconn-api/src/os-networks.wadl] || 345 || admin_state_up
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl#L439 netconn-api/src/os-networks.wadl] || 439 || admin_state_up
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl#L518 netconn-api/src/os-networks.wadl] || 518 || admin_state_up
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl#L608 netconn-api/src/os-networks.wadl] || 608 || admin_state_up
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/telemetry-api/src/v2/os-telemetry-api-2.0.wadl#L420 telemetry-api/src/v2/os-telemetry-api-2.0.wadl] || 420 || state
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/volume-api/src/v2/os-attach.wadl#L142 volume-api/src/v2/os-attach.wadl] || 142 || port_state
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/volume-api/src/v2/os-attach.wadl#L174 volume-api/src/v2/os-attach.wadl] || 174 || port_state
|}

== Status ==

{| class="wikitable"
|-
! WADL !! Line !! Param
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/compute-api/src/v2/ext/os-hosts.wadl#L118 compute-api/src/v2/ext/os-hosts.wadl] || 118 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/compute-api/src/v2/ext/os-migrations.wadl#L29 compute-api/src/v2/ext/os-migrations.wadl] || 29 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/compute-api/src/v2/ext/os-migrations.wadl#L138 compute-api/src/v2/ext/os-migrations.wadl] || 138 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/identity-api/src/v3/wadl/common.ent#L128 identity-api/src/v3/wadl/common.ent] || 128 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/image-api/src/v2/common.ent#L98 image-api/src/v2/common.ent] || 98 || member_status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/image-api/src/v2/common.ent#L118 image-api/src/v2/common.ent] || 118 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/image-api/src/v2/common.ent#L186 image-api/src/v2/common.ent] || 186 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/common.ent#L202 image-api/src/v2/common.ent] || 202 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wad#L245l netconn-api/src/os-networks.wadl] || 245 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl#L373 netconn-api/src/os-networks.wadl] || 373 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl#L467 netconn-api/src/os-networks.wadl] || 467 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl#L546 netconn-api/src/os-networks.wadl] || 546 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl#L636 netconn-api/src/os-networks.wadl] || 636 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/orchestration-api/src/v1/orchestration-api.wadl#L285 orchestration-api/src/v1/orchestration-api.wadl] || 285 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/orchestration-api/src/v1/orchestration-api.wadl#L1105 orchestration-api/src/v1/orchestration-api.wadl] || 1105 || resource_status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/orchestration-api/src/v1/orchestration-api.wadl#L1208 orchestration-api/src/v1/orchestration-api.wadl] || 1208 || resource_status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/orchestration-api/src/v1/orchestration-api.wadl#L1491 orchestration-api/src/v1/orchestration-api.wadl] || 1491 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/orchestration-api/src/v1/orchestration-api.wadl#L1499 orchestration-api/src/v1/orchestration-api.wadl] || 1499 || status_reason
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/orchestration-api/src/v1/orchestration-api.wadl#L1567 orchestration-api/src/v1/orchestration-api.wadl] || 1567 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/orchestration-api/src/v1/orchestration-api.wadl#L1575 orchestration-api/src/v1/orchestration-api.wadl] || 1575 || status_reason
|}

API Special Interest Group/Current Design/State vs Status

2015-01-22T00:36:37Z

Shaunak Kashyap: Adding line number anchors to links

= Analysis =

13 calls that take a param with the word '''state''' in it

20 call that take a param with the word '''status''' in it

Nova and Neutron have calls with both state and status

= Current Design =

== Methodology ==

<pre><nowiki>
git clone https://github.com/openstack/api-site.git
cd api-ref/src/wadls/
grep -nR "param .*state.*" *
grep -nR "param .*status.*" *
</nowiki></pre>

== State ==

{| class="wikitable"
|-
! WADL !! Line !! Param
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/compute-api/src/v2/ext/os-admin-actions.wadl compute-api/src/v2/ext/os-admin-actions.wadl#L527] || 527 || state
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/compute-api/src/v2/ext/os-interface.wadl compute-api/src/v2/ext/os-interface.wadl#L109] || 109 || port_state
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/compute-api/src/v2/ext/os-interface.wadl compute-api/src/v2/ext/os-interface.wadl#L134] || 134 || port_state
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/common.ent netconn-api/src/common.ent#L220] || 220 || admin_state_up
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl netconn-api/src/os-networks.wadl#L217] || 217 || admin_state_up
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl netconn-api/src/os-networks.wadl#L291] || 291 || admin_state_up
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl netconn-api/src/os-networks.wadl#L345] || 345 || admin_state_up
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl netconn-api/src/os-networks.wadl#L439] || 439 || admin_state_up
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl netconn-api/src/os-networks.wadl#L518] || 518 || admin_state_up
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl netconn-api/src/os-networks.wadl#L608] || 608 || admin_state_up
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/telemetry-api/src/v2/os-telemetry-api-2.0.wadl telemetry-api/src/v2/os-telemetry-api-2.0.wadl#L420] || 420 || state
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/volume-api/src/v2/os-attach.wadl volume-api/src/v2/os-attach.wadl#L142] || 142 || port_state
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/volume-api/src/v2/os-attach.wadl volume-api/src/v2/os-attach.wadl#L174] || 174 || port_state
|}

== Status ==

{| class="wikitable"
|-
! WADL !! Line !! Param
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/compute-api/src/v2/ext/os-hosts.wadl compute-api/src/v2/ext/os-hosts.wadl#L118] || 118 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/compute-api/src/v2/ext/os-migrations.wadl compute-api/src/v2/ext/os-migrations.wadl#L29] || 29 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/compute-api/src/v2/ext/os-migrations.wadl compute-api/src/v2/ext/os-migrations.wadl#L138] || 138 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/identity-api/src/v3/wadl/common.ent identity-api/src/v3/wadl/common.ent#L128] || 128 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/image-api/src/v2/common.ent image-api/src/v2/common.ent#L98] || 98 || member_status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/image-api/src/v2/common.ent image-api/src/v2/common.ent#L118] || 118 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/image-api/src/v2/common.ent image-api/src/v2/common.ent#L186] || 186 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/common.ent image-api/src/v2/common.ent#L202] || 202 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl netconn-api/src/os-networks.wadl#L245] || 245 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl netconn-api/src/os-networks.wadl#L373] || 373 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl netconn-api/src/os-networks.wadl#L467] || 467 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl netconn-api/src/os-networks.wadl#L546] || 546 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/netconn-api/src/os-networks.wadl netconn-api/src/os-networks.wadl#L636] || 636 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/orchestration-api/src/v1/orchestration-api.wadl orchestration-api/src/v1/orchestration-api.wadl#L285] || 285 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/orchestration-api/src/v1/orchestration-api.wadl orchestration-api/src/v1/orchestration-api.wadl#L1105] || 1105 || resource_status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/orchestration-api/src/v1/orchestration-api.wadl orchestration-api/src/v1/orchestration-api.wadl#L1208] || 1208 || resource_status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/orchestration-api/src/v1/orchestration-api.wadl orchestration-api/src/v1/orchestration-api.wadl#L1491] || 1491 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/orchestration-api/src/v1/orchestration-api.wadl orchestration-api/src/v1/orchestration-api.wadl#L1499] || 1499 || status_reason
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/orchestration-api/src/v1/orchestration-api.wadl orchestration-api/src/v1/orchestration-api.wadl#L1567] || 1567 || status
|-
| [https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/orchestration-api/src/v1/orchestration-api.wadl orchestration-api/src/v1/orchestration-api.wadl#L1575] || 1575 || status_reason
|}

Meetings/API-SIG

2014-11-13T01:41:17Z

Shaunak Kashyap: /* Previous Meetings */

= Weekly API Work Group Meeting =

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

* Standardising 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>
* #startmeeting api wg
* MeetBot Manual http://meetbot.debian.net/Manual.html
* Chaired by: Jay Pipes | Christopher Yeoh | Everett Toews

=== Next Meeting ===
Thursday 2014/11/13 at 0000 UTC

==== Agenda ====

* summit review https://etherpad.openstack.org/p/kilo-crossproject-api-wg
* additional meeting time https://review.openstack.org/#/c/132668/
* wiki page updates https://wiki.openstack.org/wiki/API_Working_Group
* APIImpact flag https://review.openstack.org/#/q/status:open+AND+(message:ApiImpact+OR+message:APIImpact),n,z
* review 201-header-and-body https://review.openstack.org/#/c/133087/
* reviews https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

=== Previous Meetings ===

* 2014/10/30
** [http://eavesdrop.openstack.org/meetings/api_wg/2014/api_wg.2014-10-30-00.00.html Minutes]
** [http://eavesdrop.openstack.org/meetings/api_wg/2014/api_wg.2014-10-30-00.00.log.html Log]

* 2014/11/13
** [http://eavesdrop.openstack.org/meetings/api_wg/2014/api_wg.2014-11-13-00.08.html Minutes]
** [http://eavesdrop.openstack.org/meetings/api_wg/2014/api_wg.2014-11-13-00.08.log.html Log]

Meetings/API-SIG

2014-11-12T15:02:52Z

Shaunak Kashyap: Fixing typo date of next meeting

Meetings/Poppy

2014-10-27T16:38:42Z

Shaunak Kashyap: Fixing TZ converter link to use correct meeting time

== Weekly Poppy Team Meeting ==

If you're interested in [[Poppy]], we hold public meetings weekly in `#openstack-meeting-alt` on freenode.

{| class="wikitable"
|-
! Meeting Time !! Local Time
|-
| UTC 1900 Thursdays || https://www.worldtimebuddy.com/event?lid=100&h=100&sts=23577120&sln=19-20&a=show&euid=3e9b9e6b-c064-10d4-f1b1-102a36ec33cf
|}

Please feel free to add items to the agenda below with your name and we'll cover them.

== Next meeting ==
* Thursday October 30, 2014 @ 1900 UTC on #openstack-meeting-alt on Freenode

=== Agenda ===

===== Usual Items =====
* Review last weeks Action Items
* Updates on Blueprints - see https://blueprints.launchpad.net/poppy
* Updates on Bugs - see https://bugs.launchpad.net/poppy

===== New Items =====
* Discuss the topics to focus on during the Design Session in Paris - https://etherpad.openstack.org/p/poppy-design-session-paris

===== Time Permitting =====
* Open Discussion

== Previous meetings ==
* Meeting #12 | Kilo Design Session | 23 October 2014 | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-10-23-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-10-23-19.00.html summary]
* Meeting #11 | Review | 16 October 2014 | [http://eavesdrop.openstack.org/meetings/__poppy/2014/__poppy.2014-10-16-18.59.log.html log] | [http://eavesdrop.openstack.org/meetings/__poppy/2014/__poppy.2014-10-16-18.59.html summary]
* Meeting #10 | Summit | 9 October 2014 | [http://eavesdrop.openstack.org/meetings/weekly_poppy_meeting/2014/weekly_poppy_meeting.2014-10-09-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/weekly_poppy_meeting/2014/weekly_poppy_meeting.2014-10-09-19.00.html summary]
* Meeting #9 | Status Fields | 2 October 2014 | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-10-02-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-10-02-19.00.html summary]
* Meeting #8 | Review | 25 September 2014 | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-09-25-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-09-25-19.00.html summary]
* Meeting #7 | Analytics | 18 September 2014 | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-09-18-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-09-18-19.00.html summary]
* Meeting #6 | Review | 11 September 2014 | [http://eavesdrop.openstack.org/meetings/weekly_poppy_meeting/2014/weekly_poppy_meeting.2014-09-11-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/weekly_poppy_meeting/2014/weekly_poppy_meeting.2014-09-11-19.00.html summary]
* Meeting #5 | Limits | 4 September 2014 | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-09-04-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-09-04-19.00.html summary]
* Meeting #4 | Log Delivery, Load Testing | 28 August 2014 | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-08-28-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-08-28-19.00.html summary]
* Meeting #3 | Blueprints | 21 August 2014 | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-08-21-19.02.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-08-21-19.02.html summary]
* Meeting #2 | Reseller Models | 14 August 2014 | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-08-14-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-08-14-19.00.html summary]
* Meeting #1 | Introductions | 7 August 2014 | [http://eavesdrop.openstack.org/meetings/poppy_team_meeting/2014/poppy_team_meeting.2014-08-07-19.15.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_team_meeting/2014/poppy_team_meeting.2014-08-07-19.15.html summary]

== Meeting organizers ==

* Groom the agenda 24h in advance
* Use http://meetbot.debian.net/Manual.html to get an automatic summary, and remember to record minutes on this page (see above).
* Record decisions and commitments; review in the next meeting

Meetings/Poppy

2014-10-27T16:30:23Z

Shaunak Kashyap: Fixing TZ converter link to use correct meeting time

== Weekly Poppy Team Meeting ==

If you're interested in [[Poppy]], we hold public meetings weekly in `#openstack-meeting-alt` on freenode.

{| class="wikitable"
|-
! Meeting Time !! Local Time
|-
| UTC 1900 Thursdays || http://www.worldtimebuddy.com/?qm=1&lid=5392171,100&h=5392171&date=2014-10-30&sln=12-13
|}

Please feel free to add items to the agenda below with your name and we'll cover them.

== Next meeting ==
* Thursday October 30, 2014 @ 1900 UTC on #openstack-meeting-alt on Freenode

=== Agenda ===

===== Usual Items =====
* Review last weeks Action Items
* Updates on Blueprints - see https://blueprints.launchpad.net/poppy
* Updates on Bugs - see https://bugs.launchpad.net/poppy

===== New Items =====
* Discuss the topics to focus on during the Design Session in Paris - https://etherpad.openstack.org/p/poppy-design-session-paris

===== Time Permitting =====
* Open Discussion

== Previous meetings ==
* Meeting #12 | Kilo Design Session | 23 October 2014 | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-10-23-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-10-23-19.00.html summary]
* Meeting #11 | Review | 16 October 2014 | [http://eavesdrop.openstack.org/meetings/__poppy/2014/__poppy.2014-10-16-18.59.log.html log] | [http://eavesdrop.openstack.org/meetings/__poppy/2014/__poppy.2014-10-16-18.59.html summary]
* Meeting #10 | Summit | 9 October 2014 | [http://eavesdrop.openstack.org/meetings/weekly_poppy_meeting/2014/weekly_poppy_meeting.2014-10-09-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/weekly_poppy_meeting/2014/weekly_poppy_meeting.2014-10-09-19.00.html summary]
* Meeting #9 | Status Fields | 2 October 2014 | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-10-02-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-10-02-19.00.html summary]
* Meeting #8 | Review | 25 September 2014 | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-09-25-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-09-25-19.00.html summary]
* Meeting #7 | Analytics | 18 September 2014 | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-09-18-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-09-18-19.00.html summary]
* Meeting #6 | Review | 11 September 2014 | [http://eavesdrop.openstack.org/meetings/weekly_poppy_meeting/2014/weekly_poppy_meeting.2014-09-11-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/weekly_poppy_meeting/2014/weekly_poppy_meeting.2014-09-11-19.00.html summary]
* Meeting #5 | Limits | 4 September 2014 | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-09-04-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-09-04-19.00.html summary]
* Meeting #4 | Log Delivery, Load Testing | 28 August 2014 | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-08-28-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-08-28-19.00.html summary]
* Meeting #3 | Blueprints | 21 August 2014 | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-08-21-19.02.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-08-21-19.02.html summary]
* Meeting #2 | Reseller Models | 14 August 2014 | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-08-14-19.00.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2014/poppy_weekly_meeting.2014-08-14-19.00.html summary]
* Meeting #1 | Introductions | 7 August 2014 | [http://eavesdrop.openstack.org/meetings/poppy_team_meeting/2014/poppy_team_meeting.2014-08-07-19.15.log.html log] | [http://eavesdrop.openstack.org/meetings/poppy_team_meeting/2014/poppy_team_meeting.2014-08-07-19.15.html summary]

== Meeting organizers ==

* Groom the agenda 24h in advance
* Use http://meetbot.debian.net/Manual.html to get an automatic summary, and remember to record minutes on this page (see above).
* Record decisions and commitments; review in the next meeting

API Special Interest Group

2014-10-19T01:53:03Z

Shaunak Kashyap: Adding myself as member

'''Status''': Forming

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

==Deliverables==

Agreed upon and accepted guidelines must be added to version controlled documents (e.g. Git via Gerrit or [[Governance/Proposed/APIGuidelines]]).

Review comments on code changes and specs that affect any OpenStack Program API.

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

There is the related [[End_User_Working_Group]] (EU 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 EU 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 EU 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: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: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]

OpenStack-SDK-PHP/UserFacingDocumentation

2014-04-29T23:37:28Z

Shaunak Kashyap: /* Mock complete-user-guide.rst */

== Proposed Directory Structure==

At the top-most level (i.e., right under the project root directory), there will be two directories related to user-facing documentation: <code>doc</code> and <code>examples</code>. The <code>doc</code> directory will contain the actual user-facing documentation while the <code>examples</code> directory will contain standalone PHP scripts for individual tasks (such as creating a container). The documentation in the <code>doc</code> directory will reference the example scripts in the <code>examples</code> directory, letting the user download standalone, working versions of PHP code for examples shown in the documentation.

The <code>doc</code> directory will contain a <code>user-guides</code> subdirectory. This will contain Getting Started Guides and Complete User Guides for each OpenStack service. It will also contain a <code>_common</code> directory for any shared documentation snippets to be included from other documentation (for instance, documentation on authentication).

The <code>examples</code> directory will also contain subdirectories. These subdirectories will mirror those under <code>doc/user-guides</code>.

doc/
user-guides/
_common/
compute/
getting-started.rst
complete-user-guide.rst
object-store/
getting-started.rst
complete-user-guide.rst

examples/
compute/
object-store/
create-container.php

== Getting Started Guide Structure ==
There will be exactly one Getting Started Guide per OpenStack service (excluding Identity, perhaps?). The goal of this guide is to let the reader start using that service in a few minutes. As such, it should guide the user through a '''common''' and '''short''' use case for that service.

Finally, at the end of a Getting Started Guide, there should be a link to the Complete User Guide for the same service. This gives the reader a next step instead of a dead end.

===Sample getting-started.rst (abbreviated)===

First, authenticate:
code snippet 1

Then, do XXX.
code snippet 2

As a result of XXX, you will get so and so.

Then, do YYY.
code snippet 3

Then, do ZZZ.
code snippet 4

[Download standalone PHP script for this example] -> links to <code>examples/compute/getting-started.php</code>

Next Steps:
There's more you can do with QQQ service. To find out, read the [complete user guide] next.

==Complete User Guide Structure==
There will be exactly one Complete User Guide per OpenStack service (excluding Identity, perhaps?). The goal of this guide is to let the reader browse through a comprehensive set of use cases for the service. Organization of this guide will be more complex than that of the Getting Started Guide. Primarily, the guide should be organized such that it covers the common use cases first. This might not be straightforward, though, since other factors will also come into play: it might be helpful to introduce readers to concepts first, before delving into specific use cases that use those concepts; similarly, it might make sense to group use cases around the components of the service so there is less context-switching for the reader.

Finally, it is possible that a reader arrives at this guide without reading the corresponding Getting Started Guide first. Therefore the content in the Getting Started Guide may be duplicated in the Complete User Guide. Avoid the temptation to ''link'' the reader to the Getting Started Guide. Consider embedding it if possible instead. This gets the reader all their content on one page (i.e. no further clicks) as well as keeps it easily searchable (using Ctrl/Cmd-F for instance).

===Sample complete-user-guide.rst===
First, authenticate:
code snippet 1

Common use case #1
code snippet 2

[Download standalone PHP script for this example] -> links to <code>examples/object-store/create-container.php</code>

Common use case #2
code snippet 3

[Download standalone PHP script for this example] -> links to <code>examples/object-store/…</code>

==General Content Guidelines==
These guidelines are generally applicable when writing user-facing documentation for this project. They apply to the Getting Started Guides as well as the Complete User Guides.
* Use commonly-understood terms for services (e.g. Compute) instead of the OpenStack codename (e.g. Nova).
* Try to use well-understood projects when writing guides for a service (e.g. a blog project that could use Object Store to store its images) . This will reduce cognitive load on readers.
* Please make sure to document method parameters, especially if they are optional and therefore left out in the example code. Even better might be to link method calls in example code to phpdoc-generated documentation (but, at this point, I'm not entirely sure how to do this without being too distracting to the reader; some experimentation needed).

OpenStack-SDK-PHP/UserFacingDocumentation

2014-04-29T23:37:09Z

Shaunak Kashyap: /* Mock getting-started.rst (abbreviated) */

== Proposed Directory Structure==

At the top-most level (i.e., right under the project root directory), there will be two directories related to user-facing documentation: <code>doc</code> and <code>examples</code>. The <code>doc</code> directory will contain the actual user-facing documentation while the <code>examples</code> directory will contain standalone PHP scripts for individual tasks (such as creating a container). The documentation in the <code>doc</code> directory will reference the example scripts in the <code>examples</code> directory, letting the user download standalone, working versions of PHP code for examples shown in the documentation.

The <code>doc</code> directory will contain a <code>user-guides</code> subdirectory. This will contain Getting Started Guides and Complete User Guides for each OpenStack service. It will also contain a <code>_common</code> directory for any shared documentation snippets to be included from other documentation (for instance, documentation on authentication).

The <code>examples</code> directory will also contain subdirectories. These subdirectories will mirror those under <code>doc/user-guides</code>.

doc/
user-guides/
_common/
compute/
getting-started.rst
complete-user-guide.rst
object-store/
getting-started.rst
complete-user-guide.rst

examples/
compute/
object-store/
create-container.php

== Getting Started Guide Structure ==
There will be exactly one Getting Started Guide per OpenStack service (excluding Identity, perhaps?). The goal of this guide is to let the reader start using that service in a few minutes. As such, it should guide the user through a '''common''' and '''short''' use case for that service.

Finally, at the end of a Getting Started Guide, there should be a link to the Complete User Guide for the same service. This gives the reader a next step instead of a dead end.

===Sample getting-started.rst (abbreviated)===

First, authenticate:
code snippet 1

Then, do XXX.
code snippet 2

As a result of XXX, you will get so and so.

Then, do YYY.
code snippet 3

Then, do ZZZ.
code snippet 4

[Download standalone PHP script for this example] -> links to <code>examples/compute/getting-started.php</code>

Next Steps:
There's more you can do with QQQ service. To find out, read the [complete user guide] next.

==Complete User Guide Structure==
There will be exactly one Complete User Guide per OpenStack service (excluding Identity, perhaps?). The goal of this guide is to let the reader browse through a comprehensive set of use cases for the service. Organization of this guide will be more complex than that of the Getting Started Guide. Primarily, the guide should be organized such that it covers the common use cases first. This might not be straightforward, though, since other factors will also come into play: it might be helpful to introduce readers to concepts first, before delving into specific use cases that use those concepts; similarly, it might make sense to group use cases around the components of the service so there is less context-switching for the reader.

Finally, it is possible that a reader arrives at this guide without reading the corresponding Getting Started Guide first. Therefore the content in the Getting Started Guide may be duplicated in the Complete User Guide. Avoid the temptation to ''link'' the reader to the Getting Started Guide. Consider embedding it if possible instead. This gets the reader all their content on one page (i.e. no further clicks) as well as keeps it easily searchable (using Ctrl/Cmd-F for instance).

===Mock complete-user-guide.rst===
First, authenticate:
code snippet 1

Common use case #1
code snippet 2

[Download standalone PHP script for this example] -> links to <code>examples/object-store/create-container.php</code>

Common use case #2
code snippet 3

[Download standalone PHP script for this example] -> links to <code>examples/object-store/…</code>

==General Content Guidelines==
These guidelines are generally applicable when writing user-facing documentation for this project. They apply to the Getting Started Guides as well as the Complete User Guides.
* Use commonly-understood terms for services (e.g. Compute) instead of the OpenStack codename (e.g. Nova).
* Try to use well-understood projects when writing guides for a service (e.g. a blog project that could use Object Store to store its images) . This will reduce cognitive load on readers.
* Please make sure to document method parameters, especially if they are optional and therefore left out in the example code. Even better might be to link method calls in example code to phpdoc-generated documentation (but, at this point, I'm not entirely sure how to do this without being too distracting to the reader; some experimentation needed).

OpenStack-SDK-PHP/UserFacingDocumentation

2014-04-29T23:35:34Z

Shaunak Kashyap: s/samples/examples/

== Proposed Directory Structure==

At the top-most level (i.e., right under the project root directory), there will be two directories related to user-facing documentation: <code>doc</code> and <code>examples</code>. The <code>doc</code> directory will contain the actual user-facing documentation while the <code>examples</code> directory will contain standalone PHP scripts for individual tasks (such as creating a container). The documentation in the <code>doc</code> directory will reference the example scripts in the <code>examples</code> directory, letting the user download standalone, working versions of PHP code for examples shown in the documentation.

The <code>doc</code> directory will contain a <code>user-guides</code> subdirectory. This will contain Getting Started Guides and Complete User Guides for each OpenStack service. It will also contain a <code>_common</code> directory for any shared documentation snippets to be included from other documentation (for instance, documentation on authentication).

The <code>examples</code> directory will also contain subdirectories. These subdirectories will mirror those under <code>doc/user-guides</code>.

doc/
user-guides/
_common/
compute/
getting-started.rst
complete-user-guide.rst
object-store/
getting-started.rst
complete-user-guide.rst

examples/
compute/
object-store/
create-container.php

== Getting Started Guide Structure ==
There will be exactly one Getting Started Guide per OpenStack service (excluding Identity, perhaps?). The goal of this guide is to let the reader start using that service in a few minutes. As such, it should guide the user through a '''common''' and '''short''' use case for that service.

Finally, at the end of a Getting Started Guide, there should be a link to the Complete User Guide for the same service. This gives the reader a next step instead of a dead end.

===Mock getting-started.rst (abbreviated)===

First, authenticate:
code snippet 1

Then, do XXX.
code snippet 2

As a result of XXX, you will get so and so.

Then, do YYY.
code snippet 3

Then, do ZZZ.
code snippet 4

[Download standalone PHP script for this example] -> links to <code>examples/compute/getting-started.php</code>

Next Steps:
There's more you can do with QQQ service. To find out, read the [complete user guide] next.

==Complete User Guide Structure==
There will be exactly one Complete User Guide per OpenStack service (excluding Identity, perhaps?). The goal of this guide is to let the reader browse through a comprehensive set of use cases for the service. Organization of this guide will be more complex than that of the Getting Started Guide. Primarily, the guide should be organized such that it covers the common use cases first. This might not be straightforward, though, since other factors will also come into play: it might be helpful to introduce readers to concepts first, before delving into specific use cases that use those concepts; similarly, it might make sense to group use cases around the components of the service so there is less context-switching for the reader.

Finally, it is possible that a reader arrives at this guide without reading the corresponding Getting Started Guide first. Therefore the content in the Getting Started Guide may be duplicated in the Complete User Guide. Avoid the temptation to ''link'' the reader to the Getting Started Guide. Consider embedding it if possible instead. This gets the reader all their content on one page (i.e. no further clicks) as well as keeps it easily searchable (using Ctrl/Cmd-F for instance).

===Mock complete-user-guide.rst===
First, authenticate:
code snippet 1

Common use case #1
code snippet 2

[Download standalone PHP script for this example] -> links to <code>examples/object-store/create-container.php</code>

Common use case #2
code snippet 3

[Download standalone PHP script for this example] -> links to <code>examples/object-store/…</code>

==General Content Guidelines==
These guidelines are generally applicable when writing user-facing documentation for this project. They apply to the Getting Started Guides as well as the Complete User Guides.
* Use commonly-understood terms for services (e.g. Compute) instead of the OpenStack codename (e.g. Nova).
* Try to use well-understood projects when writing guides for a service (e.g. a blog project that could use Object Store to store its images) . This will reduce cognitive load on readers.
* Please make sure to document method parameters, especially if they are optional and therefore left out in the example code. Even better might be to link method calls in example code to phpdoc-generated documentation (but, at this point, I'm not entirely sure how to do this without being too distracting to the reader; some experimentation needed).

OpenStack-SDK-PHP/UserFacingDocumentation

2014-04-29T23:31:16Z

Shaunak Kashyap:

== Proposed Directory Structure==

At the top-most level (i.e., right under the project root directory), there will be two directories related to user-facing documentation: <code>doc</code> and <code>samples</code>. The <code>doc</code> directory will contain the actual user-facing documentation while the <code>samples</code> directory will contain standalone PHP scripts for individual tasks (such as creating a container). The documentation in the <code>doc</code> directory will reference the sample scripts in the <code>samples</code> directory, letting the user download standalone, working versions of PHP code for examples shown in the documentation.

The <code>doc</code> directory will contain a <code>user-guides</code> subdirectory. This will contain Getting Started Guides and Complete User Guides for each OpenStack service. It will also contain a <code>_common</code> directory for any shared documentation snippets to be included from other documentation (for instance, documentation on authentication).

The <code>samples</code> directory will also contain subdirectories. These subdirectories will mirror those under <code>doc/user-guides</code>.

doc/
user-guides/
_common/
compute/
getting-started.rst
complete-user-guide.rst
object-store/
getting-started.rst
complete-user-guide.rst

samples/
compute/
object-store/
create-container.php

== Getting Started Guide Structure ==
There will be exactly one Getting Started Guide per OpenStack service (excluding Identity, perhaps?). The goal of this guide is to let the reader start using that service in a few minutes. As such, it should guide the user through a '''common''' and '''short''' use case for that service.

Finally, at the end of a Getting Started Guide, there should be a link to the Complete User Guide for the same service. This gives the reader a next step instead of a dead end.

===Sample getting-started.rst (abbreviated)===

First, authenticate:
code snippet 1

Then, do XXX.
code snippet 2

As a result of XXX, you will get so and so.

Then, do YYY.
code snippet 3

Then, do ZZZ.
code snippet 4

[Download standalone PHP script for this example] -> links to <code>samples/compute/getting-started.php</code>

Next Steps:
There's more you can do with QQQ service. To find out, read the [complete user guide] next.

==Complete User Guide Structure==
There will be exactly one Complete User Guide per OpenStack service (excluding Identity, perhaps?). The goal of this guide is to let the reader browse through a comprehensive set of use cases for the service. Organization of this guide will be more complex than that of the Getting Started Guide. Primarily, the guide should be organized such that it covers the common use cases first. This might not be straightforward, though, since other factors will also come into play: it might be helpful to introduce readers to concepts first, before delving into specific use cases that use those concepts; similarly, it might make sense to group use cases around the components of the service so there is less context-switching for the reader.

Finally, it is possible that a reader arrives at this guide without reading the corresponding Getting Started Guide first. Therefore the content in the Getting Started Guide may be duplicated in the Complete User Guide. Avoid the temptation to ''link'' the reader to the Getting Started Guide. Consider embedding it if possible instead. This gets the reader all their content on one page (i.e. no further clicks) as well as keeps it easily searchable (using Ctrl/Cmd-F for instance).

===Sample complete-user-guide.rst===
First, authenticate:
code snippet 1

Common use case #1
code snippet 2

[Download standalone PHP script for this example] -> links to <code>samples/object-store/create-container.php</code>

Common use case #2
code snippet 3

[Download standalone PHP script for this example] -> links to <code>samples/object-store/…</code>

==General Content Guidelines==
These guidelines are generally applicable when writing user-facing documentation for this project. They apply to the Getting Started Guides as well as the Complete User Guides.
* Use commonly-understood terms for services (e.g. Compute) instead of the OpenStack codename (e.g. Nova).
* Try to use well-understood projects when writing guides for a service (e.g. a blog project that could use Object Store to store its images) . This will reduce cognitive load on readers.
* Please make sure to document method parameters, especially if they are optional and therefore left out in the sample code. Even better might be to link method calls in sample code to phpdoc-generated documentation (but, at this point, I'm not entirely sure how to do this without being too distracting to the reader; some experimentation needed).

OpenStack-SDK-PHP/UserFacingDocumentation

2014-04-29T23:30:54Z

Shaunak Kashyap: s/docs/doc/

== Proposed Directory Structure==

At the top-most level (i.e., right under the project root directory), there will be two directories related to user-facing documentation: <code>doc</code> and <code>samples</code>. The <code>doc</code> directory will contain the actual user-facing documentation while the <code>samples</code> directory will contain standalone PHP scripts for individual tasks (such as creating a container). The documentation in the <code>doc</code> directory will reference the sample scripts in the <code>samples</code> directory, letting the user download standalone, working versions of PHP code for examples shown in the documentation.

The <code>docs</code> directory will contain a <code>user-guides</code> subdirectory. This will contain Getting Started Guides and Complete User Guides for each OpenStack service. It will also contain a <code>_common</code> directory for any shared documentation snippets to be included from other documentation (for instance, documentation on authentication).

The <code>samples</code> directory will also contain subdirectories. These subdirectories will mirror those under <code>doc/user-guides</code>.

doc/
user-guides/
_common/
compute/
getting-started.rst
complete-user-guide.rst
object-store/
getting-started.rst
complete-user-guide.rst

samples/
compute/
object-store/
create-container.php

== Getting Started Guide Structure ==
There will be exactly one Getting Started Guide per OpenStack service (excluding Identity, perhaps?). The goal of this guide is to let the reader start using that service in a few minutes. As such, it should guide the user through a '''common''' and '''short''' use case for that service.

Finally, at the end of a Getting Started Guide, there should be a link to the Complete User Guide for the same service. This gives the reader a next step instead of a dead end.

===Sample getting-started.rst (abbreviated)===

First, authenticate:
code snippet 1

Then, do XXX.
code snippet 2

As a result of XXX, you will get so and so.

Then, do YYY.
code snippet 3

Then, do ZZZ.
code snippet 4

[Download standalone PHP script for this example] -> links to <code>samples/compute/getting-started.php</code>

Next Steps:
There's more you can do with QQQ service. To find out, read the [complete user guide] next.

==Complete User Guide Structure==
There will be exactly one Complete User Guide per OpenStack service (excluding Identity, perhaps?). The goal of this guide is to let the reader browse through a comprehensive set of use cases for the service. Organization of this guide will be more complex than that of the Getting Started Guide. Primarily, the guide should be organized such that it covers the common use cases first. This might not be straightforward, though, since other factors will also come into play: it might be helpful to introduce readers to concepts first, before delving into specific use cases that use those concepts; similarly, it might make sense to group use cases around the components of the service so there is less context-switching for the reader.

Finally, it is possible that a reader arrives at this guide without reading the corresponding Getting Started Guide first. Therefore the content in the Getting Started Guide may be duplicated in the Complete User Guide. Avoid the temptation to ''link'' the reader to the Getting Started Guide. Consider embedding it if possible instead. This gets the reader all their content on one page (i.e. no further clicks) as well as keeps it easily searchable (using Ctrl/Cmd-F for instance).

===Sample complete-user-guide.rst===
First, authenticate:
code snippet 1

Common use case #1
code snippet 2

[Download standalone PHP script for this example] -> links to <code>samples/object-store/create-container.php</code>

Common use case #2
code snippet 3

[Download standalone PHP script for this example] -> links to <code>samples/object-store/…</code>

==General Content Guidelines==
These guidelines are generally applicable when writing user-facing documentation for this project. They apply to the Getting Started Guides as well as the Complete User Guides.
* Use commonly-understood terms for services (e.g. Compute) instead of the OpenStack codename (e.g. Nova).
* Try to use well-understood projects when writing guides for a service (e.g. a blog project that could use Object Store to store its images) . This will reduce cognitive load on readers.
* Please make sure to document method parameters, especially if they are optional and therefore left out in the sample code. Even better might be to link method calls in sample code to phpdoc-generated documentation (but, at this point, I'm not entirely sure how to do this without being too distracting to the reader; some experimentation needed).

OpenStack-SDK-PHP/UserFacingDocumentation

2014-04-28T00:55:38Z

Shaunak Kashyap:

== Proposed Directory Structure==

At the top-most level (i.e., right under the project root directory), there will be two directories related to user-facing documentation: <code>docs</code> and <code>samples</code>. The <code>docs</code> directory will contain the actual user-facing documentation while the <code>samples</code> directory will contain standalone PHP scripts for individual tasks (such as creating a container). The documentation in the <code>docs</code> directory will reference the sample scripts in the <code>samples</code> directory, letting the user download standalone, working versions of PHP code for examples shown in the documentation.

The <code>docs</code> directory will contain a <code>user-guides</code> subdirectory. This will contain Getting Started Guides and Complete User Guides for each OpenStack service. It will also contain a <code>_common</code> directory for any shared documentation snippets to be included from other documentation (for instance, documentation on authentication).

The <code>samples</code> directory will also contain subdirectories. These subdirectories will mirror those under <code>docs/user-guides</code>.

docs/
user-guides/
_common/
compute/
getting-started.rst
complete-user-guide.rst
object-store/
getting-started.rst
complete-user-guide.rst

samples/
compute/
object-store/
create-container.php

== Getting Started Guide Structure ==
There will be exactly one Getting Started Guide per OpenStack service (excluding Identity, perhaps?). The goal of this guide is to let the reader start using that service in a few minutes. As such, it should guide the user through a '''common''' and '''short''' use case for that service.

Finally, at the end of a Getting Started Guide, there should be a link to the Complete User Guide for the same service. This gives the reader a next step instead of a dead end.

===Sample getting-started.rst (abbreviated)===

First, authenticate:
code snippet 1

Then, do XXX.
code snippet 2

As a result of XXX, you will get so and so.

Then, do YYY.
code snippet 3

Then, do ZZZ.
code snippet 4

[Download standalone PHP script for this example] -> links to <code>samples/compute/getting-started.php</code>

Next Steps:
There's more you can do with QQQ service. To find out, read the [complete user guide] next.

==Complete User Guide Structure==
There will be exactly one Complete User Guide per OpenStack service (excluding Identity, perhaps?). The goal of this guide is to let the reader browse through a comprehensive set of use cases for the service. Organization of this guide will be more complex than that of the Getting Started Guide. Primarily, the guide should be organized such that it covers the common use cases first. This might not be straightforward, though, since other factors will also come into play: it might be helpful to introduce readers to concepts first, before delving into specific use cases that use those concepts; similarly, it might make sense to group use cases around the components of the service so there is less context-switching for the reader.

Finally, it is possible that a reader arrives at this guide without reading the corresponding Getting Started Guide first. Therefore the content in the Getting Started Guide may be duplicated in the Complete User Guide. Avoid the temptation to ''link'' the reader to the Getting Started Guide. Consider embedding it if possible instead. This gets the reader all their content on one page (i.e. no further clicks) as well as keeps it easily searchable (using Ctrl/Cmd-F for instance).

===Sample complete-user-guide.rst===
First, authenticate:
code snippet 1

Common use case #1
code snippet 2

[Download standalone PHP script for this example] -> links to <code>samples/object-store/create-container.php</code>

Common use case #2
code snippet 3

[Download standalone PHP script for this example] -> links to <code>samples/object-store/…</code>

==General Content Guidelines==
These guidelines are generally applicable when writing user-facing docs for this project. They apply to the Getting Started Guides as well as the Complete User Guides.
* Use commonly-understood terms for services (e.g. Compute) instead of the OpenStack codename (e.g. Nova).
* Try to use well-understood projects when writing guides for a service (e.g. a blog project that could use Object Store to store its images) . This will reduce cognitive load on readers.
* Please make sure to document method parameters, especially if they are optional and therefore left out in the sample code. Even better might be to link method calls in sample code to phpdoc-generated documentation (but, at this point, I'm not entirely sure how to do this without being too distracting to the reader; some experimentation needed).

OpenStack-SDK-PHP/UserFacingDocumentation

2014-04-28T00:51:47Z

Shaunak Kashyap:

== Proposed Directory Structure==

At the top-most level (i.e., right under the project root directory), there will be two directories related to user-facing documentation: <code>docs</code> and <code>samples</code>. The <code>docs</code> directory will contain the actual user-facing documentation while the <code>samples</code> directory will contain standalone PHP scripts for individual tasks (such as creating a container). The documentation in the <code>docs</code> directory will reference the sample scripts in the <code>samples</code> directory, letting the user download standalone, working versions of PHP code for examples shown in the documentation.

The <code>docs</code> directory will contain a <code>user-guides</code> subdirectory. This will contain Getting Started Guides and Complete User Guides for each OpenStack service. It will also contain a <code>_common</code> directory for any shared documentation snippets to be included from other documentation (for instance, documentation on authentication).

The <code>samples</code> directory will also contain subdirectories. These subdirectories will mirror those under <code>docs/user-guides</code>.

docs/
user-guides/
_common/
compute/
getting-started.rst
complete-user-guide.rst
object-store/
getting-started.rst
complete-user-guide.rst

samples/
compute/
object-store/
create-container.php

== Getting Started Guide Structure ==
There will be exactly one Getting Started Guide per OpenStack service (excluding Identity, perhaps?). The goal of this guide is to let the reader start using that service in a few minutes. As such, it should guide the user through a '''common''' and '''short''' use case for that service.

Finally, at the end of a Getting Started Guide, there should be a link to the Complete User Guide for the same service. This gives the reader a next step instead of a dead end.

===Sample getting-started.rst (abbreviated)===

First, authenticate:
code snippet 1

Then, do XXX.
code snippet 2

As a result of XXX, you will get so and so.

Then, do YYY.
code snippet 3

Then, do ZZZ.
code snippet 4

[Download standalone PHP script for this example] -> links to <code>samples/compute/getting-started.php</code>

Next Steps:
There's more you can do with QQQ service. To find out, read the [complete user guide] next.

==Complete User Guide Structure==
There will be exactly one Complete User Guide per OpenStack service (excluding Identity, perhaps?). The goal of this guide is to let the reader browse through a comprehensive set of use cases for the service. Organization of this guide will be more complex than that of the Getting Started Guide. Primarily, the guide should be organized such that it covers the common use cases first. This might not be straightforward, though, since other factors will also come into play: it might be helpful to introduce readers to concepts first, before delving into specific use cases that use those concepts; similarly, it might make sense to group use cases around the components of the service so there is less context-switching for the reader.

Finally, it is possible that a reader arrives at this guide without reading the corresponding Getting Started Guide first. Therefore the content in the Getting Started Guide may be duplicated in the Complete User Guide. Avoid the temptation to ''link'' the reader to the Getting Started Guide. Consider embedding it if possible instead. This gets the reader all their content on one page (i.e. no further clicks) as well as keeps it easily searchable (using Ctrl/Cmd-F for instance).

===Sample complete-user-guide.rst===
First, authenticate:
code snippet 1

Common use case #1
code snippet 2

[Download standalone PHP script for this example] -> links to <code>samples/object-store/create-container.php</code>

Common use case #2
code snippet 3

[Download standalone PHP script for this example] -> links to <code>samples/object-store/…</code>

==General Content Guidelines==
These guidelines are generally applicable when writing user-facing docs for this project. They apply to the Getting Started Guides as well as the Complete User Guides.
* Try to use a consistent commonly-known theme (e.g. a contrived blog project) throughout each service's GetiComplete User Guide. This will reduce cognitive load on readers.
* Use commonly-understood terms for services (e.g. Compute) instead of the OpenStack codename (e.g. Nova).
* Please make sure to document method parameters, especially if they are optional and therefore left out in the sample code. Even better might be to link method calls in sample code to phpdoc-generated documentation (but, at this point, I'm not entirely sure how to do this without being too distracting to the reader; some experimentation needed).

OpenStack-SDK-PHP/UserFacingDocumentation

2014-04-28T00:17:51Z

Shaunak Kashyap: Initial content

== Proposed Directory Structure==

At the top-most level (i.e., right under the project root directory), there will be two directories related to user-facing documentation: <code>docs</code> and <code>samples</code>. The <code>docs</code> directory will contain the actual user-facing documentation while the <code>samples</code> directory will contain standalone PHP scripts for individual tasks (such as creating a container). The documentation in the <code>docs</code> directory will reference the sample scripts in the <code>samples</code> directory, letting the user download standalone, working versions of PHP code for examples shown in the documentation.

The <code>docs</code> directory will contain a <code>user-guides</code> subdirectory. This will contain Getting Started Guides and Complete User Guides for each OpenStack service. It will also contain a <code>_common</code> directory for any shared documentation snippets to be included from other documentation (for instance, documentation on authentication).

The <code>samples</code> directory will also contain subdirectories. These subdirectories will mirror those under <code>docs/user-guides</code>.

docs/
user-guides/
_common/
compute/
getting-started.rst
complete-user-guide.rst
object-store/
getting-started.rst
complete-user-guide.rst

samples/
compute/
object-store/
create-container.php

== Getting Started Guide Structure ==
There will be exactly one Getting Started Guide per OpenStack service (excluding Identity, perhaps?). The goal of this guide is to let the reader start using that service in a few minutes. As such, it should guide the user through a '''common''' and '''short''' use case for that service.

Finally, at the end of a Getting Started Guide, there should be a link to the Complete User Guide for the same service. This gives the reader a next step instead of a dead end.

===Sample getting-started.rst (abbreviated)===

First, authenticate:
code snippet 1

Then, do XXX.
code snippet 2

As a result of XXX, you will get so and so.

Then, do YYY.
code snippet 3

Then, do ZZZ.
code snippet 4

[Download standalone PHP script for this example] -> links to <code>samples/compute/getting-started.php</code>

Next Steps:
There's more you can do with QQQ service. To find out, read the [complete user guide] next.

==Complete User Guide Structure==
There will be exactly one Complete User Guide per OpenStack service (excluding Identity, perhaps?). The goal of this guide is to let the reader browse through a comprehensive set of use cases for the service. Organization of this guide will be more complex than that of the Getting Started Guide. Primarily, the guide should be organized such that it covers the common use cases first. This might not be straightforward, though, since other factors will also come into play: it might be helpful to introduce readers to concepts first, before delving into specific use cases that use those concepts; similarly, it might make sense to group use cases around the components of the service so there is less context-switching for the reader.

Try to use a consistent commonly-known theme (e.g. a contrived blog project) throughout each service's Complete User Guide. This will reduce cognitive load on readers.

Please make sure to document method parameters, especially if they are optional and therefore left out in the sample code. Even better might be to link method calls in sample code to phpdoc-generated documentation (but, at this point, I'm not entirely sure how to do this without being too distracting to the reader; some experimentation needed).

Finally, It is possible that a reader arrives at this guide without reading the corresponding Getting Started Guide first. Therefore the content in the Getting Started Guide may be duplicated in the Complete User Guide. Avoid the temptation to ''link'' the reader to the Getting Started Guide. Consider embedding it if possible instead. This gets the reader all their content on one page (i.e. no further clicks) as well as keeps it easily searchable (using Ctrl/Cmd-F for instance).

===Sample complete-user-guide.rst===
First, authenticate:
code snippet 1

Common use case #1
code snippet 2

[Download standalone PHP script for this example] -> links to <code>samples/object-store/create-container.php</code>

Common use case #2
code snippet 3

[Download standalone PHP script for this example] -> links to <code>samples/object-store/…</code>

OpenStack-SDK-PHP/UserFacingDocumentation

2014-04-23T15:51:30Z

Shaunak Kashyap: Created page with "To be fleshed out by Shaunak"

To be fleshed out by Shaunak

Meetings

2014-03-26T17:19:15Z

Shaunak Kashyap: Fixing closing code tag

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> and <code><nowiki>#openstack-meeting-3</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 Project & Release Status meeting ==
* Weekly on Tuesdays at 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): [[ThierryCarrez]]
* See [[Meetings/ProjectMeeting]] 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 [[Governance/TechnicalCommittee]] for details

== OpenStack Compute (Nova) ==
=== Nova team Meeting ===
* Weekly on Thursdays, alternating times - 1400 UTC and 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> (1400 UTC)
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code> (2100 UTC)
* Chair (to contact for more information): Russell Bryant
* 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)

=== 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: [[ShawnHartsock]]
* 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: #openstack-meeting-alt
* 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

== 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: #openstack-meeting
* 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 Thursdays at 2pm Pacific (will track daylight savings time) - now at 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chairs (to contact for more information): Rob "zehicle" Hirschfeld & Joshua McKenty
* See [[Meetings/DefCore]] for an agenda

Face to Face Meetings planned (Piston HQ in SFO)
* Friday 3/28 1pm for Web Front Page
* Tuesday 4/15 10am for general working session

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

== State management team meeting ==
* Weekly on Thursdays at 2000 UTC (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130502T2000)
* 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): [[DolphMathews]]
* See [[Meetings/KeystoneMeeting]] for an agenda

== Ironic (Bare Metal) team meeting ==
* Weekly on Mondays at 1900 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more infomation) Devananda van der Veen
* see [[Meetings/Ironic]] for agenda

== TripleO team meeting ==
* Weekly on Tuesdays at 1900 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more infomation) Robert Collins (lifeless)
* see [[Meetings/TripleO]] for agenda

== OpenStack Networking (Neutron) ==
=== Neutron team meeting ===
* Weekly on Mondays at 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more infomation) Mark McClain
* see [[Network/Meetings]] for agenda

=== LBaaS meeting ===
* Weekly on Thursdays at 1400 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more infomation) enikanorov (Eugene Nikanorov)
* see [[Network/LBaaS]] 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): mestery (Kyle Mestery)
* 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' Common requirements team meeting ===
* Weekly on Wednesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenStack+Neutron+Adv+Services+IRC&iso=20140326T1730&p1=1440&ah=1 1730 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-3</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 1400 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: sc68cal (Sean M. Collins)
* See [[Meetings/Neutron-IPv6-Subteam]] for details

=== Neutron Group Policy Sub-Team Meeting ===
* Weekly on Thursdays at 1900 UTC
* IRC channel: #openstack-meeting-alt
* Chair: mestery (Kyle Mestery)
* 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: #openstack-meeting
* 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 Tuesdays at 500UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: yamahata (Isaku Yamahata)
* Agenda: See [[Meetings/ServiceVM]]

== 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 ==
* Even weeks on Thursdays at 1500 UTC.
* Odd weeks on Wednesdays at 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by jd__ (Julien Danjou)
* 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): Michael Basnight (hub_cap) / Vipul Sabhaya (vipul) / Nikhil Manchanda (SlickNik) / Tim Simpson (grapex)
* See [[Meetings/TroveMeeting]] for details

== Marconi (queues) team meeting ==
* Weekly on Tuesday at 1500 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: kgriffs (Kurt Griffiths)
* See [[Meetings/Marconi]] for details

== Savanna 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/SavannaAgenda]] 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: Georgiy Okrokvertskhov (Georgy_Ok)
* See [[Meetings/MuranoAgenda]] for details

== Heat (orchestration) team meeting ==
* Weekly on Wednesdays at 2000 UTC in <code><nowiki>#openstack-meeting</nowiki></code> or Thursdays at 0000 UTC in <code><nowiki>#openstack-meeting-alt</nowiki></code> (alternate weeks)
* Chair (to contact for more information): Steve Baker (stevebaker)
* See [[Meetings/HeatAgenda]] for details

== Horizon team meeting ==
* Weekly on Tuesdays at 1600 UTC
* 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 1800 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): bdpayne (Bryan Payne)
* 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/2000 UTC (alternating)
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more information): markwash (Mark Washenberger)
* See [[Meetings/Glance]] for details

== Oslo Team meeting ==
* On demand on Fridays at 1400 UTC (see [http://www.doodle.com/vbs7ux7m4pa3c6c5 this doodle])
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): dhellmann (Doug Hellmann)
* See [[Meetings/Oslo]] for details

== OpenStack Community team meeting ==
* Weekly on Wednesday at [http://www.worldclock.com/world_clock.html 2300 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: reed ([http://www.openstack.org/community/members/profile/1372 Stefano Maffulli])
* See [[Meetings/Community]] for details

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

== Training-manuals Team meeting ==
* Weekly on Monday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 1700 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: sarob
* See [[Meetings/training-manuals]] 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

== Stackalytics team meeting ==
* Be-Weekly on Mondays (starting from October 21st) at [http://www.worldclock.com/world_clock.html 1500 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: ilyashakhat (Ilya Shakhat)
* See [[Meetings/Stackalytics]] for details

== Climate (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/Climate]] 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 [http://www.worldclock.com/world_clock.html 1600 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: adrian_otto (Adrian Otto)
* See [[Meetings/Solum]] for details

== Congress Team Meeting ==
* Bi-weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1700 UTC], e.g. Feb 25, 2014
* IRC channel: #openstack-meeting-3
* Chair: pballand (Pete Balland)
* 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 meeting ==
* Weekly on Mondays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-chef</nowiki></code>
* Chair: mattray (Matt Ray)
* See [[Meetings/ChefCookbook]] for details

== Milk Meeting ==
* Weekly on Monday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 2000 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: sarob
* See [[Meetings/milk]] for details

== StoryBoard Meeting ==
* Weekly on Thursdays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: cody-somerville or ttx
* See [[StoryBoard]] for details

== Hierarchical Multitenancy Meeting ==
* Weekly on Fridays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: vishy
* See [[HierarchicalMultitenancy]] 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 OpenStack CI Workshop and Q&A Meetings ==
* Weekly on Mondays at 1800 UTC starting March 3rd, 2014
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: JayPipes

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

== PHP SDK Team Meeting ==
* Weekly on Wednesdays at 1530 UTC
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair: mfer
* See [[OpenStack-SDK-PHP]] for details

Meetings

2014-03-26T17:18:49Z

Shaunak Kashyap: Adding PHP SDK 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> and <code><nowiki>#openstack-meeting-3</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 Project & Release Status meeting ==
* Weekly on Tuesdays at 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): [[ThierryCarrez]]
* See [[Meetings/ProjectMeeting]] 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 [[Governance/TechnicalCommittee]] for details

== OpenStack Compute (Nova) ==
=== Nova team Meeting ===
* Weekly on Thursdays, alternating times - 1400 UTC and 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> (1400 UTC)
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code> (2100 UTC)
* Chair (to contact for more information): Russell Bryant
* 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)

=== 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: [[ShawnHartsock]]
* 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: #openstack-meeting-alt
* 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

== 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: #openstack-meeting
* 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 Thursdays at 2pm Pacific (will track daylight savings time) - now at 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chairs (to contact for more information): Rob "zehicle" Hirschfeld & Joshua McKenty
* See [[Meetings/DefCore]] for an agenda

Face to Face Meetings planned (Piston HQ in SFO)
* Friday 3/28 1pm for Web Front Page
* Tuesday 4/15 10am for general working session

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

== State management team meeting ==
* Weekly on Thursdays at 2000 UTC (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130502T2000)
* 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): [[DolphMathews]]
* See [[Meetings/KeystoneMeeting]] for an agenda

== Ironic (Bare Metal) team meeting ==
* Weekly on Mondays at 1900 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more infomation) Devananda van der Veen
* see [[Meetings/Ironic]] for agenda

== TripleO team meeting ==
* Weekly on Tuesdays at 1900 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more infomation) Robert Collins (lifeless)
* see [[Meetings/TripleO]] for agenda

== OpenStack Networking (Neutron) ==
=== Neutron team meeting ===
* Weekly on Mondays at 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more infomation) Mark McClain
* see [[Network/Meetings]] for agenda

=== LBaaS meeting ===
* Weekly on Thursdays at 1400 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more infomation) enikanorov (Eugene Nikanorov)
* see [[Network/LBaaS]] 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): mestery (Kyle Mestery)
* 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' Common requirements team meeting ===
* Weekly on Wednesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenStack+Neutron+Adv+Services+IRC&iso=20140326T1730&p1=1440&ah=1 1730 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-3</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 1400 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: sc68cal (Sean M. Collins)
* See [[Meetings/Neutron-IPv6-Subteam]] for details

=== Neutron Group Policy Sub-Team Meeting ===
* Weekly on Thursdays at 1900 UTC
* IRC channel: #openstack-meeting-alt
* Chair: mestery (Kyle Mestery)
* 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: #openstack-meeting
* 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 Tuesdays at 500UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: yamahata (Isaku Yamahata)
* Agenda: See [[Meetings/ServiceVM]]

== 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 ==
* Even weeks on Thursdays at 1500 UTC.
* Odd weeks on Wednesdays at 2100 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by jd__ (Julien Danjou)
* 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): Michael Basnight (hub_cap) / Vipul Sabhaya (vipul) / Nikhil Manchanda (SlickNik) / Tim Simpson (grapex)
* See [[Meetings/TroveMeeting]] for details

== Marconi (queues) team meeting ==
* Weekly on Tuesday at 1500 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: kgriffs (Kurt Griffiths)
* See [[Meetings/Marconi]] for details

== Savanna 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/SavannaAgenda]] 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: Georgiy Okrokvertskhov (Georgy_Ok)
* See [[Meetings/MuranoAgenda]] for details

== Heat (orchestration) team meeting ==
* Weekly on Wednesdays at 2000 UTC in <code><nowiki>#openstack-meeting</nowiki></code> or Thursdays at 0000 UTC in <code><nowiki>#openstack-meeting-alt</nowiki></code> (alternate weeks)
* Chair (to contact for more information): Steve Baker (stevebaker)
* See [[Meetings/HeatAgenda]] for details

== Horizon team meeting ==
* Weekly on Tuesdays at 1600 UTC
* 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 1800 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): bdpayne (Bryan Payne)
* 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/2000 UTC (alternating)
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more information): markwash (Mark Washenberger)
* See [[Meetings/Glance]] for details

== Oslo Team meeting ==
* On demand on Fridays at 1400 UTC (see [http://www.doodle.com/vbs7ux7m4pa3c6c5 this doodle])
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): dhellmann (Doug Hellmann)
* See [[Meetings/Oslo]] for details

== OpenStack Community team meeting ==
* Weekly on Wednesday at [http://www.worldclock.com/world_clock.html 2300 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: reed ([http://www.openstack.org/community/members/profile/1372 Stefano Maffulli])
* See [[Meetings/Community]] for details

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

== Training-manuals Team meeting ==
* Weekly on Monday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 1700 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: sarob
* See [[Meetings/training-manuals]] 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

== Stackalytics team meeting ==
* Be-Weekly on Mondays (starting from October 21st) at [http://www.worldclock.com/world_clock.html 1500 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: ilyashakhat (Ilya Shakhat)
* See [[Meetings/Stackalytics]] for details

== Climate (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/Climate]] 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 [http://www.worldclock.com/world_clock.html 1600 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: adrian_otto (Adrian Otto)
* See [[Meetings/Solum]] for details

== Congress Team Meeting ==
* Bi-weekly on Tuesdays at [http://www.worldclock.com/world_clock.html 1700 UTC], e.g. Feb 25, 2014
* IRC channel: #openstack-meeting-3
* Chair: pballand (Pete Balland)
* 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 meeting ==
* Weekly on Mondays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-chef</nowiki></code>
* Chair: mattray (Matt Ray)
* See [[Meetings/ChefCookbook]] for details

== Milk Meeting ==
* Weekly on Monday at [http://www.worldclock.com/current-local-time-in-san-francisco_598.htm 2000 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: sarob
* See [[Meetings/milk]] for details

== StoryBoard Meeting ==
* Weekly on Thursdays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: cody-somerville or ttx
* See [[StoryBoard]] for details

== Hierarchical Multitenancy Meeting ==
* Weekly on Fridays at 1600 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: vishy
* See [[HierarchicalMultitenancy]] 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 OpenStack CI Workshop and Q&A Meetings ==
* Weekly on Mondays at 1800 UTC starting March 3rd, 2014
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: JayPipes

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

== PHP SDK Team Meeting ==
* Weekly on Wednesdays at 1530 UTC
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki><code>
* Chair: mfer
* See [[OpenStack-SDK-PHP]] for details

OpenStack-SDK-PHP/TechnicalRequirements

2014-03-19T12:59:27Z

Shaunak Kashyap: Added sub-section on releases

== Requirements ==

=== Top-level objectives ===

==== Ease of installation ====

* Composer/Packagist package (Priority 1)
* PHAR file (Priority 2)

PEAR and Linux packages are not currently part of the requirements. If someone believes one of them should be handled please file a blueprint and make a case.

==== Ease of use ====

* Human-readable service names: minimize usage of OpenStack codenames
* Well-written and highly accessible end-user documentation that strives to be as comprehensive and helpful as possible
** Assumption-free documention, capable of expressing a concept soundly to both novices and experts
** Quick start guides for every service, starting with most popular ones
** Consistent use of code samples [''Discussion point:'' could we store these as sample files in GitHub or as gists and then include them from within the documentation?]
** API documentation
** PHP docblock annotations
* A simple API that minimizes complexity and vendor differences
* Multiple forums to make announcements and answer queries:
** GitHub issues
** IRC
** -users@ mailing list [''Discussion point:'' should this be different from the contributors mailing list (see section on contributing below)?]
** Twitter account (similar to https://twitter.com/awsforphp)

==== Ease of contributing ====

* Community-driven decisions with full feedback and transparency
* A CONTRIBUTING guide, encouraging all forms of engagement
* Active on irc channels
* A mailing list
* Google Hangout meetings

=== Technical requirements ===

==== HTTP transport layer ====

* Support for all HTTP request methods, including custom ones
* Requests, responses, headers and URLs can be easily accessed and editable (i.e. they serve as objects)
* Persistent connections
* Connection pooling
* Parallelization with multi-cURL
* Request bodies are handled as streams rather than strings - to avoid in-memory storage
** Ability to register a Swift stream wrapper, so that native filesystem functions can be utilized
** Perhaps the ability to use `swift://` protocol
* Flexible authentication
* Auth caching
* Multiple connection types offered through adapters: cURL, sockets, test/mock
* Redirect handling
* SSL support
* Retry strategies (in response to cURL/HTTP errors, throttling, etc.)

==== Service layer ====

===== General =====

* Support for multiple service versions, easily selected by an end-user

* The core library will contain common functionality essential to the running of a pure OpenStack installation

===== Extensions =====

* Extensions, whether vendor-specific or not, need to be handled appropriately. There is a strong argument for extracting this supplementary functionality from the core library and placing it in other namespaces (or repositories)

* ''Discussion point:'' Need to agree where to place / how to structure vendor extensions

===== Service clients =====

* ''Discussion point:'' Need to agree whether each service will act as its own client, or whether a more global context will be used.

* ''Discussion point:'' Need to agree the best way to define API services (json-schema, Guzzle DSL, userland code)

* ''Discussion point:'' Need to agree the best way to create or marshall service objects from their descriptions - i.e. some form of service container

===== API concepts =====

* We should objectify and properly abstract the basic concepts of a ReSTful API. For example: a service is composed of Resources
** Each resource has state and is expressed through properties.
*** ''Discussion point:'' How strict should we be with API resource properties?
** Each resource can be modified with ReSTful operations. Each operation is composed of the following:
*** A HTTP method
*** A URL (absolute or relative)
*** Parameters (key/val array)
*** A description
*** A definition of how its response will be parsed

==== Miscellaneous ====

===== Events =====
* We should use Event dispatching to expose all moments of a request's lifecycle to the end-user. This allows them to add in or modify functionality as it suits them, rather than them having to extend and override main classes.
* We should think about what "events" are most important for an end-user: request.before_send, request.sent, request.error, curl.progress, etc.

===== Iterators =====
* We should support iterators and request-based append functionality.
* We should make this as consistent as possible and hide any underlying inconsistencies.
* We should also utilize native SPL iterators where possible.

===== Waiters =====
* Ability for users to "wait for" an operation to achieve some state. For example, a user may want to wait until a Nova instance has finished building before continuing with their script.
* This should be easy for an end-user to work with

===== Error handling =====

* Error messages need to be as descriptive and helpful as possible. We should not expose them to an API message or HTTP status code.

* ''Discussion point:'' Need to agree about how to use exception classes

=== Workflow/methodology ===

==== Standardisation ====
* PSR-2 coding style
* PSR-3 logging interface
* PSR-4 autoloading

==== Documentation ====
''Discussion point:'' Need to discuss what technology or tooling we will use to write our end-user documentation - i.e. Sphinx, markup
''Discussion point:'' Need to decide how to host our documentation - i.e. [https://readthedocs.org/ Read the Docs] or OpenStack domain

==== Testing ====

===== Methodology =====
''Discussion point:'' Need to decide our testing methodology.

===== Tooling =====

''Discussion point:'' Need to decide our testing tool.

===== Continuous integration =====
* Travis?
OpenStack has its own continuous integration framework, but we can probably use Travis in addition to that.

==== Releases ====
* ''Discussion point'': When should we cut new releases? Should these be time-based or milestone-based?

OpenStack-SDK-PHP/TechnicalRequirements

2014-03-07T16:39:45Z

Shaunak Kashyap: Adding discussion/announcement forums in ease of use

OpenStack-SDK-PHP/TechnicalRequirements

2014-03-07T16:27:54Z

Shaunak Kashyap: Fixing formatting

== Requirements ==

=== Top-level objectives ===

==== Ease of installation ====

* Composer/Packagist package (Priority 1)
* PHAR file (Priority 2)

PEAR and Linux packages are not currently part of the requirements. If someone believes one of them should be handled please file a blueprint and make a case.

==== Ease of use ====

* Human-readable service names: minimize usage of OpenStack codenames
* Well-written and highly accessible end-user documentation that strives to be as comprehensive and helpful as possible
** Assumption-free documention, capable of expressing a concept soundly to both novices and experts
** Quick start guides for every service, starting with most popular ones
** Consistent use of code samples [''Discussion point:'' could we store these as sample files in GitHub or as gists and then include them from within the documentation?]
** API documentation
** PHP docblock annotations
* A simple API that minimizes complexity and vendor differences

==== Ease of contributing ====

* Community-driven decisions with full feedback and transparency
* A CONTRIBUTING guide, encouraging all forms of engagement
* Active on irc channels
* A mailing list
* Google Hangout meetings

=== Technical requirements ===

==== HTTP transport layer ====

* Support for all HTTP request methods, including custom ones
* Requests, responses, headers and URLs can be easily accessed and editable (i.e. they serve as objects)
* Persistent connections
* Connection pooling
* Parallelization with multi-cURL
* Request bodies are handled as streams rather than strings - to avoid in-memory storage
** Ability to register a Swift stream wrapper, so that native filesystem functions can be utilized
** Perhaps the ability to use `swift://` protocol
* Flexible authentication
* Auth caching
* Multiple connection types offered through adapters: cURL, sockets, test/mock
* Redirect handling
* SSL support
* Retry strategies (in response to cURL/HTTP errors, throttling, etc.)

==== Service layer ====

===== General =====

* Support for multiple service versions, easily selected by an end-user

* The core library will contain common functionality essential to the running of a pure OpenStack installation

===== Extensions =====

* Extensions, whether vendor-specific or not, need to be handled appropriately. There is a strong argument for extracting this supplementary functionality from the core library and placing it in other namespaces (or repositories)

* ''Discussion point:'' Need to agree where to place / how to structure vendor extensions

===== Service clients =====

* ''Discussion point:'' Need to agree whether each service will act as its own client, or whether a more global context will be used.

* ''Discussion point:'' Need to agree the best way to define API services (json-schema, Guzzle DSL, userland code)

* ''Discussion point:'' Need to agree the best way to create or marshall service objects from their descriptions - i.e. some form of service container

===== API concepts =====

* We should objectify and properly abstract the basic concepts of a ReSTful API. For example: a service is composed of Resources
** Each resource has state and is expressed through properties.
*** ''Discussion point:'' How strict should we be with API resource properties?
** Each resource can be modified with ReSTful operations. Each operation is composed of the following:
*** A HTTP method
*** A URL (absolute or relative)
*** Parameters (key/val array)
*** A description
*** A definition of how its response will be parsed

==== Miscellaneous ====

===== Events =====
* We should use Event dispatching to expose all moments of a request's lifecycle to the end-user. This allows them to add in or modify functionality as it suits them, rather than them having to extend and override main classes.
* We should think about what "events" are most important for an end-user: request.before_send, request.sent, request.error, curl.progress, etc.

===== Iterators =====
* We should support iterators and request-based append functionality.
* We should make this as consistent as possible and hide any underlying inconsistencies.
* We should also utilize native SPL iterators where possible.

===== Waiters =====
* Ability for users to "wait for" an operation to achieve some state. For example, a user may want to wait until a Nova instance has finished building before continuing with their script.
* This should be easy for an end-user to work with

===== Error handling =====

* Error messages need to be as descriptive and helpful as possible. We should not expose them to an API message or HTTP status code.

* ''Discussion point:'' Need to agree about how to use exception classes

=== Workflow/methodology ===

==== Standardisation ====
* PSR-2 coding style
* PSR-3 logging interface
* PSR-4 autoloading

==== Documentation ====
''Discussion point:'' Need to discuss what technology or tooling we will use to write our end-user documentation - i.e. Sphinx, markup
''Discussion point:'' Need to decide how to host our documentation - i.e. [https://readthedocs.org/ Read the Docs] or OpenStack domain

==== Testing ====

===== Methodology =====
''Discussion point:'' Need to decide our testing methodology.

===== Tooling =====

''Discussion point:'' Need to decide our testing tool.

===== Continuous integration =====
* Travis?

OpenStack-SDK-PHP/TechnicalRequirements

2014-03-07T16:27:35Z

Shaunak Kashyap: Added quick start guide, discussion point on code samples

== Requirements ==

=== Top-level objectives ===

==== Ease of installation ====

* Composer/Packagist package (Priority 1)
* PHAR file (Priority 2)

PEAR and Linux packages are not currently part of the requirements. If someone believes one of them should be handled please file a blueprint and make a case.

==== Ease of use ====

* Human-readable service names: minimize usage of OpenStack codenames
* Well-written and highly accessible end-user documentation that strives to be as comprehensive and helpful as possible
** Assumption-free documention, capable of expressing a concept soundly to both novices and experts
** Quick start guides for every service, starting with most popular ones
** Consistent use of code samples [''Discussion point:'' could we store these as sample files in GitHub or as gists and then include them from within the documentation?']
** API documentation
** PHP docblock annotations
* A simple API that minimizes complexity and vendor differences

==== Ease of contributing ====

* Community-driven decisions with full feedback and transparency
* A CONTRIBUTING guide, encouraging all forms of engagement
* Active on irc channels
* A mailing list
* Google Hangout meetings

=== Technical requirements ===

==== HTTP transport layer ====

* Support for all HTTP request methods, including custom ones
* Requests, responses, headers and URLs can be easily accessed and editable (i.e. they serve as objects)
* Persistent connections
* Connection pooling
* Parallelization with multi-cURL
* Request bodies are handled as streams rather than strings - to avoid in-memory storage
** Ability to register a Swift stream wrapper, so that native filesystem functions can be utilized
** Perhaps the ability to use `swift://` protocol
* Flexible authentication
* Auth caching
* Multiple connection types offered through adapters: cURL, sockets, test/mock
* Redirect handling
* SSL support
* Retry strategies (in response to cURL/HTTP errors, throttling, etc.)

==== Service layer ====

===== General =====

* Support for multiple service versions, easily selected by an end-user

* The core library will contain common functionality essential to the running of a pure OpenStack installation

===== Extensions =====

* Extensions, whether vendor-specific or not, need to be handled appropriately. There is a strong argument for extracting this supplementary functionality from the core library and placing it in other namespaces (or repositories)

* ''Discussion point:'' Need to agree where to place / how to structure vendor extensions

===== Service clients =====

* ''Discussion point:'' Need to agree whether each service will act as its own client, or whether a more global context will be used.

* ''Discussion point:'' Need to agree the best way to define API services (json-schema, Guzzle DSL, userland code)

* ''Discussion point:'' Need to agree the best way to create or marshall service objects from their descriptions - i.e. some form of service container

===== API concepts =====

* We should objectify and properly abstract the basic concepts of a ReSTful API. For example: a service is composed of Resources
** Each resource has state and is expressed through properties.
*** ''Discussion point:'' How strict should we be with API resource properties?
** Each resource can be modified with ReSTful operations. Each operation is composed of the following:
*** A HTTP method
*** A URL (absolute or relative)
*** Parameters (key/val array)
*** A description
*** A definition of how its response will be parsed

==== Miscellaneous ====

===== Events =====
* We should use Event dispatching to expose all moments of a request's lifecycle to the end-user. This allows them to add in or modify functionality as it suits them, rather than them having to extend and override main classes.
* We should think about what "events" are most important for an end-user: request.before_send, request.sent, request.error, curl.progress, etc.

===== Iterators =====
* We should support iterators and request-based append functionality.
* We should make this as consistent as possible and hide any underlying inconsistencies.
* We should also utilize native SPL iterators where possible.

===== Waiters =====
* Ability for users to "wait for" an operation to achieve some state. For example, a user may want to wait until a Nova instance has finished building before continuing with their script.
* This should be easy for an end-user to work with

===== Error handling =====

* Error messages need to be as descriptive and helpful as possible. We should not expose them to an API message or HTTP status code.

* ''Discussion point:'' Need to agree about how to use exception classes

=== Workflow/methodology ===

==== Standardisation ====
* PSR-2 coding style
* PSR-3 logging interface
* PSR-4 autoloading

==== Documentation ====
''Discussion point:'' Need to discuss what technology or tooling we will use to write our end-user documentation - i.e. Sphinx, markup
''Discussion point:'' Need to decide how to host our documentation - i.e. [https://readthedocs.org/ Read the Docs] or OpenStack domain

==== Testing ====

===== Methodology =====
''Discussion point:'' Need to decide our testing methodology.

===== Tooling =====

''Discussion point:'' Need to decide our testing tool.

===== Continuous integration =====
* Travis?

SDK-Development

2014-03-04T18:58:44Z

Shaunak Kashyap: Adding link to PHP SDK

To enable application developers to build applications that use OpenStack, we need SDKs for each programming language (e.g., PHP, Go, Java) to provide them with what they need.

__TOC__

The purpose of this page is to work through how we go about building SDKs in a semi-consistent manner on the OpenStack infrastructure.

== What's in an SDK? ==

An SDK is more than just a set of APIs provided to you. A complete SDK provides a consumer focused API for interacting with the system, and it additionally includes:

* Documentation aimed at users consuming the SDK and system.
* Clear examples of usage, including functioning, executable examples.

== Audience ==
Application developers build applications that interact with OpenStack. Application developers are not OpenStack Operators or Developers. These are developers looking to consume a feature-rich OpenStack Cloud with its many services. These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.

== Goals for each SDK ==

# Support multiple API versions for each service (e.g., Keystone API v2 and v3).
# Use application developer friendly language in descriptions (e.g., Compute instead of Nova).
# Provide a manner to extend the services in the SDKs.
# Be written in a manner consistent with the language and platform they are for (e.g., A Java SDK shouldn't look like Python).
# Contain example code to get started.
# Contain documentation explaining how to get started and going with the SDKs and the services.
# Contain cross-linked class/module reference documentation.
# Contain a release history/change log documenting deprecations, new additions and bug fixes in the SDK (with links wherever possible).
# Handle OpenStack extensions in a graceful manner (e.g. you should be able to simply make a method call to determine if an OpenStack cloud supports a particular extension).
# Be open source and [http://opensource.com/life/14/1/evaluate-sustainability-open-source-project sustainable].
# Open source license must be compatible with Apache License v2?

== Non-Goals for each SDK ==

# While an SDK should provide working code examples showing usage of the SDK, it must '''not''' provide a complete end-user client (e.g. a CLI) implementation. Such an implementation belongs to a separate project that would depend on and use the appropriate SDK.

==SDK Projects==
# [[SDK-Development/PythonOpenStackSDK]]
# [[OpenStack-SDK-PHP]]

== Resources ==
Summit Design Sessions
# [https://etherpad.openstack.org/p/sdk-documentation SDK Documentation Discussion] at Grizzly Summit
# [https://etherpad.openstack.org/p/icehouse-doc-app-devs Documenting Application Developer Resources] at Icehouse Summit

== Example uses of an SDK ==
* Syncing objects between containers from two different providers. For example, syncing objects between a private and public cloud.
* Using object storage as a back end to store data or files within an application.
* Building a custom services management tool (e.g., a special purpose CLI or console).

SDK-Development

2014-02-08T08:32:57Z

Shaunak Kashyap: Adding non-goals

To enable application developers to build applications that use OpenStack, we need SDKs for each programming language (e.g., PHP, Go, Java) to provide them with what they need.

The purpose of this page is to work through how we go about building SDKs in a semi-consistent manner on the OpenStack infrastructure.

'''What's in an SDK?:'''

An SDK is more than just a set of APIs provided to you. A complete SDK provides a consumer focused API for interacting with the system, and it additionally includes:

* Documentation aimed at users consuming the SDK and system.
* Clear examples of usage, including functioning, executable examples.

== Audience ==
Application developers build applications that interact with OpenStack. Application developers are not OpenStack Operators or Developers. These are developers looking to consume a feature-rich OpenStack Cloud with its many services. These Developers require a consistent, single namespace API ("Application Programming Interface") that allows them to build and deploy their application with minimal dependencies.

== Goals for each SDK ==

# Support multiple API versions for each service (e.g., Keystone API v2 and v3).
# Use application developer friendly language in descriptions (e.g., Compute instead of Nova).
# Provide a manner to extend the services in the SDKs.
# Be written in a manner consistent with the language and platform they are for (e.g., A Java SDK shouldn't look like Python).
# Contain example code to get started.
# Contain documentation explaining how to get started and going with the SDKs and the services.
# Contain cross-linked class/module reference documentation.
# Contain a release history/change log documenting deprecations, new additions and bug fixes in the SDK (with links wherever possible).

== Non-Goals for each SDK ==

# While an SDK should provide working code examples showing usage of the SDK, it must '''not''' provide a complete end-user client (e.g. a CLI) implementation. Such an implementation belongs to a separate project that would depend on and use the appropriate SDK.

SDK-Development

2014-02-08T08:19:51Z

Shaunak Kashyap: Added class reference, change log

SDK-Development

2014-02-08T08:12:49Z

Shaunak Kashyap: Fixing minor typo