Notifications between Aeolus components

Matt Wagner matt.wagner at redhat.com
Wed Jan 23 22:21:56 UTC 2013


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


More information about the aeolus-devel mailing list