In order to lock down components, it has been proposed that we offer an API on
top of conductor that exposes image management functionality (pretty much what
is currently offered by aeolus-image command line). This would mean that any
client wanting to manipulate objects would talk directly with conductor and go
through conductor authentication etc... This gives a central point of contact
for image related tasks via the conductor API and also hides the bits and
pieces going on in the background, i.e. iwhd and imagefactory, that really a
user is not concerned about.
To recap the state of aeolus-image:
At the moment the rubygem aeolus-image that is used by conductor serves 2
purposes: firstly, it acts as a client lib to iwhd (which conductor uses in the
new catalogue functionality); secondly it holds all the logic for the CLI.
So as it stands, we need to:
1) Rip out the object model (iwhd client part) of aeolus-image and place it in
a new rubygem; this will serve solely as a client lib rubygem for iwhd and
imagefactory called "aeolus-image-resource" (or another better name)
2) Add imagefactory interaction to the iwhd/imagefactory client lib rubygem -
aeolus-image-resource.
This will interface with the new ImageFactory REST API, and will be used
to create builds and push images etc... using the same object model that is
currently in place inside aeolus-image, which is used for interfacing with
iwhd. This will also replace code that talks to the imagefactorys qmf interface
which is in the aeolus-image CLI code.
3) Add to the current REST API in conductor, to add in the extra resources we
need:
images
builds
target_images
provider_images
This probably just consists of wrapping the aeolus-image-resource calls in
the relevant controllers.
4) Update the aeolus-image command libraries to talk directly to conductor API,
hopefully using ActiceResource.
5) Add certificate authentication to aeolus-image.
6) Add aeolus-image configuration in conductor, rather than in ~/.aeolus-image,
(we probably want to use configure to set this up)
_______________________________________________
deltacloud-devel mailing list
[email protected]
https://fedorahosted.org/mailman/listinfo/deltacloud-devel
