It must be easier to add VIF driver support for all the various Neutron subsystems. OS VIF library tries to tackle this issue, starting with a focus on the libvirt driver.
PCI passthrough support, and SR-IOV, has been in Nova for some time now, and has not been without it's issues during that time. Despite it's issues, it has been a feature that has seen a lot of interest.
We want to go out of a session with the Nova community having a better understanding of where the issues and limitations currently are, and what features we see being requested in the short to medium term, including pass through of PFs, not just VFs.
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
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 need more consistency around our error handling. Lets agree on some patterns we want to adopt more widely. And lets assign work, so we can make progress in Mitaka.
We need to review the list of priorities for Mitaka, and see what needs to be done on Friday to confirm that list. We will also review the process used during Liberty to give those priority.
