On Thu, Aug 18, 2011 at 03:51:25PM -0500, Ian McLeod wrote:
All,
I'm writing this to summarize a lengthy IRC and phone discussion from
earlier today that included Hugh, Steve, Chris, Jay and me (among
others). If anyone who was involved thinks I'm mis-representing
anything, please chime in.
(Note that I am intentionally discussing only the question of the
interface here, not the separate and largely orthogonal issue of status
updates and logging.)
So, as things currently stand, the process of building and pushing
images occurs outside of conductor in the "aeolus-image" command line
tool. This tool uses the existing QMF interface to the factory to drive
the build and push process.
There is a desire to move building and pushing back into the Conductor
web app.
To be absolutely clear, it's more that there is a desire to present
the user a view of building and pushing from within the app, as an
additive to the aeolus-image command line. But I'm probably just
splitting hairs there.
As far as we know, it is still not possible to cleanly integrate the
QMF
Ruby console bindings into the rails app itself. Jay encountered a
number of issues when originally attempting to do this. The two most
significant were excessive blocking of the entire rails process and the
need to restart the web app to recover from a failure or restart of the
qpid broker. We believe these issues still exist.
We discussed a range of options to address this:
1) Have the webapp call the aeolus-image CLI directly and just parse the
results - This is a quick hack but is probably workable.
2) Push to resolve the QMF Ruby binding issues to make it possible for
the webapp to run as a console - We've no idea of the scope of effort
required to do this.
3) Add a REST-style API to the Factory - This appeals as REST is already
widely used by other Aeolus project components (DC core api, iwhd,
numerous external and private cloud providers, Conductor itself, etc.).
It would also remove our dependency on the qpid components entirely. We
saw no particular technical issues that would stop us from doing this.
The structure of the Factory code makes it relatively easy to add a new
front-end interface.
We've tentatively added this to Redmine as issue 2142 though we have not
committed to it or included it in a particular sprint yet.
I like the idea.
I think my dream solution would be 4) Make Factory into an application
that I can call, which will then build things and deposit them and
their metadata into the Warehouse, and exit. But I understand this is
a whole ton of rework and therefore undesirable. So I'll settle for 3.
--Hugh
--
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
==
http://aeolusproject.org ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey