Open Stack

Hi,

As part of Glance's image import [1] work we need to define how operators
can run site specific code as part of the import process. For example
an operator may want to perform some site-specific validation on the
image bits.

Note that I'm not so much interested in what we use to do this (ie
we don't need to discuss the merits of taskflow/stevedore). Rather I'm
just interested in what level of abstraction we should provide.

Currently, the closest thing we have to a plugin [2] provides no
abstraction at all. You need to understand the Glance internals to use
it, and are not insulated from any future changes in Glance's internals.
You can do things like update the image state directly (possibly in a racy
or invalid way, leading to a poor experience for users) in your plugin.

To what degree are the following true?

1. An operator should not have to become intimitely familiar with
internal Glance code in order to write a plugin.
2. The plugin should be as insulated as possible from future changes in
Glance's internals.
3. The plugin should have very limited access to what it can touch. It
should not be possible for plugins to cause race conditions by
setting the image state for example. (This is related to 1 and 2).
4. The interface should just require instantiating a class.  We shouldn't
require plugin writers to know implementation details eg how glance logs
(instead, provide a log method), or whether or not we use taskflow.

To give an example of an interface of this kind, we could just provide
an image data iterator to the plugin class. Obviously this is a really
incomplete example, but gives an idea of a simple interface which would
allow a plugin to read the image data and perform validation without
knowing/being exposed to Glance's internals.

(Note: I'd like to keep the scope of this thread to what kind of
interface/contract a plugin should have, not what we use to implement
it, whether we should be doing this at all etc)

Thanks,

-Stuart

[1] https://review.openstack.org/#/c/232371
[2] https://review.openstack.org/#/c/214810/26/glance/async/flows/ovf_process.py