Image Management Engine

Richard Su rwsu at redhat.com
Tue Apr 10 22:41:08 UTC 2012


On 04/10/2012 06:24 AM, Martyn Taylor wrote:
> In the next iteration Image Factory aim to make significant 
> improvements and changes to its underlying model and its API. These 
> changes will remove any conductor specific content from image factory 
> altogether.
>
> You can find information on this here:
>
> https://www.aeolusproject.org/redmine/projects/image-factory/wiki/V2_REST_API
>
> and here:
>
> https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Imagefactory_API__Conductor_Work
>
> In order to allow conductor API work and new imagefactory API 
> integration to work in parallel we will be implementing the image 
> management functionality as a rails engine. Information on rails 
> engines can be found here:
>
> http://guides.rubyonrails.org/engines.html
>
> This brings the project a host of benefits such as the ability to use 
> this as a standalone rails application offering a UI for managing 
> Image Factory directly and also to allow other rails applications to 
> easily integrate with image factory.
>
> The engine is similar to a rails application which supplies all the 
> controllers, views, routes and generators for creating image factory 
> models. A prototype can be found here:
>
> git at github.com 
> <mailto:git at github.com>:aeolus-incubator/image-management-engine.git
>
> In the prototype are generators for creating the image management 
> models, controllers and views for managing CRUD operations on the 
> models and also the routes. Under the test folder is a dummy app that 
> shows how this engine could be integrated with conductor. Showing a 
> simple example on how to extend the engine models.
>
> Cheers
>
> Martyn
>

Hi Martyn,

Can you clarify where Image Warehouse fits in this picture? It looks 
like with these changes Conductor wouldn't need to talk to warehouse at 
all. Is part of the plan to decouple Conductor from the warehouse?

The two main points in the Conductor to warehouse communications where 
performance degrades significantly is (1) finding the last build time 
and (2) finding the metadata associated with the image (architecture, 
os, etc..).

For (1), can the last build time be determined through this api?

For (2), how is the template stored? Is it still in the warehouse?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20120410/7e6d7b0f/attachment.html>


More information about the aeolus-devel mailing list