ec2 networking containers

Kapil Thangavelu kapil.thangavelu at canonical.com
Thu May 17 06:12:59 UTC 2012


Excerpts from Gustavo Niemeyer's message of 2012-05-16 07:27:29 -0700:
> On Tue, May 15, 2012 at 8:38 PM, Kapil Thangavelu
> <kapil.thangavelu at canonical.com> wrote:
> >> Thanks for sending Kapil. Tinc definitely looks like it is focused on
> >> the simplest solution to this fairly complex problem.
> >
> > indeed it is complex, and even then it doesn't fully solve the issue. deploy
> 
> I actually think the problem is fairly simple. Will hold off on
> researching further until we actually put ourselves to fix it, though.

Conceptually it maybe simple, another layer of abstraction solves everything 
right? ;-) operationally not so much, there's performance issues both at the vpn 
layer resource consumption per node (evens sans crytpo) and in tuning it for the 
provider network level. I've heard tell that implementing this at a kernel 
mod level might help on those counts, but thats a significant resource 
investment. For systems targetting physical hardware via maas being able to 
operate in a non hostile environment gives significantly more flexibility to 
directly utilizing quantum and physical/soft switches optimally.

Nonetheless for public providers it feels like we've held off on this by 
dictating (via the exposed charm api which dictates dynamic per unit ports) we 
need this sort of solution to get density and then handwaving about doing it. 
Which is a bit like getting into a rowboat without a paddle. In that context, 
clint's suggestion that we just use the available instance types a provider 
gives is probably the most appropriate. specialized solutions dealing with 
particular application domains (paas/saas) can workaround/achieve density with 
more protocol and app specific behaviors.

cheers,

Kapil



More information about the Juju mailing list