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
