Notifications between Aeolus components

Chris Lalancette clalancette at gmail.com
Mon Jan 28 15:50:18 UTC 2013


On Thu, Jan 24, 2013 at 6:18 PM, Martin Povolny <mpovolny at redhat.com> wrote:

> Matt, please, do not take anything I write personally or as an offense.
> I started with saying that all these as IMHOs. Most my ideas are based
> on my previous experience from outside this project and although I think
> that 4 months is enough time to get the idea of Conductor, I surely
> don't have much idea about the history of the project, don't know all
> the components in much detail and cannot yet understand reasons that led
> to previous decisions that might seem strange to me.
>
> I will try to address the points you made one by one, no offense.
>
> On Thu, Jan 24, 2013 at 01:55:09PM -0500, Matt Wagner wrote:
> > On Thu, Jan 24, 2013 at 10:10:47AM +0100, Martin Povolny wrote:
> > >
> > > I was not here when this decisions where made and did not hear any
> > > reasonable argument why the MQ was removed from the project.
> >
> > I'm trying to find the mailing list thread, but I think it predates the
> > aeolus-devel.
> >
> > But suffice it to say that a lot of smart people thought about it and
> > the community decided it was the right path forward at the time. That's
> > not to say that it means we shouldn't consider re-adding it, just that
> > your not seeing "any reasonable argument" doesn't mean that the decision
> > at the time was wrong.
>
> Sorry, that is not an argument. It also does not mean that the decision
> was right.
>
>
I can provide a bit of historical perspective here.  I will first point
out, though, that I totally agree with Hugh; you need to define what user
problems you are trying to solve, and then pick a messaging mechanism.
Doing it the other way around is what got us into trouble to start with.

When the project was first spinning up, there was a lot of pressure to use
AMQP, and more specifically, QMF.  However, it turned out that there were a
few problems, some with QMF, and some with AMQP.   The main problem with
QMF was that it was not well maintained at the time, and had numerous bugs
and inefficiencies[1].  It wasn't clear who was going to step up and
improve it.  The main problem with AMQP had to do with the general
complexity of setting it up.  Aeolus Conductor is very complicated to set
up; the fact that aeolus-configure exists is testament to that.  In
addition to the complexity of the Conductor, we were adding in a whole
messaging layer that a sysadmin would have to understand.  Further, since
the whole point of AMQP is to be multi-machine, it is not trivial to write
scripting that will set it up[2].

So basically, the QMF support in imagefactory was adding a whole lot of
complexity, for unclear gain.  Since it was the only component using QMF at
the time, it was simple enough to switch it over to a REST interface and
dump the complexity.

That all being said, I will re-iterate my starting point.  The most
important thing to do is to clearly define what it is the users want to
do.  Not what they might want to do in some nebulous future, but what
features they are asking for right now.  If it turns out that AMQP is the
best solution for the task, then that is fine; but you can't start with
that and work backwards.

Regards,
Chris

[1] I will hasten to add that I have no idea if this is still the case.  It
very well may have been fixed by now.
[2] This is of course possible, using something like puppet.  However, you
have now added 3 new things that the sysadmin would need to understand.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20130128/b79a858a/attachment.html>


More information about the aeolus-devel mailing list