Much of the explanation below would be very helpful to have in the README.rdoc of the
image-management-engine project. What is there now tells a visitor nothing about what that
code is (or intended to be).
-steve
On Jun 7, 2012, at 1:29 PM, Jason Guiditta wrote:
On 07/06/12 17:49 +0100, Mark McLoughlin wrote:
> On Wed, 2012-06-06 at 11:47 -0400, Jason Guiditta wrote:
>> We also have in the incubator[1] the new rails engine that acts as a
>> reusable client for factory
>
>> [1]
https://github.com/aeolus-incubator/image-management-engine
>
> Am I roughly correct in saying that this is?
>
> - An image registry API which exposes the mapping of an image
> identifier to cloud provider specific images, perhaps also tracking
> multiple versions/builds of an image
>
Yes, that seems like a fair initial description to me, though
'registry' makes it sound like more that it really is (maybe the term
just throws me off).
> Your "client for factory" description makes it sound like you can submit
> a build request through image-management-service, but I don't see that
> in the code?
It may well not yet be in the code, I forget how much of the
imlpementation is actually complete at this point, but when done, yes,
you will build and push with the client, which will in turn be used by
conductor (This is all via the new v2 REST api that is under
development by the factory folks, so you will create a certain type
of object to initiate a build, etc). To explain a bit more, this was
part of the reason we decided to go the rails engine route - it is a
mountable component that can either be run on its own, or built
around/layered on top of/extended. Our fist user is expected to be
conductor, but we hope katello will find it useful at some point as
well as anyone else who wants to manage virtual images across clouds.
>
> Whatever ... this kind of effort is exactly the way to be moving
> forward. Kudos to you and Martyn.
>
Thanks!
> One suggestion I'd make for this would be to concentrate 100% on a nice
> API and CLI for it. Make it easy to integrate with it. Make it so you
> can go and promote this and image factory together completely
> independent of conductor and all the rest.
>
I am 100% in agreement here, and we are in fact focusing on those two
things pretty much exclusively. The cli part is/was likely to start
in the existing aeolus-cli repo, but if we want to keep it more
standalone, perhaps we would be better served repurposing the existing
aeolus-image gem for this, and merely requiring it in aeolus-cli. The
whole cli structure is pretty much designed to handle this anyway, we
just need to make sure we actually do it.
-j