[Planetlab-devel] NM improvement: support for IP aliases

[Faiyaz Ahmed]

Hi Marc,

This sounds all sounds pretty feasible, but how often are free IPs  
added to nodes?  If not very often, then we could forgo calling  
getnodenetworks periodically from within NM which avoids moving BM  
code into NM.  We could potentially setup all available IPs by BM  
(much the same way as is done now) and dynamically assign available  
IPs to slices via slice attributes in NM.

A simple callback can then be written to execute the proper shell  
command followed by the proper vserver command to configure the local  
firewall and bind the IP to the sliver.  An example of this already  
exists in NM which is used to dynamically bind/remove vsys scripts  
available to specific slices.

Does this sound better?


Faiyaz

On Oct 2, 2008, at 4:49 PM, Marc E. Fiuczynski wrote:

> Hi Faiyaz, Thierry, and Daniel, (and everyone else),
>
> Thought I'd bounce something off of the developers list before  
> creating a ticket for an NM enhancement.
>
> Linux-VServer has support to assign each vserver its own IP  
> address.  Daniel developed some initial support for this already,  
> but we need to take this proof of concept to production.  I just  
> went through the process of obtaining the necessary information from  
> Daniel to understand how this is supposed to work, but then at the  
> end reached a limitation where such an "aliased" IP address is  
> currently only assigned to a node by BM. This (and a few other  
> things) should be done by NM dynamically, not by BM statically when  
> the system boots.
>
> Specifically, what NM needs to do is periodically process the set of  
> NodeNetworks associated with the node, check if one of the  
> NodeNetworks settings (nodenetwork_setting_ids) happens to be an  
> "alias", and if so invoke the appropriate "ifconfig ethX" commands  
> to setup an ethernet alias.  (Btw., I have no idea in what way this  
> is supposed to work on a multi-homed box, unless the alias somehow  
> binds itself to another NodeNetwork from which one can deduce to  
> which ethX we should be using.).
>
> Does this make sense?  Is this the right approach?  My sense is that  
> the work required is to
>
> a) move the "alias" related code from BootManager/source/steps/ 
> WriteNetworkConfig.py:run() to somewhere within NM.
>
> b) add logic to NM such that it can add new aliases on the fly
>
> c) add logic to NM such that it can remove old aliases on the fly  
> (which might be difficult)
>
> thoughts?
>
> Marc
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel