OpenStack - User contributions [en]

Design Summit/Mitaka/Etherpads

2015-10-26T22:54:16Z

Vipuls: /* Designate */

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

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

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

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

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

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

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

== Cross-Project workshops ==

All sessions are on Tuesday 2015-10-27

* 11:15
** Service Catalog TNG (double session) [https://etherpad.openstack.org/p/mitaka-service-catalog-session]
** Cycle themes [https://etherpad.openstack.org/p/mitaka-crossproject-themes]
* 12:05
** Supporting DefCore and Interoperability Testing [https://etherpad.openstack.org/p/mitaka-crossproject-defcore]
** Tags today and tomorrow [https://etherpad.openstack.org/p/mitaka-crossproject-next-tags]
* 14:00
** Standard Deprecation Policy [https://etherpad.openstack.org/p/mitaka-deprecation-policy]
* 14:50
** Role Assignments for Service users [https://etherpad.openstack.org/p/mitaka-cross-project-role-assignment-service-user]
* 15:40
** Documenting the OpenStack way [https://etherpad.openstack.org/p/mitaka-crossproject-doc-the-way]
* 16:40
** Troubleshooting cross-project comms [https://etherpad.openstack.org/p/mitaka-crossproject-comms]
* 17:30
** Serving extreme use cases [https://etherpad.openstack.org/p/mitaka-crossproject-extreme-usecases]

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

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

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

== Cue ==

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

== Designate ==

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

== Documentation ==

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

== Glance ==

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

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

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

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

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

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

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

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

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

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

== Kolla ==

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

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

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

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

== Neutron ==

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

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

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

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

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

== Nova ==

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

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

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

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

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

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

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

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

'''Fri'''

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

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

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

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

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

== Oslo ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Meetings/InfraTeamMeeting

2015-06-26T22:38:07Z

Vipuls: /* Upcoming Project Renames */

{{:Header}}

= Weekly Project Infrastructure team meeting =

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

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

== Agenda for next meeting ==

* Announcements
* Actions from last meeting
* Specs approval
** RefStack Site Hosting
*** https://review.openstack.org/#/c/188207/ (hogepodge, davidlenwell)
* Schedule Project Renames
* Priority Efforts
** Swift logs
** Nodepool DIB
** Migration to Zanata
*** Adding infra as Zanata admin [https://review.openstack.org/#/c/193677/ change] is pending, once this lands we'll need to link it to an openstackid (on openstackid-dev for now) account for infra, AFAIK we don't yet have an infra service account on openstackid, how should we handle this?
** Downstream Puppet
** Upgrading Gerrit
** Docs publishing
*** Holding pattern while Swift logs issues get ironed out
* Hosting for Manila service image (u_glide, bswartz)
* Open discussion

== Upcoming Project Renames ==
* stackforge/puppet-murano -> openstack/puppet-murano, https://review.openstack.org/192730
* stackforge/cue -> openstack/cue, https://review.openstack.org/#/c/196268/
(any additions should mention original->new full names and link to the corresponding change in Gerrit)

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

Meetings/Cue

2015-06-22T17:44:18Z

Vipuls: /* Agenda */

= Weekly Cue meeting =

The [https://launchpad.net/cue Cue] project holds a weekly team meeting every Monday at following time/place:
* [http://www.timeanddate.com/worldclock/fixedtime.html?hour=18&min=0&sec=0%201900%20UTC 18:00 UTC] in <code><nowiki>#openstack-meeting-alt</nowiki></code>

== Next meeting ==
June 22, 2015 - http://www.timeanddate.com/worldclock/fixedtime.html?msg=Cue+Weekly+Meeting&iso=20150615T18&p1=1440&ah=1

==== Agenda ====
* Action Items
** http://eavesdrop.openstack.org/meetings/cue/2015/cue.2015-06-15-18.02.html
* Discussion Topics

* Bugs
** [https://bugs.launchpad.net/cue/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.importance%3Alist=CRITICAL&field.importance%3Alist=HIGH&field.importance%3Alist=MEDIUM&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search New [Critical | High | Medium<nowiki>]</nowiki> Bugs]

* Open discussion

Meetings/Cue

2015-06-22T17:43:38Z

Vipuls: /* Next meeting */

= Weekly Cue meeting =

The [https://launchpad.net/cue Cue] project holds a weekly team meeting every Monday at following time/place:
* [http://www.timeanddate.com/worldclock/fixedtime.html?hour=18&min=0&sec=0%201900%20UTC 18:00 UTC] in <code><nowiki>#openstack-meeting-alt</nowiki></code>

== Next meeting ==
June 22, 2015 - http://www.timeanddate.com/worldclock/fixedtime.html?msg=Cue+Weekly+Meeting&iso=20150615T18&p1=1440&ah=1

==== Agenda ====
* Action Items
** http://eavesdrop.openstack.org/meetings/cue/2015/cue.2015-06-08-18.02.html

* Discussion Topics

* Bugs
** [https://bugs.launchpad.net/cue/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.importance%3Alist=CRITICAL&field.importance%3Alist=HIGH&field.importance%3Alist=MEDIUM&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search New [Critical | High | Medium<nowiki>]</nowiki> Bugs]

* Open discussion

IRC

2015-06-08T23:44:49Z

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

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

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

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

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

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

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

* [https://kashyapc.fedorapeople.org/notes-bip-IRC-proxy/README Installation notes for Fedora/RH-like] and [https://kashyapc.fedorapeople.org/notes-bip-IRC-proxy/bip.conf example bip.conf] contributed by Kashyap Chamarthy
* ZNC [https://dague.net/2014/09/13/my-irc-proxy-setup/ configuration notes] contributed by Sean Dague

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

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

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

{| class="wikitable sortable" border="1"
|-
! IRC Channel !! Description
|-
|'''#openstack''' || general discussion, support
|-
| '''#openstack-101''' || guidance for new contributors
|-
|'''#openstack-anvil''' || [http://anvil.readthedocs.org/ Anvil] discussion channel
|-
|'''#openstack-barbican''' || Barbican-related team discussions
|-
|'''#openstack-blazar''' || blazar (formerly climate) team discussions
|-
|'''#openstack-board''' || OpenStack Foundation Board Meeting Back channel (mainly quiet except during meetings)
|-
|'''#openstack-ceilometer''' || ceilometer team discussions
|-
|'''#openstack-chef''' || deployment and operating OpenStack with Chef
|-
|'''#openstack-cinder''' || cinder team discussions
|-
| '''#openstack-community''' || coordination of community activity
|-
| '''#openstack-containers''' || containers team discussion
|-
| '''#openstack-cue''' || Cue team discussion
|-
|'''#openstack-defcore''' || Defcore discussion channel
|-
|'''#openstack-dev''' || general and cross-project development discussion
|-
|'''#openstack-dns''' || Designate DNS team discussions
|-
|'''#openstack-doc''' || documentation team discussion
|-
|'''#openstack-fr''' || general discussion, support in French
|-
|'''#openstack-fwaas''' || Firewall as a Service discussions
|-
|'''#openstack-gbp''' || Group Based Policy discussions
|-
|'''#openstack-glance''' || glance team discussions
|-
|'''#openstack-gsoc''' || google summer of code discussions
|-
|'''#openstack-horizon''' || horizon team discussions
|-
|'''#openstack-hyper-v''' || Microsoft Windows guests and hypervisor discussion
|-
|'''#openstack-infra''' || developer community infrastructure, continuous integration testing
|-
|'''#openstack-ironic''' || ironic & bare metal discussions
|-
|'''#openstack-keystone''' || keystone team discussions
|-
|'''#openstack-ko''' || general discussion, support in Korean
|-
|'''#openstack-latinamerica''' || OpenStack Latin America (Spanish)
|-
|'''#openstack-lbaas''' || Neutron LBaaS and Project Octavia discussions
|-
|'''#openstack-manila''' || shared / distributed file system service team discussions
|-
|'''#openstack-marconi''' || queue/messaging marconi team discussions
|-
|'''#openstack-meeting''' || team meetings
|-
|'''#openstack-meeting-alt''' || team meetings, alternate channel
|-
|'''#openstack-meeting-3''' || team meetings, another alternate channel
|-
|'''#openstack-meeting-4''' || team meetings, another alternate channel
|-
|'''#openstack-mistral''' || Mistral Workflow Service for OpenStack
|-
|'''#openstack-neutron''' || neutron team discussions
|-
|'''#openstack-nfv''' || [[Teams/NFV|NFV]] team discussions
|-
|'''#openstack-nova''' || nova team discussions
|-
|'''#openstack-operators''' || OpenStack Operators discussion channel
|-
|'''#openstack-opw''' || GNOME OPW mentor, intern and supporter discussions
|-
|'''#openstack-oslo''' || [https://wiki.openstack.org/wiki/Oslo Oslo] development discussion
|-
| '''#openstack-qa''' || QA team discussion
|-
|'''#openstack-rally''' || [https://wiki.openstack.org/wiki/Rally Rally] measure performance of your cloud
|-
|'''#openstack-rating''' || Rating team discussions
|-
|'''#openstack-relmgr-office''' || Release managers office hours channel
|-
|'''#openstack-sahara''' || [https://wiki.openstack.org/wiki/Sahara Sahara] team discussions
|-
|'''#openstack-sdks''' || Development of SDKs to work with OpenStack and the unified OpenStack command line tool
|-
|'''#openstack-security''' || General discussion about OpenStack security and open channel for the OpenStack Security Group (OSSG)
|-
|'''#openstack-stable''' || stable branch management and packaging discussions
|-
|'''#openstack-state-management''' || [https://wiki.openstack.org/wiki/TaskFlow TaskFlow] and state-management development discussion
|-
|'''#openstack-swift''' || swift team discussions
|-
| '''#openstack-translation''' || translation groups discussion
|-
|'''#openstack-trove''' || trove database team discussions
|-
|'''#openstack-tw''' || general discussion, support in Taiwan
|-
| '''#openstack-ux''' || discussion channel for user experience
|-
|'''#openstack-vmware''' || The VMwareAPI team discussion channel
|-
|'''#congress''' || Congress policy developer discussion channel
|-
|'''#heat''' || Heat developer discussion channel
|-
|'''#magnetodb''' || Key-Value storage for OpenStack
|-
|'''#murano''' || Murano team discussions
|-
|'''#nova-docker''' || Nova Docker team discussions
|-
|'''#refstack''' || RefStack
|-
|'''#storyboard''' || StoryBoard team discussions
|-
|'''#tripleo''' || TripleO team discussions
|-
|'''#openstack-ansible''' || Openstack ansible deployments discussions
|-}

[[Category:Connect]]

Design Summit/Liberty/Etherpads

2015-05-21T22:19:21Z

Vipuls: /* Akanda */

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

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

* 11:15 - 11:55
** [https://etherpad.openstack.org/p/liberty-cross-project-python3 Moving apps to Python 3]
** [https://etherpad.openstack.org/p/liberty-cross-project-user-notifications Async status updates]
* 12:05 - 12:45
** [https://etherpad.openstack.org/p/liberty-crossproject-ux Improving UX across all projects]
** [https://etherpad.openstack.org/p/liberty-functional-testing-show-tell Functional Testing Show & Tell]
* 2:00 - 2:40
** [https://etherpad.openstack.org/p/sdk-cross-project-vancouver OpenStack SDK]
** [https://etherpad.openstack.org/p/modern-javascript-vancouver-2015 Modern JavaScript]
* 2:50 - 3:30
** [https://etherpad.openstack.org/p/liberty-cross-project-in-team-scaling In-team scaling]
** [https://etherpad.openstack.org/p/service-catalog-cross-project-vancouver Service Catalog Standardization]
* 3:40 - 4:20
** [https://etherpad.openstack.org/p/liberty-cross-project-api-wg API Working Group]
** [https://etherpad.openstack.org/p/liberty-neutron-gaps-concerns Towards one Network Stack: Part 1 - Neutron Gaps and Concerns]
** [https://etherpad.openstack.org/p/liberty-xproject-scheduler Cross project scheduling APIs (Rm 221)]
* 4:40 - 5:20
** [https://etherpad.openstack.org/p/liberty-cross-project-release-models OpenStack release model(s)]
** [https://etherpad.openstack.org/p/liberty-cross-project-unified-policy Unified Policy File]
* 5:30 - 6:10
** [https://etherpad.openstack.org/p/Cross-project_workshop_Documentation OpenStack Documentation]
** [https://etherpad.openstack.org/p/liberty-cross-project-managing-concurrency Managing concurrency]

==Barbican==
* https://etherpad.openstack.org/p/barbican-L-design-sessions

==Ceilometer==
wednesday:
* 0900 - 0940: [https://etherpad.openstack.org/p/ceilo-multi-identity componentisation / multi identity]
* 0950 - 1030: [https://etherpad.openstack.org/p/event_alarm event alarms]
* 1100 - 1140: [https://etherpad.openstack.org/p/liberty-ceilometer-pipeline-config pipeline configuration]
* 1150 - 1230: [https://etherpad.openstack.org/p/ceilo-declarative-notifications declarative notification meters]
* 1440 - 1520: [https://etherpad.openstack.org/p/YVR-ops-ceilometer ops followup]
* 1530 - 1610: [https://etherpad.openstack.org/p/ceilo-multi-identity componentization carry over]

 thursday:
* 0900 - 0940: [https://etherpad.openstack.org/p/liberty-ceilometer-meter-deprecation meter deprecation]
* 0950 - 1030: [https://etherpad.openstack.org/p/liberty-ceilometer-meter-event samples/events integration]
* 1100 - 1140: [https://etherpad.openstack.org/p/liberty-ceilometer-versioned-objects versioned objects]
* 1150 - 1230: ops followup

 friday:
* 0900 - 1200: [https://etherpad.openstack.org/p/liberty-ceilometer-contributors-meetup contributor meetup]

==Cinder==

* Tuesday • 2:00pm - 2:40pm https://etherpad.openstack.org/p/YVR-ops-cinder
* Wednesday • 11:50am - 12:30pm https://etherpad.openstack.org/p/cinder-live-instance-migration-with-volume
* Wednesday • 1:50pm - 2:30pm https://etherpad.openstack.org/p/collect-display-storage-backend-status
* Wednesday • 2:40pm - 3:20pm https://etherpad.openstack.org/p/cinder-standard-capabilities
* Wednesday • 3:30pm - 4:10pm https://etherpad.openstack.org/p/YVR-cinder-nested-quota
* Wednesday • 4:30pm - 5:10pm https://etherpad.openstack.org/p/YVR-public-and-shared-snapshots
* Wednesday • 5:20pm - 6:00pm https://etherpad.openstack.org/p/liberty-cinder-ironic-integration
* Thursday • 9:00am - 9:40am https://etherpad.openstack.org/p/volume-migration-improvement
* Thursday • 9:50am - 10:50am https://etherpad.openstack.org/p/cinder-scaling-backup-service
* Thursday • 11:00am - 11:40am https://etherpad.openstack.org/p/cinder-active-active-vol-service-issues
* Thursday • 11:50am - 12:30pm https://etherpad.openstack.org/p/cinder-not-bypass-scheduler & https://etherpad.openstack.org/p/cinder-auto-sync-storage-service-catalog
* Thursday • 13:30pm - 14:10pm https://etherpad.openstack.org/p/YVR-cinder-tasks-resumptions & https://etherpad.openstack.org/p/cinder-taskflow
* Thursday • 2:20pm - 3:00pm https://etherpad.openstack.org/p/cinder-rolling-upgrade
* Thursday • 3:10pm - 3:50pm https://etherpad.openstack.org/p/replication_v2_liberty_discussion

==Designate==
==Documentation==

* Tuesday cross-project • 5:30pm - 6:10pm https://etherpad.openstack.org/p/Cross-project_workshop_Documentation
* Wednesday • 1:50pm - 2:30pm https://etherpad.openstack.org/p/Documentation__RST_Migration
* Wednesday • 3:30pm - 4:10pm https://etherpad.openstack.org/p/Documentation__Ops_Work_Session
* Thursday • 11:50am - 12:30pm https://etherpad.openstack.org/p/Documentation__API_Work_Session
* Thursday • 1:30pm - 2:10pm https://etherpad.openstack.org/p/Documentation__Blueprint_Work_Session
* Thursday • 2:20pm - 3:00pm https://etherpad.openstack.org/p/Documentation__Team_Structure_1
* Thursday • 3:10pm - 3:50pm https://etherpad.openstack.org/p/Documentation__Team_Structure_1
* Thursday • 4:10pm - 4:50pm https://etherpad.openstack.org/p/Documentation__Info_Architecture_1
* Thursday • 5:00pm - 5:40pm https://etherpad.openstack.org/p/Documentation__Info_Architecture_2
* Friday • 9:00am - 12:20pm https://etherpad.openstack.org/p/Documentation__Contributors_Meetup

==Glance==
'''Wed'''
* 11:00 - 11:40: [https://etherpad.openstack.org/p/liberty-caching (W) Object Downloads: Cache Misses & Pollution]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/liberty-glance-reliable-upload (W) Upload Recovery]
* 13:50 - 14:30: [https://etherpad.openstack.org/p/liberty-glance-hierarchical-multitenancy (W) Hierarchical Multi-tenancy]
* 14:40 - 15:20: [https://etherpad.openstack.org/p/liberty-what-is-glance (F) Glance: The direction of the Glance project]
* 15:30 - 16:10: [https://etherpad.openstack.org/p/catalog-index-service-liberty (F) Glance: Catalog Index Service - Future and Scope]
* 16:40 - 17:10: [https://etherpad.openstack.org/p/liberty-glance-image-signing-and-encryption (F) Glance: Image Signing and Encryption]
* 17:20 - 18:00: [https://etherpad.openstack.org/p/liberty-glance-intercloud-image-sharing (F) Glance: Intercloud image sharing]

'''Thur'''
* 09:00 - 09:40: [https://etherpad.openstack.org/p/OVF-support-in-glance (W) OVF Support in Glance]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/liberty-glance-nosql-backend (W) NoSql backend for Glance]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/liberty-glance-store-CI (W) glance_store CI]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/liberty-glance-ops-feedback (W) Ops feedback]
* 13:30 - 14:10: [https://etherpad.openstack.org/p/liberty-glance-open-discussion (W) Open discussion]

==Heat==
'''Wed'''
* 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-heat-liberty-convergence-1 (W) Finishing off Convergence phase 1]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-heat-liberty-convergence-2 (W) Convergence phase 2 planning]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-heat-liberty-testing (W) Functional and integration testing, identify gaps and suggest improvements]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-heat-liberty-lifecycle-ops (W) Better support for lifecycle operations on (tripleo) heat stacks (upgrades etc)]
* 13:50 - 14:30: [https://etherpad.openstack.org/p/YVR-heat-liberty-client-usability (F) Heat client usability]
* 14:40 - 15:20: [https://etherpad.openstack.org/p/YVR-heat-liberty-template-format (F) Heat template format improvements]
* 15:30 - 16:10: [https://etherpad.openstack.org/p/YVR-heat-liberty-rest-api (F) REST API design and roadmap]
* 16:30 - 17:10: [https://etherpad.openstack.org/p/YVR-heat-liberty-senlin-autoscaling (F) Senlin Autoscaling Project - Deep Dive]
* 17:20 - 18:00: [https://etherpad.openstack.org/p/YVR-heat-liberty-containers (F) Orchestrating containers with Heat]

'''Thu'''
* 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-heat-liberty-alembic (W) Migrating from sqlalchemy-migrations to alembic]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-heat-liberty-versioned-objects (W) Future of Versioned objects in heat]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-heat-liberty-autoscaling (W) Autoscaling improvements]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-heat-liberty-deprecation (W) Our deprecation process]
* 16:10 - 16:50: [https://etherpad.openstack.org/p/YVR-heat-liberty-contrib-plugins (W) Moving most contrib plugins in-tree]
* 17:00 - 17:40: [https://etherpad.openstack.org/p/YVR-heat-liberty-resource-registering (W) Conditional registering of resources]

'''Fri'''
* 09:00-12:20: [https://etherpad.openstack.org/p/YVR-heat-contributor-meetup Contributor Meetup]

==Horizon==
* Wed 9:00 Plugins https://etherpad.openstack.org/p/YVR-horizon-plugins
* Wed 9:50 Merlin and Curvature https://etherpad.openstack.org/p/YVR-horizon-new-tech
* Wed 13:50 Keystone and session storage https://etherpad.openstack.org/p/YVR-horizon-keystone
* Thurs 9:00 Angular Planning https://etherpad.openstack.org/p/YVR-horizon-angular-planning
* Thurs 9:50 Angular Specifics https://etherpad.openstack.org/p/YVR-horizon-angular-topics
* Thurs 11:00 User Experience https://etherpad.openstack.org/p/YVR-horizon-ux
* Thurs 11:50 Performance, Scalability, Elastic Search https://etherpad.openstack.org/p/YVR-horizon-performance
* Thurs 13:30 Operator Feedback https://etherpad.openstack.org/p/YVR-horizon-ops-feedback
* Thurs 14:20 Plan to address Operator Feedback https://etherpad.openstack.org/p/YVR-horizon-addressing-ops-feedback
* Thurs 15:10 Messaging (better error messages to users AND websockets) https://etherpad.openstack.org/p/YVR-horizon-liberty-messaging
* Thurs 17:00 Liberty Priorities https://etherpad.openstack.org/p/YVR-horizon-liberty-priorities
* Fri 9:00 Contributor Meetup #1 https://etherpad.openstack.org/p/YVR-horizon-collab-meetup
* Fri 1:20 Contributor Meetup #2 https://etherpad.openstack.org/p/YVR-horizon-collab-meetup

==Infrastructure==
* Wed 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-infra-irc-meetings (W) Work session on Gerrit-driven IRC meetings]
* Wed 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-infra-activity-tracking (W) Work session on activity tracking]
* Thu 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-infra-zuulv3 (F) Zuul v3]
* Thu 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-infra-task-tracking (F) Task tracking]
* Thu 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-infra-cloud (F) Infra-Cloud]
* Thu 11:50 - 12:30: [https://etherpad.openstack.org/p/kilo-infra-puppet-testing (F) Puppet Testing]
* Thu 15:10 - 16:50: [https://etherpad.openstack.org/p/YVR-infra-puppet-openstackci (W) Work session on puppet-openstackci]

==Ironic==
https://etherpad.openstack.org/p/liberty-ironic-design-summit-ideas

==Keystone==
==Manila==
'''Wed'''
* 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-manila-liberty-mount-automation (F) Mount automation]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-manila-liberty-share-migration (F) Share migration]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-manila-liberty-share-replication (F) Share replication]
* 16:30 - 17:10: [https://etherpad.openstack.org/p/YVR-manila-liberty-versioned-objects-and-apis (W) Versioned objects and APIs]
* 17:20 - 18:00: [https://etherpad.openstack.org/p/YVR-manila-liberty-fault-indication (W) Fault indication]

'''Thu'''
* 16:10 - 16:50: [https://etherpad.openstack.org/p/YVR-manila-liberty-thin-provisioning (W) Thin provisioning and consistency groups]
* 17:00 - 17:40: [https://etherpad.openstack.org/p/YVR-manila-service-image (W) Snapshot-share relationship and Manila service image]

==Neutron==
'''Mon'''
* 20:00 - 22:30: [http://lists.openstack.org/pipermail/openstack-dev/2015-May/064323.html Neutron Social]

'''Wed'''
* 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-neutron-liberty-development Neutron Liberty Development]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-neutron-use-case-discussion Neutron Use Case Discussion]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-neutron-vlan-trunk VLAN Aware VMs]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-neutron-lightning-talks Neutron Lightning Talks]
* 13:50 - 14:30: [https://etherpad.openstack.org/p/YVR-neutron-octavia Octavia]
* 14:40 - 15:20: [https://etherpad.openstack.org/p/YVR-neutron-ironic Ironic and Neutron integration]
* 15:30 - 16:10: [https://etherpad.openstack.org/p/YVR-neutron-ovn OVN]
* 16:30 - 17:10: [https://etherpad.openstack.org/p/YVR-neutron-opendaylight OpenDaylight]
* 17:20 - 18:00: [https://etherpad.openstack.org/p/YVR-neutron-get-me-a-network Get Me a Network!]

'''Thu'''
* 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases Neutron LBaaS Use Cases]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-neutron-l3 Neutron L3]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-neutron-qos QoS]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-neutron-third-party-ci-liberty Third Party CI in Liberty and Beyond]
* 13:30 - 14:10: [https://etherpad.openstack.org/p/YVR-neutron-testing-in-liberty Testing In Liberty]
* 14:20 - 15:00:
** [https://etherpad.openstack.org/p/YVR-neutron-RBAC RBAC shared network]
** [https://etherpad.openstack.org/p/YVR-neutron-port-status Neutron Port Status]
* 15:10 - 15:50: [https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction SG and FWaaS Future Directions]
* 16:10 - 16:50: [https://etherpad.openstack.org/p/YVR-neutron-nfv-enhancements Neutron NFV Enhancements]

'''Fri'''
* 09:00-12:20: [https://etherpad.openstack.org/p/YVR-neutron-contributor-meetup Contributor Meetup]

==Nova==

'''Wednesday:'''

* 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-nova-scheduler-in-liberty Scheduler in Liberty]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-nova-scalling-out-scheduler-for-cells Scaling out scheduler for cells ]

* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-nova-cells-v2 Cells v2]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-nova-resource-tracker Resource Tracker, Clustered Hypervisors and NFV]

* 13:50 - 14:30: [https://etherpad.openstack.org/p/YVR-nova-spec-blueprint-unconference Nova Spec/Blueprint Unconference]
* 14:40 - 15:20: [https://etherpad.openstack.org/p/YVR-nova-database-internals Database (part 1)]
* 15:30 - 16:10: [https://etherpad.openstack.org/p/YVR-nova-functional-testing-feature-classification Functional Testing and Feature Classification]

* 16:30 - 17:10: [https://etherpad.openstack.org/p/YVR-nova-instance-ha-evacuate-resize Dealing with compute host failure: Instance HA, Evacuate, Resize]
* 17:20 - 18:00: [https://etherpad.openstack.org/p/YVR-nova-api-2.1-in-liberty Nova API v2.1 in Liberty]

 
'''Thursday:'''

* 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-nova-api-2.0-3rd-party Future of Nova API v2.0 and 3rd Party APIs]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-nova-quotas-and-database Quotas and Database (part 2)]

* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-nova-flavors-and-image-properties Flavors and Image Properties]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-nova-error-handling Error Handling]

* 13:30 - 14:10: [https://etherpad.openstack.org/p/YVR-nova-spec-blueprint-unconference Nova Spec/Blueprint Unconference]
* 14:20 - 15:00: [https://etherpad.openstack.org/p/YVR-nova-liberty-priorities Liberty Priorities (part 1)]
* 15:10 - 15:50: [https://etherpad.openstack.org/p/YVR-nova-liberty-priorities Liberty Priorities (part 2)]

* 16:10 - 16:50: [https://etherpad.openstack.org/p/YVR-nova-liberty-process Liberty Process and Scaling out Reviews]
* 17:00 - 17:40: [https://etherpad.openstack.org/p/YVR-nova-network Future of Nova's networking and nova-network]

 
'''Friday:'''

* 09:00 - 12:20 and 13:20 - 16:40: [https://etherpad.openstack.org/p/YVR-nova-contributor-meetup Nova Contributor Meetup]

==OpenStackClient==

'''Thursday:'''

* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-osc-roadmap (F) Roadmap and Priorities]
* 14:20 - 15:00: [https://etherpad.openstack.org/p/YVR-osc-work-session (W) Working session]

==Oslo==

'''Wednesday:'''

* 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-oslo-versioned-objects-intro (F) Get to know your objects and learn how to version them (an introduction to oslo.versionedobjects)!]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-oslo-taskflow-plans (F) Give me liberty, or give me taskflow (come learn about taskflow liberty plans)!]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-oslo-rootwrap-plans (W) Give me liberty, or give me wraps (the future of oslo.rootwrap) ]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-oslo-functional-testing (W) The cost of liberty is less than the price of functional testing]
* 13:50 - 14:30: [https://etherpad.openstack.org/p/YVR-oslo-graduation-schedule (W) Give me more oslo in liberty or else! Schedule & new libraries]
* 14:40 - 15:20: [https://etherpad.openstack.org/p/YVR-oslo-messaging-zmq-status (F) State of zmq in oslo.messaging]
* 15:30 - 16:10: [https://etherpad.openstack.org/p/YVR-oslo-optional-dependencies (W) Emancipate/liberate your optional dependencies - Optional Dependencies]
* 16:30 - 17:10: [https://etherpad.openstack.org/p/YVR-oslo-release-process-review (W) Reviewing our release processes]
* 17:20 - 18:00: [https://etherpad.openstack.org/p/YVR-oslo-config-filter (W) Configuration Filters in oslo.config]

 
'''Thursday:'''

* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-oslo-strategy-discussion (F) The oslo liberty proclamation (and associated strategy discussion)]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-oslo-config-plans (F) Enfranchise oslo.config, let's discuss alternative data sources in oslo.config]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-oslo-log-plans (W) Life, Liberty, and the pursuit of oslo.log changes]
* 13:30 - 14:10: [https://etherpad.openstack.org/p/YVR-oslo-versioned-objects-deep-dive (W) Deep dive on oslo.versionedobjects, bring your wet suits.]
* 14:20 - 15:00: [https://etherpad.openstack.org/p/YVR-oslo-db-plans (F) For a people who are free, and who mean to remain so, a well organized and armed 'oslo.db' is their best security]
* 15:10 - 15:50: [https://etherpad.openstack.org/p/YVR-oslo-asyncio (F) Event loops, coroutines, yield from, futures, a discussion on asyncio (and triollus?)]
* 16:10 - 16:50: [https://etherpad.openstack.org/p/YVR-oslo-messaging-plans (F) Ping pong, oslo.messaging plans for liberty.]
* 17:00 - 17:40: [https://etherpad.openstack.org/p/YVR-oslo-tech-debt-deprecation (F) How to clean up your tech-debt; let's discuss best practices on how to deprecate things in oslo libraries]

 

==QA==

'''Wed'''

* 1150-1230 - [https://etherpad.openstack.org/p/YVR-QA-testing-beyond-the-gate Testing beyond the gate]
* 1350-1430 - [https://etherpad.openstack.org/p/YVR-QA-Devstack-Roadmap Devstack Roadmap]
* 1440-1520 - [https://etherpad.openstack.org/p/YVR-QA-Tempest-service-clients Work Session: Tempest service clients]
* 1630-1710 - [https://etherpad.openstack.org/p/YVR-QA-in-the-big-tent QA in the Big Tent]

'''Thurs.'''
* 0900-0940 - [https://etherpad.openstack.org/p/YVR-QA-idempotent-id Work Session: Idempotent ID]
* 1330-1410 - [https://etherpad.openstack.org/p/YVR-QA-Tempest-as-a-system-program Work Session: Tempest as System Program]
* 1420-1500 - [https://etherpad.openstack.org/p/YVR-QA-Tempest-CLI Work Session: Tempest CLI and Tempest Cleanup]
* 1610-1650 - [https://etherpad.openstack.org/p/YVR-QA-Tempest-Scope-Revisited Tempest Scope Revisited]
* 1700-1740 - [https://etherpad.openstack.org/p/YVR-QA-Liberty-Priorities Liberty Priorities]

==Release Management==
* Wed 17:20-18:00: [https://etherpad.openstack.org/p/YVR-relmgt-stable-branch Stable branch]
* Thu 11:00-11:40 [https://etherpad.openstack.org/p/YVR-relmgt-library-releases Work session: Library releases]

==Sahara==

'''Wed'''

* 11:00am (W) HA http://etherpad.openstack.org/p/sahara-liberty-ha
* 11:50am (W) API v2 https://etherpad.openstack.org/p/sahara-liberty-api-v2

''Thu'''

* 1:30pm (F) UI https://etherpad.openstack.org/p/sahara-liberty-ui
* 2:20pm (F) Security https://etherpad.openstack.org/p/sahara-liberty-security
* 3:10pm (W) EDP https://etherpad.openstack.org/p/sahara-liberty-edp
* 4:10pm (W) Resources Visibility/ACL https://etherpad.openstack.org/p/sahara-liberty-resources
* 5:00pm (W) Plugins https://etherpad.openstack.org/p/sahara-liberty-plugins

''Fri'''

* 9am - 4:40pm Meetup https://etherpad.openstack.org/p/sahara-liberty-meetup

==Security==
* Wed 13:50-14:30: [https://etherpad.openstack.org/p/YVR-security-vmt Vulnerability management]

==Swift==
'''Wednesday:'''
* 9:00am - 9:40am: [https://etherpad.openstack.org/p/liberty-swift-large-containers Large containers (container sharding)]
* 9:50am - 10:30am: [https://etherpad.openstack.org/p/python-swiftclient-liberty-discussion python-swiftclient status and next steps]
* 11:00am - 11:40am [https://etherpad.openstack.org/p/liberty-swift-changing-policies Changing Policies]
* 1:50pm - 2:30pm [https://etherpad.openstack.org/p/liberty-swift-increase-part-power Increasing ring partition power]
* 3:30pm - 4:10pm [https://etherpad.openstack.org/p/liberty-swift-documentation Swift Documentation]
* 4:30pm - 5:10pm [https://etherpad.openstack.org/p/liberty-swift-softlayer Softlayer]
* 5:20pm - 6:00pm [https://etherpad.openstack.org/p/Liberty_Swift_Summit_Encryption Swift on-disk encryption]
 
'''Thursday:'''
* 9:00am - 9:40am: [https://etherpad.openstack.org/p/Liberty_Swift_Summit_Storlets Swift Storlets]
* 9:50am - 10:30am: [https://etherpad.openstack.org/p/liberty-swift-ops-feedback Ops Feedback Session]
* 11:00am - 11:40am: [https://etherpad.openstack.org/p/liberty-swift-tape-storage Tape Storage]
* 11:50am - 12:30pm: [https://etherpad.openstack.org/p/liberty-swift-hummingbird Hummingbird: Scaling Swift using Go]
* 1:30pm - 2:10pm: [https://etherpad.openstack.org/p/liberty-swift-ec-overview EC Overview]
* 2:20pm - 3:00pm: [https://etherpad.openstack.org/p/liberty-swift-metadata-search Metadata search/object update notification]
* 3:10pm - 3:50pm: [https://etherpad.openstack.org/p/liberty-swift-ec-follow-on-work EC follow on work]
* 4:10pm - 4:50pm: [https://etherpad.openstack.org/p/Liberty_Swift_Summit_Encryption_Working Encryption]
* 5:00pm - 5:40pm: [https://etherpad.openstack.org/p/liberty-swift-tiering Tiering]
 
'''Friday:'''
* All day: [https://etherpad.openstack.org/p/liberty-swift-contributors-meetup Contributors' Meetup]

==TripleO==
'''Thursday:'''
* 1:30pm - 2:10pm: [https://etherpad.openstack.org/p/tripleo-liberty-tripleo-heat-templates tripleo-heat-templates interfaces and containerization enablement]
* 2:20pm - 3:00pm: [https://etherpad.openstack.org/p/tripleo-dib-ci-production diskimage-builder functional testing, CI, and TripleO in production]
* 3:10pm - 3:50pm: [https://etherpad.openstack.org/p/tripleo-service-endpoints Work Session: Isolated network architecture]
* 5:00pm - 5:40pm: Work Session
 
'''Friday:'''
* 9:00am - 12:20pm: [https://etherpad.openstack.org/p/tripleo-liberty-proposed-sessions Contributor's Meetup]
* 1:20pm - 4:40pm: [https://etherpad.openstack.org/p/tripleo-liberty-proposed-sessions Contributor's Meetup]

==Trove==
'''Wednesday:'''
* 2:40pm - 3:20pm: [https://etherpad.openstack.org/p/trove-liberty-extending-clusters Extending Cluster creation and actions for extensibility]
* 3:30pm - 4:10pm: [https://etherpad.openstack.org/p/trove-liberty-datastore-testing Testing Different Trove Datastores -- the path from experimental to stable]
* 4:30pm - 5:10pm [https://etherpad.openstack.org/p/trove-2015-vancouver-logging Show me the Logs -- Allowing Trove Users Access to Datastore Log files]
 
'''Thursday:'''
* 9:00am - 9:40am: [https://etherpad.openstack.org/p/trove-liberty-bp-update Work session - Blueprint and Spec Priorities for Liberty]
* 9:50am - 10:30am: [https://etherpad.openstack.org/p/trove-liberty-production-deploy Work session - Deploying Trove in Production]
* 1:30pm - 2:10pm: [https://etherpad.openstack.org/p/trove-liberty-monitoring Work session - Monitoring Trove Datastores]
* 2:20pm - 3:00pm: [https://etherpad.openstack.org/p/trove-liberty-openstack-integration Work session - Trove integration with other OpenStack components]
* 3:10pm - 3:50pm: [https://etherpad.openstack.org/p/trove-liberty-gaps-in-trove Work session - Gaps in Trove]
 
'''Friday:'''
* All day: [https://etherpad.openstack.org/p/trove-liberty-contributors-meetup Contributors' Meetup]

==Zaqar==

* Thursday, May 21 - 3.10pm to 3.50pm - Room 222 - [https://etherpad.openstack.org/p/zaqar-liberty-ops-friendly Zaqar needs to be OPs friendly]
* Thursday, May 21 - 4.10pm to 4.50pm - Room 222 - [https://etherpad.openstack.org/p/zaqar-liberty-testsuite Test suite refactor for Zaqar and Zaqarclient]

==Murano==
'''Thu'''

* 2:20pm (F) [https://etherpad.openstack.org/p/murano-liberty-now-n-future Murano: Now, Liberty and Future]
* 4:10pm (W) [https://etherpad.openstack.org/p/murano-liberty-work-session-1 Images & Murano]
* 5:00pm (W) [https://etherpad.openstack.org/p/murano-liberty-work-session-2 Authentication & Agent]

'''Fri'''

* 9am - 4:40pm [https://etherpad.openstack.org/p/murano-liberty-contributors-meetup Contributors Meetup]

==Event intro/closure==
* Tue 11:15-11:55: [https://etherpad.openstack.org/p/YVR-design-summit-101 Design Summit 101]
* Fri 16:50-17:30: [https://etherpad.openstack.org/p/YVR-design-summit-feedback Design Summit feedback session]

==Ops==
Tuesday:
* https://etherpad.openstack.org/p/YVR-ops-101
* https://etherpad.openstack.org/p/YVR-ops-federation
* https://etherpad.openstack.org/p/YVR-ops-rabbitmq
* https://etherpad.openstack.org/p/YVR-ops-logging
* https://etherpad.openstack.org/p/YVR-ops-arch-show-tell
* https://etherpad.openstack.org/p/YVR-ops-ceilometer
* https://etherpad.openstack.org/p/YVR-ops-billing
* https://etherpad.openstack.org/p/YVR-ops-cinder
* https://etherpad.openstack.org/p/YVR-ops-legacy-apps
* https://etherpad.openstack.org/p/YVR-ops-user-committee
* https://etherpad.openstack.org/p/YVR-ops-hypervisor-tuning
* https://etherpad.openstack.org/p/YVR-ops-security
* https://etherpad.openstack.org/p/YVR-ops-deployment
* https://etherpad.openstack.org/p/YVR-ops-database
* https://etherpad.openstack.org/p/YVR-ops-evangelism
* https://etherpad.openstack.org/p/YVR-ops-multi-site
* https://etherpad.openstack.org/p/YVR-ops-nova
* https://etherpad.openstack.org/p/YVR-ops-customer-onboarding
* https://etherpad.openstack.org/p/YVR-ops-containers
* https://etherpad.openstack.org/p/YVR-ops-neutron

Wednesday:
* https://etherpad.openstack.org/p/YVR-ops-telco
* https://etherpad.openstack.org/p/YVR-ops-puppet
* https://etherpad.openstack.org/p/YVR-ops-chef
* https://etherpad.openstack.org/p/YVR-ops-hpc
* https://etherpad.openstack.org/p/YVR-ops-tools
* https://etherpad.openstack.org/p/YVR-ops-ansible
* https://etherpad.openstack.org/p/YVR-ops-ceph
* https://etherpad.openstack.org/p/YVR-ops-tags
* https://etherpad.openstack.org/p/YVR-ops-large-deployments
* https://etherpad.openstack.org/p/YVR-ops-burning-issues
* https://etherpad.openstack.org/p/YVR-ops-docs
* https://etherpad.openstack.org/p/YVR-ops-tech-choices
* https://etherpad.openstack.org/p/YVR-ops-cmdb
* https://etherpad.openstack.org/p/YVR-ops-data-plane-transitions
* https://etherpad.openstack.org/p/YVR-ops-upgrades
* https://etherpad.openstack.org/p/YVR-ops-packaging
* https://etherpad.openstack.org/p/YVR-ops-nova-network

==Group Based Policy (GBP)==
* https://etherpad.openstack.org/p/gbp-liberty-design-summit

== Magnum ==
Wednesday
* 09:00 AM - 09:40 AM https://etherpad.openstack.org/p/liberty-fishbowl-using-native
* 09:50 AM - 10:30 AM https://etherpad.openstack.org/liberty-fishbowl-determining-storage
* 11:00 AM - 11:40 AM https://etherpad.openstack.org/p/liberty-fishbowl-cultivating-caas-apps
* 11:50 AM - 12:30 PM https://etherpad.openstack.org/liberty-fishbowl-magnum-project-ideas
* 2:40 PM - 3:20 PM https://etherpad.openstack.org/liberty-work-tls-endpoint
* 3:30 PM - 4:10 PM https://etherpad.openstack.org/liberty-work-native-networking
* 4:30 PM - 5:10 PM http://etherpad.openstack.org/liberty-work-ci-functional-testing
* 5:20 PM - 6:00 PM https://etherpad.openstack.org/liberty-work-heat-coe-templates

Thursday
* 11:00 AM - 11:40 AM https://etherpad.openstack.org/liberty-work-magnum-horizontal-scale
* 11:50 AM - 12:30 PM https://etherpad.openstack.org/p/liberty-work-abstract-backend

== Akanda ==
Thursday
* 1:30pm - 2:10pm https://etherpad.openstack.org/p/liberty-akanda-design

== Cue ==
Thursday
* 3:20pm - 4:00pm https://etherpad.openstack.org/p/liberty-cue-design

Design Summit/Liberty/Etherpads

2015-05-21T22:19:10Z

Vipuls: /* Akanda */

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

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

* 11:15 - 11:55
** [https://etherpad.openstack.org/p/liberty-cross-project-python3 Moving apps to Python 3]
** [https://etherpad.openstack.org/p/liberty-cross-project-user-notifications Async status updates]
* 12:05 - 12:45
** [https://etherpad.openstack.org/p/liberty-crossproject-ux Improving UX across all projects]
** [https://etherpad.openstack.org/p/liberty-functional-testing-show-tell Functional Testing Show & Tell]
* 2:00 - 2:40
** [https://etherpad.openstack.org/p/sdk-cross-project-vancouver OpenStack SDK]
** [https://etherpad.openstack.org/p/modern-javascript-vancouver-2015 Modern JavaScript]
* 2:50 - 3:30
** [https://etherpad.openstack.org/p/liberty-cross-project-in-team-scaling In-team scaling]
** [https://etherpad.openstack.org/p/service-catalog-cross-project-vancouver Service Catalog Standardization]
* 3:40 - 4:20
** [https://etherpad.openstack.org/p/liberty-cross-project-api-wg API Working Group]
** [https://etherpad.openstack.org/p/liberty-neutron-gaps-concerns Towards one Network Stack: Part 1 - Neutron Gaps and Concerns]
** [https://etherpad.openstack.org/p/liberty-xproject-scheduler Cross project scheduling APIs (Rm 221)]
* 4:40 - 5:20
** [https://etherpad.openstack.org/p/liberty-cross-project-release-models OpenStack release model(s)]
** [https://etherpad.openstack.org/p/liberty-cross-project-unified-policy Unified Policy File]
* 5:30 - 6:10
** [https://etherpad.openstack.org/p/Cross-project_workshop_Documentation OpenStack Documentation]
** [https://etherpad.openstack.org/p/liberty-cross-project-managing-concurrency Managing concurrency]

==Barbican==
* https://etherpad.openstack.org/p/barbican-L-design-sessions

==Ceilometer==
wednesday:
* 0900 - 0940: [https://etherpad.openstack.org/p/ceilo-multi-identity componentisation / multi identity]
* 0950 - 1030: [https://etherpad.openstack.org/p/event_alarm event alarms]
* 1100 - 1140: [https://etherpad.openstack.org/p/liberty-ceilometer-pipeline-config pipeline configuration]
* 1150 - 1230: [https://etherpad.openstack.org/p/ceilo-declarative-notifications declarative notification meters]
* 1440 - 1520: [https://etherpad.openstack.org/p/YVR-ops-ceilometer ops followup]
* 1530 - 1610: [https://etherpad.openstack.org/p/ceilo-multi-identity componentization carry over]

 thursday:
* 0900 - 0940: [https://etherpad.openstack.org/p/liberty-ceilometer-meter-deprecation meter deprecation]
* 0950 - 1030: [https://etherpad.openstack.org/p/liberty-ceilometer-meter-event samples/events integration]
* 1100 - 1140: [https://etherpad.openstack.org/p/liberty-ceilometer-versioned-objects versioned objects]
* 1150 - 1230: ops followup

 friday:
* 0900 - 1200: [https://etherpad.openstack.org/p/liberty-ceilometer-contributors-meetup contributor meetup]

==Cinder==

* Tuesday • 2:00pm - 2:40pm https://etherpad.openstack.org/p/YVR-ops-cinder
* Wednesday • 11:50am - 12:30pm https://etherpad.openstack.org/p/cinder-live-instance-migration-with-volume
* Wednesday • 1:50pm - 2:30pm https://etherpad.openstack.org/p/collect-display-storage-backend-status
* Wednesday • 2:40pm - 3:20pm https://etherpad.openstack.org/p/cinder-standard-capabilities
* Wednesday • 3:30pm - 4:10pm https://etherpad.openstack.org/p/YVR-cinder-nested-quota
* Wednesday • 4:30pm - 5:10pm https://etherpad.openstack.org/p/YVR-public-and-shared-snapshots
* Wednesday • 5:20pm - 6:00pm https://etherpad.openstack.org/p/liberty-cinder-ironic-integration
* Thursday • 9:00am - 9:40am https://etherpad.openstack.org/p/volume-migration-improvement
* Thursday • 9:50am - 10:50am https://etherpad.openstack.org/p/cinder-scaling-backup-service
* Thursday • 11:00am - 11:40am https://etherpad.openstack.org/p/cinder-active-active-vol-service-issues
* Thursday • 11:50am - 12:30pm https://etherpad.openstack.org/p/cinder-not-bypass-scheduler & https://etherpad.openstack.org/p/cinder-auto-sync-storage-service-catalog
* Thursday • 13:30pm - 14:10pm https://etherpad.openstack.org/p/YVR-cinder-tasks-resumptions & https://etherpad.openstack.org/p/cinder-taskflow
* Thursday • 2:20pm - 3:00pm https://etherpad.openstack.org/p/cinder-rolling-upgrade
* Thursday • 3:10pm - 3:50pm https://etherpad.openstack.org/p/replication_v2_liberty_discussion

==Designate==
==Documentation==

* Tuesday cross-project • 5:30pm - 6:10pm https://etherpad.openstack.org/p/Cross-project_workshop_Documentation
* Wednesday • 1:50pm - 2:30pm https://etherpad.openstack.org/p/Documentation__RST_Migration
* Wednesday • 3:30pm - 4:10pm https://etherpad.openstack.org/p/Documentation__Ops_Work_Session
* Thursday • 11:50am - 12:30pm https://etherpad.openstack.org/p/Documentation__API_Work_Session
* Thursday • 1:30pm - 2:10pm https://etherpad.openstack.org/p/Documentation__Blueprint_Work_Session
* Thursday • 2:20pm - 3:00pm https://etherpad.openstack.org/p/Documentation__Team_Structure_1
* Thursday • 3:10pm - 3:50pm https://etherpad.openstack.org/p/Documentation__Team_Structure_1
* Thursday • 4:10pm - 4:50pm https://etherpad.openstack.org/p/Documentation__Info_Architecture_1
* Thursday • 5:00pm - 5:40pm https://etherpad.openstack.org/p/Documentation__Info_Architecture_2
* Friday • 9:00am - 12:20pm https://etherpad.openstack.org/p/Documentation__Contributors_Meetup

==Glance==
'''Wed'''
* 11:00 - 11:40: [https://etherpad.openstack.org/p/liberty-caching (W) Object Downloads: Cache Misses & Pollution]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/liberty-glance-reliable-upload (W) Upload Recovery]
* 13:50 - 14:30: [https://etherpad.openstack.org/p/liberty-glance-hierarchical-multitenancy (W) Hierarchical Multi-tenancy]
* 14:40 - 15:20: [https://etherpad.openstack.org/p/liberty-what-is-glance (F) Glance: The direction of the Glance project]
* 15:30 - 16:10: [https://etherpad.openstack.org/p/catalog-index-service-liberty (F) Glance: Catalog Index Service - Future and Scope]
* 16:40 - 17:10: [https://etherpad.openstack.org/p/liberty-glance-image-signing-and-encryption (F) Glance: Image Signing and Encryption]
* 17:20 - 18:00: [https://etherpad.openstack.org/p/liberty-glance-intercloud-image-sharing (F) Glance: Intercloud image sharing]

'''Thur'''
* 09:00 - 09:40: [https://etherpad.openstack.org/p/OVF-support-in-glance (W) OVF Support in Glance]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/liberty-glance-nosql-backend (W) NoSql backend for Glance]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/liberty-glance-store-CI (W) glance_store CI]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/liberty-glance-ops-feedback (W) Ops feedback]
* 13:30 - 14:10: [https://etherpad.openstack.org/p/liberty-glance-open-discussion (W) Open discussion]

==Heat==
'''Wed'''
* 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-heat-liberty-convergence-1 (W) Finishing off Convergence phase 1]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-heat-liberty-convergence-2 (W) Convergence phase 2 planning]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-heat-liberty-testing (W) Functional and integration testing, identify gaps and suggest improvements]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-heat-liberty-lifecycle-ops (W) Better support for lifecycle operations on (tripleo) heat stacks (upgrades etc)]
* 13:50 - 14:30: [https://etherpad.openstack.org/p/YVR-heat-liberty-client-usability (F) Heat client usability]
* 14:40 - 15:20: [https://etherpad.openstack.org/p/YVR-heat-liberty-template-format (F) Heat template format improvements]
* 15:30 - 16:10: [https://etherpad.openstack.org/p/YVR-heat-liberty-rest-api (F) REST API design and roadmap]
* 16:30 - 17:10: [https://etherpad.openstack.org/p/YVR-heat-liberty-senlin-autoscaling (F) Senlin Autoscaling Project - Deep Dive]
* 17:20 - 18:00: [https://etherpad.openstack.org/p/YVR-heat-liberty-containers (F) Orchestrating containers with Heat]

'''Thu'''
* 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-heat-liberty-alembic (W) Migrating from sqlalchemy-migrations to alembic]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-heat-liberty-versioned-objects (W) Future of Versioned objects in heat]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-heat-liberty-autoscaling (W) Autoscaling improvements]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-heat-liberty-deprecation (W) Our deprecation process]
* 16:10 - 16:50: [https://etherpad.openstack.org/p/YVR-heat-liberty-contrib-plugins (W) Moving most contrib plugins in-tree]
* 17:00 - 17:40: [https://etherpad.openstack.org/p/YVR-heat-liberty-resource-registering (W) Conditional registering of resources]

'''Fri'''
* 09:00-12:20: [https://etherpad.openstack.org/p/YVR-heat-contributor-meetup Contributor Meetup]

==Horizon==
* Wed 9:00 Plugins https://etherpad.openstack.org/p/YVR-horizon-plugins
* Wed 9:50 Merlin and Curvature https://etherpad.openstack.org/p/YVR-horizon-new-tech
* Wed 13:50 Keystone and session storage https://etherpad.openstack.org/p/YVR-horizon-keystone
* Thurs 9:00 Angular Planning https://etherpad.openstack.org/p/YVR-horizon-angular-planning
* Thurs 9:50 Angular Specifics https://etherpad.openstack.org/p/YVR-horizon-angular-topics
* Thurs 11:00 User Experience https://etherpad.openstack.org/p/YVR-horizon-ux
* Thurs 11:50 Performance, Scalability, Elastic Search https://etherpad.openstack.org/p/YVR-horizon-performance
* Thurs 13:30 Operator Feedback https://etherpad.openstack.org/p/YVR-horizon-ops-feedback
* Thurs 14:20 Plan to address Operator Feedback https://etherpad.openstack.org/p/YVR-horizon-addressing-ops-feedback
* Thurs 15:10 Messaging (better error messages to users AND websockets) https://etherpad.openstack.org/p/YVR-horizon-liberty-messaging
* Thurs 17:00 Liberty Priorities https://etherpad.openstack.org/p/YVR-horizon-liberty-priorities
* Fri 9:00 Contributor Meetup #1 https://etherpad.openstack.org/p/YVR-horizon-collab-meetup
* Fri 1:20 Contributor Meetup #2 https://etherpad.openstack.org/p/YVR-horizon-collab-meetup

==Infrastructure==
* Wed 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-infra-irc-meetings (W) Work session on Gerrit-driven IRC meetings]
* Wed 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-infra-activity-tracking (W) Work session on activity tracking]
* Thu 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-infra-zuulv3 (F) Zuul v3]
* Thu 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-infra-task-tracking (F) Task tracking]
* Thu 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-infra-cloud (F) Infra-Cloud]
* Thu 11:50 - 12:30: [https://etherpad.openstack.org/p/kilo-infra-puppet-testing (F) Puppet Testing]
* Thu 15:10 - 16:50: [https://etherpad.openstack.org/p/YVR-infra-puppet-openstackci (W) Work session on puppet-openstackci]

==Ironic==
https://etherpad.openstack.org/p/liberty-ironic-design-summit-ideas

==Keystone==
==Manila==
'''Wed'''
* 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-manila-liberty-mount-automation (F) Mount automation]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-manila-liberty-share-migration (F) Share migration]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-manila-liberty-share-replication (F) Share replication]
* 16:30 - 17:10: [https://etherpad.openstack.org/p/YVR-manila-liberty-versioned-objects-and-apis (W) Versioned objects and APIs]
* 17:20 - 18:00: [https://etherpad.openstack.org/p/YVR-manila-liberty-fault-indication (W) Fault indication]

'''Thu'''
* 16:10 - 16:50: [https://etherpad.openstack.org/p/YVR-manila-liberty-thin-provisioning (W) Thin provisioning and consistency groups]
* 17:00 - 17:40: [https://etherpad.openstack.org/p/YVR-manila-service-image (W) Snapshot-share relationship and Manila service image]

==Neutron==
'''Mon'''
* 20:00 - 22:30: [http://lists.openstack.org/pipermail/openstack-dev/2015-May/064323.html Neutron Social]

'''Wed'''
* 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-neutron-liberty-development Neutron Liberty Development]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-neutron-use-case-discussion Neutron Use Case Discussion]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-neutron-vlan-trunk VLAN Aware VMs]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-neutron-lightning-talks Neutron Lightning Talks]
* 13:50 - 14:30: [https://etherpad.openstack.org/p/YVR-neutron-octavia Octavia]
* 14:40 - 15:20: [https://etherpad.openstack.org/p/YVR-neutron-ironic Ironic and Neutron integration]
* 15:30 - 16:10: [https://etherpad.openstack.org/p/YVR-neutron-ovn OVN]
* 16:30 - 17:10: [https://etherpad.openstack.org/p/YVR-neutron-opendaylight OpenDaylight]
* 17:20 - 18:00: [https://etherpad.openstack.org/p/YVR-neutron-get-me-a-network Get Me a Network!]

'''Thu'''
* 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases Neutron LBaaS Use Cases]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-neutron-l3 Neutron L3]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-neutron-qos QoS]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-neutron-third-party-ci-liberty Third Party CI in Liberty and Beyond]
* 13:30 - 14:10: [https://etherpad.openstack.org/p/YVR-neutron-testing-in-liberty Testing In Liberty]
* 14:20 - 15:00:
** [https://etherpad.openstack.org/p/YVR-neutron-RBAC RBAC shared network]
** [https://etherpad.openstack.org/p/YVR-neutron-port-status Neutron Port Status]
* 15:10 - 15:50: [https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction SG and FWaaS Future Directions]
* 16:10 - 16:50: [https://etherpad.openstack.org/p/YVR-neutron-nfv-enhancements Neutron NFV Enhancements]

'''Fri'''
* 09:00-12:20: [https://etherpad.openstack.org/p/YVR-neutron-contributor-meetup Contributor Meetup]

==Nova==

'''Wednesday:'''

* 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-nova-scheduler-in-liberty Scheduler in Liberty]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-nova-scalling-out-scheduler-for-cells Scaling out scheduler for cells ]

* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-nova-cells-v2 Cells v2]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-nova-resource-tracker Resource Tracker, Clustered Hypervisors and NFV]

* 13:50 - 14:30: [https://etherpad.openstack.org/p/YVR-nova-spec-blueprint-unconference Nova Spec/Blueprint Unconference]
* 14:40 - 15:20: [https://etherpad.openstack.org/p/YVR-nova-database-internals Database (part 1)]
* 15:30 - 16:10: [https://etherpad.openstack.org/p/YVR-nova-functional-testing-feature-classification Functional Testing and Feature Classification]

* 16:30 - 17:10: [https://etherpad.openstack.org/p/YVR-nova-instance-ha-evacuate-resize Dealing with compute host failure: Instance HA, Evacuate, Resize]
* 17:20 - 18:00: [https://etherpad.openstack.org/p/YVR-nova-api-2.1-in-liberty Nova API v2.1 in Liberty]

 
'''Thursday:'''

* 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-nova-api-2.0-3rd-party Future of Nova API v2.0 and 3rd Party APIs]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-nova-quotas-and-database Quotas and Database (part 2)]

* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-nova-flavors-and-image-properties Flavors and Image Properties]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-nova-error-handling Error Handling]

* 13:30 - 14:10: [https://etherpad.openstack.org/p/YVR-nova-spec-blueprint-unconference Nova Spec/Blueprint Unconference]
* 14:20 - 15:00: [https://etherpad.openstack.org/p/YVR-nova-liberty-priorities Liberty Priorities (part 1)]
* 15:10 - 15:50: [https://etherpad.openstack.org/p/YVR-nova-liberty-priorities Liberty Priorities (part 2)]

* 16:10 - 16:50: [https://etherpad.openstack.org/p/YVR-nova-liberty-process Liberty Process and Scaling out Reviews]
* 17:00 - 17:40: [https://etherpad.openstack.org/p/YVR-nova-network Future of Nova's networking and nova-network]

 
'''Friday:'''

* 09:00 - 12:20 and 13:20 - 16:40: [https://etherpad.openstack.org/p/YVR-nova-contributor-meetup Nova Contributor Meetup]

==OpenStackClient==

'''Thursday:'''

* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-osc-roadmap (F) Roadmap and Priorities]
* 14:20 - 15:00: [https://etherpad.openstack.org/p/YVR-osc-work-session (W) Working session]

==Oslo==

'''Wednesday:'''

* 09:00 - 09:40: [https://etherpad.openstack.org/p/YVR-oslo-versioned-objects-intro (F) Get to know your objects and learn how to version them (an introduction to oslo.versionedobjects)!]
* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-oslo-taskflow-plans (F) Give me liberty, or give me taskflow (come learn about taskflow liberty plans)!]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-oslo-rootwrap-plans (W) Give me liberty, or give me wraps (the future of oslo.rootwrap) ]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-oslo-functional-testing (W) The cost of liberty is less than the price of functional testing]
* 13:50 - 14:30: [https://etherpad.openstack.org/p/YVR-oslo-graduation-schedule (W) Give me more oslo in liberty or else! Schedule & new libraries]
* 14:40 - 15:20: [https://etherpad.openstack.org/p/YVR-oslo-messaging-zmq-status (F) State of zmq in oslo.messaging]
* 15:30 - 16:10: [https://etherpad.openstack.org/p/YVR-oslo-optional-dependencies (W) Emancipate/liberate your optional dependencies - Optional Dependencies]
* 16:30 - 17:10: [https://etherpad.openstack.org/p/YVR-oslo-release-process-review (W) Reviewing our release processes]
* 17:20 - 18:00: [https://etherpad.openstack.org/p/YVR-oslo-config-filter (W) Configuration Filters in oslo.config]

 
'''Thursday:'''

* 09:50 - 10:30: [https://etherpad.openstack.org/p/YVR-oslo-strategy-discussion (F) The oslo liberty proclamation (and associated strategy discussion)]
* 11:00 - 11:40: [https://etherpad.openstack.org/p/YVR-oslo-config-plans (F) Enfranchise oslo.config, let's discuss alternative data sources in oslo.config]
* 11:50 - 12:30: [https://etherpad.openstack.org/p/YVR-oslo-log-plans (W) Life, Liberty, and the pursuit of oslo.log changes]
* 13:30 - 14:10: [https://etherpad.openstack.org/p/YVR-oslo-versioned-objects-deep-dive (W) Deep dive on oslo.versionedobjects, bring your wet suits.]
* 14:20 - 15:00: [https://etherpad.openstack.org/p/YVR-oslo-db-plans (F) For a people who are free, and who mean to remain so, a well organized and armed 'oslo.db' is their best security]
* 15:10 - 15:50: [https://etherpad.openstack.org/p/YVR-oslo-asyncio (F) Event loops, coroutines, yield from, futures, a discussion on asyncio (and triollus?)]
* 16:10 - 16:50: [https://etherpad.openstack.org/p/YVR-oslo-messaging-plans (F) Ping pong, oslo.messaging plans for liberty.]
* 17:00 - 17:40: [https://etherpad.openstack.org/p/YVR-oslo-tech-debt-deprecation (F) How to clean up your tech-debt; let's discuss best practices on how to deprecate things in oslo libraries]

 

==QA==

'''Wed'''

* 1150-1230 - [https://etherpad.openstack.org/p/YVR-QA-testing-beyond-the-gate Testing beyond the gate]
* 1350-1430 - [https://etherpad.openstack.org/p/YVR-QA-Devstack-Roadmap Devstack Roadmap]
* 1440-1520 - [https://etherpad.openstack.org/p/YVR-QA-Tempest-service-clients Work Session: Tempest service clients]
* 1630-1710 - [https://etherpad.openstack.org/p/YVR-QA-in-the-big-tent QA in the Big Tent]

'''Thurs.'''
* 0900-0940 - [https://etherpad.openstack.org/p/YVR-QA-idempotent-id Work Session: Idempotent ID]
* 1330-1410 - [https://etherpad.openstack.org/p/YVR-QA-Tempest-as-a-system-program Work Session: Tempest as System Program]
* 1420-1500 - [https://etherpad.openstack.org/p/YVR-QA-Tempest-CLI Work Session: Tempest CLI and Tempest Cleanup]
* 1610-1650 - [https://etherpad.openstack.org/p/YVR-QA-Tempest-Scope-Revisited Tempest Scope Revisited]
* 1700-1740 - [https://etherpad.openstack.org/p/YVR-QA-Liberty-Priorities Liberty Priorities]

==Release Management==
* Wed 17:20-18:00: [https://etherpad.openstack.org/p/YVR-relmgt-stable-branch Stable branch]
* Thu 11:00-11:40 [https://etherpad.openstack.org/p/YVR-relmgt-library-releases Work session: Library releases]

==Sahara==

'''Wed'''

* 11:00am (W) HA http://etherpad.openstack.org/p/sahara-liberty-ha
* 11:50am (W) API v2 https://etherpad.openstack.org/p/sahara-liberty-api-v2

''Thu'''

* 1:30pm (F) UI https://etherpad.openstack.org/p/sahara-liberty-ui
* 2:20pm (F) Security https://etherpad.openstack.org/p/sahara-liberty-security
* 3:10pm (W) EDP https://etherpad.openstack.org/p/sahara-liberty-edp
* 4:10pm (W) Resources Visibility/ACL https://etherpad.openstack.org/p/sahara-liberty-resources
* 5:00pm (W) Plugins https://etherpad.openstack.org/p/sahara-liberty-plugins

''Fri'''

* 9am - 4:40pm Meetup https://etherpad.openstack.org/p/sahara-liberty-meetup

==Security==
* Wed 13:50-14:30: [https://etherpad.openstack.org/p/YVR-security-vmt Vulnerability management]

==Swift==
'''Wednesday:'''
* 9:00am - 9:40am: [https://etherpad.openstack.org/p/liberty-swift-large-containers Large containers (container sharding)]
* 9:50am - 10:30am: [https://etherpad.openstack.org/p/python-swiftclient-liberty-discussion python-swiftclient status and next steps]
* 11:00am - 11:40am [https://etherpad.openstack.org/p/liberty-swift-changing-policies Changing Policies]
* 1:50pm - 2:30pm [https://etherpad.openstack.org/p/liberty-swift-increase-part-power Increasing ring partition power]
* 3:30pm - 4:10pm [https://etherpad.openstack.org/p/liberty-swift-documentation Swift Documentation]
* 4:30pm - 5:10pm [https://etherpad.openstack.org/p/liberty-swift-softlayer Softlayer]
* 5:20pm - 6:00pm [https://etherpad.openstack.org/p/Liberty_Swift_Summit_Encryption Swift on-disk encryption]
 
'''Thursday:'''
* 9:00am - 9:40am: [https://etherpad.openstack.org/p/Liberty_Swift_Summit_Storlets Swift Storlets]
* 9:50am - 10:30am: [https://etherpad.openstack.org/p/liberty-swift-ops-feedback Ops Feedback Session]
* 11:00am - 11:40am: [https://etherpad.openstack.org/p/liberty-swift-tape-storage Tape Storage]
* 11:50am - 12:30pm: [https://etherpad.openstack.org/p/liberty-swift-hummingbird Hummingbird: Scaling Swift using Go]
* 1:30pm - 2:10pm: [https://etherpad.openstack.org/p/liberty-swift-ec-overview EC Overview]
* 2:20pm - 3:00pm: [https://etherpad.openstack.org/p/liberty-swift-metadata-search Metadata search/object update notification]
* 3:10pm - 3:50pm: [https://etherpad.openstack.org/p/liberty-swift-ec-follow-on-work EC follow on work]
* 4:10pm - 4:50pm: [https://etherpad.openstack.org/p/Liberty_Swift_Summit_Encryption_Working Encryption]
* 5:00pm - 5:40pm: [https://etherpad.openstack.org/p/liberty-swift-tiering Tiering]
 
'''Friday:'''
* All day: [https://etherpad.openstack.org/p/liberty-swift-contributors-meetup Contributors' Meetup]

==TripleO==
'''Thursday:'''
* 1:30pm - 2:10pm: [https://etherpad.openstack.org/p/tripleo-liberty-tripleo-heat-templates tripleo-heat-templates interfaces and containerization enablement]
* 2:20pm - 3:00pm: [https://etherpad.openstack.org/p/tripleo-dib-ci-production diskimage-builder functional testing, CI, and TripleO in production]
* 3:10pm - 3:50pm: [https://etherpad.openstack.org/p/tripleo-service-endpoints Work Session: Isolated network architecture]
* 5:00pm - 5:40pm: Work Session
 
'''Friday:'''
* 9:00am - 12:20pm: [https://etherpad.openstack.org/p/tripleo-liberty-proposed-sessions Contributor's Meetup]
* 1:20pm - 4:40pm: [https://etherpad.openstack.org/p/tripleo-liberty-proposed-sessions Contributor's Meetup]

==Trove==
'''Wednesday:'''
* 2:40pm - 3:20pm: [https://etherpad.openstack.org/p/trove-liberty-extending-clusters Extending Cluster creation and actions for extensibility]
* 3:30pm - 4:10pm: [https://etherpad.openstack.org/p/trove-liberty-datastore-testing Testing Different Trove Datastores -- the path from experimental to stable]
* 4:30pm - 5:10pm [https://etherpad.openstack.org/p/trove-2015-vancouver-logging Show me the Logs -- Allowing Trove Users Access to Datastore Log files]
 
'''Thursday:'''
* 9:00am - 9:40am: [https://etherpad.openstack.org/p/trove-liberty-bp-update Work session - Blueprint and Spec Priorities for Liberty]
* 9:50am - 10:30am: [https://etherpad.openstack.org/p/trove-liberty-production-deploy Work session - Deploying Trove in Production]
* 1:30pm - 2:10pm: [https://etherpad.openstack.org/p/trove-liberty-monitoring Work session - Monitoring Trove Datastores]
* 2:20pm - 3:00pm: [https://etherpad.openstack.org/p/trove-liberty-openstack-integration Work session - Trove integration with other OpenStack components]
* 3:10pm - 3:50pm: [https://etherpad.openstack.org/p/trove-liberty-gaps-in-trove Work session - Gaps in Trove]
 
'''Friday:'''
* All day: [https://etherpad.openstack.org/p/trove-liberty-contributors-meetup Contributors' Meetup]

==Zaqar==

* Thursday, May 21 - 3.10pm to 3.50pm - Room 222 - [https://etherpad.openstack.org/p/zaqar-liberty-ops-friendly Zaqar needs to be OPs friendly]
* Thursday, May 21 - 4.10pm to 4.50pm - Room 222 - [https://etherpad.openstack.org/p/zaqar-liberty-testsuite Test suite refactor for Zaqar and Zaqarclient]

==Murano==
'''Thu'''

* 2:20pm (F) [https://etherpad.openstack.org/p/murano-liberty-now-n-future Murano: Now, Liberty and Future]
* 4:10pm (W) [https://etherpad.openstack.org/p/murano-liberty-work-session-1 Images & Murano]
* 5:00pm (W) [https://etherpad.openstack.org/p/murano-liberty-work-session-2 Authentication & Agent]

'''Fri'''

* 9am - 4:40pm [https://etherpad.openstack.org/p/murano-liberty-contributors-meetup Contributors Meetup]

==Event intro/closure==
* Tue 11:15-11:55: [https://etherpad.openstack.org/p/YVR-design-summit-101 Design Summit 101]
* Fri 16:50-17:30: [https://etherpad.openstack.org/p/YVR-design-summit-feedback Design Summit feedback session]

==Ops==
Tuesday:
* https://etherpad.openstack.org/p/YVR-ops-101
* https://etherpad.openstack.org/p/YVR-ops-federation
* https://etherpad.openstack.org/p/YVR-ops-rabbitmq
* https://etherpad.openstack.org/p/YVR-ops-logging
* https://etherpad.openstack.org/p/YVR-ops-arch-show-tell
* https://etherpad.openstack.org/p/YVR-ops-ceilometer
* https://etherpad.openstack.org/p/YVR-ops-billing
* https://etherpad.openstack.org/p/YVR-ops-cinder
* https://etherpad.openstack.org/p/YVR-ops-legacy-apps
* https://etherpad.openstack.org/p/YVR-ops-user-committee
* https://etherpad.openstack.org/p/YVR-ops-hypervisor-tuning
* https://etherpad.openstack.org/p/YVR-ops-security
* https://etherpad.openstack.org/p/YVR-ops-deployment
* https://etherpad.openstack.org/p/YVR-ops-database
* https://etherpad.openstack.org/p/YVR-ops-evangelism
* https://etherpad.openstack.org/p/YVR-ops-multi-site
* https://etherpad.openstack.org/p/YVR-ops-nova
* https://etherpad.openstack.org/p/YVR-ops-customer-onboarding
* https://etherpad.openstack.org/p/YVR-ops-containers
* https://etherpad.openstack.org/p/YVR-ops-neutron

Wednesday:
* https://etherpad.openstack.org/p/YVR-ops-telco
* https://etherpad.openstack.org/p/YVR-ops-puppet
* https://etherpad.openstack.org/p/YVR-ops-chef
* https://etherpad.openstack.org/p/YVR-ops-hpc
* https://etherpad.openstack.org/p/YVR-ops-tools
* https://etherpad.openstack.org/p/YVR-ops-ansible
* https://etherpad.openstack.org/p/YVR-ops-ceph
* https://etherpad.openstack.org/p/YVR-ops-tags
* https://etherpad.openstack.org/p/YVR-ops-large-deployments
* https://etherpad.openstack.org/p/YVR-ops-burning-issues
* https://etherpad.openstack.org/p/YVR-ops-docs
* https://etherpad.openstack.org/p/YVR-ops-tech-choices
* https://etherpad.openstack.org/p/YVR-ops-cmdb
* https://etherpad.openstack.org/p/YVR-ops-data-plane-transitions
* https://etherpad.openstack.org/p/YVR-ops-upgrades
* https://etherpad.openstack.org/p/YVR-ops-packaging
* https://etherpad.openstack.org/p/YVR-ops-nova-network

==Group Based Policy (GBP)==
* https://etherpad.openstack.org/p/gbp-liberty-design-summit

== Magnum ==
Wednesday
* 09:00 AM - 09:40 AM https://etherpad.openstack.org/p/liberty-fishbowl-using-native
* 09:50 AM - 10:30 AM https://etherpad.openstack.org/liberty-fishbowl-determining-storage
* 11:00 AM - 11:40 AM https://etherpad.openstack.org/p/liberty-fishbowl-cultivating-caas-apps
* 11:50 AM - 12:30 PM https://etherpad.openstack.org/liberty-fishbowl-magnum-project-ideas
* 2:40 PM - 3:20 PM https://etherpad.openstack.org/liberty-work-tls-endpoint
* 3:30 PM - 4:10 PM https://etherpad.openstack.org/liberty-work-native-networking
* 4:30 PM - 5:10 PM http://etherpad.openstack.org/liberty-work-ci-functional-testing
* 5:20 PM - 6:00 PM https://etherpad.openstack.org/liberty-work-heat-coe-templates

Thursday
* 11:00 AM - 11:40 AM https://etherpad.openstack.org/liberty-work-magnum-horizontal-scale
* 11:50 AM - 12:30 PM https://etherpad.openstack.org/p/liberty-work-abstract-backend

== Akanda ==
Thursday
* 1:30pm - 2:10pm https://etherpad.openstack.org/p/liberty-akanda-design

== Akanda ==
Thursday
* 3:20pm - 4:00pm https://etherpad.openstack.org/p/liberty-cue-design

Meetings/Cue

2015-05-20T22:58:40Z

Vipuls: /* Weekly Cue meeting */

Cue/api

2015-05-04T18:31:27Z

Vipuls: /* System Context Diagram */

== Cue API Design ==
=== Acronyms ===
{| class="wikitable"
|-
! '''Acronym''' !! '''Definition'''
|-
| SSL || Secure Sockets Layer
|-
| REST || Representational State Transfer
|-
| URI || Uniform Resource Identifier
|-
| UUID || Universally Unique Identifier
|-
| AMQP || Advanced Messaging Queuing Protocol
|}

=== Requirements ===

API Requirements for Cue - Kilo timeframe.

* Keystone integration
* CRUD on Cluster
* Cluster Management – Scale up/down
* Devstack integration
* Gate Tests

=== System Architecture Diagram ===

[[File:Cue-arch.png]]
{| class="wikitable"
|-
! '''Component''' !! '''Description'''
|-
| User || Direct customer of Cue.
|-
| Horizon || Cue functionality will be added to Horizon, which will provide a web-based portal for Cue control.
|-
| CLI || Command Line Interface to Cue, provides user access to provisioning and deploying messaging clusters.
|-
| REST_API || Provides user access to provisioning and deploying messaging clusters through REST interface. This is a light-weight interface, provisioning and configuration of clusters/nodes is delegated to the TaskWorker process.
|-
| TaskScheduler || Used to synchronize work tasks between the REST_API and TaskWorker processes.
|-
| TaskWorker || Carries out work associated with all provisioning, configuration and management of RabbitMQ clusters and nodes. Makes use of heat for initial provisioning/deployment.
|-
| DB || Database to store information on clusters and nodes. Example, in cluster creation, when request is initially received through REST_API, this DB is updated accordingly and the work is delegated to TaskWorker. TaskWorker then updates this DB as provisioning and configuration takes place. Subsequent calls to check on status of cluster creation, will return updated information from this DB.
|-
| Heat || Used cloud instance orchestration in deploying RabbitMQ cluster images.
|}

=== REST API ===

General requirement, REST API must respond within 500ms.
==== List Clusters ====

'''''GET /v1/clusters'''''

This operation synchronously returns all clusters provisioned within the associated project id.

'''Request Parameters'''
N/A

{| class="wikitable"
|-
! Response !! Code(s)
|-
| Normal || ok (200)
|-
| Error || unauthorized (401)
|}

'''Response Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster(list) || string || List of clusters, detailing respective cluster id, name, status, created time stamp and updated time stamp.
|}

'''JSON Request'''

N/A

'''JSON Response'''

{
"clusters": <nowiki>[</nowiki>
{
"cluster_id": "b51948c9-1ac5-4c28-a580-6f7c500d82f8",
"network_id": "d32019d3-bc6e-4319-9c1d-6722fc136a22",
"name": "Message Cluster 1",
"status": "ACTIVE",
"created": "2014-11-11T01:02:03Z",
"updated": "2014-11-11T01:02:03Z"
},
{
"cluster_id": "13c456c9-bbfc-4c31-b26d-3ae5c3cd7a77",
"network_id": "d32019d3-bc6e-4319-9c1d-6722fc136a22",
"name": "Message Cluster 2",
"status": "ACTIVE",
"created": "2014-11-12T13:23:54Z",
"updated": "2014-11-13T19:55:01Z"
}
]
}

==== Create Cluster ====

'''''POST /v1/clusters'''''

This operation asynchronously creates a new cluster of Nova instances provisioned with the required message brokers in a central project id.

'''Request Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| nic || UUID || Network Identification for a Neutron network where cluster will be created in.
|-
| name || string || Name of cluster.
|-
| volume_size || int || Optional parameter to indicate size of volume for node instance. If volumes are supported, then this parameter will be used. If ephmeral disk are not supported, volume support will be required.
|-
| flavor (list) || string || List of node flavors, which specify VM type in terms of CPU/memory/disk resources. See http://docs.openstack.org/openstack-ops/content/flavors.html for more information.
|}

'''Response Codes'''

{| class="wikitable"
|-
! Response !! Code(s)
|-
| Normal || 202 (accepted)
|-
| Error || badRequest (400), unauthorized (401), itemNotFound (404)
|}

'''Response Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster_id || UUID || ID of cluster to be created.
|-
| name || string || Name of cluster (same as provided name in request parameters).
|-
| status || string || Current status of cluster.

BUILDING: Cluster is in progress of being provisioned.

UPDATING: Cluster in process of being updated.

ACTIVE: Cluster is running.

ERROR: Provisioning error(s) encountered.

DELETING: Cluster is in process of being deleted.

DELETED: Cluster has been deleted.
|}

'''JSON Request'''

{
"network_id": "d32019d3-bc6e-4319-9c1d-6722fc136a22",
"name": "MessageCluster1",
"volume_size": "100",
"nodes": [
{
"flavor": "large"
},
{
"flavor": "large"
},
{
"flavor": "large"
}
]
}

'''JSON Response'''

{
"cluster": {
"cluster_id": "dd745f4a-9333-417e-bb89-9c989c84c068",
"network_id": "d32019d3-bc6e-4319-9c1d-6722fc136a22",
"name": "Message Cluster 1",
"status": "BUILDING",
"created": "2014-11-11T01:02:03Z",
"updated": "2014-11-11T01:02:03Z",
"nodes": [
{
"node_id": "616fb98f-46ca-475e-917e-2563e5a8cd19",
"status": "BUILDING",
"flavor": "large"
},
{
"node_id": "e90c9d13-c4b8-4a08-992a-dad6109b8ac2",
"status": "BUILDING",
"flavor": "large"
},
{
"node_id": "372f8f47-6818-4d83-aa42-8744c0e689b8",
"status": "BUILDING",
"flavor": "large"
}
]
}
}

==== Show Cluster ====

'''''GET /v1/clusters/{cluster_id}'''''

This operation synchronously returns the status and information on the specified cluster within the provided project id.

'''Request Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster_id (URI) || UUID || Cluster ID. This value is returned when a new cluster is created.
|}

'''Response Codes'''

{| class="wikitable"
|-
! Response !! Code(s)
|-
| Normal || ok (200)
|-
| Error || unauthorized (401), itemNotFound (404)
|}

'''Response Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster_id || UUID || ID of requested cluster.
|-
| name || string || Name of cluster.
|-
| status || string || Current status of cluster.

BUILDING: Cluster is in progress of being provisioned.

UPDATING: Cluster in process of being updated.

ACTIVE: Cluster is running.

ERROR: Provisioning error(s) encountered.

DELETING: Cluster is in process of being deleted.

DELETED: Cluster has been deleted.
|-
| created || string || Created time stamp in format: yyyy-mm-ddThh:mm:ssZ
|-
| updated || string || Last updated time stamp in format: yyyy-mm-ddThh:mm:ssZ
|-
| nodes(list) || node || List of nodes, which includes node id, instance state, and flavor.
|}

'''JSON Request'''

N/A

'''JSON Response'''

{
"cluster": {
"cluster_id": "dd745f4a-9333-417e-bb89-9c989c84c068",
"network_id": "d32019d3-bc6e-4319-9c1d-6722fc136a22",
"name": "Message Cluster 1",
"status": "ACTIVE",
"created": "2014-11-11T01:02:03Z",
"updated": "2014-11-11T01:02:03Z",
"nodes": [
{
"node_id": "616fb98f-46ca-475e-917e-2563e5a8cd19",
"status": "ACTIVE",
"flavor": "large",
"endpoints": [
{
"type": "AMQP",
"value": "amqp://10.20.30.40:10000"
},
{
"type": "console",
"value": "http://10.20.30.40:5672"
}
],
"created": "2014-11-11T01:06:03Z",
"updated": "2014-11-11T01:06:03Z"
},
{
"node_id": "e90c9d13-c4b8-4a08-992a-dad6109b8ac2",
"status": "ACTIVE",
"flavor": "large",
"endpoints": [
{
"type": "AMQP",
"value": "amqp://10.20.30.41:10000"
},
{
"type": "console",
"value": "http://10.20.30.41:5672"
}
],
"created": "2014-11-11T01:08:03Z",
"updated": "2014-11-11T01:08:03Z"
},
{
"node_id": "372f8f47-6818-4d83-aa42-8744c0e689b8",
"status": "ACTIVE",
"flavor": "large",
"endpoints": [
{
"type": "AMQP",
"value": "amqp://10.20.30.42:10000"
},
{
"type": "console",
"value": "http://10.20.30.42:5672"
}
],
"created": "2014-11-11T01:12:03Z",
"updated": "2014-11-11T01:12:03Z"
}
]
}
}

==== Delete Cluster ====

'''''DELETE /v1/clusters/{cluster_id}'''''''

This operation will asynchronously delete the indicated cluster within the provided project id.

'''Request Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster_id (URI) || UUID || Cluster ID. This value is returned when a new cluster is created.
|}

'''Response Codes'''

{| class="wikitable"
|-
! Response !! Code(s)
|-
| Normal || accepted (202)
|-
| Error || unauthorized (401), itemNotFound (404)
|}

'''Response Parameters'''

N/A

'''JSON Request'''

N/A

'''JSON Response'''

N/A

===Testing===

Cue API testing will verify the expected functionality of the Cue user interface with both positive/negative tests. The overall scope will cover testing from the HTTP REST request to required database interactions and work-flow task submission for RPC workers.

====Unit Tests====

Unit tests will verify the resulting function calls for each REST-ful URI and action(s). The Python Mock library will be used to replace external system dependencies with placeholder objects.

{| class="wikitable"
|-
! Function !! Tests !! Input Data !! Expected Result(s)
|-
| List Clusters ||
# Create 'n' cluster(s), then call list clusters and verify expected return object
# Call list clusters when no clusters exist within the project id and verify expected return object
||
* n = # of clusters to create
||
# List of 'n' clusters is returned with appropriate fields, HTTP Ok (200)
# Empty list of clusters is returned, HTTP Ok (200)
|-
| Create Cluster ||
# Create standard cluster 'c' and verify expected return object
# Create cluster with invalid flavor and verify expected return value
# Create cluster with invalid volume size and verify expected return value
||
* n = cluster size (number of nodes)
* m = cluster name
* f = flavor
* s = volume size
* nic = Network UUID
||
# Cluster ID, name and status for newly created cluster is returned, HTTP Accepted (202)
# HTTP Bad request is returned (400)
# HTTP Bad request is returned (400)
|-
| Show Cluster ||
# Create cluster, then call get cluster and verify expected return object
# Get cluster with invalid cluster_id
||
* cluster_id = cluster ID
||
# Cluster ID, name, status, created/updated date stamp and list of nodes is returned, HTTP Ok (200).
# HTTP Bad request is returned (400)
|-
| Delete Cluster ||
# Create a cluster, then call delete cluster and verify expected return value
# Delete cluster with invalid cluster_id
||
* cluster_id = cluster ID
||
# HTTP accepted is returned (202)
# HTTP Bad request is returned (400)
|}

====Functional Tests====

The functional tests will verify the HTTP REST URI request lifecycle from controller routing to HTTP response. These tests will make use of Pecan's testing utility; pecan.testing module.

{| class="wikitable"
|-
! Operation !! URI !! Tests !! Input Data !! Expected Data (JSON)
|-
| GET || /v1/clusters ||
# Call when clusters exist
# Call when no clusters exist
||
* n/a
||
# List of 'n' clusters is returned with appropriate fields, HTTP Ok (200)
# Empty list of clusters is returned, HTTP Ok (200)
|-
| POST || /v1/clusters ||
# Create standard cluster 'c' and verify expected return object
# Create cluster with invalid flavor and verify expected return value
# Create cluster with invalid volume size and verify expected return value
||
* n = cluster size (number of nodes)
* m = cluster name
* f = flavor
* s = volume size
* nic = Network UUID
||
# Cluster ID, name and status for newly created cluster is returned, HTTP Accepted (202)
# HTTP Bad request is returned (400)
# HTTP Bad request is returned (400)
||
|-
| GET || /v1/clusters/{cluster_id} ||
# Create cluster, then call get cluster and verify expected return object
# Get cluster with invalid cluster_id
||
* cluster_id = cluster
||
# Cluster ID, name, status, created/updated date stamp and list of nodes is returned, HTTP Ok (200).
# HTTP Bad request is returned (400)
||
|-
| DELETE || /v1/clusters/{cluster_id} ||
# Create a cluster, then call delete cluster and verify expected return value
# Delete cluster with invalid cluster_id
||
* cluster_id = cluster ID
||
# HTTP accepted is returned (202)
# HTTP Bad request is returned (400)
||
|}

====Integration Tests====

The integration tests will cover API functionality from HTTP request to database access and task submission for RPC workers. The Pecan test utility will be used to route test request URI to appropriate controllers, then database record(s) will be verified for applicable change. Finally the creation of task objections will be verified to ensure valid task flows.

File:Cue-arch.png

2015-05-04T18:26:49Z

Vipuls:

Meetings/Cue

2015-04-01T22:04:09Z

Vipuls: /* Next meetings */

= Weekly Cue meeting =

The [https://launchpad.net/cue Cue] project holds a weekly team meeting every Tuesday at following time/place:
* [http://www.timeanddate.com/worldclock/fixedtime.html?hour=18&min=0&sec=0%201900%20UTC 18:00 UTC] in <code><nowiki>#openstack-meeting-alt</nowiki></code>

== Next meeting ==
April 7, 2015 - http://www.timeanddate.com/worldclock/fixedtime.html?msg=Cue+Weekly+Meeting&iso=20150407T18&p1=1440&ah=1

==== Agenda ====
* Kick-off!
* Integration Testing
* Open Discussion

Meetings/Cue

2015-04-01T18:46:24Z

Vipuls: /* Weekly Cue meeting */

= Weekly Cue meeting =

The [https://launchpad.net/cue Cue] project holds a weekly team meeting every Tuesday at following time/place:
* [http://www.timeanddate.com/worldclock/fixedtime.html?hour=18&min=0&sec=0%201900%20UTC 18:00 UTC] in <code><nowiki>#openstack-meeting-alt</nowiki></code>

== Next meetings ==
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Cue+Weekly+Meeting&iso=20150407T18&p1=1440&ah=1

==== Agenda ====
* Kick-off!

Meetings/Cue

2015-04-01T18:42:34Z

Vipuls: Created page with "= Weekly Cue meeting = The [https://launchpad.net/cue Cue] project holds a weekly team meeting at following time/place: * [http://www.timeanddate.com/worldclock/fixedtime.htm..."

= Weekly Cue meeting =

The [https://launchpad.net/cue Cue] project holds a weekly team meeting at following time/place:
* [http://www.timeanddate.com/worldclock/fixedtime.html?hour=18&min=0&sec=0%201900%20UTC 18:00 UTC] in <code><nowiki>#openstack-meeting-alt</nowiki></code>

== Next meetings ==

==== Agenda ====

Meetings

2015-04-01T18:40:13Z

Vipuls: /* Zaqar (Messaging and Notification) team meeting */

The OpenStack project holds its various public meetings on '''IRC''', in the <code><nowiki>#openstack-meeting</nowiki></code>, <code><nowiki>#openstack-meeting-alt</nowiki></code>, <code><nowiki>#openstack-meeting-3</nowiki></code>, and <code><nowiki>#openstack-meeting-4</nowiki></code> channels on Freenode. Everyone is encouraged to attend. [http://webchat.freenode.net?randomnick=1&channels=%23openstack-meeting%2C%23openstack-meeting-alt%2C%23openstack-meeting-3%2C%23openstack-meeting-4&prompt=1&uio=d4 Connect to IRC via webclient].

Some guidance on how to create a meeting can be found here: [[Meetings/CreateaMeeting]]

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

== OpenStack Cross-Project meeting ==
* Weekly on Tuesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=21&min=0&sec=0 2100] UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): [[ThierryCarrez]]
* See [[Meetings/CrossProjectMeeting]] for details

== Technical Committee meeting ==
* Weekly on Tuesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=20&min=0&sec=0 2000] UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): [[ThierryCarrez]]
* See [[Meetings/TechnicalCommittee]] for details

== OpenStack Compute (Nova) ==
=== Nova team Meeting ===
* Weekly on Thursdays, alternating times - [http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=0&sec=0 1400] UTC and [http://www.timeanddate.com/worldclock/fixedtime.html?hour=21&min=0&sec=0 2100] UTC
** For 2014 - odd weeks at 1400, even weeks at 2100 (date "+%U")
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair (to contact for more information): Michael Still (even weeks), John Garbutt (odd weeks)
* See [[Meetings/Nova]] for an agenda

=== XenAPI team meeting ===
* Weekly on Wednesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=0&sec=0 1500] UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by: [[JohnGarbutt]]
* See [[Meetings/XenAPI]] for agenda

=== Nova Hyper-V team meeting ===
* Weekly on Tuesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=16&min=0&sec=0 1600] UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by primeministerp (Peter Pouliot)
* See [[Meetings/Hyper-V|Meetings/Hyper-V]] for agenda and details

=== Gantt (Scheduler) team meeting ===
* Weekly on Tuesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=0&sec=0 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 [http://www.timeanddate.com/worldclock/fixedtime.html?hour=17&min=0&sec=0 1700] UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: [[TracyJones]]
* See [[Meetings/VMwareAPI]] for details

=== PCI Passthrough Meeting ===
* Biweekly on Tuesday at [http://www.worldclock.com/world_clock.html 1300 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: baoli (Robert Li)
* See [[Meetings/Passthrough]] for details

=== Nova API meeting ===
* Weekly on Friday at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=00&min=0&sec=0 00ː00] UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: Chris Yeoh
* See [[Meetings/NovaAPI]] for details

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

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

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

===HA Guide Update Meeting ===
* Every Thursday at 21:00 UTC
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair (to contact for more information): [[MattGriffin]]
* See [https://etherpad.openstack.org/p/openstack-haguide-update Etherpad] for an agenda

===Networking Guide Update Meeting ===
* Every Friday at 21:00 UTC
* Google Hangout: https://plus.google.com/hangouts/_/mirantis.com/networking?authuser=0
* Chair (to contact for more information): [[NickChase]]
* See past status reports on the openstack-docs mailing list for typical agenda

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

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

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

== DefCore Progress Update Meeting ==
* Weekly from Jan 2015 through April 2015
* 9 am PT, 60 minutes (will follow daylight savings time)
* Agenda & Connection Details at https://etherpad.openstack.org/p/DefCoreScale.5 (and increments)
* Chairs (to contact for more information): Rob "@zehicle" Hirschfeld & Egle Sigler
* 2/20/2015 DefCoreScale.F2F 10am-4pm Central Details at https://etherpad.openstack.org/p/DefCoreScale.F2F

== State management team meeting ==

Please refer to: [[Meetings#Oslo_Team_meeting|Oslo team meeting]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Networking L2 Gateway meeting ===
* Bi-weekly on Mondays (Every other Monday starting from January 5, 2015) at 1800 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more information): armax/Suhkdev (Armando Migliaccio / Sukhdev Kapur)
* See [[Meetings/L2Gateway]] for details

=== Nova-net to Neutron Migration meeting ===
* Weekly Tuesdays at 0900 UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code> Tuesdays
* Chair (to contact for more information) Anita Kuno (anteaya)
* see [[Meetings/Nova-nettoNeutronMigration]] for agenda
* Currently on hold pending the outcome of the discussion on the mailing list: http://lists.openstack.org/pipermail/openstack-dev/2015-March/060029.html

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

== Cinder team meeting ==
* Weekly on Wednesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=16&min=0&sec=0 1600] UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chaired by [[JohnGriffith]]
* see [[CinderMeetings]] for agenda

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

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

== Monasca (MONaaS) meeting ==
* Weekly Tuesdays at 1600 UTC
* via Vidyo Conferencing (http://www.vidyo.com/), Hosted by Rackspace
* Chair (to contact for more information): Roland Hochmuth
* See [[Meetings/Monasca]] for details

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

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

== Cue (Message Broker as a Service) team meeting ==
* Weekly on Tuesdays at 1800 UTC
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair (to contact for more information): Vipul Sabhaya (vipul)
* See [[Meetings/Cue]] for details

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

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

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

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

== Horizon team meeting ==
* Weekly on Wednesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=20&min=0&sec=0 2000] UTC or [http://www.timeanddate.com/worldclock/fixedtime.html?hour=12&min=0&sec=0 1200] UTC (on alternate weeks)
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair: David Lyle (david-lyle)
* See [[Meetings/Horizon]] for details

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

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

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

== Glance Team meeting ==
* Weekly on Thursdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=0&sec=0 1400]
* IRC channel: <code><nowiki>#openstack-meeting-4</nowiki></code>
* Chair (to contact for more information): nikhil_k (Nikhil Komawar)
* See [[Meetings/Glance]] for details

== Oslo Team meeting ==

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

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

== OpenStack Community Infrastructure Meetings ==

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

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

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

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

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

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

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

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

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

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

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

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

== Hierarchical Multitenancy Meeting ==
* Weekly on Friday at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=16&min=0&sec=0 1600] UTC
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: vishy/schwicke
* See [[Meetings/HierarchicalMultitenancyMeeting]] for details

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

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

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

== Third Party Meeting ==
* Meeting for any component to address Third Party needs
** Two times weekly: Mondays at 1500 UTC as well as Tuesdays at 0800 UTC
** IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
** Chair: anteaya
** See [[Meetings/ThirdParty]] for details
* Working Group: improve the consumability of CI components and documentation (starting January 7th, 2015)
** Weekly on Wednesdays at 1500/0400 UTC (alternating)
** IRC channel: <code><nowiki>#openstack-meeting-4</nowiki></code>
** Chair: krtaylor
** See [[Meetings/ThirdParty]] for details

== MagnetoDB Team meeting ==
* Every second week on Thursdays at 1400 UTC starting March 26th, 2015 (odd weeks)
* IRC channel: <code><nowiki>#magnetodb</nowiki></code>
* Chair: aostapenko, isviridov, dukhlov

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

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

== User Experience (UX) Team Meeting ==
* Every second week on Mondays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=17&min=0&sec=0 1700] UTC starting July 7th, 2014 (even weeks)
* IRC channel: <code><nowiki>#openstack-meeting-3</nowiki></code>
* Chair: jcoufal (Jaromir Coufal)
* See [[Meetings/UX]] for details

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

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

== Puppet OpenStack Team Meeting ==
* Weekly on Tuesday at 1500 UTC
* IRC channel: <code><nowiki>#openstack-meeting-4</nowiki></code> starting March 24, 2015
* Chair: crinkle (colleen@puppetlabs.com)
* See [[Meetings/PuppetOpenStack]] for details

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

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

== Openstack Operators Team Meeting ==
* Weekly on Wednesday at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=18&min=0&sec=0 1800] UTC (next meeting is January 7)
* IRC channel: <code><nowiki>#openstack-meeting-4</nowiki></code>
* Chair: mfisch (Matt Fischer)
* See [[Meetings/openstack-operators]] for details

== OpenStack Ambassadors Meeting ==
* Alternating Weekly on first, third, fifth Tuesdays at [http://www.timeanddate.com/time/zone/usa/san-francisco 08:00 GMT] and second and fourth Fridays at [http://www.timeanddate.com/time/zone/usa/san-francisco 18:00 GMT]
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code>
* Chair: sarob
* See [[Meetings/ambassadors]] for details

== Openstack Ansible Deployment ==
* Weekly on Thursday at [http://www.timeanddate.com/time/zone/usa/san-antonio 1600 UTC]
* IRC channel: <code><nowiki>#openstack-meeting-4</nowiki></code>
* Chair: cloudnull (Kevin Carter)
* See [[Meetings/openstack-ansible]] for details

== OpenStack Product Team Meeting ==
* Bi-Weekly Wednesdays at [http://www.timeanddate.com/time/zone/usa/san-francisco 23:00 UTC]
* IRC channel: <code><nowiki>#openstack-meeting</nowiki></code>
* Chair: sarob
* See [[Meetings/product-team]] for details

== OpenStackClient Team Meeting ==
* Weekly Thursdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=18&min=0&sec=0 1900] UTC
* IRC channel:<code><nowiki>#openstack-meeting</nowiki></code>
* Chair: dtroyer (Dean Troyer)
* See [[Meetings/OpenStackClient]] for details

== OpenStack Log Working Group Meeting ==
* Weekly Wednesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=20&min=0&sec=0 2000] UTC
* IRC channel:<code><nowiki>#openstack-meeting-4</nowiki></code>
* Chair: RockyG (Rochelle Grober)
* See [[Meetings/log-wg]] for details

== Win The Enterprise Work Group ==
* See [[Win_the_Enterprise]] for more details

=== Deployment Team ===
* Chair: Barrett (Carol Barrett)
* Weekly Tuesday at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=0&sec=0 1500] UTC Dial Inː 1-503-264-2663, Bridge: 3; Pass Code: 7053780
=== Cattle & Pets Team ===
* Chair: Barrett (Carol Barrett)
* Weekly Tuesday at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=20&min=0&sec=0 2000] UTC Dial Inː 1-503-264-2663, Bridge: 3; Pass Code: 7053780
=== Business & Marketing Team ===
* Chair: Megan Rossetti
* Weekly Thursday at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=0&sec=0 1500] UTC Dial In: 1-224-225-1234 x 051214
=== Monitoring Team ===
* Chair: Barrett (Carol Barrett)
* Weekly Friday at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=0&sec=0 1500] UTC Dial Inː 1-503-264-2663, Bridge: 3; Pass Code: 7053780

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

Cue

2014-11-26T19:23:13Z

Vipuls: /* Cue */

= Cue =
== Mission Statement ==
The OpenStack Message Broker Provisioning as a Service Mission: To provide scalable and reliable Message Broker provisioning functionality for off the shelf messaging technologies, as well as to provide advanced management, tuning, and administration of underlying message brokers.

== Description ==

Cue is a Message Broker provisioning service for Openstack. Its goal is to simplify and automate the complex tasks of provisioning, management, and administration of message brokers. Users of the service can create and manage multiple clusters of Message brokers, of various types as needed. The service will provide resource isolation at the VM level, and does not attempt to implement multi-tenancy at the message broker layer.

== Why ==
Messaging is a common development pattern for building loosely coupled distributed systems. Messaging systems also act as glue between independent applications. Several off-the-shelf products exist that implement messaging and queuing semantics.

Provisioning and supporting Messaging systems for an individual application can be a time consuming and painful experience. This product aims to simplify the provisioning and management of messaging systems, providing High Availability and auto-healing capabilities to the end user, while providing tenant-level isolation.

The main goal of this service is to simplify the end user Application development lifecycle and allow the developer to focus on their application, instead of the backend middleware services.

== Use Cases (in-work) ==
'''Macro'''
# IT teams providing managed, highly available message brokers to their app development teams, on private clouds they own and operate.
# OpenStack service providers seeking to provide a managed, highly available messaging service with multiple backends such as RabbitMQ and Kafka to their end users.

'''Micro'''
# Distributing work between micro-services deployed on top of OpenStack via PaaS offerings like Cloud Foundry.
# Sending messages between legacy systems and cloud native applications.

== Goals ==

# Produce a Message Broker Provisioning Service for Openstack
# Protocol Agnostic
# Support multiple Broker backends
# Provide HA and Fault Tolerance by leveraging underlying Broker Cluster capabilities
# Provide tuned and properly configured Message Brokers on-demand
# Support Broker management operations such as Backup of Configuration, Scale Up, Scale Down

== Non-Goals ==

# Data plane API
# Multi-tenancy at the Message Broker layer

== Brokers ==
Cue will support the following brokers (in order of priority):
# RabbitMQ
# qpid
# Kafka
# .. others?

== API ==
API documentation is located here: [https://wiki.openstack.org/wiki/Cue/api Cue API Documentation]

== Code ==
We've started building the project, it now lives on Stackforge.

https://github.com/stackforge/cue

== Find Us ==
Come talk to us on #openstack-cue on Freenode.

Cue/api

2014-11-26T19:14:31Z

Vipuls: /* Cue API Design */

== Cue API Design ==
=== Acronyms ===
{| class="wikitable"
|-
! '''Acronym''' !! '''Definition'''
|-
| SSL || Secure Sockets Layer
|-
| REST || Representational State Transfer
|-
| URI || Uniform Resource Identifier
|-
| UUID || Universally Unique Identifier
|-
| AMQP || Advanced Messaging Queuing Protocol
|}

=== Requirements ===

API Requirements for Cue - Kilo timeframe.

* Keystone integration
* CRUD on Cluster
* Cluster Management – Scale up/down
* Devstack integration
* Gate Tests

=== System Context Diagram ===

[[File:SCD.jpg]]

{| class="wikitable"
|-
! '''Component''' !! '''Description'''
|-
| User || Direct customer of Cue.
|-
| Horizon || Cue functionality will be added to Horizon, which will provide a web-based portal for Cue control.
|-
| CLI || Command Line Interface to Cue, provides user access to provisioning and deploying messaging clusters.
|-
| REST_API || Provides user access to provisioning and deploying messaging clusters through REST interface. This is a light-weight interface, provisioning and configuration of clusters/nodes is delegated to the TaskWorker process.
|-
| TaskScheduler || Used to synchronize work tasks between the REST_API and TaskWorker processes.
|-
| TaskWorker || Carries out work associated with all provisioning, configuration and management of RabbitMQ clusters and nodes. Makes use of heat for initial provisioning/deployment.
|-
| DB || Database to store information on clusters and nodes. Example, in cluster creation, when request is initially received through REST_API, this DB is updated accordingly and the work is delegated to TaskWorker. TaskWorker then updates this DB as provisioning and configuration takes place. Subsequent calls to check on status of cluster creation, will return updated information from this DB.
|-
| Heat || Used cloud instance orchestration in deploying RabbitMQ cluster images.
|}

=== REST API ===

General requirement, REST API must respond within 500ms.
==== List Clusters ====

'''''GET /v1/clusters'''''

This operation synchronously returns all clusters provisioned within the associated project id.

'''Request Parameters'''
N/A

{| class="wikitable"
|-
! Response !! Code(s)
|-
| Normal || ok (200)
|-
| Error || unauthorized (401)
|}

'''Response Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster(list) || string || List of clusters, detailing respective cluster id, name, status, created time stamp and updated time stamp.
|}

'''JSON Request'''

N/A

'''JSON Response'''

{
"clusters": <nowiki>[</nowiki>
{
"cluster_id": "b51948c9-1ac5-4c28-a580-6f7c500d82f8",
"name": "Message Cluster 1",
"status": "ACTIVE",
"created": "2014-11-11T01:02:03Z",
"updated": "2014-11-11T01:02:03Z"
},
{
"cluster_id": "13c456c9-bbfc-4c31-b26d-3ae5c3cd7a77",
"name": "Message Cluster 2",
"status": "ACTIVE",
"created": "2014-11-12T13:23:54Z",
"updated": "2014-11-13T19:55:01Z"
}
]
}

==== Create Cluster ====

'''''POST /v1/clusters'''''

This operation asynchronously creates a new cluster of Nova instances provisioned with the required message brokers in a central tenant.

'''Request Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| nic || UUID || Network Identification for a Neutron network where cluster will be created in.
|-
| name || string || Name of cluster.
|-
| volume_size || int || Optional parameter to indicate size of volume for node instance. If volumes are supported, then this parameter will be used. If ephmeral disk are not supported, volume support will be required.
|-
| flavor (list) || string || List of node flavors, which specify VM type in terms of CPU/memory/disk resources (e.g. small, medium, large). Size of list denotes the number of nodes in cluster.

small: 1 GHz dual-core CPU; 512 MB memory; 250 GB disk

medium: 2.8 GHz dual-core CPU; 4 GB memory; 1 TB disk

large: 3.6 GHz quad-core CPU; 32 GB memory; 5 TB disk
|}

'''Response Codes'''

{| class="wikitable"
|-
! Response !! Code(s)
|-
| Normal || 202 (accepted)
|-
| Error || badRequest (400), unauthorized (401), itemNotFound (404)
|}

'''Response Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster_id || UUID || ID of cluster to be created.
|-
| name || string || Name of cluster (same as provided name in request parameters).
|-
| status || string || Current status of cluster.

BUILDING: Cluster is in progress of being provisioned.

ACTIVE: Cluster is running.

ERROR: Provisioning error(s) encountered.

DELETED: Cluster has been deleted.
|}

'''JSON Request'''

{
"nic": "d32019d3-bc6e-4319-9c1d-6722fc136a22",
"name": "Message Cluster 1",
"volume_size": "100",
"nodes": [
{
"flavor": "large"
},
{
"flavor": "large"
},
{
"flavor": "large"
}
]
}

'''JSON Response'''

{
"cluster_id": "dd745f4a-9333-417e-bb89-9c989c84c068",
"name": "Message Cluster 1",
"status": "BUILDING",
"created": "2014-11-11T01:02:03Z",
"updated": "2014-11-11T01:02:03Z",
"nodes": [
{
"node_id": "616fb98f-46ca-475e-917e-2563e5a8cd19",
"status": "BUILDING",
"flavor": "large",
},
{

"node_id": "e90c9d13-c4b8-4a08-992a-dad6109b8ac2",
"status": "BUILDING",
"flavor": "large",
},
{

"node_id": "372f8f47-6818-4d83-aa42-8744c0e689b8",
"status": "BUILDING",
"flavor": "large",
}
}

==== Show Cluster ====

'''''GET /v1/clusters/{cluster_id}'''''

This operation synchronously returns the status and information on the specified cluster within the provided tenant.

'''Request Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster_id (URI) || UUID || Cluster ID. This value is returned when a new cluster is created.
|}

'''Response Codes'''

{| class="wikitable"
|-
! Response !! Code(s)
|-
| Normal || ok (200)
|-
| Error || unauthorized (401), itemNotFound (404)
|}

'''Response Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster_id || UUID || ID of requested cluster.
|-
| name || string || Name of cluster.
|-
| status || string || Current status of cluster.

BUILDING: Cluster is in progress of being provisioned.

ACTIVE: Cluster is running.

ERROR: Provisioning error(s) encountered.

DELETED: Cluster has been deleted.
|-
| created || string || Created time stamp in format: yyyy-mm-ddThh:mm:ssZ
|-
| updated || string || Last updated time stamp in format: yyyy-mm-ddThh:mm:ssZ
|-
| nodes(list) || node || List of nodes, which includes node id, instance state, and flavor.
|}

'''JSON Request'''

N/A

'''JSON Response'''

{
"cluster_id": "dd745f4a-9333-417e-bb89-9c989c84c068",
"name": "Message Cluster 1",
"status": "ACTIVE",
"created": "2014-11-11T01:02:03Z",
"updated": "2014-11-11T01:02:03Z",
"nodes": [
{
"node_id": "616fb98f-46ca-475e-917e-2563e5a8cd19",
"status": "ACTIVE",
"flavor": "large",
"endpoints": [
{
"type": "AMQP",
"value": "amqp://10.20.30.40:10000"
},
{
"type": "console",
"value": "http://10.20.30.40:5672"
}
],
"created": "2014-11-11T01:06:03Z",
"updated": "2014-11-11T01:06:03Z"
},
{

"node_id": "e90c9d13-c4b8-4a08-992a-dad6109b8ac2",
"status": "ACTIVE",
"flavor": "large",
"endpoints": [
{
"type": "AMQP",
"value": "amqp://10.20.30.41:10000"
},
{
"type": "console",
"value": "http://10.20.30.41:5672"
}
],
"created": "2014-11-11T01:08:03Z",
"updated": "2014-11-11T01:08:03Z"
},
{

"node_id": "372f8f47-6818-4d83-aa42-8744c0e689b8",
"status": "ACTIVE",
"flavor": "large",
"endpoints": [
{
"type": "AMQP",
"value": "amqp://10.20.30.42:10000"
},
{
"type": "console",
"value": "http://10.20.30.42:5672"
}
],
"created": "2014-11-11T01:12:03Z",
"updated": "2014-11-11T01:12:03Z"
}
]
}

==== Delete Cluster ====

'''''DELETE /v1/clusters/{cluster_id}'''''''

This operation will asynchronously delete the indicated cluster within the provided tenant.

'''Request Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster_id (URI) || UUID || Cluster ID. This value is returned when a new cluster is created.
|}

'''Response Codes'''

{| class="wikitable"
|-
! Response !! Code(s)
|-
| Normal || accepted (202)
|-
| Error || unauthorized (401), itemNotFound (404)
|}

'''Response Parameters'''

N/A

'''JSON Request'''

N/A

'''JSON Response'''

N/A

===Testing===

Cue API testing will verify the expected functionality of the Cue user interface with both positive/negative tests. The overall scope will cover testing from the HTTP REST request to required database interactions and work-flow task submission for RPC workers.

====Unit Tests====

Unit tests will verify the resulting function calls for each REST-ful URI and action(s). The Python Mock library will be used to replace external system dependencies with placeholder objects.

{| class="wikitable"
|-
! Function !! Tests !! Input Data !! Expected Result(s)
|-
| List Clusters ||
# Create 'n' cluster(s), then call list clusters and verify expected return object
# Call list clusters when no clusters exist within tenant and verify expected return object
||
* n = # of clusters to create
||
# List of 'n' clusters is returned with appropriate fields, HTTP Ok (200)
# Empty list of clusters is returned, HTTP Ok (200)
|-
| Create Cluster ||
# Create standard cluster 'c' and verify expected return object
# Create cluster with invalid flavor and verify expected return value
# Create cluster with invalid volume size and verify expected return value
||
* n = cluster size (number of nodes)
* m = cluster name
* f = flavor
* s = volume size
* nic = Network UUID
||
# Cluster ID, name and status for newly created cluster is returned, HTTP Accepted (202)
# HTTP Bad request is returned (400)
# HTTP Bad request is returned (400)
|-
| Show Cluster ||
# Create cluster, then call get cluster and verify expected return object
# Get cluster with invalid cluster_id
||
* cluster_id = cluster ID
||
# Cluster ID, name, status, created/updated date stamp and list of nodes is returned, HTTP Ok (200).
# HTTP Bad request is returned (400)
|-
| Delete Cluster ||
# Create a cluster, then call delete cluster and verify expected return value
# Delete cluster with invalid cluster_id
||
* cluster_id = cluster ID
||
# HTTP accepted is returned (202)
# HTTP Bad request is returned (400)
|}

====Functional Tests====

The functional tests will verify the HTTP REST URI request lifecycle from controller routing to HTTP response. These tests will make use of Pecan's testing utility; pecan.testing module.

{| class="wikitable"
|-
! Operation !! URI !! Tests !! Input Data !! Expected Data (JSON)
|-
| GET || /v1/clusters ||
# Call when clusters exist
# Call when no clusters exist
||
* n/a
||
# List of 'n' clusters is returned with appropriate fields, HTTP Ok (200)
# Empty list of clusters is returned, HTTP Ok (200)
|-
| POST || /v1/clusters ||
# Create standard cluster 'c' and verify expected return object
# Create cluster with invalid flavor and verify expected return value
# Create cluster with invalid volume size and verify expected return value
||
* n = cluster size (number of nodes)
* m = cluster name
* f = flavor
* s = volume size
* nic = Network UUID
||
# Cluster ID, name and status for newly created cluster is returned, HTTP Accepted (202)
# HTTP Bad request is returned (400)
# HTTP Bad request is returned (400)
||
|-
| GET || /v1/clusters/{cluster_id} ||
# Create cluster, then call get cluster and verify expected return object
# Get cluster with invalid cluster_id
||
* cluster_id = cluster
||
# Cluster ID, name, status, created/updated date stamp and list of nodes is returned, HTTP Ok (200).
# HTTP Bad request is returned (400)
||
|-
| DELETE || /v1/clusters/{cluster_id} ||
# Create a cluster, then call delete cluster and verify expected return value
# Delete cluster with invalid cluster_id
||
* cluster_id = cluster ID
||
# HTTP accepted is returned (202)
# HTTP Bad request is returned (400)
||
|}

====Integration Tests====

The integration tests will cover API functionality from HTTP request to database access and task submission for RPC workers. The Pecan test utility will be used to route test request URI to appropriate controllers, then database record(s) will be verified for applicable change. Finally the creation of task objections will be verified to ensure valid task flows.

Cue/api

2014-11-26T19:10:54Z

Vipuls: /* Requirements */

== Cue API Design ==
=== Acronyms ===
{| class="wikitable"
|-
! '''Acronym''' !! '''Definition'''
|-
| SSL || Secure Sockets Layer
|-
| REST || Representational State Transfer
|-
| URI || Uniform Resource Identifier
|-
| UUID || Universally Unique Identifier
|-
| AMQP || Advanced Messaging Queuing Protocol
|}

=== Introduction ===

Messaging systems enable software applications to communicate and scale. Many of today's enterprise systems make use of messaging systems as the glue between the different components or applications. These components depend on messaging to interact with each other to provide end-to-end functionality. This Openstack stackforge project is intended to solve the problem in the provisioning, deployment and management of messaging systems in a seamless automated fashion for applications deployed on the Openstack cloud operating system.

There are several off-the-shelf messaging systems that implement messaging and queuing semantics such as RabbitMQ, Qpid and ActiveMQ. These proven systems have wide acceptance, usage and testing. The goal of this project is not to implement another messaging system for the Openstack platform, but to implement an automated messaging provisioning, deployment and management system. This system will simplify the application development life-cycle to allow the developer to focus on their application instead of the back-end storage services.

=== Goals ===

The focus of the project is to provide high-availability, auto-healing and tenant level isolation to the end user. The initial goal for version 1.0 is to use RabbitMQ as the supported messaging system. The overall goal for this effort is to provide a messaging queueing provisioning service for OpenStack built with community support.

=== Requirements ===

Requirements for Cue - Kilo timeframe.

* Control plane
* Rabbit Management Console
* Keystone integration
* Command-Line – Create/Delete Cluster
* Horizon Integration - Create/Delete Cluster
* Queue Control Plane Patching
* RabbitMQ Instance Patching
* Cluster Management – Scale up/down
* Devstack integration
* Gate Tests

=== System Context Diagram ===

[[File:SCD.jpg]]

{| class="wikitable"
|-
! '''Component''' !! '''Description'''
|-
| User || Direct customer of MSGaaS.
|-
| Horizon || MSGaaS functionality will be added to Horizon, which will provide a web-based portal for MSGaaS control.
|-
| CLI || Command Line Interface to MSGaaS, provides user access to provisioning and deploying messaging clusters.
|-
| REST_API || Provides user access to provisioning and deploying messaging clusters through REST interface. This is a light-weight interface, provisioning and configuration of clusters/nodes is delegated to the TaskWorker process.
|-
| TaskScheduler || Used to synchronize work tasks between the REST_API and TaskWorker processes.
|-
| TaskWorker || Carries out work associated with all provisioning, configuration and management of RabbitMQ clusters and nodes. Makes use of heat for initial provisioning/deployment.
|-
| DB || Database to store information on clusters and nodes. Example, in cluster creation, when request is initially received through REST_API, this DB is updated accordingly and the work is delegated to TaskWorker. TaskWorker then updates this DB as provisioning and configuration takes place. Subsequent calls to check on status of cluster creation, will return updated information from this DB.
|-
| Heat || Used cloud instance orchestration in deploying RabbitMQ cluster images.
|}

=== REST API ===

General requirement, REST API must respond within 500ms.
==== List Clusters ====

'''''GET /v1/clusters'''''

This operation synchronously returns all clusters provisioned within the associated project id.

'''Request Parameters'''
N/A

{| class="wikitable"
|-
! Response !! Code(s)
|-
| Normal || ok (200)
|-
| Error || unauthorized (401)
|}

'''Response Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster(list) || string || List of clusters, detailing respective cluster id, name, status, created time stamp and updated time stamp.
|}

'''JSON Request'''

N/A

'''JSON Response'''

{
"clusters": <nowiki>[</nowiki>
{
"cluster_id": "b51948c9-1ac5-4c28-a580-6f7c500d82f8",
"name": "Message Cluster 1",
"status": "ACTIVE",
"created": "2014-11-11T01:02:03Z",
"updated": "2014-11-11T01:02:03Z"
},
{
"cluster_id": "13c456c9-bbfc-4c31-b26d-3ae5c3cd7a77",
"name": "Message Cluster 2",
"status": "ACTIVE",
"created": "2014-11-12T13:23:54Z",
"updated": "2014-11-13T19:55:01Z"
}
]
}

==== Create Cluster ====

'''''POST /v1/clusters'''''

This operation asynchronously creates a new cluster of Nova instances provisioned with the required message brokers in a central tenant.

'''Request Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| nic || UUID || Network Identification for a Neutron network where cluster will be created in.
|-
| name || string || Name of cluster.
|-
| volume_size || int || Optional parameter to indicate size of volume for node instance. If volumes are supported, then this parameter will be used. If ephmeral disk are not supported, volume support will be required.
|-
| flavor (list) || string || List of node flavors, which specify VM type in terms of CPU/memory/disk resources (e.g. small, medium, large). Size of list denotes the number of nodes in cluster.

small: 1 GHz dual-core CPU; 512 MB memory; 250 GB disk

medium: 2.8 GHz dual-core CPU; 4 GB memory; 1 TB disk

large: 3.6 GHz quad-core CPU; 32 GB memory; 5 TB disk
|}

'''Response Codes'''

{| class="wikitable"
|-
! Response !! Code(s)
|-
| Normal || 202 (accepted)
|-
| Error || badRequest (400), unauthorized (401), itemNotFound (404)
|}

'''Response Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster_id || UUID || ID of cluster to be created.
|-
| name || string || Name of cluster (same as provided name in request parameters).
|-
| status || string || Current status of cluster.

BUILDING: Cluster is in progress of being provisioned.

ACTIVE: Cluster is running.

ERROR: Provisioning error(s) encountered.

DELETED: Cluster has been deleted.
|}

'''JSON Request'''

{
"nic": "d32019d3-bc6e-4319-9c1d-6722fc136a22",
"name": "Message Cluster 1",
"volume_size": "100",
"nodes": [
{
"flavor": "large"
},
{
"flavor": "large"
},
{
"flavor": "large"
}
]
}

'''JSON Response'''

{
"cluster_id": "dd745f4a-9333-417e-bb89-9c989c84c068",
"name": "Message Cluster 1",
"status": "BUILDING",
"created": "2014-11-11T01:02:03Z",
"updated": "2014-11-11T01:02:03Z",
"nodes": [
{
"node_id": "616fb98f-46ca-475e-917e-2563e5a8cd19",
"status": "BUILDING",
"flavor": "large",
},
{

"node_id": "e90c9d13-c4b8-4a08-992a-dad6109b8ac2",
"status": "BUILDING",
"flavor": "large",
},
{

"node_id": "372f8f47-6818-4d83-aa42-8744c0e689b8",
"status": "BUILDING",
"flavor": "large",
}
}

==== Show Cluster ====

'''''GET /v1/clusters/{cluster_id}'''''

This operation synchronously returns the status and information on the specified cluster within the provided tenant.

'''Request Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster_id (URI) || UUID || Cluster ID. This value is returned when a new cluster is created.
|}

'''Response Codes'''

{| class="wikitable"
|-
! Response !! Code(s)
|-
| Normal || ok (200)
|-
| Error || unauthorized (401), itemNotFound (404)
|}

'''Response Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster_id || UUID || ID of requested cluster.
|-
| name || string || Name of cluster.
|-
| status || string || Current status of cluster.

BUILDING: Cluster is in progress of being provisioned.

ACTIVE: Cluster is running.

ERROR: Provisioning error(s) encountered.

DELETED: Cluster has been deleted.
|-
| created || string || Created time stamp in format: yyyy-mm-ddThh:mm:ssZ
|-
| updated || string || Last updated time stamp in format: yyyy-mm-ddThh:mm:ssZ
|-
| nodes(list) || node || List of nodes, which includes node id, instance state, and flavor.
|}

'''JSON Request'''

N/A

'''JSON Response'''

{
"cluster_id": "dd745f4a-9333-417e-bb89-9c989c84c068",
"name": "Message Cluster 1",
"status": "ACTIVE",
"created": "2014-11-11T01:02:03Z",
"updated": "2014-11-11T01:02:03Z",
"nodes": [
{
"node_id": "616fb98f-46ca-475e-917e-2563e5a8cd19",
"status": "ACTIVE",
"flavor": "large",
"endpoints": [
{
"type": "AMQP",
"value": "amqp://10.20.30.40:10000"
},
{
"type": "console",
"value": "http://10.20.30.40:5672"
}
],
"created": "2014-11-11T01:06:03Z",
"updated": "2014-11-11T01:06:03Z"
},
{

"node_id": "e90c9d13-c4b8-4a08-992a-dad6109b8ac2",
"status": "ACTIVE",
"flavor": "large",
"endpoints": [
{
"type": "AMQP",
"value": "amqp://10.20.30.41:10000"
},
{
"type": "console",
"value": "http://10.20.30.41:5672"
}
],
"created": "2014-11-11T01:08:03Z",
"updated": "2014-11-11T01:08:03Z"
},
{

"node_id": "372f8f47-6818-4d83-aa42-8744c0e689b8",
"status": "ACTIVE",
"flavor": "large",
"endpoints": [
{
"type": "AMQP",
"value": "amqp://10.20.30.42:10000"
},
{
"type": "console",
"value": "http://10.20.30.42:5672"
}
],
"created": "2014-11-11T01:12:03Z",
"updated": "2014-11-11T01:12:03Z"
}
]
}

==== Delete Cluster ====

'''''DELETE /v1/clusters/{cluster_id}'''''''

This operation will asynchronously delete the indicated cluster within the provided tenant.

'''Request Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster_id (URI) || UUID || Cluster ID. This value is returned when a new cluster is created.
|}

'''Response Codes'''

{| class="wikitable"
|-
! Response !! Code(s)
|-
| Normal || accepted (202)
|-
| Error || unauthorized (401), itemNotFound (404)
|}

'''Response Parameters'''

N/A

'''JSON Request'''

N/A

'''JSON Response'''

N/A

===Testing===

Cue API testing will verify the expected functionality of the Cue user interface with both positive/negative tests. The overall scope will cover testing from the HTTP REST request to required database interactions and work-flow task submission for RPC workers.

====Unit Tests====

Unit tests will verify the resulting function calls for each REST-ful URI and action(s). The Python Mock library will be used to replace external system dependencies with placeholder objects.

{| class="wikitable"
|-
! Function !! Tests !! Input Data !! Expected Result(s)
|-
| List Clusters ||
# Create 'n' cluster(s), then call list clusters and verify expected return object
# Call list clusters when no clusters exist within tenant and verify expected return object
||
* n = # of clusters to create
||
# List of 'n' clusters is returned with appropriate fields, HTTP Ok (200)
# Empty list of clusters is returned, HTTP Ok (200)
|-
| Create Cluster ||
# Create standard cluster 'c' and verify expected return object
# Create cluster with invalid flavor and verify expected return value
# Create cluster with invalid volume size and verify expected return value
||
* n = cluster size (number of nodes)
* m = cluster name
* f = flavor
* s = volume size
* nic = Network UUID
||
# Cluster ID, name and status for newly created cluster is returned, HTTP Accepted (202)
# HTTP Bad request is returned (400)
# HTTP Bad request is returned (400)
|-
| Show Cluster ||
# Create cluster, then call get cluster and verify expected return object
# Get cluster with invalid cluster_id
||
* cluster_id = cluster ID
||
# Cluster ID, name, status, created/updated date stamp and list of nodes is returned, HTTP Ok (200).
# HTTP Bad request is returned (400)
|-
| Delete Cluster ||
# Create a cluster, then call delete cluster and verify expected return value
# Delete cluster with invalid cluster_id
||
* cluster_id = cluster ID
||
# HTTP accepted is returned (202)
# HTTP Bad request is returned (400)
|}

====Functional Tests====

The functional tests will verify the HTTP REST URI request lifecycle from controller routing to HTTP response. These tests will make use of Pecan's testing utility; pecan.testing module.

{| class="wikitable"
|-
! Operation !! URI !! Tests !! Input Data !! Expected Data (JSON)
|-
| GET || /v1/clusters ||
# Call when clusters exist
# Call when no clusters exist
||
* n/a
||
# List of 'n' clusters is returned with appropriate fields, HTTP Ok (200)
# Empty list of clusters is returned, HTTP Ok (200)
|-
| POST || /v1/clusters ||
# Create standard cluster 'c' and verify expected return object
# Create cluster with invalid flavor and verify expected return value
# Create cluster with invalid volume size and verify expected return value
||
* n = cluster size (number of nodes)
* m = cluster name
* f = flavor
* s = volume size
* nic = Network UUID
||
# Cluster ID, name and status for newly created cluster is returned, HTTP Accepted (202)
# HTTP Bad request is returned (400)
# HTTP Bad request is returned (400)
||
|-
| GET || /v1/clusters/{cluster_id} ||
# Create cluster, then call get cluster and verify expected return object
# Get cluster with invalid cluster_id
||
* cluster_id = cluster
||
# Cluster ID, name, status, created/updated date stamp and list of nodes is returned, HTTP Ok (200).
# HTTP Bad request is returned (400)
||
|-
| DELETE || /v1/clusters/{cluster_id} ||
# Create a cluster, then call delete cluster and verify expected return value
# Delete cluster with invalid cluster_id
||
* cluster_id = cluster ID
||
# HTTP accepted is returned (202)
# HTTP Bad request is returned (400)
||
|}

====Integration Tests====

The integration tests will cover API functionality from HTTP request to database access and task submission for RPC workers. The Pecan test utility will be used to route test request URI to appropriate controllers, then database record(s) will be verified for applicable change. Finally the creation of task objections will be verified to ensure valid task flows.

Cue/api

2014-11-26T19:10:02Z

Vipuls: /* Requirements */

== Cue API Design ==
=== Acronyms ===
{| class="wikitable"
|-
! '''Acronym''' !! '''Definition'''
|-
| SSL || Secure Sockets Layer
|-
| REST || Representational State Transfer
|-
| URI || Uniform Resource Identifier
|-
| UUID || Universally Unique Identifier
|-
| AMQP || Advanced Messaging Queuing Protocol
|}

=== Introduction ===

Messaging systems enable software applications to communicate and scale. Many of today's enterprise systems make use of messaging systems as the glue between the different components or applications. These components depend on messaging to interact with each other to provide end-to-end functionality. This Openstack stackforge project is intended to solve the problem in the provisioning, deployment and management of messaging systems in a seamless automated fashion for applications deployed on the Openstack cloud operating system.

There are several off-the-shelf messaging systems that implement messaging and queuing semantics such as RabbitMQ, Qpid and ActiveMQ. These proven systems have wide acceptance, usage and testing. The goal of this project is not to implement another messaging system for the Openstack platform, but to implement an automated messaging provisioning, deployment and management system. This system will simplify the application development life-cycle to allow the developer to focus on their application instead of the back-end storage services.

=== Goals ===

The focus of the project is to provide high-availability, auto-healing and tenant level isolation to the end user. The initial goal for version 1.0 is to use RabbitMQ as the supported messaging system. The overall goal for this effort is to provide a messaging queueing provisioning service for OpenStack built with community support.

=== Requirements ===

The requirements for the MSGaaS Queue v1.0 project are listed in priority order below.

* Control plane
* Rabbit Management Console
* Keystone integration
* Command-Line – Create/Delete Cluster
* Horizon Integration - Create/Delete Cluster
* Queue Control Plane Patching
* RabbitMQ Instance Patching
* Cluster Management – Scale up/down
* Devstack integration
* Gate Tests

=== System Context Diagram ===

[[File:SCD.jpg]]

{| class="wikitable"
|-
! '''Component''' !! '''Description'''
|-
| User || Direct customer of MSGaaS.
|-
| Horizon || MSGaaS functionality will be added to Horizon, which will provide a web-based portal for MSGaaS control.
|-
| CLI || Command Line Interface to MSGaaS, provides user access to provisioning and deploying messaging clusters.
|-
| REST_API || Provides user access to provisioning and deploying messaging clusters through REST interface. This is a light-weight interface, provisioning and configuration of clusters/nodes is delegated to the TaskWorker process.
|-
| TaskScheduler || Used to synchronize work tasks between the REST_API and TaskWorker processes.
|-
| TaskWorker || Carries out work associated with all provisioning, configuration and management of RabbitMQ clusters and nodes. Makes use of heat for initial provisioning/deployment.
|-
| DB || Database to store information on clusters and nodes. Example, in cluster creation, when request is initially received through REST_API, this DB is updated accordingly and the work is delegated to TaskWorker. TaskWorker then updates this DB as provisioning and configuration takes place. Subsequent calls to check on status of cluster creation, will return updated information from this DB.
|-
| Heat || Used cloud instance orchestration in deploying RabbitMQ cluster images.
|}

=== REST API ===

General requirement, REST API must respond within 500ms.
==== List Clusters ====

'''''GET /v1/clusters'''''

This operation synchronously returns all clusters provisioned within the associated project id.

'''Request Parameters'''
N/A

{| class="wikitable"
|-
! Response !! Code(s)
|-
| Normal || ok (200)
|-
| Error || unauthorized (401)
|}

'''Response Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster(list) || string || List of clusters, detailing respective cluster id, name, status, created time stamp and updated time stamp.
|}

'''JSON Request'''

N/A

'''JSON Response'''

{
"clusters": <nowiki>[</nowiki>
{
"cluster_id": "b51948c9-1ac5-4c28-a580-6f7c500d82f8",
"name": "Message Cluster 1",
"status": "ACTIVE",
"created": "2014-11-11T01:02:03Z",
"updated": "2014-11-11T01:02:03Z"
},
{
"cluster_id": "13c456c9-bbfc-4c31-b26d-3ae5c3cd7a77",
"name": "Message Cluster 2",
"status": "ACTIVE",
"created": "2014-11-12T13:23:54Z",
"updated": "2014-11-13T19:55:01Z"
}
]
}

==== Create Cluster ====

'''''POST /v1/clusters'''''

This operation asynchronously creates a new cluster of Nova instances provisioned with the required message brokers in a central tenant.

'''Request Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| nic || UUID || Network Identification for a Neutron network where cluster will be created in.
|-
| name || string || Name of cluster.
|-
| volume_size || int || Optional parameter to indicate size of volume for node instance. If volumes are supported, then this parameter will be used. If ephmeral disk are not supported, volume support will be required.
|-
| flavor (list) || string || List of node flavors, which specify VM type in terms of CPU/memory/disk resources (e.g. small, medium, large). Size of list denotes the number of nodes in cluster.

small: 1 GHz dual-core CPU; 512 MB memory; 250 GB disk

medium: 2.8 GHz dual-core CPU; 4 GB memory; 1 TB disk

large: 3.6 GHz quad-core CPU; 32 GB memory; 5 TB disk
|}

'''Response Codes'''

{| class="wikitable"
|-
! Response !! Code(s)
|-
| Normal || 202 (accepted)
|-
| Error || badRequest (400), unauthorized (401), itemNotFound (404)
|}

'''Response Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster_id || UUID || ID of cluster to be created.
|-
| name || string || Name of cluster (same as provided name in request parameters).
|-
| status || string || Current status of cluster.

BUILDING: Cluster is in progress of being provisioned.

ACTIVE: Cluster is running.

ERROR: Provisioning error(s) encountered.

DELETED: Cluster has been deleted.
|}

'''JSON Request'''

{
"nic": "d32019d3-bc6e-4319-9c1d-6722fc136a22",
"name": "Message Cluster 1",
"volume_size": "100",
"nodes": [
{
"flavor": "large"
},
{
"flavor": "large"
},
{
"flavor": "large"
}
]
}

'''JSON Response'''

{
"cluster_id": "dd745f4a-9333-417e-bb89-9c989c84c068",
"name": "Message Cluster 1",
"status": "BUILDING",
"created": "2014-11-11T01:02:03Z",
"updated": "2014-11-11T01:02:03Z",
"nodes": [
{
"node_id": "616fb98f-46ca-475e-917e-2563e5a8cd19",
"status": "BUILDING",
"flavor": "large",
},
{

"node_id": "e90c9d13-c4b8-4a08-992a-dad6109b8ac2",
"status": "BUILDING",
"flavor": "large",
},
{

"node_id": "372f8f47-6818-4d83-aa42-8744c0e689b8",
"status": "BUILDING",
"flavor": "large",
}
}

==== Show Cluster ====

'''''GET /v1/clusters/{cluster_id}'''''

This operation synchronously returns the status and information on the specified cluster within the provided tenant.

'''Request Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster_id (URI) || UUID || Cluster ID. This value is returned when a new cluster is created.
|}

'''Response Codes'''

{| class="wikitable"
|-
! Response !! Code(s)
|-
| Normal || ok (200)
|-
| Error || unauthorized (401), itemNotFound (404)
|}

'''Response Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster_id || UUID || ID of requested cluster.
|-
| name || string || Name of cluster.
|-
| status || string || Current status of cluster.

BUILDING: Cluster is in progress of being provisioned.

ACTIVE: Cluster is running.

ERROR: Provisioning error(s) encountered.

DELETED: Cluster has been deleted.
|-
| created || string || Created time stamp in format: yyyy-mm-ddThh:mm:ssZ
|-
| updated || string || Last updated time stamp in format: yyyy-mm-ddThh:mm:ssZ
|-
| nodes(list) || node || List of nodes, which includes node id, instance state, and flavor.
|}

'''JSON Request'''

N/A

'''JSON Response'''

{
"cluster_id": "dd745f4a-9333-417e-bb89-9c989c84c068",
"name": "Message Cluster 1",
"status": "ACTIVE",
"created": "2014-11-11T01:02:03Z",
"updated": "2014-11-11T01:02:03Z",
"nodes": [
{
"node_id": "616fb98f-46ca-475e-917e-2563e5a8cd19",
"status": "ACTIVE",
"flavor": "large",
"endpoints": [
{
"type": "AMQP",
"value": "amqp://10.20.30.40:10000"
},
{
"type": "console",
"value": "http://10.20.30.40:5672"
}
],
"created": "2014-11-11T01:06:03Z",
"updated": "2014-11-11T01:06:03Z"
},
{

"node_id": "e90c9d13-c4b8-4a08-992a-dad6109b8ac2",
"status": "ACTIVE",
"flavor": "large",
"endpoints": [
{
"type": "AMQP",
"value": "amqp://10.20.30.41:10000"
},
{
"type": "console",
"value": "http://10.20.30.41:5672"
}
],
"created": "2014-11-11T01:08:03Z",
"updated": "2014-11-11T01:08:03Z"
},
{

"node_id": "372f8f47-6818-4d83-aa42-8744c0e689b8",
"status": "ACTIVE",
"flavor": "large",
"endpoints": [
{
"type": "AMQP",
"value": "amqp://10.20.30.42:10000"
},
{
"type": "console",
"value": "http://10.20.30.42:5672"
}
],
"created": "2014-11-11T01:12:03Z",
"updated": "2014-11-11T01:12:03Z"
}
]
}

==== Delete Cluster ====

'''''DELETE /v1/clusters/{cluster_id}'''''''

This operation will asynchronously delete the indicated cluster within the provided tenant.

'''Request Parameters'''

{| class="wikitable"
|-
! Parameter !! Type !! Description
|-
| cluster_id (URI) || UUID || Cluster ID. This value is returned when a new cluster is created.
|}

'''Response Codes'''

{| class="wikitable"
|-
! Response !! Code(s)
|-
| Normal || accepted (202)
|-
| Error || unauthorized (401), itemNotFound (404)
|}

'''Response Parameters'''

N/A

'''JSON Request'''

N/A

'''JSON Response'''

N/A

===Testing===

Cue API testing will verify the expected functionality of the Cue user interface with both positive/negative tests. The overall scope will cover testing from the HTTP REST request to required database interactions and work-flow task submission for RPC workers.

====Unit Tests====

Unit tests will verify the resulting function calls for each REST-ful URI and action(s). The Python Mock library will be used to replace external system dependencies with placeholder objects.

{| class="wikitable"
|-
! Function !! Tests !! Input Data !! Expected Result(s)
|-
| List Clusters ||
# Create 'n' cluster(s), then call list clusters and verify expected return object
# Call list clusters when no clusters exist within tenant and verify expected return object
||
* n = # of clusters to create
||
# List of 'n' clusters is returned with appropriate fields, HTTP Ok (200)
# Empty list of clusters is returned, HTTP Ok (200)
|-
| Create Cluster ||
# Create standard cluster 'c' and verify expected return object
# Create cluster with invalid flavor and verify expected return value
# Create cluster with invalid volume size and verify expected return value
||
* n = cluster size (number of nodes)
* m = cluster name
* f = flavor
* s = volume size
* nic = Network UUID
||
# Cluster ID, name and status for newly created cluster is returned, HTTP Accepted (202)
# HTTP Bad request is returned (400)
# HTTP Bad request is returned (400)
|-
| Show Cluster ||
# Create cluster, then call get cluster and verify expected return object
# Get cluster with invalid cluster_id
||
* cluster_id = cluster ID
||
# Cluster ID, name, status, created/updated date stamp and list of nodes is returned, HTTP Ok (200).
# HTTP Bad request is returned (400)
|-
| Delete Cluster ||
# Create a cluster, then call delete cluster and verify expected return value
# Delete cluster with invalid cluster_id
||
* cluster_id = cluster ID
||
# HTTP accepted is returned (202)
# HTTP Bad request is returned (400)
|}

====Functional Tests====

The functional tests will verify the HTTP REST URI request lifecycle from controller routing to HTTP response. These tests will make use of Pecan's testing utility; pecan.testing module.

{| class="wikitable"
|-
! Operation !! URI !! Tests !! Input Data !! Expected Data (JSON)
|-
| GET || /v1/clusters ||
# Call when clusters exist
# Call when no clusters exist
||
* n/a
||
# List of 'n' clusters is returned with appropriate fields, HTTP Ok (200)
# Empty list of clusters is returned, HTTP Ok (200)
|-
| POST || /v1/clusters ||
# Create standard cluster 'c' and verify expected return object
# Create cluster with invalid flavor and verify expected return value
# Create cluster with invalid volume size and verify expected return value
||
* n = cluster size (number of nodes)
* m = cluster name
* f = flavor
* s = volume size
* nic = Network UUID
||
# Cluster ID, name and status for newly created cluster is returned, HTTP Accepted (202)
# HTTP Bad request is returned (400)
# HTTP Bad request is returned (400)
||
|-
| GET || /v1/clusters/{cluster_id} ||
# Create cluster, then call get cluster and verify expected return object
# Get cluster with invalid cluster_id
||
* cluster_id = cluster
||
# Cluster ID, name, status, created/updated date stamp and list of nodes is returned, HTTP Ok (200).
# HTTP Bad request is returned (400)
||
|-
| DELETE || /v1/clusters/{cluster_id} ||
# Create a cluster, then call delete cluster and verify expected return value
# Delete cluster with invalid cluster_id
||
* cluster_id = cluster ID
||
# HTTP accepted is returned (202)
# HTTP Bad request is returned (400)
||
|}

====Integration Tests====

The integration tests will cover API functionality from HTTP request to database access and task submission for RPC workers. The Pecan test utility will be used to route test request URI to appropriate controllers, then database record(s) will be verified for applicable change. Finally the creation of task objections will be verified to ensure valid task flows.

Cue

2014-11-13T00:40:26Z

Vipuls: /* Cue */

= Cue =
== Mission Statement ==
The OpenStack Message Broker Provisioning as a Service Mission: To provide scalable and reliable Message Broker provisioning functionality for off the shelf messaging technologies, as well as to provide advanced management, tuning, and administration of underlying message brokers.

== Description ==

Cue is a Message Broker provisioning service for Openstack. Its goal is to simplify and automate the complex tasks of provisioning, management, and administration of message brokers. Users of the service can create and manage multiple clusters of Message brokers, of various types as needed. The service will provide resource isolation at the VM level, and does not attempt to implement multi-tenancy at the message broker layer.

== Why ==

Messaging is a common development pattern for building loosely coupled distributed systems. Messaging systems also act as glue between independent applications. Several off-the-shelf products exist that implement messaging and queuing semantics.

Provisioning and supporting Messaging systems for an individual application can be a time consuming and painful experience. This product aims to simplify the provisioning and management of messaging systems, providing High Availability and auto-healing capabilities to the end user, while providing tenant-level isolation.

The main goal of this service is to simplify the end user Application development lifecycle and allow the developer to focus on their application, instead of the backend middleware services.

== Goals ==
# Produce a Message Broker Provisioning Service for Openstack
# Protocol Agnostic
# Support multiple Broker backends
# Provide HA and Fault Tolerance by leveraging underlying Broker Cluster capabilities
# Provide tuned and properly configured Message Brokers on-demand
# Support Broker management operations such as Backup of Configuration, Scale Up, Scale Down

== Non-Goals ==

# Data plane API
# Multi-tenancy at the Message Broker layer

== Brokers ==
Cue will support the following brokers (in order of priority):
# RabbitMQ
# qpid
# Kafka
# .. others?

== V1 API ==
The v1 API is still a work in progress. We are working on coming up with much more detailed API design, an easy version looks like this.

'''Create a Cluster'''
<pre>
POST /v1/clusters
</pre>
'''List Clusters'''
<pre>
GET /v1/clusters
</pre>
'''Show Cluster'''
<pre>
GET /v1/clusters/{cluster_id}
</pre>
'''Delete Cluster'''
<pre>
GET /v1/clusters/{cluster_id}
</pre>
'''Add Node to Cluster (scale up)'''
<pre>
POST /v1/clusters/{cluster_id}/node/
</pre>
'''Delete Node from Cluster (scale down)'''
<pre>
DELETE /v1/clusters/{cluster_id}/node/{node_id}
</pre>

== Code ==
We've started building the project, it now lives on Stackforge.

https://github.com/stackforge/cue

Cue

2014-11-03T14:42:27Z

Vipuls: /* Cue */

= Cue =
== Mission Statement ==
The OpenStack Message Broker Provisioning as a Service Mission: To provide scalable and reliable Message Broker provisioning functionality for off the shelf messaging technologies, as well as to provide advanced management, tuning, and administration of underlying message brokers.

== Description ==

Cue is a Message Broker provisioning service for Openstack. Its goal is to simplify and automate the complex tasks of provisioning, management, and administration of message brokers. Users of the service can create and manage multiple clusters of Message brokers, of various types as needed. The service will provide resource isolation at the VM level, and does not attempt to implement multi-tenancy at the message broker layer.

== Why ==

Messaging is a common development pattern for building loosely coupled distributed systems. Messaging systems also act as glue between independent applications. Several off-the-shelf products exist that implement messaging and queuing semantics.

Provisioning and supporting Messaging systems for an individual application can be a time consuming and painful experience. This product aims to simplify the provisioning and management of messaging systems, providing High Availability and auto-healing capabilities to the end user, while providing tenant-level isolation.

The main goal of this service is to simplify the end user Application development lifecycle and allow the developer to focus on their application, instead of the backend middleware services.

== Goals ==
# Produce a Message Broker Provisioning Service for Openstack
# Protocol Agnostic
# Support multiple Broker backends
# Provide HA and Fault Tolerance by leveraging underlying Broker Cluster capabilities
# Provide tuned and properly configured Message Brokers on-demand
# Support Broker management operations such as Backup of Configuration, Scale Up, Scale Down

== Non-Goals ==

# Data plane API
# Multi-tenancy at the Message Broker layer

== Brokers ==
Cue will support the following brokers (in order of priority):
# RabbitMQ
# qpid
# Kafka
# .. others?

== V1 API ==
The v1 API is still a work in progress. We are working on coming up with much more detailed API design, an easy version looks like this.

'''Create a Cluster'''
<pre>
POST /v1/clusters
</pre>
'''List Clusters'''
<pre>
GET /v1/clusters
</pre>
'''Show Cluster'''
<pre>
GET /v1/clusters/{cluster_id}
</pre>
'''Delete Cluster'''
<pre>
GET /v1/clusters/{cluster_id}
</pre>
'''Add Node to Cluster (scale up)'''
<pre>
POST /v1/clusters/{cluster_id}/node/
</pre>
'''Delete Node from Cluster (scale down)'''
<pre>
DELETE /v1/clusters/{cluster_id}/node/{node_id}
</pre>

== Code ==
We've started building the project, it currently lives on a personal github. The project will move to Stackforge and adopt the Gerrit process.

https://github.com/vipulsabhaya/cue

Cue

2014-11-03T14:34:30Z

Vipuls: /* V1 API */

= Cue =
== Mission Statement ==
The OpenStack Message Broker Provisioning as a Service Mission: To provide scalable and reliable Message Broker provisioning functionality for off the shelf messaging technologies, as well as to provide advanced management, tuning, and administration of underlying message brokers.

== Description ==

Cue is a Message Broker provisioning service for Openstack. Its goal is to simplify and automate the complex tasks of provisioning, management, and administration of message brokers. Users of the service can create and manage multiple clusters of Message brokers, of various types as needed. The service will provide resource isolation at the VM level, and does not attempt to implement multi-tenancy at the message broker layer.

== Why ==

Messaging is a common development pattern for building loosely coupled distributed systems. Messaging systems also act as glue between independent applications. Several off-the-shelf products exist that implement messaging and queuing semantics.

Provisioning and supporting Messaging systems for an individual application can be a time consuming and painful experience. This product aims to simplify the provisioning and management of messaging systems, providing High Availability and auto-healing capabilities to the end user, while providing tenant-level isolation.

The main goal of this service is to simplify the end user Application development lifecycle and allow the developer to focus on their application, instead of the backend middleware services.

== Goals ==
# Produce a Message Broker Provisioning Service for Openstack
# Protocol Agnostic
# Support multiple Broker backends
# Provide HA and Fault Tolerance by leveraging underlying Broker Cluster capabilities
# Provide tuned and properly configured Message Brokers on-demand
# Support Broker management operations such as Backup of Configuration, Scale Up, Scale Down

== Non-Goals ==

# Data plane API
# Multi-tenancy at the Message Broker layer

== Brokers ==
Cue will support the following brokers (in order of priority):
# RabbitMQ
# qpid
# Kafka
# .. others?

== V1 API ==
The v1 API is still a work in progress. We are working on coming up with much more detailed API design, an easy version looks like this.

'''Create a Cluster'''
<pre>
POST /v1/clusters
</pre>
'''List Clusters'''
<pre>
GET /v1/clusters
</pre>
'''Show Cluster'''
<pre>
GET /v1/clusters/{cluster_id}
</pre>
'''Delete Cluster'''
<pre>
GET /v1/clusters/{cluster_id}
</pre>
'''Add Node to Cluster (scale up)'''
<pre>
POST /v1/clusters/{cluster_id}/node/
</pre>
'''Delete Node from Cluster (scale down)'''
<pre>
DELETE /v1/clusters/{cluster_id}/node/{node_id}
</pre>

Cue

2014-11-03T14:32:54Z

Vipuls: /* Cue */

= Cue =
== Mission Statement ==
The OpenStack Message Broker Provisioning as a Service Mission: To provide scalable and reliable Message Broker provisioning functionality for off the shelf messaging technologies, as well as to provide advanced management, tuning, and administration of underlying message brokers.

== Description ==

Cue is a Message Broker provisioning service for Openstack. Its goal is to simplify and automate the complex tasks of provisioning, management, and administration of message brokers. Users of the service can create and manage multiple clusters of Message brokers, of various types as needed. The service will provide resource isolation at the VM level, and does not attempt to implement multi-tenancy at the message broker layer.

== Why ==

Messaging is a common development pattern for building loosely coupled distributed systems. Messaging systems also act as glue between independent applications. Several off-the-shelf products exist that implement messaging and queuing semantics.

Provisioning and supporting Messaging systems for an individual application can be a time consuming and painful experience. This product aims to simplify the provisioning and management of messaging systems, providing High Availability and auto-healing capabilities to the end user, while providing tenant-level isolation.

The main goal of this service is to simplify the end user Application development lifecycle and allow the developer to focus on their application, instead of the backend middleware services.

== Goals ==
# Produce a Message Broker Provisioning Service for Openstack
# Protocol Agnostic
# Support multiple Broker backends
# Provide HA and Fault Tolerance by leveraging underlying Broker Cluster capabilities
# Provide tuned and properly configured Message Brokers on-demand
# Support Broker management operations such as Backup of Configuration, Scale Up, Scale Down

== Non-Goals ==

# Data plane API
# Multi-tenancy at the Message Broker layer

== Brokers ==
Cue will support the following brokers (in order of priority):
# RabbitMQ
# qpid
# Kafka
# .. others?

== V1 API ==
The v1 API is still a work in progress. We are working on coming up with much more detailed API design, an easy version looks like this.

# Create a Cluster
<pre>
POST /v1/clusters
</pre>
# List Clusters
<pre>
GET /v1/clusters
</pre>
# Show Cluster
<pre>
GET /v1/clusters/{cluster_id}
</pre>
# Delete Cluster
<pre>
GET /v1/clusters/{cluster_id}
</pre>
# Add Node to Cluster (scale up)
<pre>
POST /v1/clusters/{cluster_id}/node/
</pre>
# Delete Node from Cluster (scale down)
<pre>
DELETE /v1/clusters/{cluster_id}/node/{node_id}
</pre>

Cue

2014-11-03T12:09:01Z

Vipuls: Created page with "= Cue = == Mission Statement == The OpenStack Message Broker Provisioning as a Service Mission: To provide scalable and reliable Message Broker provisioning functionality for..."

Trove/Replication-And-Clustering

2014-04-25T00:38:19Z

Vipuls: /* Create Slave */

== Summary/Viewpoints/Strategy ==
 
* Purposefully avoids introducing a /cluster API
* Purposefully avoids the proliferation of configuration-groups to accommodate mandatory fields in the context of clusters/topologies
* Purposefully avoids introducing a v2 API
* Instead, introduces cluster{} field and /instance/<id>/cluster routes
* cluster{}'s charter is to include cluster-related fields that are absolutely required to construct the initial cluster.
* Cluster-influenced actions are handled via: 'PUT /instances/<id>/cluster', where <id> is any arbitrary instance in the cluster.
* Requests against 'PUT /instances/<id>/cluster' will follow the format of: { "<action>": { <action_specific_fields> } }
* Where possible and logical, consolidate similar <action>s amongst datastores.
 

== MySQL Master/Slave ==
 
==== Create Master ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "products",
"datastore": {
"type": "mysql",
"version": "5.5"
},
"configuration": "b9c8a3f8-7ace-4aea-9908-7b555586d7b6",
"flavorRef": "7",
"volume": {
"size": 1
}
}
}
</pre>

Response:

<pre>
{
"instance": {
"status": "BUILD",
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"name": "products",
"configuration": {
"id": "b9c8a3f8-7ace-4aea-9908-7b555586d7b6",
"name": "config-a",
"links": [{...}]
},
...
}
}
</pre>

 
==== Create Slave ====
 
--[[User:Vipuls|vipuls]] ([[User talk:Vipuls|talk]]) 00:38, 25 April 2014 (UTC) I'm not a big fan of introducing the 'cluster' attribute to wrap what is a read-only slave.
Request:

<pre>
POST /instances
{
"instance": {
"name": "product-b",
"datastore": {
"type": "mysql",
"version": "5.5"
},
"cluster": {
"slave_of": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"read_only": true
},
"configuration": "fc318e00-3a6f-4f93-af99-146b44912188",
"flavorRef": "7",
"volume": {
"size": 1
}
}
}
</pre>

Response:

<pre>
{
"instance": {
"status": "BUILD",
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
"name": "product-b",
"cluster": {
"slave_of": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"read_only": true
},
"configuration": {
"id": "fc318e00-3a6f-4f93-af99-146b44912188",
"name": "config-b",
"links": [{...}]
},
...
}
}
</pre>

Notes:
* For master/slave wirings, the 'server_id' must differ between master and slave, and optionally the slave can specify whether it is read-only or not to avoid accidental writes.
* Update: Agreed on 03/14/14 that the user should not have to specify 'server_id'. Instead, trove will be responsible for setting it and ensuring that a slave does not have the same server_id as its master, or any sibling slaves. As a part of this agreement, this requires removing 'server_id' from configuration-groups overrides (to avoid the user meddling with our bookkeeping).
* 'read_only' was removed from configuration-groups and moved to cluster{} because forcing the user to create a configuration-group for every MySQL slave is arduous and a poor user experience.
* 'read_only' is only permitted if 'slave_of' is set, otherwise the request will be failed.
* Opinion: 'read_only' should default to true if slave_of is set and read_only is not provided.
* Note: 'slave_of' is purposefully not an array to support multi-source replication coming in 5.7. Instead, a new 'channels'-like field will be introduced.
* For now, 'slave_of' requires a vanilla trove instance uuid, but will inevitably need to be prefixed with namespacing to support multiple dcs and sources (e.g. trove:us-west:tenant_id:instance:dfbbd9ca-b5e1-4028-adb7-f78643e17998) and/or additional fields will be added.
* Note: The master could have optionally included instance.cluster{} to provide a cluster_name to avoid it being the same as the master's name (see below for context)
 

==== Show Instance ====
 
Request:

<pre>
GET /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998
</pre>

Response:

<pre>
{
"instance": {
"status": "ACTIVE",
"updated": "2014-02-16T03:38:49"
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"name": "products",
"datastore": {
"version": "5.5",
"type": "mysql",
},
"flavor": {
"id": "7",
"links": [{...}]
},
"configuration": {
"id": "b9c8a3f8-7ace-4aea-9908-7b555586d7b6",
"name": "config-a",
"links": [{...}]
}
}
}
</pre>
 
Request:

<pre>
GET /instances/061aaf4c-3a57-411e-9df9-2d0f813db859
</pre>

Response:

<pre>
{
"instance": {
"status": "ACTIVE",
"updated": "2014-02-16T03:38:49"
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
"name": "product-b",
"datastore": {
"version": "5.5",
"type": "mysql",
},
"flavor": {
"id": "7",
"links": [{...}]
},
"cluster": {
"slave_of": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"read_only": true
},
"configuration": {
"id": "b9c8a3f8-7ace-4aea-9908-7b555586d7b6",
"name": "config-a",
"links": [{...}]
}
}
}
</pre>
 

==== Show Cluster ====
 
Request:

<pre>
GET /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster
</pre>

Response:

<pre>
{
"cluster": {
"name": "products",
"instances": [
{
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"name": "products"
},
{
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
"name": "product-b",
"slave_of": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"read_only": true
}
]
}
}
</pre>
 

==== Remove Replication (aka "Promote" to Standalone) ====
 
Request:

<pre>
POST or PUT /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster/action
or POST or PUT /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster

{
"promote": {
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859"
}
}
</pre>

Response:

<pre>
TBD
</pre>

Notes:
* The PUT /cluster option is more "correct", but POST /action is already an established pattern in the codebase. We must choose one of the four approaches. For the sake of brevity, it is assumed that PUT /cluster is chosen (and will be used in examples beyond this point in the document)
 
== MongoDB ==
 
==== Create Single Instance Replica-Set ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "product-a",
...
"datastore": {
"type": "mongodb",
"version": "2.4.10"
},
"cluster": {
"cluster_name": "products",
"instance_type": "member",
"join": false
},
...
}
}
</pre>

Response:

<pre>
{
"instance": {
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
...
}
}
</pre>
 
Notes:
* The existing instance-create payload for single instance MongoDB will be treated exactly the same as this example (with instance.name becoming cluster_name, instance_type defaulting to member, and join defaulting to false)
* 'cluster_name' is used as 'replSet'
* Enforce 'cluster_name' field to be provided for MongoDB, even in the case of a standalone/single instance. See http://www.mongodb.com/blog/post/dont-let-your-standalone-mongodb-server-stand-alone for reasoning.
* 'join' indicates whether you're joining an existing replica-set, or creating a new one. If 'join' is false, and an active replica-set by that name for the tenant already exists, the request will be failed. 'join' by default will be false, but was included above for illustrative purposes.
* 'instance_type' is 'member' vs. 'primary' because in a replica-set, the primary is dynamic and can change in an election.
 
==== Create 3 Instance Replica-Set ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "",
...
"datastore": {
"type": "mongodb",
"version": "2.4.10"
},
"cluster": {
"cluster_name": "products",
"instance_type": "member",
"num_instances": 3,
"join": false
},
...
}
}
</pre>

Response:

<pre>
{
TBD
}
</pre>
 
Notes:
* cluster.num_instances defaults to 1
* instance.name cannot be provided if instance.cluster.num_instances != 1 (implicitly or explicitly)
* cluster.num_instances is not supported for mysql and possibly others (see the Summary table at the bottom of this document)
* the names of the instances for num_instances != 1 will be "<cluster_name> - <suffix>", where suffix is either an incrementing number (e.g. product-1, product-2) or some variation thereof.
* it's understood that num_instances itself will not be sufficient in the future because users will want to split the allocation across different availability-zones. tying num_instance split allocations to az(s) and/or region(s) is beyond the scope of this first iteration, and therefore, all nodes will land as they would land today (az/region-wise). it's worth pointing out that building node by node vs. using the convenience of num_instances is a workaround.
 
==== Add Member to Replica-Set ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "product-b",
...
"cluster": {
"instance_type": "member",
"cluster_name": "products",
"join": true
},
...
}
}
</pre>
 
Response:
<pre>
{
"instance": {
"status": "BUILD",
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
...
}
}
</pre>
 
Notes:
* If 'join' is true, and there is no existing replica-set for the tenant matching the 'cluster_name' value, the request will be failed.
* Will have to use 'db.isMaster()' to determine the current primary to execute replica-set commands against (since it can be dynamic due to elections)
* Will use http://docs.mongodb.org/manual/tutorial/expand-replica-set/#configure-and-add-a-member
* Should protect against adding more than 12 members to a replica-set
* Should protect against adding more than 7 voting members to a replica-set
* Should return warning when number of voting members is even and there is no arbiter
 
==== Add Another Member to Replica-Set ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "product-c",
...
"cluster": {
"instance_type": "member",
"cluster_name": "products",
"join": true
},
...
}
}
</pre>
 
Response:
<pre>
{
"instance": {
"status": "BUILD",
"id": "3a72ee87-cf3e-40f1-a1e1-fe8c7263a782",
...
}
}
</pre>
 
==== Show Instance ====
 
Request:

<pre>
GET /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998
</pre>

Response:

<pre>
{
"instance": {
...
"cluster": {
"instance_type": "member",
"cluster_name": "products"
},
...
}
}
</pre>
 
==== Show Cluster ====
 
Request:

<pre>
GET /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster
</pre>

Response:

<pre>
{
"cluster": {
"name": "products",
"instances": [
{
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"name": "product-a",
"instance_type": "member"
},
{
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
"name": "product-b",
"instance_type": "member"
},
{
"id": "3a72ee87-cf3e-40f1-a1e1-fe8c7263a782",
"name": "product-c",
"instance_type": "member"
}
]
}
}
</pre>
 
==== Add Arbiter ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "product-arbiter",
...
"cluster": {
"instance_type": "arbiter",
"cluster_name": "products",
"join": true
},
...
}
}
</pre>

Response:

<pre>
{
"instance": {
"status": "BUILD",
"id": "a1b62aaa-7863-4384-8250-59024141c1f8",
...
}
}
</pre>
 
==== Add a Delayed Member ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "product-delayed",
...
"cluster": {
"instance_type": "member",
"cluster_name": "products",
"priority": 0,
"hidden": true,
"slaveDelay": 3600,
"join": true
},
...
}
}
</pre>

Response:

<pre>
{
"instance": {
"status": "BUILD",
"id": "7d8eb019-931b-4b2a-88d2-4c9f0ca1b29e",
...
}
}
</pre>
 
Notes:
* 'instance_type', 'cluster_name', 'join', 'priority', 'hidden', and 'slaveDelay' are the only fields supported in cluster{} for mongodb. All other configuration values must be set via a configuration-group. After more thought, consider supporting 'hostname' and 'votes' as well.
* Why isn't 'priority', 'hidden' and 'slaveDelay' in a configuration-group you ask? This is explained in "Modifying a Replica-Set" below.
 
==== Modifying a Replica-Set ====
 
Thus far we've been able to model building a replica-set, adding an arbiter, adding a delayed secondary member, etc. Let's continue with how to modify a replica-set.
 
 
Example:

<pre>
# from http://docs.mongodb.org/manual/tutorial/configure-secondary-only-replica-set-member/#example
cfg = rs.conf()
cfg.members[0].priority = 2
cfg.members[1].priority = 1
cfg.members[2].priority = 0.5
cfg.members[3].priority = 0
rs.reconfig(cfg)
</pre>

Executing these priority changes one at a time can have catastrophic results, so it must be done as a transaction (with rs.reconfig() commiting). However, without the ability to address the cluster (i.e. multiple members at once), this becomes impossible. The only backdoor solution would be to guarantee that the MongoDB user(s) presented to the cloud tenant all have the clusterAdmin role, as this would allow them to connect to the primary and execute such transactions themselves via the native client. Obviously however, granting clusterAdmin to every DBaaS user in MongoDB is unacceptable in most deployments. The solution is as follows:
 
 
Request:

<pre>
PUT /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster
{
"update_member_attributes": {
"instances": [
{
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"priority": 2
},
{
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
"priority": 1
},
{
"id": "3a72ee87-cf3e-40f1-a1e1-fe8c7263a782",
"priority": 0.5
}
]
}
}
</pre>
 
Notes:
* 'update_member_attributes.members[]' elements will only permit 'priority', 'hidden', and 'slaveDelay' (possibly 'votes' and 'hostname' as mentioned earlier).
* See https://wiki.openstack.org/w/index.php?title=Trove/Replication-And-Clustering&action=submit#Replica-Set_Member_Type.2FAttribute_Updates for a list of approaches considered.
 
 

==== Remove a Member ====
 
Request:

<pre>
PUT /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster

{
"promote": {
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998"
}
}
</pre>
 
Notes:
* Note that 'promote' was used here vs. "remove_member" because the action is akin to promoting a mysql/redis slave instance (see http://docs.mongodb.org/manual/reference/method/rs.remove/#rs.remove)
* See https://wiki.openstack.org/w/index.php?title=Trove/Replication-And-Clustering&action=submit#Remove_a_Member_from_a_Replica-Set for a list of approaches considered.
 
 

==== MongoDB TokuMX ====

* TokuMUX will require a new datastore-version and *possibly* a new manager class (same reasoning as why Tungsten/Galera will have their own datastore-version for MySQL)
 
 

== Cassandra ==
 
==== Create Cluster ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "product-a",
...
"datastore": {
"type": "cassandra",
"version": "cassandra-2.0.5"
},
"cluster": {
"cluster_name": "products",
"num_tokens": 256,
"is_seed": true,
"endpoint_snitch": "RackInferringSnitch",
"join": false
},
...
}
}
</pre>

Response:

<pre>
{
"instance": {
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
...
}
}
</pre>
 
Notes:
* Unlike in MongoDB, the 'instance_type' field is not required (because all instances of the cluster are of the same type)
* 'cluster_name', 'num_tokens', and 'is_seed' are always required, with 'endpoint_snitch' being required if 'join' is false (if 'join' is true, the endpoint_snitch is inherited) and 'auto_bootstrap' required if 'join' is true.
* 'seed_provider' can optionally be provided, but conveniently defaults to 'org.apache.cassandra.locator.SimpleSeedProvider'
* 'join' indicates whether you're joining an existing cluster, or creating a new one. If 'join' is false, and an active cluster by that name for the tenant already exists, the request will be failed. 'join' by default will be false, but was included above for illustrative purposes.
* Likely the Keystone region and the availability-zone inherent to the trove request can be used for the data-center and rack (cassandra-topology.properties), but if it turns out that the naming schemes are incompatible, 'data_center' and 'rack' can be introduced.
* 'is_seed' is used vs. a seed list of ip-addresses because (1) the ip-address is not yet known and (2) when additional seeds are added, each instance in the cluster must be notified and updated. More on this later.

 
==== Add Instance to Cluster ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "product-b",
...
"cluster": {
"cluster_name": "products",
"num_tokens": 256,
"is_seed": false,
"auto_bootstrap": false,
"join": true
},
...
}
}
</pre>
 
Response:
<pre>
{
"instance": {
"status": "BUILD",
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
...
}
}
</pre>
 
Notes:
* If 'join' is true, and there is no existing cluster for the tenant matching the 'cluster_name' value, the request will be failed.
* If 'endpoint_snitch' is provided, and the value does not match that of the existing instances(s) in the cluster, the request will be failed.
 
==== Add Another Instance to Cluster ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "product-c",
...
"cluster": {
"cluster_name": "products",
"num_tokens": 256,
"is_seed": false,
"auto_bootstrap": false,
"join": true
},
...
}
}
</pre>
 
Response:
<pre>
{
"instance": {
"status": "BUILD",
"id": "3a72ee87-cf3e-40f1-a1e1-fe8c7263a782",
...
}
}
</pre>
 
==== Show Instance ====
 
Request:

<pre>
GET /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998
</pre>

Response:

<pre>
{
"instance": {
...
"cluster": {
"cluster_name": "products",
"num_tokens": 256,
"is_seed": true
},
...
}
}
</pre>
 
==== Show Cluster ====
 
Request:

<pre>
GET /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster
</pre>

Response:

<pre>
{
"cluster": {
"name": "products",
"instances": [
{
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"name": "product-a",
"num_tokens": 256,
"is_seed": true
},
{
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
"name": "product-b",
"num_tokens": 256,
"is_seed": false
},
{
"id": "3a72ee87-cf3e-40f1-a1e1-fe8c7263a782",
"name": "product-c",
"num_tokens": 256,
"is_seed": false
}
]
}
}
</pre>
 
==== Modifying a Cluster ====
 
Example: Drain (http://www.datastax.com/documentation/cassandra/2.0/cassandra/tools/toolsDrain.html)

<pre>
PUT /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster
{
"drain": {
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998"
}
}
</pre>

==== Remove an Instance ====
 
Request:

<pre>
PUT /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster
{
"promote": {
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998"
}
}
</pre>
 
Notes:
* Note that 'promote' was used here vs. "remove/decomm_instance" because the action is akin to promoting a mysql/redis slave instance (see https://wiki.apache.org/cassandra/Operations#Removing_nodes_entirely)
 

== Couchbase ==
 
==== Create Cluster ====
 
'''Create Initial Cluster'''
 
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "product-a",
...
"datastore": {
"type": "couchbase",
"version": "2.5.1"
},
"cluster": {
"cluster_name": "products",
"join": false
},
...
}
}
</pre>

Response:

<pre>
{
"instance": {
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
...
}
}
</pre>
 
Notes:
* Couchbase does not support a "cluster name", but does require a xdcr-cluster-name when using XDCR.
* Tip: Summary of operations at http://docs.couchbase.com/couchbase-manual-2.2/#xdcr-replicate-options
 
==== Add Instance to Cluster ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "product-b",
...
"cluster": {
"cluster_name": "products",
"join": true
},
...
}
}
</pre>
 
Response:
<pre>
{
"instance": {
"status": "BUILD",
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
...
}
}
</pre>
 
Notes:
* If 'join' is true, and there is no existing cluster for the tenant matching the 'cluster_name' value, the request will be failed.
* In Couchbase, a new instance can join the cluster by referencing any existing instance, which is discoverable by trove via the cluster_name (unique per tenant)
 
==== Add Another Instance to Cluster ====
 
Request/Response omitted due to a lack of any special considerations required
 
 
==== Show Instance ====
 
Request/Response omitted due to a lack of any special considerations required
 
 
==== Show Cluster ====
 
Request/Response omitted due to a lack of any special considerations required
 
 
==== Modifying a Cluster ====
 
Example: Create Bucket

<pre>
PUT /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster

{
"create_bucket": {
"bucket": "test_bucket",
"bucket_type": "couchbase",
"bucket_port": 11222,
"bucket_ramsize": 200,
"bucket_replica": 1
}
}
</pre>

==== Remove a Instance ====
 
Request:

<pre>
PUT /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster

{
"failover": {
"ids": ["dfbbd9ca-b5e1-4028-adb7-f78643e17998"],
"rebalance": true
}
}
</pre>
 
Notes:
* As noted in the Couchbase documentation, removing an instance is akin to a failover and has extreme impliciations. For this reason, "promote" was not used (that, and "rebalance" is optional.)
 
 

== Redis ==
 
==== Create Master ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "products",
...
"datastore": {
"type": "redis",
"version": "2.8.6"
},
...
}
}
</pre>

Response:

<pre>
{
"instance": {
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
...
}
}
</pre>
 
Notes:
* cluster{} is not required for redis
* note: 'join' field is not required for redis. also notice the lack of a 'cluster_name' of sorts (see 'Add Slave' for reasoning)

 
==== Add Slave ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "product-b",
...
"datastore": {
"type": "redis",
"version": "2.8.6"
},
"cluster": {
"slave_of": "dfbbd9ca-b5e1-4028-adb7-f78643e17998"
},
...
}
}
</pre>
 
Response:
<pre>
{
"instance": {
"status": "BUILD",
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
...
}
}
</pre>
 
Notes:
* redis supports daisy-chaining slaves, therefore the 'slave_of' value needs to be a specific trove instance uuid vs. a manufactured 'cluster_name' of sorts.
* whether it is a master or slave can be inferred from the presence (or lack thereof) of 'slave_of'.
* note that 'slave_of' is also used for mysql (the datastore information will have to be used to determine the semantic difference)
 
==== Show Instance ====
 
Request:

<pre>
GET /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998
</pre>

Response:

<pre>
{
"instance": {
...
}
}
</pre>
 
==== Show Cluster ====
 
Request:

<pre>
GET /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster
</pre>

Response:

<pre>
{
"cluster": {
"instances": [
{
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"name": "products"
},
{
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
"name": "product-b",
"slave_of": "dfbbd9ca-b5e1-4028-adb7-f78643e17998"
}
]
}
}
</pre>
 
==== Promote/Disconnect Slave ====
 
Request:

<pre>
PUT /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster

{
"promote": {
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998"
}
}
</pre>
 
Notes:
* note that 'promote' is also used for mysql (the datastore information will have to be used to determine the semantic difference)

== Redis Cluster ==
 
==== Create Cluster ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "product-a",
...
"datastore": {
"type": "redis",
"version": "3.0.0-beta1"
},
"cluster": {
"cluster_name": "products",
"join": false
},
...
}
}
</pre>

Response:

<pre>
{
"instance": {
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
...
}
}
</pre>
 
Notes:
* Will require datastore-version (to 'manager' to cluster{}) validation that cluster_name is supported for redis (because redis 3.x supports clusters, whereas 2.x does not)
* 'cluster-node-timeout' should be handled by configuration by the deployer (outside the context of configuration-group).
* Note: shares 'cluster_name' with Cassandra.
 
==== Add Another Master to Cluster ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "product-b",
...
"datastore": {
"type": "redis",
"version": "3.0.0-beta1"
},
"cluster": {
"cluster_name": "products",
"join": true
},
...
}
}
</pre>
 
Response:
<pre>
{
"instance": {
"status": "BUILD",
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
...
}
}
</pre>
 
==== Add Slave to Cluster ====
 
Request:

<pre>
POST /instances
{
"instance": {
"name": "product-c",
...
"datastore": {
"type": "redis",
"version": "3.0.0-beta1"
},
"cluster": {
"cluster_name": "products",
"slave_of": "dfbbd9ca-b5e1-4028-adb7-f78643e17998"
},
...
}
}
</pre>
 
Response:
<pre>
{
"instance": {
"status": "BUILD",
"id": "3a72ee87-cf3e-40f1-a1e1-fe8c7263a782",
...
}
}
</pre>
 
Notes:
* Despite redis clusters supporting the ability to add a slave without designating the master, we will require it to avoid unoptimal geographical relationships.
 
==== Show Instance ====
 
Request:

<pre>
GET /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998
</pre>

Response:

<pre>
{
"instance": {
...
"cluster": {
"cluster_name": "products"
},
...
}
}
</pre>
 
==== Show Cluster ====
 
Request:

<pre>
GET /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster
</pre>

Response:

<pre>
{
"cluster": {
"name": "products",
"instances": [
{
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"name": "product-a"
},
{
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
"name": "product-b"
},
{
"id": "3a72ee87-cf3e-40f1-a1e1-fe8c7263a782",
"name": "product-c",
"slave_of": "dfbbd9ca-b5e1-4028-adb7-f78643e17998"
}
]
}
}
</pre>
 
==== Promote/Disconnect Slave ====
 
Work in Progress
 
 
== Summary ==
 
==== Summary of cluster{} Fields ====
{| class="wikitable"
|-
! Field !! Datastore(s)
|-
| slave_of || mysql, redis, redis-cluster
|-
| read_only || mysql
|-
| instance_type || mongodb
|-
| num_instances || mongodb, cassandra, couchbase, redis-cluster
|-
| cluster_name || mongodb, cassandra, couchbase, redis-cluster
|-
| priority || mongodb
|-
| hidden || mongodb
|-
| slaveDelay || mongodb
|-
| hostname || mongodb
|-
| votes || mongodb
|-
| num_tokens || cassandra
|-
| is_seed || cassandra
|-
| endpoint_snitch || cassandra
|-
| auto_bootstrap || cassandra
|-
| join || mongodb, cassandra, couchbase, redis-cluster
|}
 
Questions:
* Is this an acceptable number of added fields, is it confusing, and is the growth of fields as we add more datastores sustainable?
 
==== Summary of Route Changes ====
 
New Routes:
<pre>
GET /instances/<id>/cluster
</pre>
<pre>
{
"cluster": {
"instances": [
{
"id": "<id>",
"name": "<name>",
<datastore-specific cluster fields>
},
<repeat>
]
}
}
</pre>
<pre>
PUT /instances/<id>/cluster
</pre>
<pre>
{
"<action>": {
<action-specific fields, with one or more including the targeted id(s)>
}
}
</pre>
 
== Open Questions ==
 
* How to handle additional filtering requirements for instance-list (need to likely filter by cluster_name, so how to handle mysql/redis in these scenarios).
 

== Discussion Points ==
 
==== Replica-Set Member Type/Attribute Updates ====
 
 
'''Option #1: PATCH /instances/:id/cluster'''
 
 
Request:

<pre>
PATCH /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster

{
"instances": [
{
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"priority": 2
},
{
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
"priority": 1
},
{
"id": "3a72ee87-cf3e-40f1-a1e1-fe8c7263a782",
"priority": 0.5
}
]
}
</pre>

Response:

<pre>
{
"cluster": {
"name": "products",
"instances": [
{
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"name": "product-a",
"instance_type": "member"
},
{
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
"name": "product-b",
"instance_type": "member"
},
{
"id": "3a72ee87-cf3e-40f1-a1e1-fe8c7263a782",
"name": "product-c",
"instance_type": "member"
}
]
}
}
</pre>
 
Notes:
* An HTTP PATCH vs. PUT because the omission of a field should not be an indication to drop/delete it.
* All modified fields in a request will be changed transactionally in a single rs.reconfig().
* It should now be clear why 'priority', 'hidden' and 'slaveDelay' are in cluster{} vs. a configuration-group: when a configuration-group is changed, an event is immediately triggered to update any attached trove instances. Therefore, if you have a heterogeneous mixture of configuration-groups in a replica-set, there is no way to coordinate a consolidated rs.reconfig().
* Downside: cluster{} may have fields returned on a GET that you cannot change in a PATCH/PUT; re-worded, the granularity of what is permissible to change in a PATCH becomes complicated to check and validate.
* TBD on what should be returned in the cluster{} on a GET /instance/:id and GET /instance/:id/cluster. It's a question of whether we should persist anything beyond the 'instance_type' and 'cluster_name'. If say the 'priority' is stored, you introduce the possibility of drift from the truth, but can easily return it on a GET; if it's not stored, do we prompt MongoDB for the truth on a GET, or is that too computationally expensive?
 
 
'''Option #2: POST /instances/:id/cluster/action'''
 
 
Request:

<pre>
POST or PUT /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster/action
or POST or PUT /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster

{
"update_member_attributes": {
"instances": [
{
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
"priority": 2
},
{
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
"priority": 1
},
{
"id": "3a72ee87-cf3e-40f1-a1e1-fe8c7263a782",
"priority": 0.5
}
]
}
}
</pre>
 
Notes:
* 'update_member_attributes.members[]' elements will only permit 'priority', 'hidden', and 'slaveDelay' (possibly 'votes' and 'hostname' as mentioned earlier).
* Due to the limited field-set, this approach is much more fine-grained than the PATCH approach in Option #1.
 
 
Decision: Option #2 is more fine-grained, easier to reason about, and less error-prone. As you'll see in later operations (like Remove a Member), is also more appropriate.
 
 
==== Remove a Member from a Replica-Set ====
 
Removing a member from a cluster/cluster is not the same as deleting one, therefore DELETE /instances/:id is not appropriate.
 
 
'''Option #1: PUT /instances/:id/cluster'''
 
 
Request:

<pre>
PUT /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster

{
"instances": [
{
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998",
},
{
"id": "061aaf4c-3a57-411e-9df9-2d0f813db859",
}
]
}
</pre>
 
Notes:
* By omitting a member{} for id=3a72ee87-cf3e-40f1-a1e1-fe8c7263a782 in a PUT operation, this indicates the member should be removed from the replica-set.
* It's possible that one might want to modify the 'priority', 'hidden', 'votes', etc. fields of the remaining members while dropping a member. So although the example above does not show it, mongodb{} can be included in a member to indicate other changes, *BUT*, since it's a PUT the expectation of what happens to omitted fields in mongodb{} becomes unclear.
 
Summary: Not very clean, mildly confusing, and very error-prone (nowhere is a "remove" action ever explicitly implied).
 
 
'''Option #2: POST /instances/:id/cluster/action'''
 
 
Request:

<pre>
PUT /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster

{
"remove_member": {
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998"
}
}
</pre>
 
Notes:
* The 'remove_member' action is explicit here, vs. implicit as seen in the prior example.
* 'remove_member' has a strict set of fields that are supported, so there is no question as to what can be provided and what will be honored (as compared to Option #1).
* Note: Could rename remove_member here to 'promote'!
 
Summary: Fairly clean, with no real drawbacks.
 
 
'''Option #3: POST /instances/:id/cluster/remove'''
 
 
<pre>
POST /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster/remove

{
"id": "dfbbd9ca-b5e1-4028-adb7-f78643e17998"
}
</pre>
 
Notes:
* Differs from Option #2 in that the action is in the URI vs. the payload (which is considered incorrect in REST due to it being a verb)
* One drawback of this approach is that not every action will be supported across all datastores. So for example, a POST /instances/:id/cluster/changeoplogsize (http://docs.mongodb.org/manual/tutorial/change-oplog-size/) makes absolutely no sense to any datastore other than MongoDB.
 
Summary: At first glance it might look cleaner than Option #2 from a payload-perspective, but the URI discoverability and expansion is awful.
 
 
'''Option #4: POST /instances/:id/action'''
 
 
<pre>
POST /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/action

{
"join": false
}
</pre>
 
Notes:
* Executed against the instance you wish to remove itself from the cluster, so providing the 'id' in the payload is unnecessary.
* Drawback: There are actions that are replica-set-wide (or against a subset of the replica-set), meaning Option #1 or #2 or #3 would have to co-exist with this option anyway.
* Drawback: Increase the number of ways to accomplish the same thing (could unjoin against /instances/:id/action, or against /instances/:id/cluster)
 
Summary: For this very specific example it looks great, but isn't expressive enough for other actions.
 
 
'''Option #5: POST /instances/:id/cluster/:id/action'''
 
 
<pre>
POST /instances/dfbbd9ca-b5e1-4028-adb7-f78643e17998/cluster/dfbbd9ca-b5e1-4028-adb7-f78643e17998/action

{
"remove": {}
}
</pre>
 
Notes:
* The /instances/:id is an arbitrary member in the replica-set, it doesn't matter which one; the cluster/:id is then a member of said replica-set that this action will be applied to.
* Executed against the instance you wish to remove itself from the cluster, so providing the 'id' in the payload is unnecessary.
* Needs More Thought: Could conceivably allow only specific operations here (like remove/unjoin), but not others that could be accomplished in a PATCH against /instances/:id/cluster (like 'priority', 'hidden', etc.)
 
Summary: Fairly clean with no real drawbacks.

Oslo/ProjectLiaisons

2014-04-11T19:39:50Z

Vipuls: /* Liaisons for Oslo Integration */

= Liaisons for Oslo Integration =

There are now more projects consuming code from the Oslo incubator than we have Oslo contributors. That means we are going to need your help to make these migrations happen. We are asking for one person from each project to serve as a liaison between the project and Oslo, and to assist with integrating changes as we move code out of the incubator into libraries.

The liaison should be a core reviewer for the project, but does not need to be the PTL. The liaison should be prepared to assist with writing and reviewing patches in their project as libraries are adopted, and with discussions of API changes to the libraries to make them easier to use within the project.

{| class="wikitable"
|-
! Project !! Liaison !! IRC Handle
|-
| nova || Joe Gordon || jogo
|-
| cinder || Duncan Thomas || DuncanT
|-
| ironic || Ghe Rivero || GheRivero
|-
| horizon || Lin Hua Cheng || lcheng
|-
| ceilometer || Julien Danjou || jd__
|-
| marconi || Flavio Percoco || flaper87
|-
| glance || Flavio Percoco || flaper87
|-
| heat || Thomas Herve || therve
|-
| trove || Vipul Sabhaya || vipul
|}

Meetings/TroveMeeting

2014-02-26T17:57:01Z

Vipuls: /* Agenda for todays meeting */

= Weekly Trove (DBaaS) team meeting =

For those interested, we have meetings in #openstack-meeting-alt Weekly, Wednesdays at 18:00 UTC. Feel free to add items in the agenda below.

Logs available: http://eavesdrop.openstack.org/meetings/trove/2014/

== Agenda for todays meeting ==
* Clustering decision next week
* Replication work status
* RDJenkins maintenance

== Agenda for Mar. 5 ==

OpenPGP Web of Trust/Trove Icehouse Sprint

2014-02-17T19:40:15Z

Vipuls: /* Trove Mid-Cycle Icehouse Sprint Key Signing */

= Trove Mid-Cycle Icehouse Sprint Key Signing =
If you plan to join us, please bring one or more forms of photo identification, and make sure the real name on your key corresponds to the name on your ID. If you want additional tips, see the [[OpenPGP Web of Trust#Key Signing Process|parent article]].

If you want to bring cards or pieces of paper with your name and key fingerprint then feel free, but if you add your information to the table below we will do our best to bring paper copies (at least enough for the people who are listed here) for use as a checklist so that you won't need to use your computer. Please bring extra pens or pencils however, if you can, since there may not be many of those to go around.

{| class="wikitable"
|+ People participating in identification exchange
! Real Name !! IRC Nick !! Key Fingerprint !! Preferred E-mail Address
|-
| Nikhil Manchanda || slicknik || 5674 7211 71F8 CD59 F285 353D 9692 757E BCD3 D66C || nikhil@manchanda.me
|-
| Steve Leon || esmute || 02F1 F2AE C17D 66D2 1B1B B75C EF3B 2AB9 FFF4 F9EA || steve.leon@hp.com
|-
| Justin Hopper || juice || 7463 498F 7D3B 7DB3 FFBF 4946 C02F 046F '''EA23 8CF3''' || justin.hopper@me.com
|-
|Michael Basnight||hub_cap||9D60 7133 8AFE 4FE5 45D9 625E 9E86 DD8C 3DB5 897B||mbasnight@gmail.com
|-
|Craig Vyvial||cp16net||8975 C9C2 E879 309A 771B 7C01 046B FABA F4BD 6CC2||cp16net@gmail.com
|-
|Dan Nguyen||esp||D9D4 F72E 82FC EFCE 1923 B140 9163 F056 AE67 298E||dan.nguyens.mail@gmail.com
|-
|Daniel Salinas||imsplitbit||54C5 515E 71FB 1533 2332 F115 78EE B83C 964B C17C||imsplitbit@gmail.com
|-
|Andrew Bramley||abramley||7082 00CC 9C6F 7523 C3B1 2CB4 9E67 CA34 2DAA 044F||andrew@tesora.com
|-
|Amrith Kumar||amrith||0D22 859E BE93 63F5 9DD6 35BC 5E48 849A 9D21 A29B||amrith@tesora.com
|-
|Paul Marshall||pdmars||2DCA A0AB 6DEC A717 FC80 A6D1 9F08 2613 795C B691||paul.marshall@rackspace.com
|-
|Vipul Sabhaya||vipul||B7FA 44B3 32C7 1A3A F606 1ED7 A2C7 95BC 02AE 77A2 ||vipul.sabhaya@hp.com
|}

Meetings/TroveMeeting

2013-10-09T03:36:50Z