2:00pm

Moderator: John Griffith Every company these days wants to provide a SDS with plugins, sure sounds a lot like Cinder! The complaint is that Cinder doesn't offer enough and doesn't work outside of OpenStack, maybe we can/should change that?

2:50pm

Moderators: Michal Dulko, Duncan Thomas Change of behavior in Nova (started passing AZ when creating a volume) uncovered misunderstaning in the community about how Cinder should treat AZs. We should ask operators how they see AZs and how we can improve them in Cinder to make their life easier.

9:00am

What problem is this trying to solve?: Way back in Havana, Glance introduced "property protections". This feature was requested by deployers, who wanted the ability to put licensing information on images (which would be put onto instances) and have this info also be propagated to snapshots by Nova, so that instances created from snapshots would also receive this information. To make this work for licensing/billing info, of course, the image owner must not be able to modify such properties. The solution in Glance allows control over properties to be expressed in the policy.json file, and allows the properties that are protected to specified by regex. Thus it is extremely configurable, which is both a blessing and a curse. We left it up to deployers to communicate to their end-users how property protections work in their cloud. However, other OpenStack projects that create images (e.g., Nova, Cinder) currently require some crazy configuration/deployment gyrations to respect property protecions. Additionally, projects that allow image property creation/updates (e.g., Horizon) would like better knowledge of what the protections are in order to provide a good user experience. And it also affects projects that read image records (e.g., Searchlight) because whether an end-user should see a property or not depends on how the property is protected. There's a spec up in Nova [0] that proposes to fix this for Nova by introducing a new configuration option, "inheritable_admin_image_properties", that would specify a list of image properties for which Nova would use admin credentials to put on an image. What I'd like to do in this session is to find out from some other projects how they interact with Glance with respect to property protections and how we can improve this process. For example, though the fix mentioned above would work for Nova, it would be nice if we could figure out a secure way to update "admin-only" properties in specific contexts without requiring use of admin credentials. Additionally, maybe we can leverage metadefs to get the info about property protections out to Horizon and Searchlight. Even if we can't solve this in code during Mitaka, it would be worth gathering some best practices to communicate to deployers. [0] https://review.openstack.org/#/c/206431/ Discussion: https://etherpad.openstack.org/p/mitaka-glance-xp-property-protections-support

9:00am

OpenStack already has a variety of storage capabilities offered through Cinder, and Manila. In the Mitaka release, we plan to embark on an adventure to add new storage integration features into Magnum to allow these resources to be utilized from your containerized applications. Come to this session to affirm our current priorities for adding storage features. For example, we would like to add support for cinder volumes with filesystems automatically created by Heat/Magnum that are added to the host, and shared with the container by using "-e" hints in Docker that can be used in combination with "-v" flags with Docker to conenct a new/existing volume to a particular container. We would also like to leverage Manila to expose a given filesystem to multiple containers so they can have a consistent filesystem view across multiple containers on multiple hosts.

1:50pm

A couple of topics I see as related... * Defining/documenting the driver API * Possible changes to driver API to pull DB access out of drivers * Whether we can enable integration of drivers with non-Cinder services

2:40pm

We need to nail down the requirements for a public-facing image import mechanism that will satisfy DefCore as well as the concerns of large public clouds and small private clouds and small public clouds and large private clouds. OK, so a brief summary of this is that the current upload mechanism works fine for some folks but not others. DefCore wants us to have a single upload mechanism for everyone to use. That's what we want to nail down the requirements on. The current upload mechanism will continue to exist but won't be a DefCore requirement.

3:30pm

Topic: C-vol active/active Moderator: Michal Dulko, Gorgka Eguileor, Walter Boring Follow up from the last summit. We haven't actually managed to complete that due to multiple reasons and if we want to achive that we need to revisit the topic.

4:30pm

Topic: ABC Work Moderator: John Griffith Clean up the base driver such that it's readable, more self explanatory and easier for new drivers to use as a template/reference * Option 1 - Refactor the way we use ABC's and refactor the base driver to make it less of a mess * Option 2 - Refactor base driver and utilize Zope interfaces for impl enforcement