Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.

Sign up or log in to bookmark your favorites and sync them to your phone or calendar.

Cinder [clear filter]
Thursday, November 7


Read-only API role
Admin-only requirements in code and policy end up conflicting so that you can't have a pure read-only role that can list all volumes/snapshots/etc. This means that a logging / diagnositics / dashboard tool needs full admin creds, which are dangerous if leaked.

Can we fix this?

(Session proposed by Duncan Thomas)

Thursday November 7, 2013 9:00am - 9:40am
AWE Level 2, Room 201B


Changing the wheels on a moving bus
Various people are deploying from trunk, and rolling upgrades are useful even if you only deploying stable releases.

The aim of this session is to collect data on what different people are doing, what the pain points are, what the policy on stability in trunk ought to be, and similar.

(Session proposed by Duncan Thomas)

Thursday November 7, 2013 9:50am - 10:30am
AWE Level 2, Room 201B


incremental backup API
currently, cinder backup API only support full volume backup, not support incremental volume backup.

When system running all the time, customer need to take snapshots for their volumes, it's better to backups incremental data changed between previous snapshot and current volume, than to backup the whole volume every time.
So, it's useful to support incremental volume backup to swift. when customer restor volume from snapshot, he can choose which incremental data and base volume image to use to restor that volume.

(Session proposed by David Wang)

Thursday November 7, 2013 1:50pm - 2:30pm
AWE Level 2, Room 201B


Volume continuous replication
Add the capability for volumes whose data is continuously replicated (i.e., mirrored). This serves as a basis for improved resiliency, HA, and DR.

Session led together with Eric Harney.


(Session proposed by Avishay Traeger)

Thursday November 7, 2013 2:40pm - 3:20pm
AWE Level 2, Room 201B


More flexible scheduler policies
Currently the scheduler filters in Cinder works in strict manner, which means once a back-end failed to pass any one of the filters, this back-ends looses its chance of being chosen. It'd be useful if we can extend filter scheduler to support 'optional' or 'non-mandatory' filters. Back-ends are not immediately ruled out if they failed to pass optional/non-mandatory filters, instead, they will be considered as sub-optimal candidates and will only be chosen if no optimal back-ends can be found.

Meanwhile, the only weigher we have in Cinder is capacity weigher, which sorts back-ends by free space. This weigher is less useful than it sounds due to that fact that a lot of back-ends may report 'infinite' free space. So it's time to introduce new weighers that utilize more practical metrics as input, for example, allocated volumes, active volumes, active capacity. Since not all the metrics are available on all back-ends, a discussion is worthwhile to clarify the definitions and scope of these new metrics.

(Session proposed by Huang Zhiteng)

Thursday November 7, 2013 3:30pm - 4:10pm
AWE Level 2, Room 201B
Friday, November 8


What's next for taskflow in cinder
I would like to discuss with the cinder folks the initial work done in cinder with regards to taskflow and get some of there initial feedback as well as explore and discuss future work (and features) that can be done with the integration with cinder & taskflow.

(Session proposed by Joshua Harlow)

Friday November 8, 2013 11:00am - 11:40am
AWE Level 2, Room 203


Exception clarity and how rescheduling affects u!
While integrating taskflow with cinder there was a need to maintain backwards compataiblity with the exception model that existed for rescheduling in cinder. Now that the code has been shifted into an area where it is easily identifable what will and will not cause an exception we should start to think about other ways of how to deal with exceptions in cinder.

It would be nice to discuss the exception model and possibly discuss how we can make the exception model easier to use and more resilent to badly behaving drivers.

(Session proposed by Joshua Harlow)

Friday November 8, 2013 11:50am - 12:30pm
AWE Level 2, Room 203


Vendor neutral extra_specs
In the last we've failed to agree on some extra_specs that work for ALL storage vendors. I'd like to propose some ideas that I think could be implemented universally, and I'd like to avoid ratholes this time around.

(Session proposed by Ben Swartzlander)

Friday November 8, 2013 1:30pm - 2:10pm
AWE Level 2, Room 203


Access Control List Rule for Cinder Volumes
ACL implementation is a mechanism of permission management.
Currently only one type of permission is available: full access for the owner, no access for other users or tenants.

Purpose of ACL: make different volume access permissions possible.

Why useful?
1) Granting different access permissions to volumes, which can establish a foundation for volume transfer, read-only volumes (more flexible, than implemented in havana), public volumes, etc.
2) The owner of the volume and the administrators always have the full access and can assign the permission to other users or group of users.

Some use cases
1) as a foundation for read-only volumes (with flexible configuration, currently only 2 options are available: R/O for everyone or R/W for everyone)

Owner or Admin would be able to grant R/O access for the another user (or for users in a user group, or for a tenant, or everyone).

2) as a foundation for public(i.e. cross-tenant visible) volumes (currently Volume is visible for all the users from the only tenant)

Owner or Admin, or someone with the sufficient access level would be able to make a volume visible for all the tenants just by setting some access permission for "everyone" project.

Proposal to discuss
1) Remaking havana's ACL design to embrace foundations for read only and public volumes
2) Changing a representation of permission levels (in order to easy an aggregation of some access permissions in case if User in some groups with different access permissions e.g.)

(Session proposed by Anastasia Guzikova)

Friday November 8, 2013 2:20pm - 3:00pm
AWE Level 2, Room 203


common block storage library (brick) take 2
Modified version of Walt's proposal to talk more specifically about the implementation strategy/goals and the challenges involved.

We had some good ideas/goals for a project-shared storage library during the Havana summit. We sort of lost some focus and didn't make the progress here that we could have. This session is intended to hash out some of the ideas around how to implement the scheduling ideas, how to create a sort of "mini" driver via the brick library etc.

Session is a combination of Walter Boring's proposal to discuss library deployment and John Griffith's proposal to dig deeper into implementation strategies.

(Session proposed by Walt)

Friday November 8, 2013 3:10pm - 3:50pm
AWE Level 2, Room 203


Volume Import
IBM have some internal implementation of Volume Import that we would like to push back to the community. However, there are some interesting issues around volume import that I think warrant discussion:

1. Some Cinder drivers rely on the name of the volume matching the OpenStack-internal 'name'. This means that a driver either has to rename the volume on import, or support a decoupling between the openstack-internal name and the backend volume name. We have prototyped the Storwize driver using the admin_metadata added for read-only volumes to do this decoupling.

2. Volume Types are used to guide the creation of the backend volumes. If a volume import operation were allowed to specify a volume type, should the drivers be checking that the backend volume is in some way "compliant" with the volume type? Any such check would likely be unreliable, since there may be more features on the backend storage provider than the driver supports, and the driver can't check that it doesn't know about.

3. Our implemented also added an API extension that could retrieve a list of backend volumes that were eligible for import. Is this considered a core feature, or something that could be optional?

(Session proposed by Geraint North)

Friday November 8, 2013 4:10pm - 4:50pm
AWE Level 2, Room 203


Richer API rate limits in cinder
Currently, the only API rate limits in cinder are via the paste pipeline. This is limiting since you don't have (easy) access to the details of the call, nor the existing state of the system.

We propose adding a new pluging that gets called at the start of any API call that can implement richer ratelimits. An example of a rich rate limit is you can only create 10Tb of volumes a day. This is different to the existing quota mechanism, and is required to remove some DoS attacks on certain backend concepts.

(Session proposed by Duncan Thomas)

Friday November 8, 2013 5:00pm - 5:40pm
AWE Level 2, Room 203