<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 04/10/2012 06:24 AM, Martyn Taylor wrote:
<blockquote cite="mid:4F843495.9030509@redhat.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
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.
<p style="margin-bottom: 0in;">You can find information on this
here:<br>
</p>
<p style="margin-bottom: 0in;"><a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://www.aeolusproject.org/redmine/projects/image-factory/wiki/V2_REST_API">https://www.aeolusproject.org/redmine/projects/image-factory/wiki/V2_REST_API</a><br>
</p>
<p style="margin-bottom: 0in">and here:<br>
</p>
<p style="margin-bottom: 0in"><a moz-do-not-send="true"
href="https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Imagefactory_API__Conductor_Work">https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Imagefactory_API__Conductor_Work</a></p>
<p style="margin-bottom: 0in">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: </p>
<p style="margin-bottom: 0in"><a moz-do-not-send="true"
href="http://guides.rubyonrails.org/engines.html">http://guides.rubyonrails.org/engines.html</a></p>
<p style="margin-bottom: 0in">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.</p>
<p style="margin-bottom: 0in">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:</p>
<p style="margin-bottom: 0in"><a moz-do-not-send="true"
href="mailto:git@github.com">git@github.com</a>:aeolus-incubator/image-management-engine.git</p>
<p style="margin-bottom: 0in;">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.<br>
</p>
<p style="margin-bottom: 0in;">Cheers<br>
</p>
<p style="margin-bottom: 0in">Martyn<br>
</p>
<title></title>
<meta name="GENERATOR" content="LibreOffice 3.3 (Unix)">
<style type="text/css">
        <!--
                @page { margin: 0.79in }
                P { margin-bottom: 0.08in }
                A:link { so-language: zxx }
        -->
        </style> </blockquote>
<br>
Hi Martyn,<br>
<br>
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?<br>
<br>
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..). <br>
<br>
For (1), can the last build time be determined through this api?<br>
<br>
For (2), how is the template stored? Is it still in the warehouse? <br>
<br>
<br>
</body>
</html>