On 20/04/16 11:39 +0100, stuart.mcla...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-- @flaper87 Flavio Percoco
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev