<div dir="ltr">On Thu, Jan 24, 2013 at 6:18 PM, Martin Povolny <span dir="ltr"><<a href="mailto:mpovolny@redhat.com" target="_blank">mpovolny@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Matt, please, do not take anything I write personally or as an offense.<br>
I started with saying that all these as IMHOs. Most my ideas are based<br>
on my previous experience from outside this project and although I think<br>
that 4 months is enough time to get the idea of Conductor, I surely<br>
don't have much idea about the history of the project, don't know all<br>
the components in much detail and cannot yet understand reasons that led<br>
to previous decisions that might seem strange to me.<br>
<br>
I will try to address the points you made one by one, no offense.<br>
<div class="im"><br>
On Thu, Jan 24, 2013 at 01:55:09PM -0500, Matt Wagner wrote:<br>
</div><div class="im">> On Thu, Jan 24, 2013 at 10:10:47AM +0100, Martin Povolny wrote:<br>
> ><br>
> > I was not here when this decisions where made and did not hear any<br>
> > reasonable argument why the MQ was removed from the project.<br>
><br>
> I'm trying to find the mailing list thread, but I think it predates the<br>
> aeolus-devel.<br>
><br>
> But suffice it to say that a lot of smart people thought about it and<br>
> the community decided it was the right path forward at the time. That's<br>
> not to say that it means we shouldn't consider re-adding it, just that<br>
> your not seeing "any reasonable argument" doesn't mean that the decision<br>
> at the time was wrong.<br>
<br>
</div>Sorry, that is not an argument. It also does not mean that the decision<br>
was right.<br>
<div class="im"><br></div></blockquote><div><br><div>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.<br>
<br></div><div>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].<br>
<br></div><div>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.<br>
</div><div><br></div><div>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.<br>
</div><div><br>Regards,<br></div><div>Chris<br><br></div><div>[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.<br></div>[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.<br></div></div></div></div>