Changes between Version 3 and Version 4 of TopDl


Ignore:
Timestamp:
Oct 4, 2012 5:39:04 PM (7 years ago)
Author:
faber
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TopDl

    v3 v4  
    192192  The local emulab operating system image.  This will become less common as more plugins are capable of mapping from operating system parameters into local image name, but can be used as a low-level escape.
    193193 '''testbed'''::
    194   The experiment controller's name for the testbed this node will be placed on.  This is in place to allow native topdl descriptions to be accepted by experiment controllers - it's not needed by access controllers.  As the full experiment description language evolves, this may move into som part of that language or become a standard topdl attribute.
     194  The testbed on which to place this element if the experiment is federated.
    195195 '''type'''::
    196196  The local emulab machine type.  This will become less common as more plugins are capable of mapping from CPU/storage parameters into local machine type, but can be used as a low-level escape.
     
    198198The following attributes appear in topology descriptions for use by local DETER-like testbeds in configuration:
    199199
    200  '''active'''::
    201   Attached to a portal computer.  If true, this portal initiates connections to the peer.
    202  '''dragon_vlan'''::
    203   If assigned, the VLAN tag on which this node will communicate.  The name will change.
    204  '''domain'''::
    205   Attached to a portal computer.  This is the DNS domain of the local emulab resources.
    206200 '''ip4_address'''::
    207201  The IP version 4 address of the interface that the attribute is attached to as a dotted decimal.
    208  '''masterdomain'''::
    209   Attached to a portal computer.  The DNS domain of the emulab exporting its environment.  Used to connect services and forward traffic.
    210  '''masterexperiment'''::
    211   Attached to a portal computer.  The emulab project/experiment name of the environment being exported from the master testbed.  Used to connect services.
    212  '''masteruser'''::
    213   Attached to a portal computer. The emulab user that alloacted the exported environment on the master.  User to connect to services.
    214  '''peer'''::
    215   Attached to a portal computer.  DNS name of the portal node used to bridge services and traffic.
    216  '''peer_segment'''::
    217   Attached to a portal computer.  Fedid of the allocation in which the peer portal lives.
    218  '''portal'''::
    219   True if this is a portal computer added by the experiment controller
    220  '''portal_type''::
    221   Attached to a portal computer.  Specifies whether this portal exports services, forwards traffic, or both.
    222  '''smbshare'''::
    223   Attached to a portal computer.  The SMB/CIFS share used to export local file systems (if any)
     202 '''ip4_netmask'''::
     203  The IP version 4 network mask of the interface that the attribute is attached to as a dotted decimal.
    224204 '''startup'''::
    225   The startup command to federate the computer.
     205  The startup command to run when the node is booted
    226206 
    227 
     207== Working With Topdl ==
     208
     209First, for many applications, including the [WikiStart federation system] and the [http://containers.deterlab.net containers system], most of the functionality is accessible without writing topdl directly.  Both of those systems accept extended ns2 experiment descriptions that suffice for much of their functionality.  [http://montage.deterlab.net Montage ] generates topdl internally as well.  Researchers primarily need to work with topdl when extending tools or writing local tools.  One can either generate experiment descriptions using the DETER ns2 system or by using our [TopdlLibrary topdl library].
     210
     211=== Generating Topdl from Ns2 ===
     212
     213The [FeddCommands#fedd_ns2topdl.py fedd_ns2topdl.py] command is a simple way to generate topdl from a programmatic interface.  It is installed on {{{users.isi.deterlab.net}}}.  The same [https://trac.deterlab.net/wiki/nscommands ns2 commands] that can be used to generate a physical DETER topology are input to {{{fedd_ns2topdl.py}}}.  That command strips the event system actions and outputs the topology encoded in topdl.
     214
     215{{{fedd_ns2topdl.py}}} does not format the XML for easy reading by humans.  We recommend using a filter like {{{xmlformat}}}, which is also installed on {{{users}}} to format the topdl for reading or editing.
     216
     217The two node topology similar to the above can be generated from this ns2 code:
     218
     219{{{
     220set ns [new Simulator]
     221source tb_compat.tcl
     222
     223
     224set a [$ns node]
     225set b [$ns node]
     226
     227set link0 [ $ns duplex-link $a $b 100Mb 0ms DropTail]
     228
     229$ns rtproto Static
     230$ns run
     231}}}
     232
     233It does not produce the operating system parameters and does produce the capacity parameters.
     234
     235=== Generating and Manipulating Topdl using Python ===
     236
     237The topdl library is a set of python classes and function s that are [TopdlLibrary fully documented elsewhere].  This section gives a few examples that gives the feel for the library.  Each entity is represented by a class with attributes named and broken down as described above.  There are routines to import and export topologies in topdl as well as to translate between several formats, including ns2 and GENI Rspecs.
     238
     239The following python generates the example topdl above:
     240
     241{{{
     242#!/usr/bin/env python
     243
     244from deter import topdl
     245
     246top = topdl.Topology(substrates=[ topdl.Substrate(name='link0')],
     247        elements=[
     248            topdl.Computer(name='a', interface=[
     249                topdl.Interface(name='inf000', substrate=['link0'])]
     250            ),
     251            topdl.Computer(name='b', interface=[
     252                topdl.Interface(name='inf000', substrate=['link0'])],
     253            )]
     254        )
     255print topdl.topology_to_xml(top, top='experiment')
     256}}}
     257
     258That code constructs the small topology entirely from constructors, which is impractical for large topologies.  This breaks the construction into a couple loops, which are easier to build on and understand.  Output is identical.
     259{{{
     260#!/usr/bin/env python
     261
     262from deter import topdl
     263
     264subs = [ ]
     265elems = [ ]
     266
     267subs.append(topdl.Substrate(name='link0'))
     268
     269for elem_name in ('a', 'b'):
     270    inf = topdl.Interface(name='inf000', substrate=['link0'])
     271    elem = topdl.Computer(name=elem_name, interface=[inf])
     272    elems.append(elem)
     273   
     274top = topdl.Topology(substrates=subs, elements=elems)
     275
     276print topdl.topology_to_xml(top, top='experiment')
     277
     278}}}
     279
     280