Image Management Engine

Martyn Taylor mtaylor at redhat.com
Thu Apr 12 07:47:46 UTC 2012


On 04/11/2012 04:31 PM, Jan Provazník wrote:
> On 04/11/2012 04:17 PM, Scott Seago wrote:
>> 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.
Yes, it will have the same order of time as the UI though might be 
slightly faster since there will likely be less data and db lookups (for 
the extra data the UI needs).  This will be significantly faster than 
warehouse since we will need no remote calls at all for listing or 
showing images objects.
>>> 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
Yes this is pretty much the case.  There will be some meta data stored 
in factory, but we will likely replicate this in conductor for 
performance reasons.  We can safely do this since image objects in 
factory are immutable once they are completed.
>>
>
> This reminds me that template storage format could be updated - now 
> template is saved as XML file and some important info which is 
> displayed in UI is saved only inside this XML (OS, architecture, name) 
> this implies parsing of all template XML files when getting list of 
> templates or doing a search and could be slow. It would be nice to 
> store frequently used template properties in model attributes.
Yes, this is a good approach, I don't know why we didn't do this 
before.  The image factory engine will be responsible for managing 
templates.  We can parse the file and store all* the attributes in the 
template in the AR model.  We do still need to have the XML document 
lying around since we need it for doing new builds of the image etc...  
But that is probably best served as a file pointer rather than reading 
the content into a field (which is I I think what happens atm).
>
>> Scott
>>
>>
>




More information about the aeolus-devel mailing list