Image Management Engine

Scott Seago sseago at redhat.com
Wed Apr 11 14:17:53 UTC 2012


On 04/10/2012 06:41 PM, Richard Su wrote:
> 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?
>
Actually that's the main point behind this whole effort. Image Warehouse 
is going away and its functions are being provided by Factory and 
Conductor. Factory will be managing the actual bits on disk -- for 
pretty much everything that Conductor needs, we're managing it directly 
as a Conductor AR model.
> 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?
>
It definitely needs to be in the API -- but remember the Conductor UI 
will be interacting with this as regular AR objects, so it will be as 
fast (or as slow) as accesing provider, pool, instance, etc. data.
> For (2), how is the template stored? Is it still in the warehouse?
>
Everything that's currently in IWHD (except for binary image bits) will 
be in Conductor as Activerecord data (via this image management engine) 
-- so presumably you'd get the template in a controller/UI view by 
something as simple is calling image.template.xml

Scott


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20120411/4d87367e/attachment.html>


More information about the aeolus-devel mailing list