OpenStack - User contributions [en]

Design Summit/Liberty/Etherpads

2015-05-21T18:41:39Z

Huang Zhiteng:

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

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

<br/>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
* Thursday • 13:30pm - 14:10pm https://etherpad.openstack.org/p/YVR-cinder-tasks-resumptions
* Thursday • 2:20pm - 3:00pm https://etherpad.openstack.org/p/
* Thursday • 3:10pm - 3:50pm https://etherpad.openstack.org/p/

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

<br />
'''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]

<br />
'''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]

<br />
'''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]

<br />

==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]
<br/>
'''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]
<br/>
'''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
<br>
'''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]
<br/>
'''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]
<br/>
'''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

ReleaseNotes/Juno

2015-01-07T17:23:08Z

Huang Zhiteng:

<languages />
<translate>


[[Category:Juno|Release Note]]
[[Category:Release Note|Juno]]

= OpenStack 2014.2 (Juno) Release Notes = 


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

== General Upgrade Notes == 


* The simplejson package is an optional requirement in most projects, therefore it's not listed in all project's requirements.txt file. However, if you're using it, e.g. better performance with python 2.6 on RHEL 6, then you will need simplejson >= 2.2.0. See https://bugs.launchpad.net/oslo-incubator/+bug/1361230 for details.

== OpenStack Object Storage (Swift) == 

=== Key New Features === 


The Juno integrated release includes three releases of OpenStack Swift: 2.0.0, 2.1.0, and 2.2.0. The changelog for these releases is available at https://github.com/openstack/swift/blob/2.2.0.rc1/CHANGELOG#L1-L173. Please refer to that document for release details.


Important new features are highlighted below. Please read the CHANGELOG and associated documentation.


* Storage policies
* Keystone v3 support
* Server-side account-to-account copy
* Better partition placement when adding a new server, zone, or region.
* Zero-copy GET responses using splice()
* Parallel object auditor

=== Known Issues === 


* None at this time

=== Upgrade Notes === 


As always, you can upgrade your Swift cluster with no downtime for end-users. Please refer to sample config files and documentation before every release.


* There have been some logging changes that need to be called out. In all cases, well-behaved log processors will not be affected.
** Storage node (account, container, object) logs now have the PID logged at the end of the log line.
** Object daemons now send a user-agent string with their full name (e.g. "obj" is now "object").
* Once an additional storage policy has been enabled, downgrading to Swift pre-2.0.0 will cause any additional storage policies to become unavailable.
* As part of an effort to eventually update the default port to swift to an non-IANA-assigned range, bind_port is now a required setting. Anyone currently explicitly setting the ports will not be affected. However, if you do not currently set the ports, please ensure that your *_server.conf has bind_port set to match your ring as part of your upgrade.
* Note that storage policies include a new daemon, the container-reconciler.
* TempURL default allowed methods config setting now also allows POST and DELETE. This means tempurls can be created for these verbs. It does not affect any existing tempurls.
* A list of all updated, deprecated or removed options in swift can be found at: http://docs.openstack.org/trunk/config-reference/content/swift-conf-changes-master.html

== OpenStack Compute (Nova) == 

===Instance features=== 


