On Jan 23, 2013, at 4:21 PM, Matt Wagner <matt.wagner(a)redhat.com> wrote:
On Wed, Jan 23, 2013 at 01:42:31PM -0500, Mo Morsi wrote:
> On 01/23/2013 01:16 PM, Bryan Kearney wrote:
>> Well, just thinking out loud.. can any component go into the cloud
>> which may not be in the same VPN space?
>>
>>
>> -- bk
>>
>
> I'd imagine this would come down to the security policy of the
> organization deploying to the cloud, namely how lax the firewall can be
> to permit connections from the cloud as well as the ip address
> assignment on the cloud instances launched.
For a while now, I've been watching this discussion thinking, "It feels
like we decided a while back that AMQP would be cool, and are now trying
to work backwards to come up with reasons to justify it." Perhaps I'm
just not forward-looking enough, or perhaps I'm overlooking an important
detail, but that's sort of how it feels to me.
I think networking is an edge case, and a minor detail. We should
absolutely try to support running components on different boxes (though
I don't believe we have ever properly tested or supported it). But if
you break Aeolus up and run it on disparate network segments, you're
going to have to handle somehow patching things together. I don't think
we should choose how we handle inter-component messaging based on what
happens if you break components up on different networks and refuse to
set up a VPN or appropriate port-forwarding rules.
I don't mean to single out networking in general, though; it's just the
latest in the discussion. I just worry that the discussion is largely
theoretical and academic, focused on how different means of
inter-component communications differ. That might be a good conversation
to have if we didn't already have all our components using one. What I'm
missing from this discussion is an exploration of what issues we're
actually experiencing today with our HTTP callbacks system, and whether
the overhead of switching to AMQP is a worthwhile trade-off. Is changing
Factory and Conductor to use AMQP worthwhile to prevent the issue where
if you shut down one of the two components in the middle of an exchange
of messages, some messages might be lost? Could that better be solved by
implementing some queuing or polling? Or, is it fair to say that if you
send a job to Factory from Conductor and then shut down Conductor, it's
just expected that the updated status might be missed?
It's not my intention to vehemently oppose AMQP, and I certainly don't
mean to suggest that it shouldn't be discussed. I just don't find the
current conversation terribly productive at making the case for why we
should switch.
-- Matt
imagefactory started off using QMF. It's what we were told was decided on when Aeolus
was designed. But conductor was having a difficult time using it because it meant having a
separate thread or process to bridge conductor to the broker. So, in the summer of 2011,
there was a number of discussions where developers on both the imagefactory and conductor
teams came out in favor of imagefactory offering a REST interface. We did, and near the
end of January of 2012, we officially removed the QMF interface from the source tree when
it started to seem like QPID/QMF was failing to gain traction in the wider community.
I'm not saying the conversation shouldn't happen either. What I am saying is that
it should pick up where it was left 18 months ago with the question of if the challenges
of conductor actually connecting to a broker are easier to deal with now than they were in
2011 when they were great enough to decide to switch course.
-steve