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
