On Thu, Jan 24, 2013 at 6:18 PM, Martin Povolny <mpovolny@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.