Aeolus Community Assessment

Steve Loranz sloranz at redhat.com
Thu Jun 7 18:45:51 UTC 2012


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




More information about the aeolus-devel mailing list