On Jan 23, 2013, at 4:21 PM, Matt Wagner <[email protected]> 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