* Allow users to specify an image to use for rescue instead of the original base image. [https://blueprints.launchpad.net/nova/+spec/allow-image-to-be-specified-during-rescue launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/allow-image-to-be-specified-during-rescue specification]
* Allow images to specify if a config drive should be used. [https://blueprints.launchpad.net/nova/+spec/config-drive-image-property launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/config-drive-image-property specification]
* Give users and administrators the ability to control the vCPU topology exposed to guests via flavors. [https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/virt-driver-vcpu-topology specification]
* Attach All Local Disks During Rescue. [https://blueprints.launchpad.net/nova/+spec/rescue-attach-all-disks launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/rescue-attach-all-disks specification]

===Networking=== 


* Improve the nova-network code to allow per-network settings. [https://blueprints.launchpad.net/nova/+spec/better-support-for-multiple-networks launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/better-support-for-multiple-networks specification]
* Allow deployers to add hooks which are informed as soon as networking information for an instance is changed. [https://blueprints.launchpad.net/nova/+spec/instance-network-info-hook launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/instance-network-info-hook specification]
* Enable nova instances to be booted up with SR-IOV neutron ports. [https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/pci-passthrough-sriov specification]
* Permit VMs to attach multiple interfaces to one network. [https://blueprints.launchpad.net/nova/+spec/multiple-if-1-net launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/nfv-multiple-if-1-net specification]

===Scheduling=== 


* Extensible Resource Tracking. The set of resources tracked by nova is hard coded, this change makes that extensible, which will allow plug-ins to track new types of resources for scheduling. [https://blueprints.launchpad.net/nova/+spec/extensible-resource-tracking launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/extensible-resource-tracking specification]
* Allow a host to be evacuated, but with the scheduler selecting destination hosts for the instances moved. [https://blueprints.launchpad.net/nova/+spec/find-host-and-evacuate-instance launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/find-host-and-evacuate-instance specification]
* Add support for host aggregates to scheduler filters. launchpad: [https://blueprints.launchpad.net/nova/+spec/per-aggregate-disk-allocation-ratio disk]; [https://blueprints.launchpad.net/nova/+spec/per-aggregate-max-instances-per-host instances]; and [https://blueprints.launchpad.net/nova/+spec/per-aggregate-max-io-ops-per-host IO ops] [http://specs.openstack.org/openstack/nova-specs/specs/juno/per-aggregate-filters specification]

===Other=== 


* Offload periodic task sql query load to a slave sql server if one is configured. [https://blueprints.launchpad.net/nova/+spec/juno-slaveification launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/juno-slaveification specification]
* Only update the status of a host in the sql database when the status changes, instead of every 60 seconds. [https://blueprints.launchpad.net/nova/+spec/on-demand-compute-update launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/on-demand-compute-update specification]
* Include status information in API listings of hypervisor hosts. [https://blueprints.launchpad.net/nova/+spec/return-status-for-hypervisor-node launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/return-status-for-hypervisor-node specification]
* Allow API callers to specify more than one status to filter by when listing services. [https://blueprints.launchpad.net/nova/+spec/servers-list-support-multi-status launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/servers-list-support-multi-status specification]
* Add quota values to constrain the number and size of server groups a users can create. [https://blueprints.launchpad.net/nova/+spec/server-group-quotas launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/server-group-quotas specification]

===Hypervisor driver specific=== 

====Hyper-V==== 


* Support for differencing vhdx images. [https://blueprints.launchpad.net/nova/+spec/add-differencing-vhdx-resize-support launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/add-differencing-vhdx-resize-support specification]
* Support for console serial logs. [https://blueprints.launchpad.net/nova/+spec/hyper-v-console-log launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/hyper-v-console-log specification]
* Support soft reboot. [https://blueprints.launchpad.net/nova/+spec/hyper-v-soft-reboot launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/hyper-v-soft-reboot specification]

====Ironic==== 


* Add a virt driver for Ironic. [https://blueprints.launchpad.net/nova/+spec/add-ironic-driver launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/add-ironic-driver specification]

====libvirt==== 


* Performance improvements to listing instances on modern libvirts. [https://blueprints.launchpad.net/nova/+spec/libvirt-domain-listing-speedup launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/libvirt-domain-listing-speedup specification]
* Allow snapshots of network backed disks. [https://blueprints.launchpad.net/nova/+spec/libvirt-volume-snap-network-disk launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/libvirt-volume-snap-network-disk specification]
* Enable qemu memory balloon statistics for ceilometer reporting. [https://blueprints.launchpad.net/nova/+spec/enabled-qemu-memballoon-stats launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/enabled-qemu-memballoon-stats specification]
* Add support for handing back unused disk blocks to the underlying storage system. [https://blueprints.launchpad.net/nova/+spec/libvirt-disk-discard-option launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/libvirt-disk-discard-option specification]
* Meta-data about an instance is now recorded in the libvirt domain XML. This is intended to help administrators while debugging problems. [https://blueprints.launchpad.net/nova/+spec/libvirt-driver-domain-metadata launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/libvirt-driver-domain-metadata specification]
* Support namespaces for LXC containers. [https://blueprints.launchpad.net/nova/+spec/libvirt-lxc-user-namespaces launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/libvirt-lxc-user-namespaces specification]
* Copy-on-write cloning for RBD-backed disks. [https://blueprints.launchpad.net/nova/+spec/rbd-clone-image-handler launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/rbd-clone-image-handler specification]
* Expose interactive serial consoles. [https://blueprints.launchpad.net/nova/+spec/serial-ports launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/serial-ports specification]
* Allow controlled shutdown of guest operating systems during VM power off. [https://blueprints.launchpad.net/nova/+spec/user-defined-shutdown launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/user-defined-shutdown specification]
* Intelligent NUMA node placement for guests. [https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/virt-driver-numa-placement specification]

====vmware==== 


* Move the vmware driver to using the oslo vmware helper library. [https://blueprints.launchpad.net/nova/+spec/use-oslo-vmware launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/use-oslo-vmware specification]
* Add support for network interface hot plugging to vmware. [https://blueprints.launchpad.net/nova/+spec/vmware-hot-plug launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/vmware-hot-plug specification]
* Refactor the vmware driver's spawn functionality to be more maintainable. This work was internal, but is mentioned here because it significantly improves the supportability of the VMWare driver. [https://blueprints.launchpad.net/nova/+spec/vmware-spawn-refactor launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/vmware-spawn-refactor specification]

=== Known Issues === 


* When using libvirt, live snapshots are effectively disabled, due to this difficult-to-reproduce bug: https://bugs.launchpad.net/nova/+bug/1334398 (https://review.openstack.org/#/c/102643/)
* Glance v2 and Keystone v3 are not tested with Nova in Juno.

=== Upgrade Notes === 


* A list of all updated, deprecated or removed options in Nova can be found at: http://docs.openstack.org/juno/config-reference/content/nova-conf-changes-juno.html
* The nova-manage flavor subcommand is deprecated in Juno and will be removed in the 2015.1 (K) release: https://review.openstack.org/#/c/86122/
* https://review.openstack.org/#/c/102212/
* Minimum required libvirt version is now 0.9.11: https://review.openstack.org/#/c/58494/
* Nova is now supporting the [https://review.openstack.org/#/c/43986/ Cinder V2 API]. The Cinder V1 API is deprecated in Juno and Nova will switch over to Cinder V2 by default in the Kilo release.
** Nova talks to Cinder V1 in the gate (continuous integration testing).
* Debug log output in python-novaclient has [https://review.openstack.org/#/c/98443/ changed slightly] to improve readability. The sha1 hash of the keystone token is now printed instead of the token itself - greatly shortening the amount of content being printed while still retaining the ability to determine token mismatch scenarios. In addition, some extra '\n' characters that were being added are removed. ''Double-check any log parsers!''
* libvirt.volume_drivers config param for nova.conf is deprecated, to be removed in the Lxxxx release. In general, this should affect only a small number of developers working on drivers. If this is you, the recommended approach is to continue your work inside a nova tree.
* python 2.6 support is deprecated in Juno and will be removed in the Kilo 2015.1 release.

== OpenStack Image Service (Glance) == 

=== Key New Features === 


* Asynchronous Processing
* Pull of glance.store into its own library
* [http://docs.openstack.org/developer/glance/metadefs-concepts.html Metadata Definitions Catalog]
* Restricted policy for downloading images.
* Enhanced Scrubber service allows single instance services multiple glance-api servers cross nodes.

=== Known Issues === 

=== Upgrade Notes === 


* A list of all updated, deprecated or removed options in Glance can be found at: http://docs.openstack.org/juno/config-reference/content/glance-conf-changes-juno.html
* The ability to upload a public image is now admin-only by default. To continue to use the previous behaviour, edit the publicize_image flag in etc/policy.json to remove the role restriction.
* The requirement and check on UTF-8 charset for DB tables is enforced, operator need to migration tables and existing data to UTF-8 manually if glance-manage complains it during the sync.
* glance workers will now be equal to the number of CPUs available by default if not explicitly specified in glance-api.conf and/or glance-registry.conf
** There is no upgrade impact to glance-api workers since glance-api.conf previously hard-coded the workers value to 1 so anyone upgrading to tihs will still get whatever value was set in glance-api.conf prior to this change. There is an upgrade impact to the glance-registry workers since glance-registry.conf did not hard-code the workers value to 1 before this change. So anyone upgrading to this change that does not have workers specified in glance-registry.conf will now be running multiple workers by default when they restart the glance registry service.

== OpenStack Dashboard (Horizon) == 

=== Key New Features === 

==== Sahara ==== 


The OpenStack Data Processing project (Sahara) was formally included into the integrated release in Juno and Horizon includes broad support for managing your data processing. You can specify and build clusters to utilize several data types with user specified jobs while tracking the progress of those jobs.

==== Neutron Features ==== 


Neutron added several new features in Juno, including:
* DVR (Distributed Virtual Routing)
* L3 HA support
* IPv6 subnet modes


Horizon provides support for these new features with the Juno release. These features provide much greater flexibility in specifying software defined networks.


An existing feature in Neutron that Horizon now supports is the MAC learning extension.

==== Glance Features ==== 


In Juno, Glance introduced the ability to manage a catalog of metadata definitions where users can register the metadata definitions to be used on various resource types including images, aggregates, and flavors. Support for viewing and editing the assignment of these metadata tags is included in Horizon.

==== Cinder Features ==== 


In a continued effort to provide fuller API support, several features supported by Cinder are now supported in Horizon in the Juno release. Users can now utilize swift to store volume backups from Horizon as well as restore volumes from these backups.


Other features of the Cinder API not previously supported by Horizon added in Juno include:
* Enabling resetting the state of a snapshot
* Enabling resetting the state of a volume
* Supporting upload-to-image
* Volume retype
* QoS (quality of service) support

==== Trove ==== 


Trove supports potentially using numerous different datastores, e.g., mysql, redis, mongodb. Users can now select from the list of datastores supported by the cloud operator when creating their database instances.


Another addition is support for utilizing and restoring from incremental database backups.


To improve support for Neutron based clouds, when creating a database instance, the user can now specify the NIC for the database instance on creation allowing direct access to the instance by the user.

==== Nova ==== 


The new nova instance actions panel provides a list of all actions taken on all instances in the current project allowing users to view resulting errors or actions taken by other users on those instances.


Administrators now have the ability to evacuate instances off hypervisors which can aid in system maintenance by providing a mechanism to migrate all instances to other hosts.

==== Improved Plugin Support ==== 


The plugin system in Horizon continued to improve in the Juno release.
Some of those improvements:


* Support for adding plugin specific AngularJS modules
* Support for adding static files, e.g., CSS, JS, images
* Ability to add exceptions
* Fixing ordering issues
* Numerous other bug fixes

==== Enhanced RBAC support ==== 


In an ongoing effort to support richer role based access control (RBAC) in Horizon, the views for several more services were enhanced with RBAC checks to determine user access to actions. The newly supported services are compute, network and orchestration. These changes allow operators to implement finer grained access control than just "member" and "admin".


The identity panels (domains, projects, users, roles, groups) have also been converted to support RBAC at the view level. The identity panels have been moved from the admin dashboard into their own 'Identity' dashboard and accessibility is determined by policies alone. This is the first step toward consolidating the near duplicate content of the project and admin dashboards into single views supporting a wide range of roles.

==== UX Changes ==== 


In Juno, Horizon transitioned to utilizing Bootstrap v3. Horizon had been pinned to an older version of Bootstrap for several releases. This change now allows Horizon to pick up numerous bug fixes and overall improvements in the Bootstrap framework. The look and feel remains mainly consistent with the Havana release.

==== JavaScript Libraries Extracted ==== 


As part of the Horizon team's ongoing efforts to split the repository into more logical pieces, all the 3rd party JavaScript libraries that Horizon depends on have been removed from the Horizon code base and python xstatic packages have been utilized instead. The xstatic format allows for easy consumption by the Django framework Horizon is built on. Now JavaScript libraries are utilized like any other python dependency in Horizon.

==== Conversion from LESS to SCSS ==== 


The supported stylesheets in Horizon have been converted to utilize SCSS rather than LESS. The change was necessary due to a prevalent lack of support for LESS compilers in python. This change also allowed us to upgrade to Bootstrap 3, as parts of the Bootstrap 3 LESS stylesheets were not supported by existing python based LESS compilers.

=== Known Issues === 

==== Rendering issues in extensions ==== 


The conversion to utilizing Bootstrap v3 can cause content extensions written on top of Horizon to have rendering issues. Most of these are fixed by a simple CSS class name substitutions. These issues are primarily seen with buttons and panel content widths.

==== Online Compression ==== 


With the move to SCSS, there may be issues with utilizing online compression in non-DEBUG mode in Horizon. Offline compression continues to work as in previous releases.

==== Neutron L3 HA ==== 


The HA property is updateable in the UI, however, Neutron API does not allow the update operation because toggling HA support does not work.
https://bugs.launchpad.net/horizon/+bug/1378525

=== Upgrade Notes === 


* FLAVOR_EXTRA_KEYS setting deprecated. The use of this key has been replaced with direct calls to the nova and [http://docs.openstack.org/developer/glance/metadefs-concepts.html glance api] as appropriate.

== OpenStack Identity (Keystone) == 

=== Key New Features === 


* Keystone now has experimental support for [http://docs.openstack.org/developer/keystone/configure_federation.html#keystone-as-an-identity-provider-idp Keystone-to-Keystone federation], where one instance acts as an Identity Provider, and the other a Service Provider.
* PKIZ is a new token provider available for users of PKI tokens, which simply adds zlib-based compression to traditional PKI tokens.
* The hashing algorithm used for PKI tokens has been made configurable (the default is still MD5, but the Keystone team recommends that deployments migrate to SHA256).
* Identity-driver-configuration-per-domain now supports Internet domain names of arbitrary hierarchical complexity (for example, <code>customer.cloud.example.com</code>).
* The LDAP identity backend now supports <code>description</code> as an attribute of users.
* Identity API v3 requests are now validated via JSON Schema.
* In the case of multiple identity backends, Keystone can now map arbitrary resource IDs to arbitrary backends.
* <code>keystoneclient.middleware.auth_token</code> has been moved into it's own repository, <code>keystonemiddleware.auth_token</code>.
* Identity API v3 now supports a discrete call to retrieve a service catalog, <code>GET /v3/auth/catalog</code>.
* Federated authentication events and local role assignment operations now result in CADF (audit) notifications.
* Keystone can now associate a given policy blob with one or more endpoints.
* Keystone now provides JSON Home documents on the root API endpoints in response to <code>Accept: application/json-home</code> headers.
* Hiding endpoints from client's service catalogs is now more easily manageable via <code>OS-EP-FILTER</code>.
* The credentials collection API is now filterable per associated user (<code>GET /v3/credentials?user_id={user_id}</code>).
* New, generic API endpoints are available for retrieving authentication-related data, such as a service catalog, available project scopes, and available domain scopes.
* Keystone now supports mapping the user <code>enabled</code> attribute to the <code>lock</code> attribute in LDAP (and inverting the corresponding boolean value accordingly).
* A CA certificate file is now configurable for LDAPS connections.
* The templated catalog backend now supports generating service catalogs for Identity API v3.
* Service names were added to the v3 service catalog.
* Services can now be filtered by name (<code> GET /v3/services?name={service_name}</code>).

=== Known Issues === 

==== LDAP paged search results don't work with python-ldap 2.4 ==== 


When using an LDAP backend with paged search results enabled, AttributeErrors will be encountered if python-ldap 2.4 is being used. This is due to a backwards incompatible API change in python-ldap. The issue can be worked around in a few ways:
* Disabling paging of search results by setting ''page_size'' to ''0'' in the ''[ldap]'' section of keystone.conf.
* Downgrade python-ldap to version 2.3.x.


A fix for this issue has been proposed, which is expected to be made available in a stable update for Juno. For more details see https://bugs.launchpad.net/keystone/+bug/1381768

=== Upgrade Notes === 


* Due to the simpler out-of-the-box experience, the default token provider is now UUID instead of PKI.
* Database migrations for releases prior to Havana have been dropped, meaning that you must upgrade to the Juno release from either a Havana or Icehouse deployment.
* A comprehensive list of all updated, deprecated or removed options in Keystone can be found at: http://docs.openstack.org/juno/config-reference/content/keystone-conf-changes-juno.html
** All <code>token_api</code> methods are now deprecated.
** LDAP configuration options that previously contained the deprecated <code>tenant</code> terminology have been superseded by options using the term <code>project</code>.
** Proxy methods from the identity backend to the assignment backend (created to provide backwards compatibility as a result of the split of the Assignment backend from the Identity backend), have been removed. This should only affect custom, out-of-tree API extensions.
** Loading authentication plugins solely by class name in <code>keystone.conf</code> is now deprecated in favor of loading them by <code>custom-method-name = custom_package.CustomClass</code> pairs, and then defining the sequence of authentication methods as a list (<code>methods = custom-method-name, password</code>).
** In-tree token drivers (<code>keystone.token.backends</code>) have been moved to <code>keystone.token.persistence.backends</code>. Proxy objects exist to maintain compatibility. If a non-default value is used, it is recommended the value of the <code>driver</code> option in the <code>[token]</code> section of <code>keystone.conf</code> is updated to use the new location.
* All KVS backends besides the <code>token</code> driver have been formally deprecated.
* LDAP/AD configuration: All configuration options containing the term "tenant" have been deprecated in favor of similarly named configuration options using the term "project" (for example, <code>tenant_id_attribute</code> has been replaced by <code>project_id_attribute</code>).

== OpenStack Network Service (Neutron) == 
=== Key New Features ===
* DB migration refactor and new timeline
* Distributed Virtual Router Support (DVR)
* Full IPV6 support for tenant networks
* High Availability for the L3 Agent
* ipset support for security groups in place of iptables (this option is configurable)
* L3 agent performance improvements
* Migration to oslo.messaging library for RPC communication.
* Security group rules for devices RPC call refactoring (a huge performance improvement)
* New Plugins supported in Juno include the following:
** A10 Networks LBaaS driver for the LBaaS V1 API
** Arista L3 routing plugin
** Big Switch L3 routing plugin
** Brocade L3 routing plugin
** Cisco APIC ML2 Driver (including a L3 routing plugin).
** Cisco CSR L3 routing plugin
** Freescale SDN ML2 Mechanism Driver
** Nuage Networks ML2 Mechanism Driver
** SR-IOV capable NIC ML2 Mechanism Driver
** OpenContrail Neutron Plugin

=== Known Issues === 
* This is the first release for DVR and HA L3. The Neutron team desires to designate these features as production ready in Kilo and requests that deployers test on non-critical workloads and report any issues.
* FWaaS is still labeled as experimental, as it does not allow you to have more than one FW per tenant.

=== Upgrade Notes === 
* DB migration from the previous releases (icehouse or havana)
** In Icehouse or Hanava releases, the db migration operation is optional. If your Neutron database is not stamped (i.e., there is the db migration version info), please make sure to "stamp icehouse" before running the upgrade db migration to Juno.
** To check if your database is stamped, run the following command:
neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file <your plugin config file> current
** If the output of the current version is '''None''', please run:
neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file <your plugin config file> stamp icehouse
** and then run the db migration for upgrading Juno:
neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file <your plugin config file> upgrade juno
* A list of all updated, deprecated or removed options in neutron can be found at: http://docs.openstack.org/juno/config-reference/content/neutron-conf-changes-juno.html
* Attribute level policies dependent on resources are not enforced anymore. Meaning that some older policies from Icehouse are not needed. (e.g. "get_port:binding:vnic_type": "rule:admin_or_owner").
* The following plugins are deprecated in Juno:
** Cisco Nexus Sub-Plugin (The Nexus 1000V Sub-Plugin is still retained and supported in Juno).
** Mellanox Plugin
** Ryu Plugin
*XML support in the API is deprecated. Users and deployers should migrate to JSON for API interactions as soon as possible since the XML support will be removed in the Kilo (2015.1) release.

== OpenStack Block Storage (Cinder) == 
=== Key New Features ===
* Support for Volume Replication.
* Support for Consistency Groups and Snapshots of Consistency Groups.
* Support for Volume Pools.
* Completion of i18n-enablement
* Honor Glance protected properties in Image Upload
* Enable ability to restrict bandwidth usage on volume-copy operations
* Add Volume Num Weigher Scheduling

=== New Drivers/Plugins === 
* Datera
* Fujitsu ETERNUS
* Fusion IO
* Hitachi HBSD
* Huawei
* Nimble
* Prophetstor
* Pure
* XtremIO
* Oracle ZFS

=== Limitations/Known Issues === 
* The newly introduced 'Pool' terminology is a logical concept to describe a set of storage resource that can be used to serve core Cinder requests, e.g. volumes/snapshots. This notion is almost identical to Cinder Volume Backend, for it has simliar attributes (capacity, capability). The main difference is Pool couldn't exist on its own, it must reside in a Volume Backend. One Volume Backend can have mulitple Pools but Pools don't have sub-Pools (meaning even they have, sub-Pools don't get to exposed to Cinder, yet). Pool has a unique name in backend namespace, which means Volume Backend can't have two pools using same name. The introduction of 'Pools' has some user visible impact because it changes the granularity of scheduling a volume from 'Backend' to 'Pools'. For example: migrating/managing volume now has to include pool in 'host' parameter in order to work.
cinder manage --source-name X --name newX host@backend#POOL
cinder migrate UUID host@backend#POOL

* To find out what pools a backend has, use following API extension to query info (need admin role):
- Pool name only:
GET http://CINDER_API_ENDPOINT/v2/TENANT_ID/scheduler-stats/get_pools
- Detailed Pool info:
GET http://CINDER_API_ENDPOINT/v2/TENANT_ID/scheduler-stats/get_pools\?detail\=True

* The 'retyping' or affinity filter hint *may not* work like before. Cinder has a special code path for legacy volumes - volumes created before Juno - to allow (potential) migration between pools even migration_policy is set to 'never'. But not every driver has magic to move volumes to one pool to another at minimum cost. The inconsistency behavior between drivers (same command may take totally different time to finish), which could be confusing.

=== Upgrade Notes === 
* A list of all updated, deprecated or removed options in Cinder can be found at: http://docs.openstack.org/trunk/config-reference/content/cinder-conf-changes-master.html
* Nova is now supporting the [https://review.openstack.org/#/c/43986/ Cinder V2 API]. The Cinder V1 API is deprecated in Juno and Nova will switch over to Cinder V2 by default in the "L" release. You need to update the cinder_catalog_info config option in nova to 'volume2:cinder:internalURL' to have Nova use the cinder v2 endpoint, in addition to the cinder v2 endpoint being available in the keystone catalog.

== OpenStack Telemetry (Ceilometer) == 
=== Key New Features ===
* Support for partitioning metric collection load across horizontally scaled-out central agents
* New method of partitioning alarm evaluation load using [https://github.com/stackforge/tooz tooz] coordination, as opposed to a hand-crafted protocol
* Much improved SQLAlchemy storage performance & scalability, so that MySQL or PostgreSQL can be used as the metering store for PoCs or small deployments
* Support for hardware-oriented monitoring of IPMI sensors via notifications from either Ironic or a new standalone agent
* More flexible & efficient SNMP monitoring:
** batching queries for multiple SNMP metrics into a single call to each daemon
** dynamic discovery of nodes deployed by TripleO for SNMP polling
** the ability to more easily extend the range of SNMP metrics that ceilometer gathers
** the ability to derive new metrics from arithmetic transformations applied to multiple primary metrics
* Option to split off the alarms persistence into a separate database
* Option to use notifications instead of RPC for metering messages
* Metering of Neutron networking services: LBaaS, FWaaS & VPNaaS
* New XenAPI compute inspector
* Support for persisting events via the MongoDB & Hbase storage drivers (previously limited to SQLAlchemy)
* Support for per-device metering of instance disks
* Use of ceilometer as a collector for os-profiler data
* New Telemetry section of the [http://docs.openstack.org/admin-guide-cloud/content/ch_admin-openstack-telemetry.html Cloud Administrator Guide]

=== Known Issues === 
* [https://bugs.launchpad.net/ceilometer/+bug/1381600 1381600] The new <code>ceilometer-agent-ipmi</code> fails to emit any samples when it encounters unparseable data from <code>ipmitool</code>.

=== Upgrade Notes === 
* A list of all updated, deprecated or removed options in ceilometer can be found at: http://docs.openstack.org/trunk/config-reference/content/ceilometer-conf-changes-master.html

== OpenStack Orchestration (Heat) == 
=== Key New Features ===


* Recovery from failures during stack updates
* API to cancel and roll back an in-progress stack update
* Implementation of new resource types:
** OS::Glance::Image
** OS::Heat::SwiftSignal
*** Provides the option to store Wait Condition (and Software Deployment) data in Swift
** OS::Heat::StructuredDeployments
*** Groups code for multiple lifecycle events into a single deployment resource
** OS::Heat::SoftwareDeployments
*** Provides a way of avoiding circular dependencies when deploying an interdependent cluster of servers
** OS::Heat::SoftwareComponent
** OS::Nova::ServerGroup
** OS::Sahara::NodeGroupTemplate
** OS::Sahara::ClusterTemplate
* Remember the previously-supplied parameters when updating a stack
* Improved scalability
* Improved visibility into trees of nested stacks

=== Known Issues === 
None yet

=== Upgrade Notes === 
* A list of all updated, deprecated or removed options in heat can be found at: http://docs.openstack.org/juno/config-reference/content/heat-conf-changes-master.html

== OpenStack Database service (Trove) == 
=== Key New Features ===
* Support for Asynchronous Replication (master-slave replicas) between provisioned mysql instances.
* Introduction of a new Clustering API with initial support for MongoDB clusters.
* Support for deploying Trove on an OpenStack solution that is using Neutron for networking. Prior to this, only nova-network was supported.
* Support for provisioning PostgreSQL datastore instances.
* Backup and Restore support for Couchbase.
* Support to optionally restrict the Cinder backend used for Trove volumes.
* Support for defining custom datastore configuration parameters in the Trove database (using mgmt API).
* The ability to list all datastore types and versions in a single call

=== Other Incremental Improvements=== 
* Logging audit to improve log levels throughout the trove components.
* The extensions loading mechanism was improved by adding support for stevedore.
* The ability to support volumes for data is now on a per datastore bases.
* Created and updated timestamps and instance count were added to configuration groups list and details calls.

=== Known Issues === 


* [https://bugs.launchpad.net/trove/+bug/1333852 1333852]: Trove does not support flavor UUIDs -- the Trove flavors API requires flavors with a numerical ID in order to be consistent with the API response for icehouse Trove.

=== Upgrade Notes === 


* trove_api_workers and trove_conductor_workers will now be equal to the number of CPUs available by default if not explicitly specified in the trove configuration files.
** Anyone upgrading to this change that does not have trove_api_workers or trove_conductor_workers specified in the trove configuration files will now be running multiple API and conductor workers by default when they restart the respective trove services.

== OpenStack Data Processing (Sahara) == 

=== New Key Features === 


* Data processing UI was fully merged into OpenStack Dashboard (horizon).
* Support of CDH 5.x was added.
* Support of Apache Spark was added. Supported versions are 0.9.1 and 1.0.0. Elastic data processing (EDP) engine was refactored a lot to support non-Oozie workflow engines.
* Support of Apache Hadoop 2.4.1 was added in addition to existing 1.2.1 and 2.3.0. Version 2.3.0 is deprecated in Juno.
* Support of multi region deployments.
* Hadoop Swift authentication using [http://docs.openstack.org/developer/sahara/userdoc/advanced.configuration.guide.html#domain-usage-for-swift-proxy-users keystone trust mechanism]. Now Hadoop can access data in Swift without storing credentials in config files.
* [http://docs.openstack.org/developer/sahara/userdoc/configuration.guide.html#sahara-notifications-configuration Ceilometer integration] was added. Now Sahara notifies Ceilometer about all cluster state changes.
* Cluster provisioning error handling was improved. If something goes wrong during scaling, cluster will rollback to original state.
* Added ability to [http://docs.openstack.org/developer/sahara/userdoc/features.html#security-group-management specify security groups for a node group]. Also Sahara could automatically create security group with only required ports open.
* Implemented [http://docs.openstack.org/developer/sahara/userdoc/features.html#running-sahara-in-distributed-mode distributed mode] for Sahara: sahara-all process is decoupled into sahara-api and sahara-engine. You can run several instances of sahara-api and sahara-engine on different hosts. Note that the feature implementation is considered to be in alpha-state.

=== Known Issues === 


* [https://bugs.launchpad.net/sahara/+bug/1271349 Bug 1271349]: Sahara requires root privileges to access VMs via namespaces.

=== Upgrade Notes === 

==== Main binary renamed to sahara-all ==== 


Please, note that you should use `sahara-all` instead of `sahara-api` to start
the All-In-One Sahara.

==== sahara.conf upgrade ==== 


We've migrated from custom auth_token middleware config options to the common
config options. To update your config file you should replace the following
old config opts with the new ones.


* "os_auth_protocol", "os_auth_host", "os_auth_port" -> "[keystone_authtoken]/auth_uri" and "[keystone_authtoken]/identity_uri"
* "os_admin_username" -> "[keystone_authtoken]/admin_user"
* "os_admin_password" -> "[keystone_authtoken]/admin_password"
* "os_admin_tenant_name" -> "[keystone_authtoken]/admin_tenant_name"


We've replaced oslo code from sahara.openstack.common.db by usage of oslo.db library.


Also sqlite database is not supported anymore. Please use MySQL or PostgreSQL
db backends for Sahara. Sqlite support was dropped because it doesn't support
(and not going to support, see http://www.sqlite.org/omitted.html) ALTER
COLUMN and DROP COLUMN commands required for DB migrations between versions.


You can find more info about config file options in Sahara repository in file
"etc/sahara/sahara.conf.sample".

==== Sahara Dashboard was merged into OpenStack Dashboard ==== 


The Sahara Dashboard is not available in Juno release. Instead it's
functionality is provided by OpenStack Dashboard out of the box.
The Sahara UI is available in OpenStack Dashboard in
"Project" -> "Data Processing" tab.


Note that you have to properly register Sahara in Keystone in
order for Sahara UI in the Dashboard to work.

==== VM user name changed for HEAT infrastructure engine ==== 


We've updated HEAT infrastructure engine ("infrastructure_engine=heat") to
use the same rules for instance user name as in direct engine. Before the
change user name for VMs created by Sahara using HEAT engine was always
'ec2-user'. Now user name is taken from the image registry as it is described
in the documentation.


Note, this change breaks Sahara backward compatibility for clusters created
using HEAT infrastructure engine before the change. Clusters will continue to
operate, but it is not recommended to perform scale operation over them.

==== Anti affinity implementation changed ==== 


Starting with Juno release anti affinity feature is implemented using server
groups. There should not be much difference in Sahara behavior from user
perspective, but there are internal changes:


* Server group object will be created if anti affinity feature is enabled.
* New implementation doesn't allow several affected instances on the same host even if they don't have common processes. So, if anti affinity enabled for 'datanode' and 'tasktracker' processes, previous implementation allowed to have instance with 'datanode' process and other instance with 'tasktracker' process on one host. New implementation guarantees that instances will be on different hosts.


Note, new implementation will be applied for new clusters only. Old implementation will be applied if user scales cluster created in Icehouse.

== OpenStack Documentation == 


* This release, the OpenStack Foundation funded a five-day book sprint to write the new [http://docs.openstack.org/arch-design/content/arch-guide-how-this-book-is-organized.html OpenStack Architecture Design Guide]. It offers architectures for general purpose, compute-focused, storage-focused, network-focused, multi-site, hybrid, massively scalable, and specialized clouds.
* The Install Guides have had a lot of clean up and standardization: uses common message queue (RabbitMQ), replaces openstack-config (crudini) commands with config file editing for improved learning opportunities and consistency, references a generic SQL database so that MariaDB or MySQL can be substituted, and replaces auth_port and auth_protocol with identity_uri, and auth_host with auth_uri throughout. The Install Guides are thoroughly tested on each distribution and continuously published until the official release packages are available to everyone.
* The [http://docs.openstack.org/high-availability-guide/content/index.html High Availability Guide] now has a separate review team and has moved into a separate repository.
* The [http://docs.openstack.org/security-guide/content/ Security Guide] now has a specialized review team and has moved into a separate repository.
* The long-form API reference documents have been re-purposed to focus on the [http://developer.openstack.org/api-ref.html API Complete Reference].
* The User Guide now contains Database Service for OpenStack information.
* The Command-Line Reference has been updated with new client releases and now contains additional chapters for the common OpenStack client, the trove-manage client, and the Data processing client (sahara).
* The [http://docs.openstack.org/admin-guide-cloud/content/ OpenStack Cloud Administrator Guide] now contains information about Telemetry (ceilometer).
</translate>

ReleaseNotes/Juno

2015-01-07T17:18:44Z

Huang Zhiteng:

<languages />
<translate>


[[Category:Juno|Release Note]]
[[Category:Release Note|Juno]]

= OpenStack 2014.2 (Juno) Release Notes = 


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

== General Upgrade Notes == 


* The simplejson package is an optional requirement in most projects, therefore it's not listed in all project's requirements.txt file. However, if you're using it, e.g. better performance with python 2.6 on RHEL 6, then you will need simplejson >= 2.2.0. See https://bugs.launchpad.net/oslo-incubator/+bug/1361230 for details.

== OpenStack Object Storage (Swift) == 

=== Key New Features === 


The Juno integrated release includes three releases of OpenStack Swift: 2.0.0, 2.1.0, and 2.2.0. The changelog for these releases is available at https://github.com/openstack/swift/blob/2.2.0.rc1/CHANGELOG#L1-L173. Please refer to that document for release details.


Important new features are highlighted below. Please read the CHANGELOG and associated documentation.


* Storage policies
* Keystone v3 support
* Server-side account-to-account copy
* Better partition placement when adding a new server, zone, or region.
* Zero-copy GET responses using splice()
* Parallel object auditor

=== Known Issues === 


* None at this time

=== Upgrade Notes === 


As always, you can upgrade your Swift cluster with no downtime for end-users. Please refer to sample config files and documentation before every release.


* There have been some logging changes that need to be called out. In all cases, well-behaved log processors will not be affected.
** Storage node (account, container, object) logs now have the PID logged at the end of the log line.
** Object daemons now send a user-agent string with their full name (e.g. "obj" is now "object").
* Once an additional storage policy has been enabled, downgrading to Swift pre-2.0.0 will cause any additional storage policies to become unavailable.
* As part of an effort to eventually update the default port to swift to an non-IANA-assigned range, bind_port is now a required setting. Anyone currently explicitly setting the ports will not be affected. However, if you do not currently set the ports, please ensure that your *_server.conf has bind_port set to match your ring as part of your upgrade.
* Note that storage policies include a new daemon, the container-reconciler.
* TempURL default allowed methods config setting now also allows POST and DELETE. This means tempurls can be created for these verbs. It does not affect any existing tempurls.
* A list of all updated, deprecated or removed options in swift can be found at: http://docs.openstack.org/trunk/config-reference/content/swift-conf-changes-master.html

== OpenStack Compute (Nova) == 

===Instance features=== 


* Allow users to specify an image to use for rescue instead of the original base image. [https://blueprints.launchpad.net/nova/+spec/allow-image-to-be-specified-during-rescue launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/allow-image-to-be-specified-during-rescue specification]
* Allow images to specify if a config drive should be used. [https://blueprints.launchpad.net/nova/+spec/config-drive-image-property launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/config-drive-image-property specification]
* Give users and administrators the ability to control the vCPU topology exposed to guests via flavors. [https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/virt-driver-vcpu-topology specification]
* Attach All Local Disks During Rescue. [https://blueprints.launchpad.net/nova/+spec/rescue-attach-all-disks launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/rescue-attach-all-disks specification]

===Networking=== 


* Improve the nova-network code to allow per-network settings. [https://blueprints.launchpad.net/nova/+spec/better-support-for-multiple-networks launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/better-support-for-multiple-networks specification]
* Allow deployers to add hooks which are informed as soon as networking information for an instance is changed. [https://blueprints.launchpad.net/nova/+spec/instance-network-info-hook launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/instance-network-info-hook specification]
* Enable nova instances to be booted up with SR-IOV neutron ports. [https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/pci-passthrough-sriov specification]
* Permit VMs to attach multiple interfaces to one network. [https://blueprints.launchpad.net/nova/+spec/multiple-if-1-net launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/nfv-multiple-if-1-net specification]

===Scheduling=== 


* Extensible Resource Tracking. The set of resources tracked by nova is hard coded, this change makes that extensible, which will allow plug-ins to track new types of resources for scheduling. [https://blueprints.launchpad.net/nova/+spec/extensible-resource-tracking launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/extensible-resource-tracking specification]
* Allow a host to be evacuated, but with the scheduler selecting destination hosts for the instances moved. [https://blueprints.launchpad.net/nova/+spec/find-host-and-evacuate-instance launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/find-host-and-evacuate-instance specification]
* Add support for host aggregates to scheduler filters. launchpad: [https://blueprints.launchpad.net/nova/+spec/per-aggregate-disk-allocation-ratio disk]; [https://blueprints.launchpad.net/nova/+spec/per-aggregate-max-instances-per-host instances]; and [https://blueprints.launchpad.net/nova/+spec/per-aggregate-max-io-ops-per-host IO ops] [http://specs.openstack.org/openstack/nova-specs/specs/juno/per-aggregate-filters specification]

===Other=== 


* Offload periodic task sql query load to a slave sql server if one is configured. [https://blueprints.launchpad.net/nova/+spec/juno-slaveification launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/juno-slaveification specification]
* Only update the status of a host in the sql database when the status changes, instead of every 60 seconds. [https://blueprints.launchpad.net/nova/+spec/on-demand-compute-update launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/on-demand-compute-update specification]
* Include status information in API listings of hypervisor hosts. [https://blueprints.launchpad.net/nova/+spec/return-status-for-hypervisor-node launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/return-status-for-hypervisor-node specification]
* Allow API callers to specify more than one status to filter by when listing services. [https://blueprints.launchpad.net/nova/+spec/servers-list-support-multi-status launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/servers-list-support-multi-status specification]
* Add quota values to constrain the number and size of server groups a users can create. [https://blueprints.launchpad.net/nova/+spec/server-group-quotas launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/server-group-quotas specification]

===Hypervisor driver specific=== 

====Hyper-V==== 


* Support for differencing vhdx images. [https://blueprints.launchpad.net/nova/+spec/add-differencing-vhdx-resize-support launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/add-differencing-vhdx-resize-support specification]
* Support for console serial logs. [https://blueprints.launchpad.net/nova/+spec/hyper-v-console-log launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/hyper-v-console-log specification]
* Support soft reboot. [https://blueprints.launchpad.net/nova/+spec/hyper-v-soft-reboot launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/hyper-v-soft-reboot specification]

====Ironic==== 


* Add a virt driver for Ironic. [https://blueprints.launchpad.net/nova/+spec/add-ironic-driver launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/add-ironic-driver specification]

====libvirt==== 


* Performance improvements to listing instances on modern libvirts. [https://blueprints.launchpad.net/nova/+spec/libvirt-domain-listing-speedup launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/libvirt-domain-listing-speedup specification]
* Allow snapshots of network backed disks. [https://blueprints.launchpad.net/nova/+spec/libvirt-volume-snap-network-disk launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/libvirt-volume-snap-network-disk specification]
* Enable qemu memory balloon statistics for ceilometer reporting. [https://blueprints.launchpad.net/nova/+spec/enabled-qemu-memballoon-stats launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/enabled-qemu-memballoon-stats specification]
* Add support for handing back unused disk blocks to the underlying storage system. [https://blueprints.launchpad.net/nova/+spec/libvirt-disk-discard-option launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/libvirt-disk-discard-option specification]
* Meta-data about an instance is now recorded in the libvirt domain XML. This is intended to help administrators while debugging problems. [https://blueprints.launchpad.net/nova/+spec/libvirt-driver-domain-metadata launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/libvirt-driver-domain-metadata specification]
* Support namespaces for LXC containers. [https://blueprints.launchpad.net/nova/+spec/libvirt-lxc-user-namespaces launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/libvirt-lxc-user-namespaces specification]
* Copy-on-write cloning for RBD-backed disks. [https://blueprints.launchpad.net/nova/+spec/rbd-clone-image-handler launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/rbd-clone-image-handler specification]
* Expose interactive serial consoles. [https://blueprints.launchpad.net/nova/+spec/serial-ports launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/serial-ports specification]
* Allow controlled shutdown of guest operating systems during VM power off. [https://blueprints.launchpad.net/nova/+spec/user-defined-shutdown launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/user-defined-shutdown specification]
* Intelligent NUMA node placement for guests. [https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/virt-driver-numa-placement specification]

====vmware==== 


* Move the vmware driver to using the oslo vmware helper library. [https://blueprints.launchpad.net/nova/+spec/use-oslo-vmware launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/use-oslo-vmware specification]
* Add support for network interface hot plugging to vmware. [https://blueprints.launchpad.net/nova/+spec/vmware-hot-plug launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/vmware-hot-plug specification]
* Refactor the vmware driver's spawn functionality to be more maintainable. This work was internal, but is mentioned here because it significantly improves the supportability of the VMWare driver. [https://blueprints.launchpad.net/nova/+spec/vmware-spawn-refactor launchpad] [http://specs.openstack.org/openstack/nova-specs/specs/juno/vmware-spawn-refactor specification]

=== Known Issues === 


* When using libvirt, live snapshots are effectively disabled, due to this difficult-to-reproduce bug: https://bugs.launchpad.net/nova/+bug/1334398 (https://review.openstack.org/#/c/102643/)
* Glance v2 and Keystone v3 are not tested with Nova in Juno.

=== Upgrade Notes === 


* A list of all updated, deprecated or removed options in Nova can be found at: http://docs.openstack.org/juno/config-reference/content/nova-conf-changes-juno.html
* The nova-manage flavor subcommand is deprecated in Juno and will be removed in the 2015.1 (K) release: https://review.openstack.org/#/c/86122/
* https://review.openstack.org/#/c/102212/
* Minimum required libvirt version is now 0.9.11: https://review.openstack.org/#/c/58494/
* Nova is now supporting the [https://review.openstack.org/#/c/43986/ Cinder V2 API]. The Cinder V1 API is deprecated in Juno and Nova will switch over to Cinder V2 by default in the Kilo release.
** Nova talks to Cinder V1 in the gate (continuous integration testing).
* Debug log output in python-novaclient has [https://review.openstack.org/#/c/98443/ changed slightly] to improve readability. The sha1 hash of the keystone token is now printed instead of the token itself - greatly shortening the amount of content being printed while still retaining the ability to determine token mismatch scenarios. In addition, some extra '\n' characters that were being added are removed. ''Double-check any log parsers!''
* libvirt.volume_drivers config param for nova.conf is deprecated, to be removed in the Lxxxx release. In general, this should affect only a small number of developers working on drivers. If this is you, the recommended approach is to continue your work inside a nova tree.
* python 2.6 support is deprecated in Juno and will be removed in the Kilo 2015.1 release.

== OpenStack Image Service (Glance) == 

=== Key New Features === 


* Asynchronous Processing
* Pull of glance.store into its own library
* [http://docs.openstack.org/developer/glance/metadefs-concepts.html Metadata Definitions Catalog]
* Restricted policy for downloading images.
* Enhanced Scrubber service allows single instance services multiple glance-api servers cross nodes.

=== Known Issues === 

=== Upgrade Notes === 


* A list of all updated, deprecated or removed options in Glance can be found at: http://docs.openstack.org/juno/config-reference/content/glance-conf-changes-juno.html
* The ability to upload a public image is now admin-only by default. To continue to use the previous behaviour, edit the publicize_image flag in etc/policy.json to remove the role restriction.
* The requirement and check on UTF-8 charset for DB tables is enforced, operator need to migration tables and existing data to UTF-8 manually if glance-manage complains it during the sync.
* glance workers will now be equal to the number of CPUs available by default if not explicitly specified in glance-api.conf and/or glance-registry.conf
** There is no upgrade impact to glance-api workers since glance-api.conf previously hard-coded the workers value to 1 so anyone upgrading to tihs will still get whatever value was set in glance-api.conf prior to this change. There is an upgrade impact to the glance-registry workers since glance-registry.conf did not hard-code the workers value to 1 before this change. So anyone upgrading to this change that does not have workers specified in glance-registry.conf will now be running multiple workers by default when they restart the glance registry service.

== OpenStack Dashboard (Horizon) == 

=== Key New Features === 

==== Sahara ==== 


The OpenStack Data Processing project (Sahara) was formally included into the integrated release in Juno and Horizon includes broad support for managing your data processing. You can specify and build clusters to utilize several data types with user specified jobs while tracking the progress of those jobs.

==== Neutron Features ==== 


Neutron added several new features in Juno, including:
* DVR (Distributed Virtual Routing)
* L3 HA support
* IPv6 subnet modes


Horizon provides support for these new features with the Juno release. These features provide much greater flexibility in specifying software defined networks.


An existing feature in Neutron that Horizon now supports is the MAC learning extension.

==== Glance Features ==== 


In Juno, Glance introduced the ability to manage a catalog of metadata definitions where users can register the metadata definitions to be used on various resource types including images, aggregates, and flavors. Support for viewing and editing the assignment of these metadata tags is included in Horizon.

==== Cinder Features ==== 


In a continued effort to provide fuller API support, several features supported by Cinder are now supported in Horizon in the Juno release. Users can now utilize swift to store volume backups from Horizon as well as restore volumes from these backups.


Other features of the Cinder API not previously supported by Horizon added in Juno include:
* Enabling resetting the state of a snapshot
* Enabling resetting the state of a volume
* Supporting upload-to-image
* Volume retype
* QoS (quality of service) support

==== Trove ==== 


Trove supports potentially using numerous different datastores, e.g., mysql, redis, mongodb. Users can now select from the list of datastores supported by the cloud operator when creating their database instances.


Another addition is support for utilizing and restoring from incremental database backups.


To improve support for Neutron based clouds, when creating a database instance, the user can now specify the NIC for the database instance on creation allowing direct access to the instance by the user.

==== Nova ==== 


The new nova instance actions panel provides a list of all actions taken on all instances in the current project allowing users to view resulting errors or actions taken by other users on those instances.


Administrators now have the ability to evacuate instances off hypervisors which can aid in system maintenance by providing a mechanism to migrate all instances to other hosts.

==== Improved Plugin Support ==== 


The plugin system in Horizon continued to improve in the Juno release.
Some of those improvements:


* Support for adding plugin specific AngularJS modules
* Support for adding static files, e.g., CSS, JS, images
* Ability to add exceptions
* Fixing ordering issues
* Numerous other bug fixes

==== Enhanced RBAC support ==== 


In an ongoing effort to support richer role based access control (RBAC) in Horizon, the views for several more services were enhanced with RBAC checks to determine user access to actions. The newly supported services are compute, network and orchestration. These changes allow operators to implement finer grained access control than just "member" and "admin".


The identity panels (domains, projects, users, roles, groups) have also been converted to support RBAC at the view level. The identity panels have been moved from the admin dashboard into their own 'Identity' dashboard and accessibility is determined by policies alone. This is the first step toward consolidating the near duplicate content of the project and admin dashboards into single views supporting a wide range of roles.

==== UX Changes ==== 


In Juno, Horizon transitioned to utilizing Bootstrap v3. Horizon had been pinned to an older version of Bootstrap for several releases. This change now allows Horizon to pick up numerous bug fixes and overall improvements in the Bootstrap framework. The look and feel remains mainly consistent with the Havana release.

==== JavaScript Libraries Extracted ==== 


As part of the Horizon team's ongoing efforts to split the repository into more logical pieces, all the 3rd party JavaScript libraries that Horizon depends on have been removed from the Horizon code base and python xstatic packages have been utilized instead. The xstatic format allows for easy consumption by the Django framework Horizon is built on. Now JavaScript libraries are utilized like any other python dependency in Horizon.

==== Conversion from LESS to SCSS ==== 


The supported stylesheets in Horizon have been converted to utilize SCSS rather than LESS. The change was necessary due to a prevalent lack of support for LESS compilers in python. This change also allowed us to upgrade to Bootstrap 3, as parts of the Bootstrap 3 LESS stylesheets were not supported by existing python based LESS compilers.

=== Known Issues === 

==== Rendering issues in extensions ==== 


The conversion to utilizing Bootstrap v3 can cause content extensions written on top of Horizon to have rendering issues. Most of these are fixed by a simple CSS class name substitutions. These issues are primarily seen with buttons and panel content widths.

==== Online Compression ==== 


With the move to SCSS, there may be issues with utilizing online compression in non-DEBUG mode in Horizon. Offline compression continues to work as in previous releases.

==== Neutron L3 HA ==== 


The HA property is updateable in the UI, however, Neutron API does not allow the update operation because toggling HA support does not work.
https://bugs.launchpad.net/horizon/+bug/1378525

=== Upgrade Notes === 


* FLAVOR_EXTRA_KEYS setting deprecated. The use of this key has been replaced with direct calls to the nova and [http://docs.openstack.org/developer/glance/metadefs-concepts.html glance api] as appropriate.

== OpenStack Identity (Keystone) == 

=== Key New Features === 


* Keystone now has experimental support for [http://docs.openstack.org/developer/keystone/configure_federation.html#keystone-as-an-identity-provider-idp Keystone-to-Keystone federation], where one instance acts as an Identity Provider, and the other a Service Provider.
* PKIZ is a new token provider available for users of PKI tokens, which simply adds zlib-based compression to traditional PKI tokens.
* The hashing algorithm used for PKI tokens has been made configurable (the default is still MD5, but the Keystone team recommends that deployments migrate to SHA256).
* Identity-driver-configuration-per-domain now supports Internet domain names of arbitrary hierarchical complexity (for example, <code>customer.cloud.example.com</code>).
* The LDAP identity backend now supports <code>description</code> as an attribute of users.
* Identity API v3 requests are now validated via JSON Schema.
* In the case of multiple identity backends, Keystone can now map arbitrary resource IDs to arbitrary backends.
* <code>keystoneclient.middleware.auth_token</code> has been moved into it's own repository, <code>keystonemiddleware.auth_token</code>.
* Identity API v3 now supports a discrete call to retrieve a service catalog, <code>GET /v3/auth/catalog</code>.
* Federated authentication events and local role assignment operations now result in CADF (audit) notifications.
* Keystone can now associate a given policy blob with one or more endpoints.
* Keystone now provides JSON Home documents on the root API endpoints in response to <code>Accept: application/json-home</code> headers.
* Hiding endpoints from client's service catalogs is now more easily manageable via <code>OS-EP-FILTER</code>.
* The credentials collection API is now filterable per associated user (<code>GET /v3/credentials?user_id={user_id}</code>).
* New, generic API endpoints are available for retrieving authentication-related data, such as a service catalog, available project scopes, and available domain scopes.
* Keystone now supports mapping the user <code>enabled</code> attribute to the <code>lock</code> attribute in LDAP (and inverting the corresponding boolean value accordingly).
* A CA certificate file is now configurable for LDAPS connections.
* The templated catalog backend now supports generating service catalogs for Identity API v3.
* Service names were added to the v3 service catalog.
* Services can now be filtered by name (<code> GET /v3/services?name={service_name}</code>).

=== Known Issues === 

==== LDAP paged search results don't work with python-ldap 2.4 ==== 


When using an LDAP backend with paged search results enabled, AttributeErrors will be encountered if python-ldap 2.4 is being used. This is due to a backwards incompatible API change in python-ldap. The issue can be worked around in a few ways:
* Disabling paging of search results by setting ''page_size'' to ''0'' in the ''[ldap]'' section of keystone.conf.
* Downgrade python-ldap to version 2.3.x.


A fix for this issue has been proposed, which is expected to be made available in a stable update for Juno. For more details see https://bugs.launchpad.net/keystone/+bug/1381768

=== Upgrade Notes === 


* Due to the simpler out-of-the-box experience, the default token provider is now UUID instead of PKI.
* Database migrations for releases prior to Havana have been dropped, meaning that you must upgrade to the Juno release from either a Havana or Icehouse deployment.
* A comprehensive list of all updated, deprecated or removed options in Keystone can be found at: http://docs.openstack.org/juno/config-reference/content/keystone-conf-changes-juno.html
** All <code>token_api</code> methods are now deprecated.
** LDAP configuration options that previously contained the deprecated <code>tenant</code> terminology have been superseded by options using the term <code>project</code>.
** Proxy methods from the identity backend to the assignment backend (created to provide backwards compatibility as a result of the split of the Assignment backend from the Identity backend), have been removed. This should only affect custom, out-of-tree API extensions.
** Loading authentication plugins solely by class name in <code>keystone.conf</code> is now deprecated in favor of loading them by <code>custom-method-name = custom_package.CustomClass</code> pairs, and then defining the sequence of authentication methods as a list (<code>methods = custom-method-name, password</code>).
** In-tree token drivers (<code>keystone.token.backends</code>) have been moved to <code>keystone.token.persistence.backends</code>. Proxy objects exist to maintain compatibility. If a non-default value is used, it is recommended the value of the <code>driver</code> option in the <code>[token]</code> section of <code>keystone.conf</code> is updated to use the new location.
* All KVS backends besides the <code>token</code> driver have been formally deprecated.
* LDAP/AD configuration: All configuration options containing the term "tenant" have been deprecated in favor of similarly named configuration options using the term "project" (for example, <code>tenant_id_attribute</code> has been replaced by <code>project_id_attribute</code>).

== OpenStack Network Service (Neutron) == 
=== Key New Features ===
* DB migration refactor and new timeline
* Distributed Virtual Router Support (DVR)
* Full IPV6 support for tenant networks
* High Availability for the L3 Agent
* ipset support for security groups in place of iptables (this option is configurable)
* L3 agent performance improvements
* Migration to oslo.messaging library for RPC communication.
* Security group rules for devices RPC call refactoring (a huge performance improvement)
* New Plugins supported in Juno include the following:
** A10 Networks LBaaS driver for the LBaaS V1 API
** Arista L3 routing plugin
** Big Switch L3 routing plugin
** Brocade L3 routing plugin
** Cisco APIC ML2 Driver (including a L3 routing plugin).
** Cisco CSR L3 routing plugin
** Freescale SDN ML2 Mechanism Driver
** Nuage Networks ML2 Mechanism Driver
** SR-IOV capable NIC ML2 Mechanism Driver
** OpenContrail Neutron Plugin

=== Known Issues === 
* This is the first release for DVR and HA L3. The Neutron team desires to designate these features as production ready in Kilo and requests that deployers test on non-critical workloads and report any issues.
* FWaaS is still labeled as experimental, as it does not allow you to have more than one FW per tenant.

=== Upgrade Notes === 
* DB migration from the previous releases (icehouse or havana)
** In Icehouse or Hanava releases, the db migration operation is optional. If your Neutron database is not stamped (i.e., there is the db migration version info), please make sure to "stamp icehouse" before running the upgrade db migration to Juno.
** To check if your database is stamped, run the following command:
neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file <your plugin config file> current
** If the output of the current version is '''None''', please run:
neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file <your plugin config file> stamp icehouse
** and then run the db migration for upgrading Juno:
neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file <your plugin config file> upgrade juno
* A list of all updated, deprecated or removed options in neutron can be found at: http://docs.openstack.org/juno/config-reference/content/neutron-conf-changes-juno.html
* Attribute level policies dependent on resources are not enforced anymore. Meaning that some older policies from Icehouse are not needed. (e.g. "get_port:binding:vnic_type": "rule:admin_or_owner").
* The following plugins are deprecated in Juno:
** Cisco Nexus Sub-Plugin (The Nexus 1000V Sub-Plugin is still retained and supported in Juno).
** Mellanox Plugin
** Ryu Plugin
*XML support in the API is deprecated. Users and deployers should migrate to JSON for API interactions as soon as possible since the XML support will be removed in the Kilo (2015.1) release.

== OpenStack Block Storage (Cinder) == 
=== Key New Features ===
* Support for Volume Replication.
* Support for Consistency Groups and Snapshots of Consistency Groups.
* Support for Volume Pools.
* Completion of i18n-enablement
* Honor Glance protected properties in Image Upload
* Enable ability to restrict bandwidth usage on volume-copy operations
* Add Volume Num Weigher Scheduling

=== New Drivers/Plugins === 
* Datera
* Fujitsu ETERNUS
* Fusion IO
* Hitachi HBSD
* Huawei
* Nimble
* Prophetstor
* Pure
* XtremIO
* Oracle ZFS

=== Limitations/Known Issues === 
* The newly introduced 'Pool' terminology is a logical concept to describe a set of storage resource that can be used to serve core Cinder requests, e.g. volumes/snapshots. This notion is almost identical to Cinder Volume Backend, for it has simliar attributes (capacity, capability). The main difference
is Pool couldn't exist on its own, it must reside in a Volume Backend. One Volume Backend can have mulitple Pools but Pools don't have sub-Pools (meaning even they have, sub-Pools don't get to exposed to Cinder, yet). Pool has a unique name in backend namespace, which means Volume Backend can't have two pools using same name. The introduction of 'Pools' has some user visible impact because it changes the granularity of scheduling a volume from 'Backend' to 'Pools'. For example: migrating/managing volume now has to include pool in 'host' parameter in order to work.
cinder manage --source-name X --name newX host@backend#POOL
cinder migrate UUID host@backend#POOL

* To find out what pools a backend has, use following API extension to query info (need admin role):
- Pool name only:
GET http://CINDER_API_ENDPOINT/v2/TENANT_ID/scheduler-stats/get_pools
- Detailed Pool info:
GET http://CINDER_API_ENDPOINT/v2/TENANT_ID/scheduler-stats/get_pools\?detail\=True

* The 'retyping' or affinity filter hint *may not* work like before. Cinder has a special code path for legacy volumes - volumes created before Juno - to allow (potential) migration between pools even migration_policy is set to 'never'. But not every driver has magic to move volumes to one pool to another at minimum cost. The inconsistency behavior between drivers (same command may take totally different time to finish), which could be confusing.

=== Upgrade Notes === 
* A list of all updated, deprecated or removed options in Cinder can be found at: http://docs.openstack.org/trunk/config-reference/content/cinder-conf-changes-master.html
* Nova is now supporting the [https://review.openstack.org/#/c/43986/ Cinder V2 API]. The Cinder V1 API is deprecated in Juno and Nova will switch over to Cinder V2 by default in the "L" release. You need to update the cinder_catalog_info config option in nova to 'volume2:cinder:internalURL' to have Nova use the cinder v2 endpoint, in addition to the cinder v2 endpoint being available in the keystone catalog.

== OpenStack Telemetry (Ceilometer) == 
=== Key New Features ===
* Support for partitioning metric collection load across horizontally scaled-out central agents
* New method of partitioning alarm evaluation load using [https://github.com/stackforge/tooz tooz] coordination, as opposed to a hand-crafted protocol
* Much improved SQLAlchemy storage performance & scalability, so that MySQL or PostgreSQL can be used as the metering store for PoCs or small deployments
* Support for hardware-oriented monitoring of IPMI sensors via notifications from either Ironic or a new standalone agent
* More flexible & efficient SNMP monitoring:
** batching queries for multiple SNMP metrics into a single call to each daemon
** dynamic discovery of nodes deployed by TripleO for SNMP polling
** the ability to more easily extend the range of SNMP metrics that ceilometer gathers
** the ability to derive new metrics from arithmetic transformations applied to multiple primary metrics
* Option to split off the alarms persistence into a separate database
* Option to use notifications instead of RPC for metering messages
* Metering of Neutron networking services: LBaaS, FWaaS & VPNaaS
* New XenAPI compute inspector
* Support for persisting events via the MongoDB & Hbase storage drivers (previously limited to SQLAlchemy)
* Support for per-device metering of instance disks
* Use of ceilometer as a collector for os-profiler data
* New Telemetry section of the [http://docs.openstack.org/admin-guide-cloud/content/ch_admin-openstack-telemetry.html Cloud Administrator Guide]

=== Known Issues === 
* [https://bugs.launchpad.net/ceilometer/+bug/1381600 1381600] The new <code>ceilometer-agent-ipmi</code> fails to emit any samples when it encounters unparseable data from <code>ipmitool</code>.

=== Upgrade Notes === 
* A list of all updated, deprecated or removed options in ceilometer can be found at: http://docs.openstack.org/trunk/config-reference/content/ceilometer-conf-changes-master.html

== OpenStack Orchestration (Heat) == 
=== Key New Features ===


* Recovery from failures during stack updates
* API to cancel and roll back an in-progress stack update
* Implementation of new resource types:
** OS::Glance::Image
** OS::Heat::SwiftSignal
*** Provides the option to store Wait Condition (and Software Deployment) data in Swift
** OS::Heat::StructuredDeployments
*** Groups code for multiple lifecycle events into a single deployment resource
** OS::Heat::SoftwareDeployments
*** Provides a way of avoiding circular dependencies when deploying an interdependent cluster of servers
** OS::Heat::SoftwareComponent
** OS::Nova::ServerGroup
** OS::Sahara::NodeGroupTemplate
** OS::Sahara::ClusterTemplate
* Remember the previously-supplied parameters when updating a stack
* Improved scalability
* Improved visibility into trees of nested stacks

=== Known Issues === 
None yet

=== Upgrade Notes === 
* A list of all updated, deprecated or removed options in heat can be found at: http://docs.openstack.org/juno/config-reference/content/heat-conf-changes-master.html

== OpenStack Database service (Trove) == 
=== Key New Features ===
* Support for Asynchronous Replication (master-slave replicas) between provisioned mysql instances.
* Introduction of a new Clustering API with initial support for MongoDB clusters.
* Support for deploying Trove on an OpenStack solution that is using Neutron for networking. Prior to this, only nova-network was supported.
* Support for provisioning PostgreSQL datastore instances.
* Backup and Restore support for Couchbase.
* Support to optionally restrict the Cinder backend used for Trove volumes.
* Support for defining custom datastore configuration parameters in the Trove database (using mgmt API).
* The ability to list all datastore types and versions in a single call

=== Other Incremental Improvements=== 
* Logging audit to improve log levels throughout the trove components.
* The extensions loading mechanism was improved by adding support for stevedore.
* The ability to support volumes for data is now on a per datastore bases.
* Created and updated timestamps and instance count were added to configuration groups list and details calls.

=== Known Issues === 


* [https://bugs.launchpad.net/trove/+bug/1333852 1333852]: Trove does not support flavor UUIDs -- the Trove flavors API requires flavors with a numerical ID in order to be consistent with the API response for icehouse Trove.

=== Upgrade Notes === 


* trove_api_workers and trove_conductor_workers will now be equal to the number of CPUs available by default if not explicitly specified in the trove configuration files.
** Anyone upgrading to this change that does not have trove_api_workers or trove_conductor_workers specified in the trove configuration files will now be running multiple API and conductor workers by default when they restart the respective trove services.

== OpenStack Data Processing (Sahara) == 

=== New Key Features === 


* Data processing UI was fully merged into OpenStack Dashboard (horizon).
* Support of CDH 5.x was added.
* Support of Apache Spark was added. Supported versions are 0.9.1 and 1.0.0. Elastic data processing (EDP) engine was refactored a lot to support non-Oozie workflow engines.
* Support of Apache Hadoop 2.4.1 was added in addition to existing 1.2.1 and 2.3.0. Version 2.3.0 is deprecated in Juno.
* Support of multi region deployments.
* Hadoop Swift authentication using [http://docs.openstack.org/developer/sahara/userdoc/advanced.configuration.guide.html#domain-usage-for-swift-proxy-users keystone trust mechanism]. Now Hadoop can access data in Swift without storing credentials in config files.
* [http://docs.openstack.org/developer/sahara/userdoc/configuration.guide.html#sahara-notifications-configuration Ceilometer integration] was added. Now Sahara notifies Ceilometer about all cluster state changes.
* Cluster provisioning error handling was improved. If something goes wrong during scaling, cluster will rollback to original state.
* Added ability to [http://docs.openstack.org/developer/sahara/userdoc/features.html#security-group-management specify security groups for a node group]. Also Sahara could automatically create security group with only required ports open.
* Implemented [http://docs.openstack.org/developer/sahara/userdoc/features.html#running-sahara-in-distributed-mode distributed mode] for Sahara: sahara-all process is decoupled into sahara-api and sahara-engine. You can run several instances of sahara-api and sahara-engine on different hosts. Note that the feature implementation is considered to be in alpha-state.

=== Known Issues === 


* [https://bugs.launchpad.net/sahara/+bug/1271349 Bug 1271349]: Sahara requires root privileges to access VMs via namespaces.

=== Upgrade Notes === 

==== Main binary renamed to sahara-all ==== 


Please, note that you should use `sahara-all` instead of `sahara-api` to start
the All-In-One Sahara.

==== sahara.conf upgrade ==== 


We've migrated from custom auth_token middleware config options to the common
config options. To update your config file you should replace the following
old config opts with the new ones.


* "os_auth_protocol", "os_auth_host", "os_auth_port" -> "[keystone_authtoken]/auth_uri" and "[keystone_authtoken]/identity_uri"
* "os_admin_username" -> "[keystone_authtoken]/admin_user"
* "os_admin_password" -> "[keystone_authtoken]/admin_password"
* "os_admin_tenant_name" -> "[keystone_authtoken]/admin_tenant_name"


We've replaced oslo code from sahara.openstack.common.db by usage of oslo.db library.


Also sqlite database is not supported anymore. Please use MySQL or PostgreSQL
db backends for Sahara. Sqlite support was dropped because it doesn't support
(and not going to support, see http://www.sqlite.org/omitted.html) ALTER
COLUMN and DROP COLUMN commands required for DB migrations between versions.


You can find more info about config file options in Sahara repository in file
"etc/sahara/sahara.conf.sample".

==== Sahara Dashboard was merged into OpenStack Dashboard ==== 


The Sahara Dashboard is not available in Juno release. Instead it's
functionality is provided by OpenStack Dashboard out of the box.
The Sahara UI is available in OpenStack Dashboard in
"Project" -> "Data Processing" tab.


Note that you have to properly register Sahara in Keystone in
order for Sahara UI in the Dashboard to work.

==== VM user name changed for HEAT infrastructure engine ==== 


We've updated HEAT infrastructure engine ("infrastructure_engine=heat") to
use the same rules for instance user name as in direct engine. Before the
change user name for VMs created by Sahara using HEAT engine was always
'ec2-user'. Now user name is taken from the image registry as it is described
in the documentation.


Note, this change breaks Sahara backward compatibility for clusters created
using HEAT infrastructure engine before the change. Clusters will continue to
operate, but it is not recommended to perform scale operation over them.

==== Anti affinity implementation changed ==== 


Starting with Juno release anti affinity feature is implemented using server
groups. There should not be much difference in Sahara behavior from user
perspective, but there are internal changes:


* Server group object will be created if anti affinity feature is enabled.
* New implementation doesn't allow several affected instances on the same host even if they don't have common processes. So, if anti affinity enabled for 'datanode' and 'tasktracker' processes, previous implementation allowed to have instance with 'datanode' process and other instance with 'tasktracker' process on one host. New implementation guarantees that instances will be on different hosts.


Note, new implementation will be applied for new clusters only. Old implementation will be applied if user scales cluster created in Icehouse.

== OpenStack Documentation == 


* This release, the OpenStack Foundation funded a five-day book sprint to write the new [http://docs.openstack.org/arch-design/content/arch-guide-how-this-book-is-organized.html OpenStack Architecture Design Guide]. It offers architectures for general purpose, compute-focused, storage-focused, network-focused, multi-site, hybrid, massively scalable, and specialized clouds.
* The Install Guides have had a lot of clean up and standardization: uses common message queue (RabbitMQ), replaces openstack-config (crudini) commands with config file editing for improved learning opportunities and consistency, references a generic SQL database so that MariaDB or MySQL can be substituted, and replaces auth_port and auth_protocol with identity_uri, and auth_host with auth_uri throughout. The Install Guides are thoroughly tested on each distribution and continuously published until the official release packages are available to everyone.
* The [http://docs.openstack.org/high-availability-guide/content/index.html High Availability Guide] now has a separate review team and has moved into a separate repository.
* The [http://docs.openstack.org/security-guide/content/ Security Guide] now has a specialized review team and has moved into a separate repository.
* The long-form API reference documents have been re-purposed to focus on the [http://developer.openstack.org/api-ref.html API Complete Reference].
* The User Guide now contains Database Service for OpenStack information.
* The Command-Line Reference has been updated with new client releases and now contains additional chapters for the common OpenStack client, the trove-manage client, and the Data processing client (sahara).
* The [http://docs.openstack.org/admin-guide-cloud/content/ OpenStack Cloud Administrator Guide] now contains information about Telemetry (ceilometer).
</translate>

CinderMeetings

2014-12-17T16:13:41Z

Huang Zhiteng:

= Weekly Cinder team meeting =
'''NOTE MEETING TIME: Wed's at 16:00 UTC'''

If you're interested in Cinder or Block Storage in general for OpenStack, we have a weekly meetings in <code><nowiki>#openstack-meeting</nowiki></code>, on Wednesdays at 16:00 UTC. Please feel free to add items to the agenda below. NOTE: When adding topics please include your IRC name so we know who's topic it is and how to get more info.

== Next meeting ==
'''NOTE:''' ''Include your IRC nickname with your agenda items so that you can be called upon in the meeting and arrive at the meeting promptly if placing items in agenda. Please have any supporting links ready. You might want to put this on your calendar if you are adding items.''

'''Dec 17th, 2014 16:00 UTC'''
* Volume deletion while snapshots exist
** '''Led by:''' smatzek
** Kilo blueprint: https://review.openstack.org/#/c/133822/
** EMC VMAX FC and IBM SVC FC volume drivers implement Cinder snapshots as whole standalone volumes
* Return request ID to caller
** '''Led by:''' abhijeetm
** Reference: http://lists.openstack.org/pipermail/openstack-dev/2014-December/052822.html
* Reopen discussion of "RemoteFS configuration improvements"
** '''Led by:''' erlon
** SPEC: https://review.openstack.org/#/c/133173/
** Summary of the problems: https://etherpad.openstack.org/p/remotefs-improvments
* Cinder unit test coverage improvement
** '''Led by:''' winston-d

== Previous meetings ==
'''Dec 10th, 2014 16:00 UTC'''
* Abstract interface for volume drivers
** '''Led by:''' thingee or mkoderer
** cinder.volume.driver changes: https://review.openstack.org/#/c/127455/
** Example of applying the interface to the RBD driver: https://review.openstack.org/#/c/138661/2/cinder/volume/drivers/rbd.py
** Want to know how to configure consistency group. ie create , delete and what changes needed in the conf files. https://bugs.launchpad.net/bugs/1400392
** How to configure the lioadm or tgtadm for cinder juno. (For our own driver) https://bugs.launchpad.net/bugs/1399921
* CI for zone drivers?
** '''Led by:''' jnrao
* NFS/posix backup drivers again
** '''Led by:''' tbarron and kfox1111
** "posix" implementation: https://review.openstack.org/#/c/82996/
** "chunking" base class implementation: https://review.openstack.org/#/c/139737/
** blueprint spec: https://review.openstack.org/#/c/130858/
** original "nfs" implementation: https://review.openstack.org/#/c/138234
* Discuss implementation direction of PureISCSIDriver CHAP support changes
** '''Led by:''' patrickeast
** https://review.openstack.org/#/c/137175/
** Summary of the problems & FAQ: https://etherpad.openstack.org/p/pureiscsi-chap-faq
* Discuss database cleanup status and priorities
** '''Led by:''' e0ne
** https://etherpad.openstack.org/p/cinder-kilo-db-cleanup
* Discuss HA issues mentioned by Ops during the summit
** '''Led by:''' dulek
** https://etherpad.openstack.org/p/kilo-crossproject-ha-integration (Cinder section specifically)
* Third Party CI updates
** '''Led by:''' asselin
** Would like to invite Cinder third party ci "operators" to third party ci meeting: https://wiki.openstack.org/wiki/Meetings/ThirdParty
** Meeting time change is proposed on mailing list. Vote here: http://lists.openstack.org/pipermail/openstack-dev/2014-December/052546.html
** Asselin is proposing an in-tree 3rd party ci solution. Idea well received in 3rd party ci & infra meetings. Please review spec and/or let me know your interest.
*** Gerrit topic "thirdpartyci" query: https://review.openstack.org/#/q/topic:thirdpartyci,n,z

'''Dec 3rd, 2014 16:00 UTC'''
* Should #openstack-cinder IRC be archived?
** '''Led by:''' scottda
** It is not present in http://eavesdrop.openstack.org/irclogs/
** Infra room indicated a resolution at this meeting would make things happen
* Continue the discussion on over subscription
** '''Led by:''' xyang
** https://review.openstack.org/#/c/129342/
* Discussion on the current status of this spec "Support Modifying Volume Image Metadata"
** '''Led by:''' davechen
** https://review.openstack.org/#/c/136253/
* Posix backup driver replaces NFS backup driver
** NFS backup driver: https://review.openstack.org/#/c/138234/1
*** Kevin Fox views the Posix backup driver as a replacement to NFS https://review.openstack.org/#/c/130858/
** Posix backup driver: https://review.openstack.org/#/c/82996/
* RemoteFS snapshots
** '''Led by:''' kaisers
** https://blueprints.launchpad.net/cinder/+spec/remotefs-snaps
** Some parts of refactoring functionality from RemoteFS based drivers to the parent class have been done, we would like to complete the refactoring in the next weeks
*** Currently the addition of new drivers produces code duplication (e.g. https://blueprints.launchpad.net/cinder/+spec/quobyte-usp-driver)
*** Work will be based on aspects discussed in a previous meeting (http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-05-21-16.00.log.txt , 1655h+)

'''Nov 26th, 2014 16:00 UTC'''
* Volume status polling
** '''Led by:''' TobiasE1
** Cinder spec: https://review.openstack.org/#/c/132225/
** Nova spec: https://review.openstack.org/#/c/135367/
** This is related to the reset-state blueprint
* Over-Subscription Alternative
** '''Led by:''' bswartz
** Cinder spec: https://review.openstack.org/#/c/129342/ (xyang: Discussed at the design summit in Paris)

'''Nov 19th, 2014 16:00 UTC'''
* 3rd party CI
** '''Led by:''' DuncanT
** Current blockers? https://wiki.openstack.org/wiki/Cinder/third-party-ci-status
** Pencil in a new cutoff date?
** Dashboard - initial discussion at https://etherpad.openstack.org/p/Third-Party-CI-Dashboard-InitialPlanning
* Kilo mid-cycle meet-up:
** '''Led by:''' JungleboyJ
** IBM has started planning the event and needs to know how many people are planning on attending. (Need to figure out how big a room to have.)
** Please sign up here if planning to attend: https://etherpad.openstack.org/p/cinder-kilo-midcycle-meetup
* What to do about cinder.conf.sample
** '''Led by:''' JungleboyJ
** If we can't get rid of it, how do we keep it from breaking the gate?
* Volume metadata having semantic meaning to Cinder
** '''Led by:''' DuncanT
** https://review.openstack.org/#/c/102511/
* Discuss how to cleanup stuck volumes (creating/deleting/attaching/detaching)
** '''Led by:''' scottda
** https://blueprints.launchpad.net/cinder/+spec/reset-state-with-driver
** Is there interest in *any* solution?
** Alternatives to proposed blueprint
* Are changes to the Cinder V1 API still worth the trouble?
** '''Led by:''' pwehrle
** changes are submitted changing both v1 and v2 of the Cinder API (https://review.openstack.org/#/c/133383/, https://review.openstack.org/#/c/132657/)
** the Cinder V1 API is deprecated in Juno (https://wiki.openstack.org/wiki/ReleaseNotes/Juno)
** are (backward compatible) changes just discouraged or outright forbidden?
* Backport NFS security bugfix to stable/juno and stable/icehouse
** '''Led by:''' bswartz
** https://review.openstack.org/#/c/107693/

'''Nov 12th, 2014 16:00 UTC'''
* Cancelled since the summit just happened last week. We'll meet again November 19th.

'''Nov 5th, 2014'''
* No meeting - Openstack Summit in Paris

'''Oct 29th, 2014 16:00 UTC'''
* Discuss the brick spec/effort for Kilo
** '''Led by:''' hemna
** https://review.openstack.org/#/c/129069/
** eharney has some input here as well (see review)
* Discuss the volume type extra specs cinder-spec
** '''Led by:''' hemna
** https://review.openstack.org/#/c/127646/
* Discuss the differential backup patch (Murali)
** https://review.openstack.org/#/c/110068/
* Discuss updating https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
** '''Led by:''' patrickeast
* Project suggestions for OpenStack OPW
** '''Led by:''' thingee
** https://wiki.openstack.org/wiki/OutreachProgramForWomen/Ideas
* Liaison for Cinder third party CI
** '''Led by:''' thingee
** Problem: The OpenStack Infra team has to deal with questions from all projects on how to setup a third party CI.
** Idea #1: Is anyone willing to help the Infra team?
*** Ideally this person already has their third party ci.
*** Will be pinged on IRC from infra when someone has a question with third party CI help in Cinder.
*** Should watch infra mailing list for Cinder related CI questions.
**** If there are requests to reenable a CI, this person should be able to verify that things have been more stable and give the OK so infra can turn things on.
'''Oct 22nd, 2014 16:00 UTC'''
* Discuss kilo summit design session [https://etherpad.openstack.org/p/kilo-cinder-summit-topics proposals] for the cinder track
* '''Led by:''' thingee

'''Oct 14th, 2014 16:00 UTC'''
* Still Need Cross Project Oslo Liason
** '''Signup:''' https://wiki.openstack.org/wiki/CrossProjectLiaisons
* Thirdparty CI voting permissions
** '''Led by:''' patrickeast
** '''Discussion:''' https://etherpad.openstack.org/p/cinder-meeting-20141008
* State Machine
** '''Led by:''' thingee
** '''Previous Discussion:''' https://etherpad.openstack.org/p/juno-cinder-state-and-workflow-management
** '''Spec:''' https://github.com/openstack/cinder-specs/blob/master/specs/juno/create-states.rst
** '''Outstanding Patches:'''
*** https://review.openstack.org/#/c/110434/17
*** https://review.openstack.org/#/c/124205/
* Update on Rolling Upgrades
** '''Led by:''' Duncan
* Close off on design for NFS Security
** '''Led by:''' glenng
** '''Review:''' https://review.openstack.org/#/c/107693/
* Cinder Kilo Stabilization
** '''Led by:''' hemna and thingee
** '''Discussion:''' https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work
** Still need volunteers for (in order of priority):
*** Fix Database Abuse
*** Fix TODOs: https://etherpad.openstack.org/p/cinder-kilo-todos-cleanup
* Review Cinder specs for Kilo Release
** '''Led by:''' thingee

'''Oct 8th, 2014 16:00 UTC'''
* Thirdparty CI voting permissions (patrickeast)
** I wanted to discuss criteria for getting permission and the process for Cinder driver CI's to get there
* Introduce a nice way of accessing up-to-date information on Cinder drivers
** I wanted to discuss a new workflow of updating drivers information for maintainers (irina_pov).
* Oslo Project Liaison for Kilo Release [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg37015.html Mailing List Post] | [https://wiki.openstack.org/wiki/CrossProjectLiaisons Signup] thingee
* [https://review.openstack.org/#/q/project:+openstack/cinder-specs+status:+open+label:Verified%253E%253D1%252Cjenkins+NOT+label:Code-Review%252Cself,n,z Review Cinder specs for Kilo Release] thingee
* https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work
* Discussion and review of NFS Security: https://review.openstack.org/#/c/107693/

'''Oct 1st, 2014 16:00 UTC'''
* Kilo Stabilization effort https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work
* Discussion and review of NFS Security: https://review.openstack.org/#/c/107693/

'''Sep 24th, 2014 16:00 UTC'''
* Remove XenAPI driver (https://review.openstack.org/#/c/123162/) (DuncanT)
** Should we go through deprecation?
** There's an HP MSA driver that is unmaintained, unCIed and as far as we know unused, so we need a policy
*** Might have found a maintainer (DuncanT)

* Please remember we're coming up to RC so lots of testing and bug fixing please, not just getting stuff ready for Kilo opening!

'''Sep 17th, 2014 16:00 UTC'''

* FFEs - status (DuncanT or JGriffith)
** Are they all merged yet?
***Looks like yes according to the list on https://etherpad.openstack.org/p/juno-cinder-approved-ffes
** Are we going to go -2 things that need to wait now?
** Avoiding submarine features (AKA that's a feature not a bug)
* Hot issues - what is really affecting people? (DuncanT or JGriffith)
* 3rd Party CI Status wiki (jungleboyj)
** https://wiki.openstack.org/wiki/Cinder/third-party-ci-status
** Is this up to date?

'''Sep 10th, 2014 16:00 UTC'''
* Manage/Unmanage of non-integer GB size volumes (bswartz)
* Remove hard dep on osprofiler for services (eharney)
** Prefer for RC1 because waiting until Kilo misses some of the benefit
** https://review.openstack.org/#/c/120455/
* Kilo Stabilization work https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work (hemna)
* Splitting the client into cinder-client and cinder-admin-client (DuncanT)

'''Sep 3rd, 2014 16:00 UTC'''
* Moving Brick out of Cinder (e0ne)
** http://lists.openstack.org/pipermail/openstack-dev/2014-September/044608.html
** https://wiki.openstack.org/wiki/CinderBrick
* Cinder CI Tests Fibre Channel Passthrough & Nodepool works! (asselin)
** Big thanks to Rahul Verma (HP, UC Berkeley) for working out the FC passthrough scripts & Walter Boring (irc:hemna) for FC expertise & debugging assistance.
** Still needs cleanup/documentation: https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins_job_builder/config/macros-fc.yaml.erb
* What are the cutoffs dates for Kilo? (jungleboyj)
** No new drivers after Kilo1?
** No new driver feature implementation?
* https://bugs.launchpad.net/cinder/+bug/1289931 - DuncanT

'''Aug 27th, 2014 16:00 UTC'''
(Some problems with the bot, so minutes are incomplete)
* https://review.openstack.org/111659 - DuncanT
** Should cinder be doing this, or should cinder remain an API that does exactly what it says on the tin and let neutron/nova be 'smarter' if it wants?
** Should we be changing API behaviour? Should we be changing it just before milestone 3?

'''Aug 20th, 2014 16:00 UTC'''

* FPF Tomorrow Aug 21'st (jgriffith)
* Time to start thinking about the Summit and how to be more effective with our time there (jgriffith)
* The idea of a maintenance/ish release (jgriffith)
* Volume replication (ronenkat)
** The patch - https://review.openstack.org/#/c/113054/11
** Depends on https://review.openstack.org/#/c/115078/ to fix pylint error
** Reference replication implementation for IBM Storwize as an example - https://review.openstack.org/#/c/112224/4/
* MAINTAINERS file (DuncanT)
** https://etherpad.openstack.org/p/cinder-driver-maintainers
* Simple CI
** https://github.com/Funcan/kiss-ci (Code will be up any moment now)

'''Aug 13th, 2014 16:00 UTC'''

NO MEETING TODAY, MID CYCLE MEETUP

'''Aug 6th, 2014 16:00 UTC'''
* Cinder mid cycle meetup next week August 12-14 (scottda)
** https://etherpad.openstack.org/p/CinderMidCycleMeetupAug2014
** HP site should be set. Ping scottda with any issues/problems/concerns
** Virtual meetup will need to be taken care of
* Volume replication (ronenkat)
** Alternative approach based on jgriffith driver based replication: https://etherpad.openstack.org/p/juno-cinder-volume-replication-apparochs

'''July 30'th, 2014 16:00 UTC'''
* Planning cinderclient tag for Thursday morning July 31'st, let's catch up on client changes and testing prior to that (jgriffith)
* Breaking the inheritance between data and control path in Volume drivers https://review.openstack.org/#/c/105923/ (jgriffith)
* Consistency groups https://review.openstack.org/#/c/104732/ (xyang)
* Hitachi Block Storage cinder driver https://review.openstack.org/#/c/90379/ (saguchi)
* Volume replication https://review.openstack.org/#/c/106718/ (ronenkat)
** 17:00 UTC - Volume replication driver owner overview and Q & A
** Callin information: passcode: 6406941 call-in numbers: https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=6406941&accessNumber=1809417783#C2
* NFS secure option -- default to 666 vs 660 vs force admin choice (bswartz)
* It is code cleanup tag merge week (DuncanT)
** https://review.openstack.org/#/q/project:openstack/cinder+comment:code_cleanup_batching+-status:merged,n,z

'''July 23th, 2014 16:00 UTC'''

* J2 Milestone (DuncanT)
** JGriffith favours a freeze exception for all drivers taht currently have code / BP up, but bouncing all new ones
** Review priorities
*** Driver specs
*** CG groups - a big change that requires driver changes, so needs lots of eyes and time for driver maintainers to do their thing too: https://review.openstack.org/#/c/104743/
*** Pool scheduling - https://review.openstack.org/#/c/98715/
*** Others?
* Plug for weekly 3rd Party CI meeting (Mondays at 18:00 UTC [1 pm Central]) (jungelboyj)
** I attended this week's meeting and gave a high level status. They are looking for more participation.
* ProphetStor Cinder drivers (stevetan)
** Get feedback on progress of our DPL driver and documentation required https://review.openstack.org/#/c/95829/
** Get direction from community for our Federator SDS driver https://review.openstack.org/#/c/99616/
* Volume replication - work in progress (ronenkat)
** https://review.openstack.org/#/c/106718/2
* NFS Security, if there's time.
** https://blueprints.launchpad.net/cinder/+spec/secure-nfs

'''July 16th, 2014 16:00 UTC'''
* Putting the fun back into cinder development.
** There's been a mailing list thread recently about how nit-picky reviews are getting about typos, white space and the like, and how it is a motivation killer. I'm inclinded to agree - the formatting of the doc strings, fullstops at the end of comments etc doesn't actually improve the code much at all, and getting a -1 for it is a buzz kill of the highest order. Should we leave that sort of thing to the gate, and say that if there is no hacking check for it then it isn't important in general? (DuncanT)

* How to proceed with cinder/openstack requirements? python-dbus for https://review.openstack.org/99013, see mailing list conclusion http://lists.openstack.org/pipermail/openstack-dev/2014-July/040182.html (flip214)
* code churn, not sure where/when to start, fear of merge conflicts (flip214)

* Hitachi Block Storage cinder driver (tsekiyama)
** We want to get some feedback about how we can make this forward
** Review: https://review.openstack.org/#/c/90379/

* Log translations https://review.openstack.org/#/c/105665/ is still stuck - any thoughts? Options I can see: (DuncanT)
** A better technical solution - should be possible where the message format is not expanded outside the logging call i.e.:
Ok:
<nowiki>
LOG.warning("The flubigar id %d exploded messily", flu_id)
</nowiki>
Not ok:
<nowiki>
msg = _("The flubigar id %d exploded messily") % flu_id
LOG.warning(msg)
</nowiki>

** We don't break up our message categories
*** This makes life harder for the translation team, makes us inconsistent with Openstack in general but keeps the code from descending into ugliness
** Related discussion on enabling translation (jungleboyj):
*** Have two patches awaiting approval: Explicit import of _() https://review.openstack.org/105315 and enable lazy translation: https://review.openstack.org/105561
*** Need to get these merged so we are running with the changes.
* 3rd Party CI (jungleboyj):
** Clarification on when drivers are going to be removed.

== Previous meetings ==

'''July 9, 2014 16:00 UTC'''

* flip214 to jgriffith: Status of Separation of Connectors from Driver/Device Interface?
* Quick check: Is everybody happy in principle with the text of https://wiki.openstack.org/wiki/CinderCodeCleanupPatches ? (DuncanT)

'''July 2nd, 2014 16:00 UTC'''
* Batching up mechanical code cleanup until the one week after each milestone (DuncanT)
** See https://review.openstack.org/#/c/102872/ for example and https://review.openstack.org/#/c/101847
** Log translations and hacking fixes fall into this class
** Means you only take one bit hit per milestone for rebases
** Does require some tracking so they don't get missed (and I will suck at said tracking, enviably)
* LVM: Support a volume-group on shared storage (mtanino)
** Want to quickly discuss the driver benefit, driver comparison, performance(P8-P14): https://wiki.openstack.org/w/images/0/08/Cinder-Support_LVM_on_a_sharedLU.pdf
** Review comments? https://review.openstack.org/#/c/92479/
* Cinder Third Party CI Names (asselin)
** Online discussion of this thread: http://lists.openstack.org/pipermail/openstack-dev/2014-July/039103.html

'''June 25th, 2014 16:00 UTC'''
* Consistency groups [xyang]
** Cinder spec review: https://review.openstack.org/#/c/96665/
* CI status [xyang]
** [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg26258.html Third-Party CI Issue (asselin): direct access to review.openstack.org port 29418 required]l
* Pools implementation [navneet]
** Comparison etherpad https://etherpad.openstack.org/p/cinder-pool-impl-comparison
** Decision to select implementation
* keystoneclient integration with cinderclient [hrybacki / ayoung]
** Discuss integration and collaboration possibilities

'''June 18th, 2014 16:00 UTC'''
* It's review day !?! [jdg]
* Mid cycle meetup plans/updates [jdg]
** https://etherpad.openstack.org/p/CinderMidCycleMeetupAug2014
* Separation of Connectors from Driver/Device Interface (status update) [jdg]
* Updates on 3'rd party CI [jdg]
* Things we need to decide upon (not today, but do your homework for next week)
** Software Define Storage layers/drivers
** Pools implementation

'''June 11th, 2014 16:00 UTC'''
* Volume replication (ronenkat)
** Blueprint and spec review/comments? https://review.openstack.org/#/c/98308
* oslo.db (jungleboyj)
** Want to quickly discuss the review out there for this: https://review.openstack.org/#/c/77125/
** Move to current oslo.db? Wait for library work?
* oslo logging discussion (jungleboyj)
** Removing translation of debug messages
** Adding _LE, _LI, _LW
* 3rd party cinder ci (asselin)
** Looking for volunteers to test out my fork of jaypipe's 3rd party ci setup which has support for nodepool & http proxies.
** https://github.com/rasselin/os-ext-testing
** https://github.com/rasselin/os-ext-testing-data
** [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg26258.html Third-Party CI Issue: direct access to review.openstack.org port 29418 required]l
* HDS HNAS Cinder drivers (sombrafam)
** As we are trying check-in for quite a while, we want to get some feedback on the missing steps
** First thread: https://review.openstack.org/#/c/74371/
** Continuation: https://review.openstack.org/#/c/82505/
** Current thread in discussion: https://review.openstack.org/#/c/84244/
* Mid-cyce Sprint (scottda)
** HP in Fort Collins, CO can host on site
** The thought was 10-20 developers
** Large room is available July 14,15,17,18, 21-25, 27-Aug 1 ... Other options exist
* Backend Pools (navneet)
** which way to go? There are two WIPs.
** comparisons between the two approaches? Any wiki/etherpad present or to be prepared for documenting opinions?

'''June 4th, 2014 16:00 UTC'''
* Volume backup modification (navneet)
** Blueprint and spec review/comments? https://blueprints.launchpad.net/cinder/+spec/vol-backup-service-per-backend
* Dynamic multi pool (navneet)
** Review comments? https://review.openstack.org/#/c/85760/
** Implementation approach comparison.
* 3rd party ci (asselin)
** I have a conflict with another meeting, but my WIP to add nodepool into jaypipe's 3rd party ci solution is available here: https://github.com/rasselin/os-ext-testing/tree/nodepool
* oslo.db (jungleboyj)
** Want to quickly discuss the review out there for this: https://review.openstack.org/#/c/77125/
** Move to current oslo.db? Wait for library work?
** Need to drop off the meeting about 40 minutes in so if we can cover before then it would be appreciated. :-)

'''May 28th, 2014 16:00 UTC'''
* 3rd Party CI (jungleboyj)
** What tempest test cases to run?
** iSCSI only? What about for FC only drivers then?
** Progress on where to record results?
* SSH host keys (jungleboyj)
** https://launchpad.net/bugs/1320050 and https://bugs.launchpad.net/cinder/+bug/1320056
** Need plan to get this addressed by all drivers using SSH. (New config options?)
** Way to get this backported to Havana?
* Dynamic multi-pools (navneet)
** Status and WIP review (https://review.openstack.org/#/c/85760/)
** Back manager design improvement/rewriting for better rpc message handling.
** Back up service for multi pools.
* cinder-specs (jgriffith)
** Specs repo is live
** Process
** Reviews

'''May 21st, 2014 16:00 UTC'''
* Consistency Groups (xyang)
** A few people have concerns on the restriction of one volume type per CG. Should we allow one CG to have multiple volume types on the same backend? Let's discuss about it.
* Third-Party CI (jgriffith)
** Who's started, who's planning to and how can we help support each other to get this going smoothly
* Moving GlusterFS snapshot code into the NFS RemoteFs driver (mberlin)
** The GlusterFS snapshot code using qcow2 snapshots is useful for all file based storage systems. I would volunteer to move the GlusterFS snapshot code into the general RemoteFs driver - making it easier to get [https://review.openstack.org/#/c/94186/ our driver] accepted ;-)
** Eric Harney is fine with this and planned to do this for Juno anyway ([https://blueprints.launchpad.net/cinder/+spec/remotefs-snaps see his blueprint]). I've put it on the agenda to make sure others also agree with this approach.

'''May 7th, 2014 16:00 UTC'''
* Limit == 0 in API [https://review.openstack.org/#/c/86207/ patch review] - thingee

'''April 16th, 2014 16:00 UTC'''
* Release Status
* Summit Session Updates
* Next Stop ATL!!!
* Cinder resource status - thingee

'''April 9th, 2014 16:00 UTC'''
(Agenda entered retrospectively)
* Cinder Spec (jgriffith)
** Just a heads up that cinder blueprints will move to a gerrit based process shortly, a la nova. Details and wiki entry to follow.
* RC2 status (jgriffith)
** Just after cutting RC2, a bunch of bugs
* Testing RC code (jgriffith)
** Get on it, folks!
**Looks like theres some serious, intermittent performance issues in the API somewhere...

'''April 2, 2014 16:00 UTC'''
_Meeting cancelled and summary discussion held on #openstack-cinder_

* Release status and bugs
* -2s left on reviews from before Junos opened - please check if they are still valid
- https://review.openstack.org/#/c/73446/ (JGriffith)
- https://review.openstack.org/#/c/80550/ (JBryant)
- https://review.openstack.org/#/c/82100/ (Avishay)
- https://review.openstack.org/#/c/74158/ (Avishay)
- + a whole bunch of stable branch stuff

== Previous meetings ==

'''Mar 26, 2014 16:00 UTC'''
* RC1 updates (jgriffith)
* Design Summit Sessions (jgriffith)
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-03-26-16.00.log.html

'''Mar 19, 2014 16:00 UTC'''
* ProphetStor Driver Exception request for Icehouse (jgriffith)
* Bug status/updates (jgriffith)
* What we should be punting to Juno (aka immediate -2 in Gerrit) (jgriffith)
* Continuous Integration for Cinder Certification (jungleboyj)

'''Mar 12, 2014 16:00 UTC'''
* Cancelled due to nothing on the agenda. Ad-hoc discussion on #openstack-cinder instead

'''Mar 5, 2014 16:00 UTC'''
* Volume replication - avishay
* [https://blueprints.launchpad.net/cinder/+spec/lvm-driver-for-shared-storage New LVM-based driver for shared storage] - mtanino
* DRBD/drbdmanage driver for cinder - philr

'''Feb 19, 2014 16:00 UTC'''
* I3 Status check/updates
* Cert test
* [https://review.openstack.org/#/c/73745 Milestone Consideration for Drivers] -thingee
* [https://etherpad.openstack.org/p/cinder-hack-201402 Hack-a-thon details] -thingee
* [https://review.openstack.org/#/c/66737/ scheduling for local storage] -DuncanT

'''Feb 5, 2014 16:00 UTC'''
* I3 Status check/updates
* Cert test
* Multiple pools per backend (bswartz)
'''Jan 8, 2014 16:00 UTC'''
* I2 is just around the corner, blueprint updates
* Alternating meeting time proposal, results on feedback
* Driver cert test, it's there... use it
* Prioritizing patches and reviews
'''December 18, 2013 16:00 UTC'''
* Blueprint discussion [https://blueprints.launchpad.net/cinder/+spec/cinder-backup-recover-api cinder backup recovery api - import/export backups] - avishay
* Blueprint discussion [https://blueprints.launchpad.net/cinder/+spec/copy-volume-to-image-task-flow] - Griffith
* [https://blueprints.launchpad.net/cinder/+spec/admin-defined-capabilities Admin-defined capabilities] - Ollie
* Why is type manage an extension? -Thingee

'''December 11, 2013 16:00 UTC'''
* Proposal of [https://etherpad.openstack.org/p/cinder-extensions extension packages] -Thingee

'''December 4, 2013 16:00 UTC'''
* Progressing with [https://wiki.openstack.org/wiki/Cinder/blueprints/multi-attach-volume multi-attach / shared-volume] - sgordon
* [https://etherpad.openstack.org/p/icehouse-cinder-acls-for-volumes Access Control List design discussion] - alatynskaya

'''November 27, 2013 16:00 UTC'''
* [https://etherpad.openstack.org/p/icehouse-cinder-continuous-volume-replication-v2 Updated volume mirroring design] - avishay
* Start using only Mock for new tests... [http://lists.openstack.org/pipermail/openstack-dev/2013-November/018501.html Related Nova Discussion] - Thingee
* Rate limiting came up in the summit, and [http://lists.openstack.org/pipermail/openstack-dev/2013-November/020291.html on openstack-dev] - avishay
* Metadata backup (https://review.openstack.org/#/c/51900/) progress RFC - dosaboy

'''November 20, 2013 16:00 UTC'''
* I-1 scheduling - JGriffith

'''November 13, 2013 16:00 UTC'''
* patches should update doc files where necessary to ease writing of release notes (Avishay?)
* fencing host from storage (Ehud Trainin)
* Summarize priority of tasks from summit discussions (https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads#Cinder and https://etherpad.openstack.org/p/cinder-icehouse-summary) Griff

'''October 30, 2013 16:00 UTC'''
* cinder backup metadata support - http://goo.gl/Jkg2FV (dosaboy)
* fencing and unfencing host from storage - https://blueprints.launchpad.net/cinder/+spec/fencing-and-unfencing (Ehud Trainin)

'''October 23, 2013 16:00 UTC'''
* Nexenta backup driver https://review.openstack.org/#/c/47005/ - DuncanT

'''October 2, 2013 16:00 UTC'''
* What's still broken in Havana
:* Backups and multibackend (https://code.launchpad.net/bugs/1228223): Fix committed
:* Configuration - Global CONF settings in brick don't belong, and a number of them break multi-backend (Bug #1230066): Fix committed
:* TaskFlow retry mechanism - The majority felt this should be left as a white list, but no work has been done to fix it so we still have ugly failures/roll-backs (3 bugs logged here): '''???'''
:* Quotas - Don't know that anybody has gotten to the bottom of the quota syncing issue (Bug #1202896): '''Still open'''
:* iSCSI Target creation failures - This was thought to have been fixed but showed up last night (Bug #1223469): Probable fix committed
:* Summary of gate issue pertaining to Cinder can be viewed here: http://paste.openstack.org/show/47798/
:* Moving to taskflow - avishay

'''Sept 25, 2013, 16:00 UTC'''
* PTL nomination process is open until the 26'th, if you want to run send your nomination proposal out to the dev ML
* What's broken in Havana
:* Backups (specifically when configured with multi-backend volumes)
:* Configuration - Global CONF settings in brick don't belong, and a number of them break multi-backend (Bug #1230066)
:* TaskFlow retry mechanism - The majority felt this should be left as a white list, but no work has been done to fix it so we still have ugly failures/roll-backs (3 bugs logged here)
:* Quotas - Don't know that anybody has gotten to the bottom of the quota syncing issue (Bug #1202896)
:* iSCSI Target creation failures - This was thought to have been fixed but showed up last night (Bug #1223469)
:* ????
* Cinderclient release plans/status? (Eharney)
* OSLO imports (DuncanT)
* bp/cinder-backup-improvements (dosaboy)
* bp/multi-attach (zhiyan)

'''Aug 21, 2013, 16:00 UTC'''
# No agenda, no meeting.

'''Aug 14, 2013, 16:00 UTC'''
# Volume migration status - avishay
# API extensions using metadata. This comes from the [https://review.openstack.org/#/c/38322/ readonly volume attach support]. - thingee
[http://eavesdrop.openstack.org/meetings/cinder/2013/cinder.2013-08-14-16.00.log.html IRC Log]

'''Aug 7, 2013, 16:00 UTC'''
# [https://bugs.launchpad.net/cinder/+bug/1209199 RFC - make all rbd clones copy-on-write] -- Dosaboy
# V1 API removal issues, plans and timescales - DuncanT

== Meeting Minutes ==

http://eavesdrop.openstack.org/meetings/cinder/2014/

http://eavesdrop.openstack.org/meetings/cinder/2013/

http://eavesdrop.openstack.org/meetings/cinder/2012/

CinderMeetings

2014-12-17T16:12:46Z

Huang Zhiteng:

= Weekly Cinder team meeting =
'''NOTE MEETING TIME: Wed's at 16:00 UTC'''

If you're interested in Cinder or Block Storage in general for OpenStack, we have a weekly meetings in <code><nowiki>#openstack-meeting</nowiki></code>, on Wednesdays at 16:00 UTC. Please feel free to add items to the agenda below. NOTE: When adding topics please include your IRC name so we know who's topic it is and how to get more info.

== Next meeting ==
'''NOTE:''' ''Include your IRC nickname with your agenda items so that you can be called upon in the meeting and arrive at the meeting promptly if placing items in agenda. Please have any supporting links ready. You might want to put this on your calendar if you are adding items.''

'''Dec 17th, 2014 16:00 UTC'''
* Volume deletion while snapshots exist
** '''Led by:''' smatzek
** Kilo blueprint: https://review.openstack.org/#/c/133822/
** EMC VMAX FC and IBM SVC FC volume drivers implement Cinder snapshots as whole standalone volumes
* Return request ID to caller
** '''Led by:''' abhijeetm
** Reference: http://lists.openstack.org/pipermail/openstack-dev/2014-December/052822.html
* Reopen discussion of "RemoteFS configuration improvements"
** '''Led by:''' erlon
** SPEC: https://review.openstack.org/#/c/133173/
** Summary of the problems: https://etherpad.openstack.org/p/remotefs-improvments
* Cinder unit test coverage improvement
** "'Led by:'" winston-d

== Previous meetings ==
'''Dec 10th, 2014 16:00 UTC'''
* Abstract interface for volume drivers
** '''Led by:''' thingee or mkoderer
** cinder.volume.driver changes: https://review.openstack.org/#/c/127455/
** Example of applying the interface to the RBD driver: https://review.openstack.org/#/c/138661/2/cinder/volume/drivers/rbd.py
** Want to know how to configure consistency group. ie create , delete and what changes needed in the conf files. https://bugs.launchpad.net/bugs/1400392
** How to configure the lioadm or tgtadm for cinder juno. (For our own driver) https://bugs.launchpad.net/bugs/1399921
* CI for zone drivers?
** '''Led by:''' jnrao
* NFS/posix backup drivers again
** '''Led by:''' tbarron and kfox1111
** "posix" implementation: https://review.openstack.org/#/c/82996/
** "chunking" base class implementation: https://review.openstack.org/#/c/139737/
** blueprint spec: https://review.openstack.org/#/c/130858/
** original "nfs" implementation: https://review.openstack.org/#/c/138234
* Discuss implementation direction of PureISCSIDriver CHAP support changes
** '''Led by:''' patrickeast
** https://review.openstack.org/#/c/137175/
** Summary of the problems & FAQ: https://etherpad.openstack.org/p/pureiscsi-chap-faq
* Discuss database cleanup status and priorities
** '''Led by:''' e0ne
** https://etherpad.openstack.org/p/cinder-kilo-db-cleanup
* Discuss HA issues mentioned by Ops during the summit
** '''Led by:''' dulek
** https://etherpad.openstack.org/p/kilo-crossproject-ha-integration (Cinder section specifically)
* Third Party CI updates
** '''Led by:''' asselin
** Would like to invite Cinder third party ci "operators" to third party ci meeting: https://wiki.openstack.org/wiki/Meetings/ThirdParty
** Meeting time change is proposed on mailing list. Vote here: http://lists.openstack.org/pipermail/openstack-dev/2014-December/052546.html
** Asselin is proposing an in-tree 3rd party ci solution. Idea well received in 3rd party ci & infra meetings. Please review spec and/or let me know your interest.
*** Gerrit topic "thirdpartyci" query: https://review.openstack.org/#/q/topic:thirdpartyci,n,z

'''Dec 3rd, 2014 16:00 UTC'''
* Should #openstack-cinder IRC be archived?
** '''Led by:''' scottda
** It is not present in http://eavesdrop.openstack.org/irclogs/
** Infra room indicated a resolution at this meeting would make things happen
* Continue the discussion on over subscription
** '''Led by:''' xyang
** https://review.openstack.org/#/c/129342/
* Discussion on the current status of this spec "Support Modifying Volume Image Metadata"
** '''Led by:''' davechen
** https://review.openstack.org/#/c/136253/
* Posix backup driver replaces NFS backup driver
** NFS backup driver: https://review.openstack.org/#/c/138234/1
*** Kevin Fox views the Posix backup driver as a replacement to NFS https://review.openstack.org/#/c/130858/
** Posix backup driver: https://review.openstack.org/#/c/82996/
* RemoteFS snapshots
** '''Led by:''' kaisers
** https://blueprints.launchpad.net/cinder/+spec/remotefs-snaps
** Some parts of refactoring functionality from RemoteFS based drivers to the parent class have been done, we would like to complete the refactoring in the next weeks
*** Currently the addition of new drivers produces code duplication (e.g. https://blueprints.launchpad.net/cinder/+spec/quobyte-usp-driver)
*** Work will be based on aspects discussed in a previous meeting (http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-05-21-16.00.log.txt , 1655h+)

'''Nov 26th, 2014 16:00 UTC'''
* Volume status polling
** '''Led by:''' TobiasE1
** Cinder spec: https://review.openstack.org/#/c/132225/
** Nova spec: https://review.openstack.org/#/c/135367/
** This is related to the reset-state blueprint
* Over-Subscription Alternative
** '''Led by:''' bswartz
** Cinder spec: https://review.openstack.org/#/c/129342/ (xyang: Discussed at the design summit in Paris)

'''Nov 19th, 2014 16:00 UTC'''
* 3rd party CI
** '''Led by:''' DuncanT
** Current blockers? https://wiki.openstack.org/wiki/Cinder/third-party-ci-status
** Pencil in a new cutoff date?
** Dashboard - initial discussion at https://etherpad.openstack.org/p/Third-Party-CI-Dashboard-InitialPlanning
* Kilo mid-cycle meet-up:
** '''Led by:''' JungleboyJ
** IBM has started planning the event and needs to know how many people are planning on attending. (Need to figure out how big a room to have.)
** Please sign up here if planning to attend: https://etherpad.openstack.org/p/cinder-kilo-midcycle-meetup
* What to do about cinder.conf.sample
** '''Led by:''' JungleboyJ
** If we can't get rid of it, how do we keep it from breaking the gate?
* Volume metadata having semantic meaning to Cinder
** '''Led by:''' DuncanT
** https://review.openstack.org/#/c/102511/
* Discuss how to cleanup stuck volumes (creating/deleting/attaching/detaching)
** '''Led by:''' scottda
** https://blueprints.launchpad.net/cinder/+spec/reset-state-with-driver
** Is there interest in *any* solution?
** Alternatives to proposed blueprint
* Are changes to the Cinder V1 API still worth the trouble?
** '''Led by:''' pwehrle
** changes are submitted changing both v1 and v2 of the Cinder API (https://review.openstack.org/#/c/133383/, https://review.openstack.org/#/c/132657/)
** the Cinder V1 API is deprecated in Juno (https://wiki.openstack.org/wiki/ReleaseNotes/Juno)
** are (backward compatible) changes just discouraged or outright forbidden?
* Backport NFS security bugfix to stable/juno and stable/icehouse
** '''Led by:''' bswartz
** https://review.openstack.org/#/c/107693/

'''Nov 12th, 2014 16:00 UTC'''
* Cancelled since the summit just happened last week. We'll meet again November 19th.

'''Nov 5th, 2014'''
* No meeting - Openstack Summit in Paris

'''Oct 29th, 2014 16:00 UTC'''
* Discuss the brick spec/effort for Kilo
** '''Led by:''' hemna
** https://review.openstack.org/#/c/129069/
** eharney has some input here as well (see review)
* Discuss the volume type extra specs cinder-spec
** '''Led by:''' hemna
** https://review.openstack.org/#/c/127646/
* Discuss the differential backup patch (Murali)
** https://review.openstack.org/#/c/110068/
* Discuss updating https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
** '''Led by:''' patrickeast
* Project suggestions for OpenStack OPW
** '''Led by:''' thingee
** https://wiki.openstack.org/wiki/OutreachProgramForWomen/Ideas
* Liaison for Cinder third party CI
** '''Led by:''' thingee
** Problem: The OpenStack Infra team has to deal with questions from all projects on how to setup a third party CI.
** Idea #1: Is anyone willing to help the Infra team?
*** Ideally this person already has their third party ci.
*** Will be pinged on IRC from infra when someone has a question with third party CI help in Cinder.
*** Should watch infra mailing list for Cinder related CI questions.
**** If there are requests to reenable a CI, this person should be able to verify that things have been more stable and give the OK so infra can turn things on.
'''Oct 22nd, 2014 16:00 UTC'''
* Discuss kilo summit design session [https://etherpad.openstack.org/p/kilo-cinder-summit-topics proposals] for the cinder track
* '''Led by:''' thingee

'''Oct 14th, 2014 16:00 UTC'''
* Still Need Cross Project Oslo Liason
** '''Signup:''' https://wiki.openstack.org/wiki/CrossProjectLiaisons
* Thirdparty CI voting permissions
** '''Led by:''' patrickeast
** '''Discussion:''' https://etherpad.openstack.org/p/cinder-meeting-20141008
* State Machine
** '''Led by:''' thingee
** '''Previous Discussion:''' https://etherpad.openstack.org/p/juno-cinder-state-and-workflow-management
** '''Spec:''' https://github.com/openstack/cinder-specs/blob/master/specs/juno/create-states.rst
** '''Outstanding Patches:'''
*** https://review.openstack.org/#/c/110434/17
*** https://review.openstack.org/#/c/124205/
* Update on Rolling Upgrades
** '''Led by:''' Duncan
* Close off on design for NFS Security
** '''Led by:''' glenng
** '''Review:''' https://review.openstack.org/#/c/107693/
* Cinder Kilo Stabilization
** '''Led by:''' hemna and thingee
** '''Discussion:''' https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work
** Still need volunteers for (in order of priority):
*** Fix Database Abuse
*** Fix TODOs: https://etherpad.openstack.org/p/cinder-kilo-todos-cleanup
* Review Cinder specs for Kilo Release
** '''Led by:''' thingee

'''Oct 8th, 2014 16:00 UTC'''
* Thirdparty CI voting permissions (patrickeast)
** I wanted to discuss criteria for getting permission and the process for Cinder driver CI's to get there
* Introduce a nice way of accessing up-to-date information on Cinder drivers
** I wanted to discuss a new workflow of updating drivers information for maintainers (irina_pov).
* Oslo Project Liaison for Kilo Release [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg37015.html Mailing List Post] | [https://wiki.openstack.org/wiki/CrossProjectLiaisons Signup] thingee
* [https://review.openstack.org/#/q/project:+openstack/cinder-specs+status:+open+label:Verified%253E%253D1%252Cjenkins+NOT+label:Code-Review%252Cself,n,z Review Cinder specs for Kilo Release] thingee
* https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work
* Discussion and review of NFS Security: https://review.openstack.org/#/c/107693/

'''Oct 1st, 2014 16:00 UTC'''
* Kilo Stabilization effort https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work
* Discussion and review of NFS Security: https://review.openstack.org/#/c/107693/

'''Sep 24th, 2014 16:00 UTC'''
* Remove XenAPI driver (https://review.openstack.org/#/c/123162/) (DuncanT)
** Should we go through deprecation?
** There's an HP MSA driver that is unmaintained, unCIed and as far as we know unused, so we need a policy
*** Might have found a maintainer (DuncanT)

* Please remember we're coming up to RC so lots of testing and bug fixing please, not just getting stuff ready for Kilo opening!

'''Sep 17th, 2014 16:00 UTC'''

* FFEs - status (DuncanT or JGriffith)
** Are they all merged yet?
***Looks like yes according to the list on https://etherpad.openstack.org/p/juno-cinder-approved-ffes
** Are we going to go -2 things that need to wait now?
** Avoiding submarine features (AKA that's a feature not a bug)
* Hot issues - what is really affecting people? (DuncanT or JGriffith)
* 3rd Party CI Status wiki (jungleboyj)
** https://wiki.openstack.org/wiki/Cinder/third-party-ci-status
** Is this up to date?

'''Sep 10th, 2014 16:00 UTC'''
* Manage/Unmanage of non-integer GB size volumes (bswartz)
* Remove hard dep on osprofiler for services (eharney)
** Prefer for RC1 because waiting until Kilo misses some of the benefit
** https://review.openstack.org/#/c/120455/
* Kilo Stabilization work https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work (hemna)
* Splitting the client into cinder-client and cinder-admin-client (DuncanT)

'''Sep 3rd, 2014 16:00 UTC'''
* Moving Brick out of Cinder (e0ne)
** http://lists.openstack.org/pipermail/openstack-dev/2014-September/044608.html
** https://wiki.openstack.org/wiki/CinderBrick
* Cinder CI Tests Fibre Channel Passthrough & Nodepool works! (asselin)
** Big thanks to Rahul Verma (HP, UC Berkeley) for working out the FC passthrough scripts & Walter Boring (irc:hemna) for FC expertise & debugging assistance.
** Still needs cleanup/documentation: https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins_job_builder/config/macros-fc.yaml.erb
* What are the cutoffs dates for Kilo? (jungleboyj)
** No new drivers after Kilo1?
** No new driver feature implementation?
* https://bugs.launchpad.net/cinder/+bug/1289931 - DuncanT

'''Aug 27th, 2014 16:00 UTC'''
(Some problems with the bot, so minutes are incomplete)
* https://review.openstack.org/111659 - DuncanT
** Should cinder be doing this, or should cinder remain an API that does exactly what it says on the tin and let neutron/nova be 'smarter' if it wants?
** Should we be changing API behaviour? Should we be changing it just before milestone 3?

'''Aug 20th, 2014 16:00 UTC'''

* FPF Tomorrow Aug 21'st (jgriffith)
* Time to start thinking about the Summit and how to be more effective with our time there (jgriffith)
* The idea of a maintenance/ish release (jgriffith)
* Volume replication (ronenkat)
** The patch - https://review.openstack.org/#/c/113054/11
** Depends on https://review.openstack.org/#/c/115078/ to fix pylint error
** Reference replication implementation for IBM Storwize as an example - https://review.openstack.org/#/c/112224/4/
* MAINTAINERS file (DuncanT)
** https://etherpad.openstack.org/p/cinder-driver-maintainers
* Simple CI
** https://github.com/Funcan/kiss-ci (Code will be up any moment now)

'''Aug 13th, 2014 16:00 UTC'''

NO MEETING TODAY, MID CYCLE MEETUP

'''Aug 6th, 2014 16:00 UTC'''
* Cinder mid cycle meetup next week August 12-14 (scottda)
** https://etherpad.openstack.org/p/CinderMidCycleMeetupAug2014
** HP site should be set. Ping scottda with any issues/problems/concerns
** Virtual meetup will need to be taken care of
* Volume replication (ronenkat)
** Alternative approach based on jgriffith driver based replication: https://etherpad.openstack.org/p/juno-cinder-volume-replication-apparochs

'''July 30'th, 2014 16:00 UTC'''
* Planning cinderclient tag for Thursday morning July 31'st, let's catch up on client changes and testing prior to that (jgriffith)
* Breaking the inheritance between data and control path in Volume drivers https://review.openstack.org/#/c/105923/ (jgriffith)
* Consistency groups https://review.openstack.org/#/c/104732/ (xyang)
* Hitachi Block Storage cinder driver https://review.openstack.org/#/c/90379/ (saguchi)
* Volume replication https://review.openstack.org/#/c/106718/ (ronenkat)
** 17:00 UTC - Volume replication driver owner overview and Q & A
** Callin information: passcode: 6406941 call-in numbers: https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=6406941&accessNumber=1809417783#C2
* NFS secure option -- default to 666 vs 660 vs force admin choice (bswartz)
* It is code cleanup tag merge week (DuncanT)
** https://review.openstack.org/#/q/project:openstack/cinder+comment:code_cleanup_batching+-status:merged,n,z

'''July 23th, 2014 16:00 UTC'''

* J2 Milestone (DuncanT)
** JGriffith favours a freeze exception for all drivers taht currently have code / BP up, but bouncing all new ones
** Review priorities
*** Driver specs
*** CG groups - a big change that requires driver changes, so needs lots of eyes and time for driver maintainers to do their thing too: https://review.openstack.org/#/c/104743/
*** Pool scheduling - https://review.openstack.org/#/c/98715/
*** Others?
* Plug for weekly 3rd Party CI meeting (Mondays at 18:00 UTC [1 pm Central]) (jungelboyj)
** I attended this week's meeting and gave a high level status. They are looking for more participation.
* ProphetStor Cinder drivers (stevetan)
** Get feedback on progress of our DPL driver and documentation required https://review.openstack.org/#/c/95829/
** Get direction from community for our Federator SDS driver https://review.openstack.org/#/c/99616/
* Volume replication - work in progress (ronenkat)
** https://review.openstack.org/#/c/106718/2
* NFS Security, if there's time.
** https://blueprints.launchpad.net/cinder/+spec/secure-nfs

'''July 16th, 2014 16:00 UTC'''
* Putting the fun back into cinder development.
** There's been a mailing list thread recently about how nit-picky reviews are getting about typos, white space and the like, and how it is a motivation killer. I'm inclinded to agree - the formatting of the doc strings, fullstops at the end of comments etc doesn't actually improve the code much at all, and getting a -1 for it is a buzz kill of the highest order. Should we leave that sort of thing to the gate, and say that if there is no hacking check for it then it isn't important in general? (DuncanT)

* How to proceed with cinder/openstack requirements? python-dbus for https://review.openstack.org/99013, see mailing list conclusion http://lists.openstack.org/pipermail/openstack-dev/2014-July/040182.html (flip214)
* code churn, not sure where/when to start, fear of merge conflicts (flip214)

* Hitachi Block Storage cinder driver (tsekiyama)
** We want to get some feedback about how we can make this forward
** Review: https://review.openstack.org/#/c/90379/

* Log translations https://review.openstack.org/#/c/105665/ is still stuck - any thoughts? Options I can see: (DuncanT)
** A better technical solution - should be possible where the message format is not expanded outside the logging call i.e.:
Ok:
<nowiki>
LOG.warning("The flubigar id %d exploded messily", flu_id)
</nowiki>
Not ok:
<nowiki>
msg = _("The flubigar id %d exploded messily") % flu_id
LOG.warning(msg)
</nowiki>

** We don't break up our message categories
*** This makes life harder for the translation team, makes us inconsistent with Openstack in general but keeps the code from descending into ugliness
** Related discussion on enabling translation (jungleboyj):
*** Have two patches awaiting approval: Explicit import of _() https://review.openstack.org/105315 and enable lazy translation: https://review.openstack.org/105561
*** Need to get these merged so we are running with the changes.
* 3rd Party CI (jungleboyj):
** Clarification on when drivers are going to be removed.

== Previous meetings ==

'''July 9, 2014 16:00 UTC'''

* flip214 to jgriffith: Status of Separation of Connectors from Driver/Device Interface?
* Quick check: Is everybody happy in principle with the text of https://wiki.openstack.org/wiki/CinderCodeCleanupPatches ? (DuncanT)

'''July 2nd, 2014 16:00 UTC'''
* Batching up mechanical code cleanup until the one week after each milestone (DuncanT)
** See https://review.openstack.org/#/c/102872/ for example and https://review.openstack.org/#/c/101847
** Log translations and hacking fixes fall into this class
** Means you only take one bit hit per milestone for rebases
** Does require some tracking so they don't get missed (and I will suck at said tracking, enviably)
* LVM: Support a volume-group on shared storage (mtanino)
** Want to quickly discuss the driver benefit, driver comparison, performance(P8-P14): https://wiki.openstack.org/w/images/0/08/Cinder-Support_LVM_on_a_sharedLU.pdf
** Review comments? https://review.openstack.org/#/c/92479/
* Cinder Third Party CI Names (asselin)
** Online discussion of this thread: http://lists.openstack.org/pipermail/openstack-dev/2014-July/039103.html

'''June 25th, 2014 16:00 UTC'''
* Consistency groups [xyang]
** Cinder spec review: https://review.openstack.org/#/c/96665/
* CI status [xyang]
** [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg26258.html Third-Party CI Issue (asselin): direct access to review.openstack.org port 29418 required]l
* Pools implementation [navneet]
** Comparison etherpad https://etherpad.openstack.org/p/cinder-pool-impl-comparison
** Decision to select implementation
* keystoneclient integration with cinderclient [hrybacki / ayoung]
** Discuss integration and collaboration possibilities

'''June 18th, 2014 16:00 UTC'''
* It's review day !?! [jdg]
* Mid cycle meetup plans/updates [jdg]
** https://etherpad.openstack.org/p/CinderMidCycleMeetupAug2014
* Separation of Connectors from Driver/Device Interface (status update) [jdg]
* Updates on 3'rd party CI [jdg]
* Things we need to decide upon (not today, but do your homework for next week)
** Software Define Storage layers/drivers
** Pools implementation

'''June 11th, 2014 16:00 UTC'''
* Volume replication (ronenkat)
** Blueprint and spec review/comments? https://review.openstack.org/#/c/98308
* oslo.db (jungleboyj)
** Want to quickly discuss the review out there for this: https://review.openstack.org/#/c/77125/
** Move to current oslo.db? Wait for library work?
* oslo logging discussion (jungleboyj)
** Removing translation of debug messages
** Adding _LE, _LI, _LW
* 3rd party cinder ci (asselin)
** Looking for volunteers to test out my fork of jaypipe's 3rd party ci setup which has support for nodepool & http proxies.
** https://github.com/rasselin/os-ext-testing
** https://github.com/rasselin/os-ext-testing-data
** [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg26258.html Third-Party CI Issue: direct access to review.openstack.org port 29418 required]l
* HDS HNAS Cinder drivers (sombrafam)
** As we are trying check-in for quite a while, we want to get some feedback on the missing steps
** First thread: https://review.openstack.org/#/c/74371/
** Continuation: https://review.openstack.org/#/c/82505/
** Current thread in discussion: https://review.openstack.org/#/c/84244/
* Mid-cyce Sprint (scottda)
** HP in Fort Collins, CO can host on site
** The thought was 10-20 developers
** Large room is available July 14,15,17,18, 21-25, 27-Aug 1 ... Other options exist
* Backend Pools (navneet)
** which way to go? There are two WIPs.
** comparisons between the two approaches? Any wiki/etherpad present or to be prepared for documenting opinions?

'''June 4th, 2014 16:00 UTC'''
* Volume backup modification (navneet)
** Blueprint and spec review/comments? https://blueprints.launchpad.net/cinder/+spec/vol-backup-service-per-backend
* Dynamic multi pool (navneet)
** Review comments? https://review.openstack.org/#/c/85760/
** Implementation approach comparison.
* 3rd party ci (asselin)
** I have a conflict with another meeting, but my WIP to add nodepool into jaypipe's 3rd party ci solution is available here: https://github.com/rasselin/os-ext-testing/tree/nodepool
* oslo.db (jungleboyj)
** Want to quickly discuss the review out there for this: https://review.openstack.org/#/c/77125/
** Move to current oslo.db? Wait for library work?
** Need to drop off the meeting about 40 minutes in so if we can cover before then it would be appreciated. :-)

'''May 28th, 2014 16:00 UTC'''
* 3rd Party CI (jungleboyj)
** What tempest test cases to run?
** iSCSI only? What about for FC only drivers then?
** Progress on where to record results?
* SSH host keys (jungleboyj)
** https://launchpad.net/bugs/1320050 and https://bugs.launchpad.net/cinder/+bug/1320056
** Need plan to get this addressed by all drivers using SSH. (New config options?)
** Way to get this backported to Havana?
* Dynamic multi-pools (navneet)
** Status and WIP review (https://review.openstack.org/#/c/85760/)
** Back manager design improvement/rewriting for better rpc message handling.
** Back up service for multi pools.
* cinder-specs (jgriffith)
** Specs repo is live
** Process
** Reviews

'''May 21st, 2014 16:00 UTC'''
* Consistency Groups (xyang)
** A few people have concerns on the restriction of one volume type per CG. Should we allow one CG to have multiple volume types on the same backend? Let's discuss about it.
* Third-Party CI (jgriffith)
** Who's started, who's planning to and how can we help support each other to get this going smoothly
* Moving GlusterFS snapshot code into the NFS RemoteFs driver (mberlin)
** The GlusterFS snapshot code using qcow2 snapshots is useful for all file based storage systems. I would volunteer to move the GlusterFS snapshot code into the general RemoteFs driver - making it easier to get [https://review.openstack.org/#/c/94186/ our driver] accepted ;-)
** Eric Harney is fine with this and planned to do this for Juno anyway ([https://blueprints.launchpad.net/cinder/+spec/remotefs-snaps see his blueprint]). I've put it on the agenda to make sure others also agree with this approach.

'''May 7th, 2014 16:00 UTC'''
* Limit == 0 in API [https://review.openstack.org/#/c/86207/ patch review] - thingee

'''April 16th, 2014 16:00 UTC'''
* Release Status
* Summit Session Updates
* Next Stop ATL!!!
* Cinder resource status - thingee

'''April 9th, 2014 16:00 UTC'''
(Agenda entered retrospectively)
* Cinder Spec (jgriffith)
** Just a heads up that cinder blueprints will move to a gerrit based process shortly, a la nova. Details and wiki entry to follow.
* RC2 status (jgriffith)
** Just after cutting RC2, a bunch of bugs
* Testing RC code (jgriffith)
** Get on it, folks!
**Looks like theres some serious, intermittent performance issues in the API somewhere...

'''April 2, 2014 16:00 UTC'''
_Meeting cancelled and summary discussion held on #openstack-cinder_

* Release status and bugs
* -2s left on reviews from before Junos opened - please check if they are still valid
- https://review.openstack.org/#/c/73446/ (JGriffith)
- https://review.openstack.org/#/c/80550/ (JBryant)
- https://review.openstack.org/#/c/82100/ (Avishay)
- https://review.openstack.org/#/c/74158/ (Avishay)
- + a whole bunch of stable branch stuff

== Previous meetings ==

'''Mar 26, 2014 16:00 UTC'''
* RC1 updates (jgriffith)
* Design Summit Sessions (jgriffith)
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-03-26-16.00.log.html

'''Mar 19, 2014 16:00 UTC'''
* ProphetStor Driver Exception request for Icehouse (jgriffith)
* Bug status/updates (jgriffith)
* What we should be punting to Juno (aka immediate -2 in Gerrit) (jgriffith)
* Continuous Integration for Cinder Certification (jungleboyj)

'''Mar 12, 2014 16:00 UTC'''
* Cancelled due to nothing on the agenda. Ad-hoc discussion on #openstack-cinder instead

'''Mar 5, 2014 16:00 UTC'''
* Volume replication - avishay
* [https://blueprints.launchpad.net/cinder/+spec/lvm-driver-for-shared-storage New LVM-based driver for shared storage] - mtanino
* DRBD/drbdmanage driver for cinder - philr

'''Feb 19, 2014 16:00 UTC'''
* I3 Status check/updates
* Cert test
* [https://review.openstack.org/#/c/73745 Milestone Consideration for Drivers] -thingee
* [https://etherpad.openstack.org/p/cinder-hack-201402 Hack-a-thon details] -thingee
* [https://review.openstack.org/#/c/66737/ scheduling for local storage] -DuncanT

'''Feb 5, 2014 16:00 UTC'''
* I3 Status check/updates
* Cert test
* Multiple pools per backend (bswartz)
'''Jan 8, 2014 16:00 UTC'''
* I2 is just around the corner, blueprint updates
* Alternating meeting time proposal, results on feedback
* Driver cert test, it's there... use it
* Prioritizing patches and reviews
'''December 18, 2013 16:00 UTC'''
* Blueprint discussion [https://blueprints.launchpad.net/cinder/+spec/cinder-backup-recover-api cinder backup recovery api - import/export backups] - avishay
* Blueprint discussion [https://blueprints.launchpad.net/cinder/+spec/copy-volume-to-image-task-flow] - Griffith
* [https://blueprints.launchpad.net/cinder/+spec/admin-defined-capabilities Admin-defined capabilities] - Ollie
* Why is type manage an extension? -Thingee

'''December 11, 2013 16:00 UTC'''
* Proposal of [https://etherpad.openstack.org/p/cinder-extensions extension packages] -Thingee

'''December 4, 2013 16:00 UTC'''
* Progressing with [https://wiki.openstack.org/wiki/Cinder/blueprints/multi-attach-volume multi-attach / shared-volume] - sgordon
* [https://etherpad.openstack.org/p/icehouse-cinder-acls-for-volumes Access Control List design discussion] - alatynskaya

'''November 27, 2013 16:00 UTC'''
* [https://etherpad.openstack.org/p/icehouse-cinder-continuous-volume-replication-v2 Updated volume mirroring design] - avishay
* Start using only Mock for new tests... [http://lists.openstack.org/pipermail/openstack-dev/2013-November/018501.html Related Nova Discussion] - Thingee
* Rate limiting came up in the summit, and [http://lists.openstack.org/pipermail/openstack-dev/2013-November/020291.html on openstack-dev] - avishay
* Metadata backup (https://review.openstack.org/#/c/51900/) progress RFC - dosaboy

'''November 20, 2013 16:00 UTC'''
* I-1 scheduling - JGriffith

'''November 13, 2013 16:00 UTC'''
* patches should update doc files where necessary to ease writing of release notes (Avishay?)
* fencing host from storage (Ehud Trainin)
* Summarize priority of tasks from summit discussions (https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads#Cinder and https://etherpad.openstack.org/p/cinder-icehouse-summary) Griff

'''October 30, 2013 16:00 UTC'''
* cinder backup metadata support - http://goo.gl/Jkg2FV (dosaboy)
* fencing and unfencing host from storage - https://blueprints.launchpad.net/cinder/+spec/fencing-and-unfencing (Ehud Trainin)

'''October 23, 2013 16:00 UTC'''
* Nexenta backup driver https://review.openstack.org/#/c/47005/ - DuncanT

'''October 2, 2013 16:00 UTC'''
* What's still broken in Havana
:* Backups and multibackend (https://code.launchpad.net/bugs/1228223): Fix committed
:* Configuration - Global CONF settings in brick don't belong, and a number of them break multi-backend (Bug #1230066): Fix committed
:* TaskFlow retry mechanism - The majority felt this should be left as a white list, but no work has been done to fix it so we still have ugly failures/roll-backs (3 bugs logged here): '''???'''
:* Quotas - Don't know that anybody has gotten to the bottom of the quota syncing issue (Bug #1202896): '''Still open'''
:* iSCSI Target creation failures - This was thought to have been fixed but showed up last night (Bug #1223469): Probable fix committed
:* Summary of gate issue pertaining to Cinder can be viewed here: http://paste.openstack.org/show/47798/
:* Moving to taskflow - avishay

'''Sept 25, 2013, 16:00 UTC'''
* PTL nomination process is open until the 26'th, if you want to run send your nomination proposal out to the dev ML
* What's broken in Havana
:* Backups (specifically when configured with multi-backend volumes)
:* Configuration - Global CONF settings in brick don't belong, and a number of them break multi-backend (Bug #1230066)
:* TaskFlow retry mechanism - The majority felt this should be left as a white list, but no work has been done to fix it so we still have ugly failures/roll-backs (3 bugs logged here)
:* Quotas - Don't know that anybody has gotten to the bottom of the quota syncing issue (Bug #1202896)
:* iSCSI Target creation failures - This was thought to have been fixed but showed up last night (Bug #1223469)
:* ????
* Cinderclient release plans/status? (Eharney)
* OSLO imports (DuncanT)
* bp/cinder-backup-improvements (dosaboy)
* bp/multi-attach (zhiyan)

'''Aug 21, 2013, 16:00 UTC'''
# No agenda, no meeting.

'''Aug 14, 2013, 16:00 UTC'''
# Volume migration status - avishay
# API extensions using metadata. This comes from the [https://review.openstack.org/#/c/38322/ readonly volume attach support]. - thingee
[http://eavesdrop.openstack.org/meetings/cinder/2013/cinder.2013-08-14-16.00.log.html IRC Log]

'''Aug 7, 2013, 16:00 UTC'''
# [https://bugs.launchpad.net/cinder/+bug/1209199 RFC - make all rbd clones copy-on-write] -- Dosaboy
# V1 API removal issues, plans and timescales - DuncanT

== Meeting Minutes ==

http://eavesdrop.openstack.org/meetings/cinder/2014/

http://eavesdrop.openstack.org/meetings/cinder/2013/

http://eavesdrop.openstack.org/meetings/cinder/2012/

CinderMeetings

2014-12-17T16:11:06Z

Huang Zhiteng:

= Weekly Cinder team meeting =
'''NOTE MEETING TIME: Wed's at 16:00 UTC'''

If you're interested in Cinder or Block Storage in general for OpenStack, we have a weekly meetings in <code><nowiki>#openstack-meeting</nowiki></code>, on Wednesdays at 16:00 UTC. Please feel free to add items to the agenda below. NOTE: When adding topics please include your IRC name so we know who's topic it is and how to get more info.

== Next meeting ==
'''NOTE:''' ''Include your IRC nickname with your agenda items so that you can be called upon in the meeting and arrive at the meeting promptly if placing items in agenda. Please have any supporting links ready. You might want to put this on your calendar if you are adding items.''

'''Dec 17th, 2014 16:00 UTC'''
* Volume deletion while snapshots exist
** '''Led by:''' smatzek
** Kilo blueprint: https://review.openstack.org/#/c/133822/
** EMC VMAX FC and IBM SVC FC volume drivers implement Cinder snapshots as whole standalone volumes
* Return request ID to caller
** '''Led by:''' abhijeetm
** Reference: http://lists.openstack.org/pipermail/openstack-dev/2014-December/052822.html
* Reopen discussion of "RemoteFS configuration improvements"
** '''Led by:''' erlon
** SPEC: https://review.openstack.org/#/c/133173/
** Summary of the problems: https://etherpad.openstack.org/p/remotefs-improvments
* Cinder unit test coverage improvement
** ""Led by:"" winston-d

== Previous meetings ==
'''Dec 10th, 2014 16:00 UTC'''
* Abstract interface for volume drivers
** '''Led by:''' thingee or mkoderer
** cinder.volume.driver changes: https://review.openstack.org/#/c/127455/
** Example of applying the interface to the RBD driver: https://review.openstack.org/#/c/138661/2/cinder/volume/drivers/rbd.py
** Want to know how to configure consistency group. ie create , delete and what changes needed in the conf files. https://bugs.launchpad.net/bugs/1400392
** How to configure the lioadm or tgtadm for cinder juno. (For our own driver) https://bugs.launchpad.net/bugs/1399921
* CI for zone drivers?
** '''Led by:''' jnrao
* NFS/posix backup drivers again
** '''Led by:''' tbarron and kfox1111
** "posix" implementation: https://review.openstack.org/#/c/82996/
** "chunking" base class implementation: https://review.openstack.org/#/c/139737/
** blueprint spec: https://review.openstack.org/#/c/130858/
** original "nfs" implementation: https://review.openstack.org/#/c/138234
* Discuss implementation direction of PureISCSIDriver CHAP support changes
** '''Led by:''' patrickeast
** https://review.openstack.org/#/c/137175/
** Summary of the problems & FAQ: https://etherpad.openstack.org/p/pureiscsi-chap-faq
* Discuss database cleanup status and priorities
** '''Led by:''' e0ne
** https://etherpad.openstack.org/p/cinder-kilo-db-cleanup
* Discuss HA issues mentioned by Ops during the summit
** '''Led by:''' dulek
** https://etherpad.openstack.org/p/kilo-crossproject-ha-integration (Cinder section specifically)
* Third Party CI updates
** '''Led by:''' asselin
** Would like to invite Cinder third party ci "operators" to third party ci meeting: https://wiki.openstack.org/wiki/Meetings/ThirdParty
** Meeting time change is proposed on mailing list. Vote here: http://lists.openstack.org/pipermail/openstack-dev/2014-December/052546.html
** Asselin is proposing an in-tree 3rd party ci solution. Idea well received in 3rd party ci & infra meetings. Please review spec and/or let me know your interest.
*** Gerrit topic "thirdpartyci" query: https://review.openstack.org/#/q/topic:thirdpartyci,n,z

'''Dec 3rd, 2014 16:00 UTC'''
* Should #openstack-cinder IRC be archived?
** '''Led by:''' scottda
** It is not present in http://eavesdrop.openstack.org/irclogs/
** Infra room indicated a resolution at this meeting would make things happen
* Continue the discussion on over subscription
** '''Led by:''' xyang
** https://review.openstack.org/#/c/129342/
* Discussion on the current status of this spec "Support Modifying Volume Image Metadata"
** '''Led by:''' davechen
** https://review.openstack.org/#/c/136253/
* Posix backup driver replaces NFS backup driver
** NFS backup driver: https://review.openstack.org/#/c/138234/1
*** Kevin Fox views the Posix backup driver as a replacement to NFS https://review.openstack.org/#/c/130858/
** Posix backup driver: https://review.openstack.org/#/c/82996/
* RemoteFS snapshots
** '''Led by:''' kaisers
** https://blueprints.launchpad.net/cinder/+spec/remotefs-snaps
** Some parts of refactoring functionality from RemoteFS based drivers to the parent class have been done, we would like to complete the refactoring in the next weeks
*** Currently the addition of new drivers produces code duplication (e.g. https://blueprints.launchpad.net/cinder/+spec/quobyte-usp-driver)
*** Work will be based on aspects discussed in a previous meeting (http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-05-21-16.00.log.txt , 1655h+)

'''Nov 26th, 2014 16:00 UTC'''
* Volume status polling
** '''Led by:''' TobiasE1
** Cinder spec: https://review.openstack.org/#/c/132225/
** Nova spec: https://review.openstack.org/#/c/135367/
** This is related to the reset-state blueprint
* Over-Subscription Alternative
** '''Led by:''' bswartz
** Cinder spec: https://review.openstack.org/#/c/129342/ (xyang: Discussed at the design summit in Paris)

'''Nov 19th, 2014 16:00 UTC'''
* 3rd party CI
** '''Led by:''' DuncanT
** Current blockers? https://wiki.openstack.org/wiki/Cinder/third-party-ci-status
** Pencil in a new cutoff date?
** Dashboard - initial discussion at https://etherpad.openstack.org/p/Third-Party-CI-Dashboard-InitialPlanning
* Kilo mid-cycle meet-up:
** '''Led by:''' JungleboyJ
** IBM has started planning the event and needs to know how many people are planning on attending. (Need to figure out how big a room to have.)
** Please sign up here if planning to attend: https://etherpad.openstack.org/p/cinder-kilo-midcycle-meetup
* What to do about cinder.conf.sample
** '''Led by:''' JungleboyJ
** If we can't get rid of it, how do we keep it from breaking the gate?
* Volume metadata having semantic meaning to Cinder
** '''Led by:''' DuncanT
** https://review.openstack.org/#/c/102511/
* Discuss how to cleanup stuck volumes (creating/deleting/attaching/detaching)
** '''Led by:''' scottda
** https://blueprints.launchpad.net/cinder/+spec/reset-state-with-driver
** Is there interest in *any* solution?
** Alternatives to proposed blueprint
* Are changes to the Cinder V1 API still worth the trouble?
** '''Led by:''' pwehrle
** changes are submitted changing both v1 and v2 of the Cinder API (https://review.openstack.org/#/c/133383/, https://review.openstack.org/#/c/132657/)
** the Cinder V1 API is deprecated in Juno (https://wiki.openstack.org/wiki/ReleaseNotes/Juno)
** are (backward compatible) changes just discouraged or outright forbidden?
* Backport NFS security bugfix to stable/juno and stable/icehouse
** '''Led by:''' bswartz
** https://review.openstack.org/#/c/107693/

'''Nov 12th, 2014 16:00 UTC'''
* Cancelled since the summit just happened last week. We'll meet again November 19th.

'''Nov 5th, 2014'''
* No meeting - Openstack Summit in Paris

'''Oct 29th, 2014 16:00 UTC'''
* Discuss the brick spec/effort for Kilo
** '''Led by:''' hemna
** https://review.openstack.org/#/c/129069/
** eharney has some input here as well (see review)
* Discuss the volume type extra specs cinder-spec
** '''Led by:''' hemna
** https://review.openstack.org/#/c/127646/
* Discuss the differential backup patch (Murali)
** https://review.openstack.org/#/c/110068/
* Discuss updating https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
** '''Led by:''' patrickeast
* Project suggestions for OpenStack OPW
** '''Led by:''' thingee
** https://wiki.openstack.org/wiki/OutreachProgramForWomen/Ideas
* Liaison for Cinder third party CI
** '''Led by:''' thingee
** Problem: The OpenStack Infra team has to deal with questions from all projects on how to setup a third party CI.
** Idea #1: Is anyone willing to help the Infra team?
*** Ideally this person already has their third party ci.
*** Will be pinged on IRC from infra when someone has a question with third party CI help in Cinder.
*** Should watch infra mailing list for Cinder related CI questions.
**** If there are requests to reenable a CI, this person should be able to verify that things have been more stable and give the OK so infra can turn things on.
'''Oct 22nd, 2014 16:00 UTC'''
* Discuss kilo summit design session [https://etherpad.openstack.org/p/kilo-cinder-summit-topics proposals] for the cinder track
* '''Led by:''' thingee

'''Oct 14th, 2014 16:00 UTC'''
* Still Need Cross Project Oslo Liason
** '''Signup:''' https://wiki.openstack.org/wiki/CrossProjectLiaisons
* Thirdparty CI voting permissions
** '''Led by:''' patrickeast
** '''Discussion:''' https://etherpad.openstack.org/p/cinder-meeting-20141008
* State Machine
** '''Led by:''' thingee
** '''Previous Discussion:''' https://etherpad.openstack.org/p/juno-cinder-state-and-workflow-management
** '''Spec:''' https://github.com/openstack/cinder-specs/blob/master/specs/juno/create-states.rst
** '''Outstanding Patches:'''
*** https://review.openstack.org/#/c/110434/17
*** https://review.openstack.org/#/c/124205/
* Update on Rolling Upgrades
** '''Led by:''' Duncan
* Close off on design for NFS Security
** '''Led by:''' glenng
** '''Review:''' https://review.openstack.org/#/c/107693/
* Cinder Kilo Stabilization
** '''Led by:''' hemna and thingee
** '''Discussion:''' https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work
** Still need volunteers for (in order of priority):
*** Fix Database Abuse
*** Fix TODOs: https://etherpad.openstack.org/p/cinder-kilo-todos-cleanup
* Review Cinder specs for Kilo Release
** '''Led by:''' thingee

'''Oct 8th, 2014 16:00 UTC'''
* Thirdparty CI voting permissions (patrickeast)
** I wanted to discuss criteria for getting permission and the process for Cinder driver CI's to get there
* Introduce a nice way of accessing up-to-date information on Cinder drivers
** I wanted to discuss a new workflow of updating drivers information for maintainers (irina_pov).
* Oslo Project Liaison for Kilo Release [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg37015.html Mailing List Post] | [https://wiki.openstack.org/wiki/CrossProjectLiaisons Signup] thingee
* [https://review.openstack.org/#/q/project:+openstack/cinder-specs+status:+open+label:Verified%253E%253D1%252Cjenkins+NOT+label:Code-Review%252Cself,n,z Review Cinder specs for Kilo Release] thingee
* https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work
* Discussion and review of NFS Security: https://review.openstack.org/#/c/107693/

'''Oct 1st, 2014 16:00 UTC'''
* Kilo Stabilization effort https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work
* Discussion and review of NFS Security: https://review.openstack.org/#/c/107693/

'''Sep 24th, 2014 16:00 UTC'''
* Remove XenAPI driver (https://review.openstack.org/#/c/123162/) (DuncanT)
** Should we go through deprecation?
** There's an HP MSA driver that is unmaintained, unCIed and as far as we know unused, so we need a policy
*** Might have found a maintainer (DuncanT)

* Please remember we're coming up to RC so lots of testing and bug fixing please, not just getting stuff ready for Kilo opening!

'''Sep 17th, 2014 16:00 UTC'''

* FFEs - status (DuncanT or JGriffith)
** Are they all merged yet?
***Looks like yes according to the list on https://etherpad.openstack.org/p/juno-cinder-approved-ffes
** Are we going to go -2 things that need to wait now?
** Avoiding submarine features (AKA that's a feature not a bug)
* Hot issues - what is really affecting people? (DuncanT or JGriffith)
* 3rd Party CI Status wiki (jungleboyj)
** https://wiki.openstack.org/wiki/Cinder/third-party-ci-status
** Is this up to date?

'''Sep 10th, 2014 16:00 UTC'''
* Manage/Unmanage of non-integer GB size volumes (bswartz)
* Remove hard dep on osprofiler for services (eharney)
** Prefer for RC1 because waiting until Kilo misses some of the benefit
** https://review.openstack.org/#/c/120455/
* Kilo Stabilization work https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work (hemna)
* Splitting the client into cinder-client and cinder-admin-client (DuncanT)

'''Sep 3rd, 2014 16:00 UTC'''
* Moving Brick out of Cinder (e0ne)
** http://lists.openstack.org/pipermail/openstack-dev/2014-September/044608.html
** https://wiki.openstack.org/wiki/CinderBrick
* Cinder CI Tests Fibre Channel Passthrough & Nodepool works! (asselin)
** Big thanks to Rahul Verma (HP, UC Berkeley) for working out the FC passthrough scripts & Walter Boring (irc:hemna) for FC expertise & debugging assistance.
** Still needs cleanup/documentation: https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins_job_builder/config/macros-fc.yaml.erb
* What are the cutoffs dates for Kilo? (jungleboyj)
** No new drivers after Kilo1?
** No new driver feature implementation?
* https://bugs.launchpad.net/cinder/+bug/1289931 - DuncanT

'''Aug 27th, 2014 16:00 UTC'''
(Some problems with the bot, so minutes are incomplete)
* https://review.openstack.org/111659 - DuncanT
** Should cinder be doing this, or should cinder remain an API that does exactly what it says on the tin and let neutron/nova be 'smarter' if it wants?
** Should we be changing API behaviour? Should we be changing it just before milestone 3?

'''Aug 20th, 2014 16:00 UTC'''

* FPF Tomorrow Aug 21'st (jgriffith)
* Time to start thinking about the Summit and how to be more effective with our time there (jgriffith)
* The idea of a maintenance/ish release (jgriffith)
* Volume replication (ronenkat)
** The patch - https://review.openstack.org/#/c/113054/11
** Depends on https://review.openstack.org/#/c/115078/ to fix pylint error
** Reference replication implementation for IBM Storwize as an example - https://review.openstack.org/#/c/112224/4/
* MAINTAINERS file (DuncanT)
** https://etherpad.openstack.org/p/cinder-driver-maintainers
* Simple CI
** https://github.com/Funcan/kiss-ci (Code will be up any moment now)

'''Aug 13th, 2014 16:00 UTC'''

NO MEETING TODAY, MID CYCLE MEETUP

'''Aug 6th, 2014 16:00 UTC'''
* Cinder mid cycle meetup next week August 12-14 (scottda)
** https://etherpad.openstack.org/p/CinderMidCycleMeetupAug2014
** HP site should be set. Ping scottda with any issues/problems/concerns
** Virtual meetup will need to be taken care of
* Volume replication (ronenkat)
** Alternative approach based on jgriffith driver based replication: https://etherpad.openstack.org/p/juno-cinder-volume-replication-apparochs

'''July 30'th, 2014 16:00 UTC'''
* Planning cinderclient tag for Thursday morning July 31'st, let's catch up on client changes and testing prior to that (jgriffith)
* Breaking the inheritance between data and control path in Volume drivers https://review.openstack.org/#/c/105923/ (jgriffith)
* Consistency groups https://review.openstack.org/#/c/104732/ (xyang)
* Hitachi Block Storage cinder driver https://review.openstack.org/#/c/90379/ (saguchi)
* Volume replication https://review.openstack.org/#/c/106718/ (ronenkat)
** 17:00 UTC - Volume replication driver owner overview and Q & A
** Callin information: passcode: 6406941 call-in numbers: https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=6406941&accessNumber=1809417783#C2
* NFS secure option -- default to 666 vs 660 vs force admin choice (bswartz)
* It is code cleanup tag merge week (DuncanT)
** https://review.openstack.org/#/q/project:openstack/cinder+comment:code_cleanup_batching+-status:merged,n,z

'''July 23th, 2014 16:00 UTC'''

* J2 Milestone (DuncanT)
** JGriffith favours a freeze exception for all drivers taht currently have code / BP up, but bouncing all new ones
** Review priorities
*** Driver specs
*** CG groups - a big change that requires driver changes, so needs lots of eyes and time for driver maintainers to do their thing too: https://review.openstack.org/#/c/104743/
*** Pool scheduling - https://review.openstack.org/#/c/98715/
*** Others?
* Plug for weekly 3rd Party CI meeting (Mondays at 18:00 UTC [1 pm Central]) (jungelboyj)
** I attended this week's meeting and gave a high level status. They are looking for more participation.
* ProphetStor Cinder drivers (stevetan)
** Get feedback on progress of our DPL driver and documentation required https://review.openstack.org/#/c/95829/
** Get direction from community for our Federator SDS driver https://review.openstack.org/#/c/99616/
* Volume replication - work in progress (ronenkat)
** https://review.openstack.org/#/c/106718/2
* NFS Security, if there's time.
** https://blueprints.launchpad.net/cinder/+spec/secure-nfs

'''July 16th, 2014 16:00 UTC'''
* Putting the fun back into cinder development.
** There's been a mailing list thread recently about how nit-picky reviews are getting about typos, white space and the like, and how it is a motivation killer. I'm inclinded to agree - the formatting of the doc strings, fullstops at the end of comments etc doesn't actually improve the code much at all, and getting a -1 for it is a buzz kill of the highest order. Should we leave that sort of thing to the gate, and say that if there is no hacking check for it then it isn't important in general? (DuncanT)

* How to proceed with cinder/openstack requirements? python-dbus for https://review.openstack.org/99013, see mailing list conclusion http://lists.openstack.org/pipermail/openstack-dev/2014-July/040182.html (flip214)
* code churn, not sure where/when to start, fear of merge conflicts (flip214)

* Hitachi Block Storage cinder driver (tsekiyama)
** We want to get some feedback about how we can make this forward
** Review: https://review.openstack.org/#/c/90379/

* Log translations https://review.openstack.org/#/c/105665/ is still stuck - any thoughts? Options I can see: (DuncanT)
** A better technical solution - should be possible where the message format is not expanded outside the logging call i.e.:
Ok:
<nowiki>
LOG.warning("The flubigar id %d exploded messily", flu_id)
</nowiki>
Not ok:
<nowiki>
msg = _("The flubigar id %d exploded messily") % flu_id
LOG.warning(msg)
</nowiki>

** We don't break up our message categories
*** This makes life harder for the translation team, makes us inconsistent with Openstack in general but keeps the code from descending into ugliness
** Related discussion on enabling translation (jungleboyj):
*** Have two patches awaiting approval: Explicit import of _() https://review.openstack.org/105315 and enable lazy translation: https://review.openstack.org/105561
*** Need to get these merged so we are running with the changes.
* 3rd Party CI (jungleboyj):
** Clarification on when drivers are going to be removed.

== Previous meetings ==

'''July 9, 2014 16:00 UTC'''

* flip214 to jgriffith: Status of Separation of Connectors from Driver/Device Interface?
* Quick check: Is everybody happy in principle with the text of https://wiki.openstack.org/wiki/CinderCodeCleanupPatches ? (DuncanT)

'''July 2nd, 2014 16:00 UTC'''
* Batching up mechanical code cleanup until the one week after each milestone (DuncanT)
** See https://review.openstack.org/#/c/102872/ for example and https://review.openstack.org/#/c/101847
** Log translations and hacking fixes fall into this class
** Means you only take one bit hit per milestone for rebases
** Does require some tracking so they don't get missed (and I will suck at said tracking, enviably)
* LVM: Support a volume-group on shared storage (mtanino)
** Want to quickly discuss the driver benefit, driver comparison, performance(P8-P14): https://wiki.openstack.org/w/images/0/08/Cinder-Support_LVM_on_a_sharedLU.pdf
** Review comments? https://review.openstack.org/#/c/92479/
* Cinder Third Party CI Names (asselin)
** Online discussion of this thread: http://lists.openstack.org/pipermail/openstack-dev/2014-July/039103.html

'''June 25th, 2014 16:00 UTC'''
* Consistency groups [xyang]
** Cinder spec review: https://review.openstack.org/#/c/96665/
* CI status [xyang]
** [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg26258.html Third-Party CI Issue (asselin): direct access to review.openstack.org port 29418 required]l
* Pools implementation [navneet]
** Comparison etherpad https://etherpad.openstack.org/p/cinder-pool-impl-comparison
** Decision to select implementation
* keystoneclient integration with cinderclient [hrybacki / ayoung]
** Discuss integration and collaboration possibilities

'''June 18th, 2014 16:00 UTC'''
* It's review day !?! [jdg]
* Mid cycle meetup plans/updates [jdg]
** https://etherpad.openstack.org/p/CinderMidCycleMeetupAug2014
* Separation of Connectors from Driver/Device Interface (status update) [jdg]
* Updates on 3'rd party CI [jdg]
* Things we need to decide upon (not today, but do your homework for next week)
** Software Define Storage layers/drivers
** Pools implementation

'''June 11th, 2014 16:00 UTC'''
* Volume replication (ronenkat)
** Blueprint and spec review/comments? https://review.openstack.org/#/c/98308
* oslo.db (jungleboyj)
** Want to quickly discuss the review out there for this: https://review.openstack.org/#/c/77125/
** Move to current oslo.db? Wait for library work?
* oslo logging discussion (jungleboyj)
** Removing translation of debug messages
** Adding _LE, _LI, _LW
* 3rd party cinder ci (asselin)
** Looking for volunteers to test out my fork of jaypipe's 3rd party ci setup which has support for nodepool & http proxies.
** https://github.com/rasselin/os-ext-testing
** https://github.com/rasselin/os-ext-testing-data
** [http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg26258.html Third-Party CI Issue: direct access to review.openstack.org port 29418 required]l
* HDS HNAS Cinder drivers (sombrafam)
** As we are trying check-in for quite a while, we want to get some feedback on the missing steps
** First thread: https://review.openstack.org/#/c/74371/
** Continuation: https://review.openstack.org/#/c/82505/
** Current thread in discussion: https://review.openstack.org/#/c/84244/
* Mid-cyce Sprint (scottda)
** HP in Fort Collins, CO can host on site
** The thought was 10-20 developers
** Large room is available July 14,15,17,18, 21-25, 27-Aug 1 ... Other options exist
* Backend Pools (navneet)
** which way to go? There are two WIPs.
** comparisons between the two approaches? Any wiki/etherpad present or to be prepared for documenting opinions?

'''June 4th, 2014 16:00 UTC'''
* Volume backup modification (navneet)
** Blueprint and spec review/comments? https://blueprints.launchpad.net/cinder/+spec/vol-backup-service-per-backend
* Dynamic multi pool (navneet)
** Review comments? https://review.openstack.org/#/c/85760/
** Implementation approach comparison.
* 3rd party ci (asselin)
** I have a conflict with another meeting, but my WIP to add nodepool into jaypipe's 3rd party ci solution is available here: https://github.com/rasselin/os-ext-testing/tree/nodepool
* oslo.db (jungleboyj)
** Want to quickly discuss the review out there for this: https://review.openstack.org/#/c/77125/
** Move to current oslo.db? Wait for library work?
** Need to drop off the meeting about 40 minutes in so if we can cover before then it would be appreciated. :-)

'''May 28th, 2014 16:00 UTC'''
* 3rd Party CI (jungleboyj)
** What tempest test cases to run?
** iSCSI only? What about for FC only drivers then?
** Progress on where to record results?
* SSH host keys (jungleboyj)
** https://launchpad.net/bugs/1320050 and https://bugs.launchpad.net/cinder/+bug/1320056
** Need plan to get this addressed by all drivers using SSH. (New config options?)
** Way to get this backported to Havana?
* Dynamic multi-pools (navneet)
** Status and WIP review (https://review.openstack.org/#/c/85760/)
** Back manager design improvement/rewriting for better rpc message handling.
** Back up service for multi pools.
* cinder-specs (jgriffith)
** Specs repo is live
** Process
** Reviews

'''May 21st, 2014 16:00 UTC'''
* Consistency Groups (xyang)
** A few people have concerns on the restriction of one volume type per CG. Should we allow one CG to have multiple volume types on the same backend? Let's discuss about it.
* Third-Party CI (jgriffith)
** Who's started, who's planning to and how can we help support each other to get this going smoothly
* Moving GlusterFS snapshot code into the NFS RemoteFs driver (mberlin)
** The GlusterFS snapshot code using qcow2 snapshots is useful for all file based storage systems. I would volunteer to move the GlusterFS snapshot code into the general RemoteFs driver - making it easier to get [https://review.openstack.org/#/c/94186/ our driver] accepted ;-)
** Eric Harney is fine with this and planned to do this for Juno anyway ([https://blueprints.launchpad.net/cinder/+spec/remotefs-snaps see his blueprint]). I've put it on the agenda to make sure others also agree with this approach.

'''May 7th, 2014 16:00 UTC'''
* Limit == 0 in API [https://review.openstack.org/#/c/86207/ patch review] - thingee

'''April 16th, 2014 16:00 UTC'''
* Release Status
* Summit Session Updates
* Next Stop ATL!!!
* Cinder resource status - thingee

'''April 9th, 2014 16:00 UTC'''
(Agenda entered retrospectively)
* Cinder Spec (jgriffith)
** Just a heads up that cinder blueprints will move to a gerrit based process shortly, a la nova. Details and wiki entry to follow.
* RC2 status (jgriffith)
** Just after cutting RC2, a bunch of bugs
* Testing RC code (jgriffith)
** Get on it, folks!
**Looks like theres some serious, intermittent performance issues in the API somewhere...

'''April 2, 2014 16:00 UTC'''
_Meeting cancelled and summary discussion held on #openstack-cinder_

* Release status and bugs
* -2s left on reviews from before Junos opened - please check if they are still valid
- https://review.openstack.org/#/c/73446/ (JGriffith)
- https://review.openstack.org/#/c/80550/ (JBryant)
- https://review.openstack.org/#/c/82100/ (Avishay)
- https://review.openstack.org/#/c/74158/ (Avishay)
- + a whole bunch of stable branch stuff

== Previous meetings ==

'''Mar 26, 2014 16:00 UTC'''
* RC1 updates (jgriffith)
* Design Summit Sessions (jgriffith)
http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-03-26-16.00.log.html

'''Mar 19, 2014 16:00 UTC'''
* ProphetStor Driver Exception request for Icehouse (jgriffith)
* Bug status/updates (jgriffith)
* What we should be punting to Juno (aka immediate -2 in Gerrit) (jgriffith)
* Continuous Integration for Cinder Certification (jungleboyj)

'''Mar 12, 2014 16:00 UTC'''
* Cancelled due to nothing on the agenda. Ad-hoc discussion on #openstack-cinder instead

'''Mar 5, 2014 16:00 UTC'''
* Volume replication - avishay
* [https://blueprints.launchpad.net/cinder/+spec/lvm-driver-for-shared-storage New LVM-based driver for shared storage] - mtanino
* DRBD/drbdmanage driver for cinder - philr

'''Feb 19, 2014 16:00 UTC'''
* I3 Status check/updates
* Cert test
* [https://review.openstack.org/#/c/73745 Milestone Consideration for Drivers] -thingee
* [https://etherpad.openstack.org/p/cinder-hack-201402 Hack-a-thon details] -thingee
* [https://review.openstack.org/#/c/66737/ scheduling for local storage] -DuncanT

'''Feb 5, 2014 16:00 UTC'''
* I3 Status check/updates
* Cert test
* Multiple pools per backend (bswartz)
'''Jan 8, 2014 16:00 UTC'''
* I2 is just around the corner, blueprint updates
* Alternating meeting time proposal, results on feedback
* Driver cert test, it's there... use it
* Prioritizing patches and reviews
'''December 18, 2013 16:00 UTC'''
* Blueprint discussion [https://blueprints.launchpad.net/cinder/+spec/cinder-backup-recover-api cinder backup recovery api - import/export backups] - avishay
* Blueprint discussion [https://blueprints.launchpad.net/cinder/+spec/copy-volume-to-image-task-flow] - Griffith
* [https://blueprints.launchpad.net/cinder/+spec/admin-defined-capabilities Admin-defined capabilities] - Ollie
* Why is type manage an extension? -Thingee

'''December 11, 2013 16:00 UTC'''
* Proposal of [https://etherpad.openstack.org/p/cinder-extensions extension packages] -Thingee

'''December 4, 2013 16:00 UTC'''
* Progressing with [https://wiki.openstack.org/wiki/Cinder/blueprints/multi-attach-volume multi-attach / shared-volume] - sgordon
* [https://etherpad.openstack.org/p/icehouse-cinder-acls-for-volumes Access Control List design discussion] - alatynskaya

'''November 27, 2013 16:00 UTC'''
* [https://etherpad.openstack.org/p/icehouse-cinder-continuous-volume-replication-v2 Updated volume mirroring design] - avishay
* Start using only Mock for new tests... [http://lists.openstack.org/pipermail/openstack-dev/2013-November/018501.html Related Nova Discussion] - Thingee
* Rate limiting came up in the summit, and [http://lists.openstack.org/pipermail/openstack-dev/2013-November/020291.html on openstack-dev] - avishay
* Metadata backup (https://review.openstack.org/#/c/51900/) progress RFC - dosaboy

'''November 20, 2013 16:00 UTC'''
* I-1 scheduling - JGriffith

'''November 13, 2013 16:00 UTC'''
* patches should update doc files where necessary to ease writing of release notes (Avishay?)
* fencing host from storage (Ehud Trainin)
* Summarize priority of tasks from summit discussions (https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads#Cinder and https://etherpad.openstack.org/p/cinder-icehouse-summary) Griff

'''October 30, 2013 16:00 UTC'''
* cinder backup metadata support - http://goo.gl/Jkg2FV (dosaboy)
* fencing and unfencing host from storage - https://blueprints.launchpad.net/cinder/+spec/fencing-and-unfencing (Ehud Trainin)

'''October 23, 2013 16:00 UTC'''
* Nexenta backup driver https://review.openstack.org/#/c/47005/ - DuncanT

'''October 2, 2013 16:00 UTC'''
* What's still broken in Havana
:* Backups and multibackend (https://code.launchpad.net/bugs/1228223): Fix committed
:* Configuration - Global CONF settings in brick don't belong, and a number of them break multi-backend (Bug #1230066): Fix committed
:* TaskFlow retry mechanism - The majority felt this should be left as a white list, but no work has been done to fix it so we still have ugly failures/roll-backs (3 bugs logged here): '''???'''
:* Quotas - Don't know that anybody has gotten to the bottom of the quota syncing issue (Bug #1202896): '''Still open'''
:* iSCSI Target creation failures - This was thought to have been fixed but showed up last night (Bug #1223469): Probable fix committed
:* Summary of gate issue pertaining to Cinder can be viewed here: http://paste.openstack.org/show/47798/
:* Moving to taskflow - avishay

'''Sept 25, 2013, 16:00 UTC'''
* PTL nomination process is open until the 26'th, if you want to run send your nomination proposal out to the dev ML
* What's broken in Havana
:* Backups (specifically when configured with multi-backend volumes)
:* Configuration - Global CONF settings in brick don't belong, and a number of them break multi-backend (Bug #1230066)
:* TaskFlow retry mechanism - The majority felt this should be left as a white list, but no work has been done to fix it so we still have ugly failures/roll-backs (3 bugs logged here)
:* Quotas - Don't know that anybody has gotten to the bottom of the quota syncing issue (Bug #1202896)
:* iSCSI Target creation failures - This was thought to have been fixed but showed up last night (Bug #1223469)
:* ????
* Cinderclient release plans/status? (Eharney)
* OSLO imports (DuncanT)
* bp/cinder-backup-improvements (dosaboy)
* bp/multi-attach (zhiyan)

'''Aug 21, 2013, 16:00 UTC'''
# No agenda, no meeting.

'''Aug 14, 2013, 16:00 UTC'''
# Volume migration status - avishay
# API extensions using metadata. This comes from the [https://review.openstack.org/#/c/38322/ readonly volume attach support]. - thingee
[http://eavesdrop.openstack.org/meetings/cinder/2013/cinder.2013-08-14-16.00.log.html IRC Log]

'''Aug 7, 2013, 16:00 UTC'''
# [https://bugs.launchpad.net/cinder/+bug/1209199 RFC - make all rbd clones copy-on-write] -- Dosaboy
# V1 API removal issues, plans and timescales - DuncanT

== Meeting Minutes ==

http://eavesdrop.openstack.org/meetings/cinder/2014/

http://eavesdrop.openstack.org/meetings/cinder/2013/

http://eavesdrop.openstack.org/meetings/cinder/2012/

CinderMeetings

2013-08-28T07:49:58Z

Huang Zhiteng: /* Next meeting */

CinderMeetings

2013-08-28T07:49:22Z

Huang Zhiteng: /* Next meeting */

CinderMeetings

2013-07-03T15:35:56Z

Huang Zhiteng:

CinderMeetings

2013-06-12T16:05:25Z

Huang Zhiteng:

Design Summit/Havana/Etherpads

2013-04-17T00:59:12Z

Huang Zhiteng:

(Please add links to the Havana Design Summit etherpad documents here)

=== Documentation ===

* Monday 2013-04-15 11:00 - [https://etherpad.openstack.org/restructure-docs-session Restructure documentation]
* Monday 2013-04-15 11:50 - [https://etherpad.openstack.org/openstack-ops-session Review Operations Manual and Plan Future Work]
* Monday 2013-04-15 13:50 - [https://etherpad.openstack.org/openstack-docs-translation Translation management enhancement]
* Monday 2013-04-15 14:40 - [https://etherpad.openstack.org/openstack-docs-new-projects Documentation for Newly Integrated Projects]

=== Heat ===

* [https://etherpad.openstack.org/heat-multiple-engines 9:50am How to run multiple heat-engines and scaling]
* [https://etherpad.openstack.org/heat-credentials-management 11:00am Heat credentials management/delegation]
* 11:50am Adding support for OASIS TOSCA to Heat
* 1:50pm Abstracting the AWS out of Heat
* [https://etherpad.openstack.org/heat-autoscaling 2:40pm Autoscaling API for Heat]
* 3:40pm Concurrent Resource Scheduling in Heat
* [https://etherpad.openstack.org/heat-rolling-updates 4:30pm Rolling Updates and Instance Specific Metadata]

=== Horizon ===

* [https://etherpad.openstack.org/HavanaHorizonTesting 11:00am Testing in Horizon]
* [https://etherpad.openstack.org/HorizonKeystoneV3 11:50am Keystone v3 and multi endpoint/region support]
* [https://etherpad.openstack.org/HavanaHorizonQuantum 1:50pm Quantum/Horizon integration]
* 2:40pm Heat GUI integration into Horizon
* [https://etherpad.openstack.org/havana-horizon-ceilometer 3:40pm Ceilometer/Horizon Integration]
* [https://etherpad.openstack.org/havana-horizon-realtime 4:30pm Are we ready for real-time data in Horizon?]
* 5:20pm BoF: Building on Horizon

=== Keystone ===
* [https://etherpad.openstack.org/havana-saml-oauth-scim SAML, OAuth 2, and SCIM]
* [https://etherpad.openstack.org/havana-external-auth Generic support for external authn/authz]
* [https://etherpad.openstack.org/havana-keystone-performance Scaling & Performance]
* [https://etherpad.openstack.org/havana-availability-zone-and-region-management Availability zone and region management]
* [https://etherpad.openstack.org/havana-key-manager Key Manager]
* [https://etherpad.openstack.org/havana-ldap-integration LDAP Integration]
* [https://etherpad.openstack.org/HavanaCentralizedQuotas Centralized Quotas]
* [https://etherpad.openstack.org/havana-endpoint-filtering Endpoint Filtering]
* [https://etherpad.openstack.org/havana-fine-grained-access-control Fine-grained access control]

=== Nova ===
* [https://etherpad.openstack.org/ZeroDowntimeUpgrades Zero down upgrades]
* [https://etherpad.openstack.org/HavanaContinuingRoadToLiveUpgrade The (continuing) road to live upgrade]
* [https://etherpad.openstack.org/HavanaVersionedInternalObjects Versioned internal objects]
* [https://etherpad.openstack.org/HavanaDatabaseRedux Database Status Redux]
* [https://etherpad.openstack.org/HavanaTripleO Openstack-on-Openstack]
* [https://etherpad.openstack.org/HavanaBaremetalNextSteps Baremetal Driver Next Steps]
* [https://etherpad.openstack.org/roadmap-for-ceph-integration-with-openstack Roadmap for Ceph integration with Openstack]
* [https://etherpad.openstack.org/NovaAPIExtensionFramework Nova API Extension framework]
* [https://etherpad.openstack.org/NovaV3APIHavana Nova v3 API]
* [https://etherpad.openstack.org/NovaApiValidationFramework Nova API Validation Framework]
* [https://etherpad.openstack.org/UnifiedResourcePlacement Unified Resource Placement Module]
* [https://etherpad.openstack.org/HavanaSchedulerFeatures Scheduler Features]
* [https://etherpad.openstack.org/HavanaMultiHypervisor Multi-hypervisor clouds]
* [https://etherpad.openstack.org/HavanaLongLivedPeriodicTasks Long lived periodic tasks]
* [https://etherpad.openstack.org/API_for_block_devices Richer and more flexible APIs for block devices]
* [https://etherpad.openstack.org/HavanaXenAPIRoadmap XenAPI driver roadmap]
* [https://etherpad.openstack.org/Havana_Nova_vSphere vSphere driver roadmap for Havana]
* [https://etherpad.openstack.org/HavanaUnifyMigrateAndLiveMigrate Host Maintenance]
* [https://etherpad.openstack.org/HavanaMothballServer Mothball Server]
* [https://etherpad.openstack.org/HavanaNovaWholeHostAllocation Whole Host Allocation]
* [https://etherpad.openstack.org/HavanaNovaExtendSchedulerResources Extended Scheduler Resources]
* [https://etherpad.openstack.org/HavanaNovaRackAwareScheduling Rack Aware Scheduling]
* [https://etherpad.openstack.org/HavanaNovaSchedulerHintsAPI Scheduler Hints API]
* [https://etherpad.openstack.org/group-scheduling Group Scheduling]
* [https://etherpad.openstack.org/the-future-of-orch The structured orchestration manifesto]
* [https://etherpad.openstack.org/HavanaNovaClient Nova Client]
* [https://etherpad.openstack.org/HavanaMultipleSchedulers Support for Multiple Schedulers]
* [https://etherpad.openstack.org/HavanaTopologyAwarePlacement Topology-aware scheduling (incl. across compute/storage/network)]
* [https://etherpad.openstack.org/Nova_Updates_for_Disk_Encryption Nova Updates for Disk Encryption]
* [https://etherpad.openstack.org/unified-notifications Unified Notifications (logging, etc)]
* [https://etherpad.openstack.org/HavanaCellsStatus Cells status]
* [https://etherpad.openstack.org/the-future-of-orch The structured orchestration manifesto]
=== Oslo ===

* [https://etherpad.openstack.org/havana-oslo Oslo Status and Plans]
* [https://etherpad.openstack.org/havana-common-wsgi Pecan/WSME Status]
* [https://etherpad.openstack.org/HavanaNoDowntimeDBMigrations No-downtime DB migrations]
* [https://etherpad.openstack.org/HavanaRootwrap Rootwrap improvements for the Havana cycle]
* [https://etherpad.openstack.org/havana-oslo-packaging-and-hacking Common packaging support and code analysis tools]
* [https://etherpad.openstack.org/havana-rpc-api-review RPC API review]
* [https://etherpad.openstack.org/havana-rpc-zmq-for-ceilometer-and-quantum ZeroMQ RPC for Ceilometer and Quantum]
* [https://etherpad.openstack.org/havana-rpc-access-control Message queue access control]
* [https://etherpad.openstack.org/havana-rpc-signing-and-encryption RPC Message Signing and Encryption]
* [https://etherpad.openstack.org/zipkin-tracing Zipkin tracing in OpenStack]
* [https://etherpad.openstack.org/havana-oslo-i18n-strategy i18n strategy for OpenStack services]
* [https://etherpad.openstack.org/havana-common-xenapi-library Common XenAPI libary]

=== Network (formerly "Quantum") ===
'''Monday'''
* [https://etherpad.openstack.org/NovaQuantumIntegration 11a Nova and Quantum ]
* [https://etherpad.openstack.org/havana-openstack-networking-api-update 11:50p Openstack networking API update]
* ([https://etherpad.openstack.org/havana-openstack-decoupling-authz Decouplling AuthZ logic (same session as networking API update)])
* [https://etherpad.openstack.org/havana-network-simpler 1:50p Making Quantum Simpler ]
* [https://etherpad.openstack.org/havana-networking-db-improvements 2:40pOpenstack networking DB improvements]
* [https://etherpad.openstack.org/havana-quantum-unittests 3:40p Reviewing Openstack Networking unit tests]
* [https://etherpad.openstack.org/network-proximity 4:30p Mini-Session Network Proximity]
* [https://etherpad.openstack.org/OpenStackNetworkingCLI 4:30p Mini-Session OpenStack Networking CLI]
* [https://etherpad.openstack.org/Quantum_Services'_Chaining_and_Insertion 5:20pm Services' Chaining & Insertion]
'''Tuesday'''
* 11:00a [https://etherpad.openstack.org/havana-quantum-lbaas LBaaS]
* 11:50a [https://etherpad.openstack.org/HavanaVPNaaS VPNaaS]
* [https://etherpad.openstack.org/quantum-qos-api 1:40p QoS API]
* 2:40p [https://etherpad.openstack.org/Quantum_Firewall_As_A_Service FWaaS]
* 3:40p [https://etherpad.openstack.org/HavanaBareMetalVLAN BareMetal VLAN]
* 4:30p [https://etherpad.openstack.org/quantum-sdn-controler-improvement SDN controller improvement]
* [https://etherpad.openstack.org/OVSPlugin_Support_for_Hardware_Devices 5:20pm OVSPlugin support for hardware devices]
'''Wednesday'''
* 11:00a Module L2 and L3
* 11:50a [https://etherpad.openstack.org/pni-vni-pluggable-quantum Network Pluggable Architecture (PNI, VNI & ENI)]
* 1:50p OpenStack Networking and Ceilometer
* 2:40p [https://etherpad.openstack.org/Quantum_Firewall_As_A_Service FWaaS]
* 3:40p Layer 3 Networks
* 4:30p Networking Mini Session
* 5:20p [https://etherpad.openstack.org/HavanaVPNaaS VPNaaS]

* [https://etherpad.openstack.org/HavanaHADHCP HA DHCP]

=== QA ===
'''Tuesday'''
* [https://etherpad.openstack.org/havana-tempest-scope Tempest Scope]
* [https://etherpad.openstack.org/havana-gating-strategies Strategies for Gating in a growing project]
* [https://etherpad.openstack.org/havana-multi-node multi-node openstack testing]
* [https://etherpad.openstack.org/havana-fits-testing FITS testing of public clouds]
* [https://etherpad.openstack.org/havana-gating-validation Gating/Validation of OpenStack Deployments]
* [https://etherpad.openstack.org/havana-upgrade-testing Upgrade testing and Grenade]
* [https://etherpad.openstack.org/havana-beyond-api Beyond the API - End to End Testing of OpenStack]

'''Wednesday'''
* [https://etherpad.openstack.org/havana-adding-integrated Adding new integrated projects to Tempest]
* [https://etherpad.openstack.org/havana-testr-feedback testr / testtools feedback/next-steps]
* [https://etherpad.openstack.org/havana-tempest-best-practice-guide Tempest Best Practice Guide]
* [https://etherpad.openstack.org/havan-rackspace-engine Rackspace testing engine Case Study/Overview]
* [https://etherpad.openstack.org/havana-gap-analysis Tempest - Gap Analysis - Identify new testsdevelop]

=== Swift ===
'''Monday'''

* [https://etherpad.openstack.org/swift-openstack-havana Swift and OpenStack what's next]
* [http://etherpad.openstack.org/HavanaSwiftBenchmarking Benchmarking Swift]
* [https://etherpad.openstack.org/swift_api Swift API Cleanup]
* [https://etherpad.openstack.org/Swift-LFS Swift Local Filesystem]
* [https://etherpad.openstack.org/faster_object_server Speeding Up the Object Server]
* [https://etherpad.openstack.org/Swift_workloads Swift Drive Workloads]

'''Tuesday (scheduled on-site for the unconference)'''
* [http://etherpad.openstack.org/Multi_namespaces Swift Multi Namespaces, Swift Multi - Tenants]
* [http://etherpad.openstack.org/Acls_metadata Extending Swift ACLs and Metadata]

=== Process / Infra ===
* Calling all Interns and Mentors: Ideas to improve
* Python3 in OpenStack
* [https://etherpad.openstack.org/havana-stable-branch Stable Branch]
* [http://etherpad.openstack.org/HavanaVulnerabilityManagement Vulnerability management: infra needs, scoring...]
* [http://etherpad.openstack.org/TCMembershipEvolution Technical Committee membership evolution]
* Continuous-deployment for upstream Openstack
* Dependency Management
* Sorting out test runners, wrappers and venvs B119
* Failure management in the gate
* Bare Metal Testing
* OpenStack CI logging
* [http://etherpad.openstack.org/NonInfraManagedTooling Review of non-infra-managed tooling]
* [http://etherpad.openstack.org/ProjectsReNaming Projects (re)naming]
* [http://etherpad.openstack.org/HavanaReleaseSchedule Havana release schedule]
* [http://etherpad.openstack.org/HavanaContinuousDeployment Continuous Deployment]

=== Ceilometer ===

'''Wednesday'''

* [https://etherpad.openstack.org/havana-ceilometer-architecture-overview Intro to Ceilometer Architecture]
* Feedback from ceilometer users

'''Thursday'''

* [https://etherpad.openstack.org/havana-ceilometer-incremental-grab-bag Incremental improvement grab-bag]
* Double Entry Auditing of collected metrics in CM
* API improvements for ceilometer
* [https://etherpad.openstack.org/havana-ceilometer-alarm-threshold-eval Alarm threshold evaluation]
* [https://etherpad.openstack.org/havana-ceilometer-time-series-nosql Time series data manipulation in nosql stores]
* Simple messaging action for Alerting
* [https://etherpad.openstack.org/havana-ceilometer-alarm-state-history Alarm state and history management]
* Ceilometer support for advanced billing models
* Supporting rich data types and aggregation

=== Glance ===

'''Wednesday April 17'''

* 11:00 [https://etherpad.openstack.org/havana-getting-glance-ready-for-public-clouds Getting glance ready for Public Clouds]
* 11:50 [https://etherpad.openstack.org/havana-image-interchange Image Interchange]
* 13:50 [https://etherpad.openstack.org/havana-image-cloning-to-other-regions Image Cloning to Other Regions]
* 14:40 [https://etherpad.openstack.org/havana-image-performance Image Performance]
* 15:40 [https://etherpad.openstack.org/havana-rolling-db-upgrades-in-glance Rolling DB upgrades in Glance]

=== Cinder ===

'''Wednesday'''
* [https://etherpad.openstack.org/Cinder-Havana-Refactor-Attach-Code Refactor Cinder Attach Code]
* [https://etherpad.openstack.org/havana-cinder-api2-a-new-hope API V2 a new hope for better validation]

'''Thursday'''
* [https://etherpad.openstack.org/summit-havana-cinder-multi-attach-and-ro-volumes Multi-Attach and Read Only Volumes]
* [https://etherpad.openstack.org/Summit-Havana-Cinder-Safe-Shutdown Safe Shutdown]
* [https://etherpad.openstack.org/Cinder_Update_for_Disk_Encryption Cinder Update for Disk Encryption]
* [https://etherpad.openstack.org/summit-havana-cinder-volume-types-and-capabilities Cinder Volume Types and Capabilities]
* [https://etherpad.openstack.org/havana-cinder-volume-migration Cinder Volume Migration]

=== Marconi ===

'''Monday'''
* 3:40pm [https://etherpad.openstack.org/havana-marconi-intro Project Overview and Feedback (Unconference)]

Cinder-multi-backend

2013-03-01T01:25:58Z

Huang Zhiteng: /* Configuration */

= Cinder multi backends =
This article is a explanation for creating an environment w/ multiple backends. Cinder volume backends are spawned as children to cinder-volume, and they are keyed from a unique Queue. They are named cinder-volume.HOST.BACKEND. Example cinder-volume.ubuntu.lvmdriver. The filter scheduler determines where to send the volume based on the volume type thats passed in.

== Configuration ==
The configuration now has a flag, enabled_backends. This defines the names of the option groups for the different backends. Each backend defined here has to link to a config group (example [lvmdriver]) in the configuration. A full example of this is included in the configuration with 2 backends. The options need to be defined in the group, or the defaults in the code will be used. Putting a config value in [DEFAULT] will not be used.

Example (cinder.conf)
<div style="margin-left: 2em;">
<source lang="ini">
# a list of backends that will be served by this machine
enabled_backends=lvmdriver-1,lvmdriver-2
[lvmdriver-1]
volume_group=stack-volumes-1
volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name=LVM_iSCSI
[lvmdriver-2]
volume_group=stack-volumes-2
volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name=LVM_iSCSI
</source>
</div>

The cinder filter_scheduler also needs to be used in order to achieve the goal that one can explicitly create volume on certain back-end using volume types. However filter scheduler is the default scheduler starting Grizzly.
<div style="margin-left: 2em;">
<source lang="ini">
scheduler_driver=cinder.scheduler.filter_scheduler.FilterScheduler
</source>
</div>

== Volume Type ==
The volume_type must be defined in the volume_type table in the database. When creating a volume for a particular backend (or group of > 1 backends) the volume_type is passed in. There can be > 1 backend per volume_type, and the capacity scheduler kicks in and keeps the backends of a particular volume_type even. In order to group a volume_type to a backend, you must define extra specs for the type.

Example
* cinder --os-username admin --os-tenant-name admin type-create lvm
* cinder --os-username admin --os-tenant-name admin type-key lvm set volume_backend_name=LVM_iSCSI
* cinder --os-username admin --os-tenant-name admin extra-specs-list (just to check the settings are there)

== Usage ==
When creating a volume, specify the volume_type that you created in the above example. This will be used in determining which type of backend to send to. As previously stated, if there is > 1 backend for a type, the capacity scheduler is used.

* cinder create --volume_type lvm --display_name my-test 1

If the volume type is defined in the database but no volume types exist for that backend in the configuration, then no valid host will be found. If both are true, it will prov to one of the volume backends.

Cinder-multi-backend

2013-03-01T01:25:41Z

Huang Zhiteng: /* Configuration */

Cinder-multi-backend

2013-03-01T01:24:56Z

Huang Zhiteng: /* Configuration */

= Cinder multi backends =
This article is a explanation for creating an environment w/ multiple backends. Cinder volume backends are spawned as children to cinder-volume, and they are keyed from a unique Queue. They are named cinder-volume.HOST.BACKEND. Example cinder-volume.ubuntu.lvmdriver. The filter scheduler determines where to send the volume based on the volume type thats passed in.

== Configuration ==
The configuration now has a flag, enabled_backends. This defines the names of the option groups for the different backends. Each backend defined here has to link to a config group (example [lvmdriver]) in the configuration. A full example of this is included in the configuration with 2 backends. The options need to be defined in the group, or the defaults in the code will be used. Putting a config value in [DEFAULT] will not be used.

Example (cinder.conf)
<div style="margin-left: 2em;">
<source lang="ini">
# a list of backends that will be served by this machine
enabled_backends=lvmdriver-1,lvmdriver-2
[lvmdriver-1]
volume_group=stack-volumes-1
volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name=LVM_iSCSI
[lvmdriver-2]
volume_group=stack-volumes-2
volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name=LVM_iSCSI
</source>
</div>

<div style="margin-left: 2em;">
<source lang="ini">
# The cinder filter_scheduler also needs to be used in order to achieve the goal that one
# can explicitly create volume on certain back-end using volume types. However filter
# scheduler is the default scheduler starting Grizzly.
scheduler_driver=cinder.scheduler.filter_scheduler.FilterScheduler
</source>
</div>

== Volume Type ==
The volume_type must be defined in the volume_type table in the database. When creating a volume for a particular backend (or group of > 1 backends) the volume_type is passed in. There can be > 1 backend per volume_type, and the capacity scheduler kicks in and keeps the backends of a particular volume_type even. In order to group a volume_type to a backend, you must define extra specs for the type.

Example
* cinder --os-username admin --os-tenant-name admin type-create lvm
* cinder --os-username admin --os-tenant-name admin type-key lvm set volume_backend_name=LVM_iSCSI
* cinder --os-username admin --os-tenant-name admin extra-specs-list (just to check the settings are there)

== Usage ==
When creating a volume, specify the volume_type that you created in the above example. This will be used in determining which type of backend to send to. As previously stated, if there is > 1 backend for a type, the capacity scheduler is used.

* cinder create --volume_type lvm --display_name my-test 1

If the volume type is defined in the database but no volume types exist for that backend in the configuration, then no valid host will be found. If both are true, it will prov to one of the volume backends.

Cinder-multi-backend

2013-03-01T01:24:02Z

Huang Zhiteng: /* Configuration */

= Cinder multi backends =
This article is a explanation for creating an environment w/ multiple backends. Cinder volume backends are spawned as children to cinder-volume, and they are keyed from a unique Queue. They are named cinder-volume.HOST.BACKEND. Example cinder-volume.ubuntu.lvmdriver. The filter scheduler determines where to send the volume based on the volume type thats passed in.

== Configuration ==
The configuration now has a flag, enabled_backends. This defines the names of the option groups for the different backends. Each backend defined here has to link to a config group (example [lvmdriver]) in the configuration. A full example of this is included in the configuration with 2 backends. The options need to be defined in the group, or the defaults in the code will be used. Putting a config value in [DEFAULT] will not be used.

Example (cinder.conf)
<div style="margin-left: 2em;">
<source lang="ini">
# a list of backends that will be served by this machine
enabled_backends=lvmdriver-1,lvmdriver-2
[lvmdriver-1]
volume_group=stack-volumes-1
volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name=LVM_iSCSI
[lvmdriver-2]
volume_group=stack-volumes-2
volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name=LVM_iSCSI
</source>
</div>

#The cinder filter_scheduler also needs to be used in order to achieve the goal that one
#can explicitly create volume on certain back-end using volume types. However filter
#scheduler is the default scheduler starting Grizzly.
<div style="margin-left: 2em;">
<source lang="ini">
scheduler_driver=cinder.scheduler.filter_scheduler.FilterScheduler
</source>
</div>

== Volume Type ==
The volume_type must be defined in the volume_type table in the database. When creating a volume for a particular backend (or group of > 1 backends) the volume_type is passed in. There can be > 1 backend per volume_type, and the capacity scheduler kicks in and keeps the backends of a particular volume_type even. In order to group a volume_type to a backend, you must define extra specs for the type.

Example
* cinder --os-username admin --os-tenant-name admin type-create lvm
* cinder --os-username admin --os-tenant-name admin type-key lvm set volume_backend_name=LVM_iSCSI
* cinder --os-username admin --os-tenant-name admin extra-specs-list (just to check the settings are there)

== Usage ==
When creating a volume, specify the volume_type that you created in the above example. This will be used in determining which type of backend to send to. As previously stated, if there is > 1 backend for a type, the capacity scheduler is used.

* cinder create --volume_type lvm --display_name my-test 1

If the volume type is defined in the database but no volume types exist for that backend in the configuration, then no valid host will be found. If both are true, it will prov to one of the volume backends.

Cinder-multi-backend

2013-03-01T01:22:50Z

Huang Zhiteng: /* Configuration */

= Cinder multi backends =
This article is a explanation for creating an environment w/ multiple backends. Cinder volume backends are spawned as children to cinder-volume, and they are keyed from a unique Queue. They are named cinder-volume.HOST.BACKEND. Example cinder-volume.ubuntu.lvmdriver. The filter scheduler determines where to send the volume based on the volume type thats passed in.

== Configuration ==
The configuration now has a flag, enabled_backends. This defines the names of the option groups for the different backends. Each backend defined here has to link to a config group (example [lvmdriver]) in the configuration. A full example of this is included in the configuration with 2 backends. The options need to be defined in the group, or the defaults in the code will be used. Putting a config value in [DEFAULT] will not be used.

Example (cinder.conf)
<div style="margin-left: 2em;">
<source lang="ini">
# a list of backends that will be served by this machine
enabled_backends=lvmdriver-1,lvmdriver-2
[lvmdriver-1]
volume_group=stack-volumes-1
volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name=LVM_iSCSI
[lvmdriver-2]
volume_group=stack-volumes-2
volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name=LVM_iSCSI
</source>
</div>

#The cinder filter_scheduler also needs to be used in order to achieve the goal that one
#can explicitly create volume on certain back-end using volume types. However filter scheduler is the default scheduler starting Grizzly.
<div style="margin-left: 2em;">
<source lang="ini">
scheduler_driver=cinder.scheduler.filter_scheduler.[[FilterScheduler]]
</source>
</div>

== Volume Type ==
The volume_type must be defined in the volume_type table in the database. When creating a volume for a particular backend (or group of > 1 backends) the volume_type is passed in. There can be > 1 backend per volume_type, and the capacity scheduler kicks in and keeps the backends of a particular volume_type even. In order to group a volume_type to a backend, you must define extra specs for the type.

Example
* cinder --os-username admin --os-tenant-name admin type-create lvm
* cinder --os-username admin --os-tenant-name admin type-key lvm set volume_backend_name=LVM_iSCSI
* cinder --os-username admin --os-tenant-name admin extra-specs-list (just to check the settings are there)

== Usage ==
When creating a volume, specify the volume_type that you created in the above example. This will be used in determining which type of backend to send to. As previously stated, if there is > 1 backend for a type, the capacity scheduler is used.

* cinder create --volume_type lvm --display_name my-test 1

If the volume type is defined in the database but no volume types exist for that backend in the configuration, then no valid host will be found. If both are true, it will prov to one of the volume backends.