Community-Lab introduction

Differences From Artifact [2be8593ac1]:

• File script,lightning.txt — part of check-in [fc5ef3c414] at 2014-01-30 11:17:22 on branch fosdem-2014 — Change private/public net diagram order, expand ``[+]`` text, include in script. (user: ivan, size: 5800) [annotate] [blame] [check-ins using]

To Artifact [0a81b0f647]:

• File script,lightning.txt — part of check-in [38cde6816a] at 2014-01-30 12:07:56 on branch fosdem-2014 — Use stacked diagrams for testbed architecture and logos, update script. (user: ivan, size: 5909) [annotate] [blame] [check-ins using]

    56     56     stations, etc. to be used by the community. *##*
    57     57   - In a more sophisticated approach, nodes can also be used to implement cloud
    58     58     infrastructure provided and managed by the community for the community.
    59     59     This is the mission of the Clommunity project. *##*
    60     60   
    61     61   * Architecture and technologies
    62     62   ** Testbed architecture
    63         -- Community-Lab consists of a set of nodes (managed by CN members) that follow
    64         -  the configuration in a set of servers (managed by testbed operators).
           63  +- How does the Community-Lab testbed work?
           64  +- It consists of a set of nodes (managed by CN members) that follow the
           65  +  configuration in a set of servers (managed by testbed operators).
    65     66   - All components in the testbed become reachable via a dedicated management
    66     67     network implemented as an IPv6 overlay.
    67         -- Researchers define experiments (so called slices) in a server.
    68         -- Nodes use a REST API to get those definitions from servers and run several
    69         -  of them simultaneously as VMs (so called slivers).
           68  +- Then researchers define experiments (the so called slices) in a server.
           69  +- And nodes use a REST API to get those definitions from servers and run
           70  +  several of them simultaneously as VMs (the so called slivers).
    70     71   - Slivers can access the CN via NAT, natively at the network layer, or in an
    71     72     isolated VLAN for routing experiments. *##*
    72     73   
    73     74   ** Technologies
    74         -- Nodes are connected via Ethernet to normal community devices.
    75         -- Nodes are moderately powerful computers running OpenWrt with a control
    76         -  daemon written in Lua.  Slivers are implemented as Linux containers.  We are
    77         -  working on safe node upgrade using kexec.
           75  +- Nodes are moderately powerful computers (like this barebone computer)
           76  +  connected via Ethernet to normal community devices (i.e. routers). *##*
           77  +- Nodes run OpenWrt with a control daemon written in Lua.  Slivers are
           78  +  implemented as light Linux containers.  We are working on safe node upgrade
           79  +  using kexec. *##*
    78     80   - The GUI and REST API in servers are implemented as Django applications.
    79         -- The IPv6 overlay used for the management network is a tinc mesh VPN.
           81  +- The IPv6 overlay used for the management network is a tinc mesh VPN. *##*
    80     82   - We use Git, Redmine, Jenkins and our Virtual CONFINE Tesbed (VCT) package
    81     83     for development and testing. *##*
    82     84   
    83     85   * Collaborations
    84     86   - CONFINE actively collaborates to the development of several Free software
    85     87     projects: the OpenWrt router distro, the BMX6 and OLSR mesh routing
    86     88     protocols, the DLEP protocol for collecting link characteristics, the NodeDB