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