<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>