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