What problem is this trying to solve?: There is a longterm issue with token expiration during image upload. It irritates users, reduces functionality and leads to differen bugs, including security. Trusts mechanism will allow us to eliminate it for good. Discussion: We should discuss the implementation of trusts in Glance.
Moderator: Mike Fedosin (mfedosin) Etherpad: https://etherpad.openstack.org/p/mitaka-glance-trusts
Wednesday October 28, 2015 2:00pm - 2:40pm JST
Ho-O Room
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
Thursday October 29, 2015 9:00am - 9:40am JST
Amethyst room
What problem is this trying to solve?: The initial implementation of glance image signature verification landed in Liberty, but there are improvements that should be made in Mitaka. Discussion: https://etherpad.openstack.org/p/mitaka-glance-image-signing-and-encryption
Thursday October 29, 2015 9:50am - 10:30am JST
Jako room
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.
We have a experimental API for artifacts now. We should now consider all the constraints as well as requirements from users, operators, other projects and WGs to ensure the new upcoming API is ready and steady for launch.
Discussion: We should discuss the API details, tradeoffs for interop, scalability, usability etc. Consider the requirements from other teams' requirements and adopt the API accordingly.
