On Tue, Jun 17, 2008 at 4:48 PM, Matthew Farrellee mfarrellee@redhat.com wrote:
Renato Figueiredo wrote:
It's great to see this project getting off the ground!
Our group is very interested in this idea. We have been working with wide-area VM appliance Condor pools for a couple of years and have developed a peer-to-peer virtual network (IP-over-P2P, or IPOP) that supports decentralized NAT traversal with techniques including hole-punching and proxying. We've found this to be very useful to facilitate the deployment of ad-hoc wide-area Condor pools/flocks where nodes are increasingly behind NATs. The IPOP code is also open source and user level (though it currently uses a tap device), so I thought this would be of interest to the list. Here are some pointers for more information (and software):
http://grid-appliance.org http://ipop-project.org
We're starting a collaboration with the Condor group on a particular application of this virtual infrastructure for computer architecture simulation (http://archer-project.org); hopefully sharing our experience with this system can benefit nightlife and vice-versa.
Bests, --rf
Renato,
IPOP is definitely something that could be of use to the Nightlife project. Letting NAT'd execution nodes join the network is currently an issue. As Nightlife grows it could also become a good testbed for IPOP.
Have you considered packaging IPOP in Fedora?
Best,
matt
Matt,
Currently we distribute the source code and a binary snapshot. As far as creating a Fedora package, that shouldn't be difficult at all - the only dependences we have are the mono C# runtime, the dhcp client, and a tap device.
The other issue is configuration of virtual IP addresses. That would be a function of how nightlife is expected to be deployed - e.g. a single big pool or many smaller pools. We typically use a private address space for the tap endpoints and that is within NATed virtual machines - avoiding conflicts with the host network. If the tap device is connected directly to a host, it's important to configure the tap to avoid overlapping private network address spaces. We can deal with multiple decoupled IP overlays through IPOP namespaces, but that assumes multiple Condor pools - a node would join only a pool for an IP range that doesn't conflict with their private networks.
One idea we have thought about in the context of Condor but have not implemented is port forwarding instead of IP tunneling, which would not require a tap device. This requires some more development, unfortunately we haven't had the cycles to pull this off yet.
Bests, --rf