Open Stack

On 20/04/16 11:39 +0100, stuart.mclaren at hp.com wrote:
>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.

I'd say the required knowledge of Glance internals should be taken to the
minimum.

>2. The plugin should be as insulated as possible from future changes in
>Glance's internals.

Since it allows for external plugins to be written, I'd agree that the public
API should respect all the backwards compatibility policies. Exposing just
what's really necessary would be better.

>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).

++

I'd like to note, though, that these races exist not because of the way the task
plugins were create but because the domain model allows for it. To be more
precise, these races exist in Glance too and not only in the tasks.

>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.

Just to build up on your example. It's very likely that consumers of this
interface will need to have information about the image's metadata as well.

Thanks for starting this thread,
Flavio

>(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
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160420/8c243454/attachment.pgp>