User Tools

Site Tools


milestones:a-hack

“A Hack” milestone

The objective of this release is to allow to run an experiment or two on the nodes already deployed. The testbed should satisfy the minimal set of requirements, should be inspired by the basics of our architectural concepts, with quick and simple code that may not be reused in future releases.

Node architecture

This is a diagram of the proposed architecture (source):

node architecture

Database model

This is a diagram of the proposed database model (source):

database model

Available features

Connectivity
  • Only internal, local and wired direct interfaces supported in RD: EFFECT (LEANDRO)
  • Only private, public and isolated interfaces support in slivers: EFFECT (LEANDRO)
  • At most one public interface per sliver.
Node management
  • IPv6 overlay used by management traffic (use tinc encryption and auth). READY/TESTED? (LEANDRO)
  • Management connections from the server to a node using SSH public key auth. NEEDED? (LEANDRO)
  • The rest of management connections are just public queries (PULL method).
  • All node's tinc daemons only ConnectTo the server (tinc allows P2P data).
User and slice management
  • Manual user creation by server admin.
  • One SSH public key per user.
  • Manual slice creation by server admin on behalf of user (no UI). UI? (DJANGO) (LEANDRO)
  • One user (owner) per slice.
  • Partial accountability: slice start/stop times are not recorded.
  • Experiment code is an archive to be unpacked in the container. NO NEED (UP TO THE RESEARCHER: E.G. RSYNC or vxargs) (LEANDRO)
  • Base sliver images (templates) assumed to exist in all nodes. ASSUMED SAME FOR ALL NODES (LEANDRO)
  • Direct access with SSH to slivers (pub key + nodes→sliver based on slice_id)

Technical needs

Base system
Networking
  • Openvswitch support. EFFECT (LEANDRO)
  • Initial network configuration (ipv4 and ipv6) for local interface
  • IP assignment for slivers with public interface
  • Configuration of local bridge and internal bridge
  • Firewall configuration
  • Traffic control configuration (fair scheduling only)
  • Tinc configuration
Virtualization
  • LXC support
  • LXC usertool
  • Scripts/Recipes to automatic sliver install
  • SO templates?
Control Software
  • Based on UCI files/node
  • Rest interface
Sliver services
  • DHCP server
  • DNS server

Dnsmasq can do both tasks.

Deployment
  • Which nodes (Hw)

Experiments

  • Research experiments
    • Bittorrent eval with vxargs?
  • Development experiments
    • Unordered List Item

Results from discussion (Monday 16 15h)

In random order:

  • Apart from experiments (BT by default) we also need to identify “development experiments” to be done using the A testbed to prepare for the B testbed (can be done later perhaps).
  • We need a Redmine system to coordinate development (repository?) [MarcAy]
  • Specific topics to work and clarify: (Deadline: send to wp2 an email with a proposal before Wed 18 at noon)
    • Interface server with node(s): UCI file, REST/JSON calls: [Leandro, Davide]
    • Integration and development of software in the nodes: [Pau, Axel, Ivan]
    • Server (design/architecture, development): [Marc Aymerich, Leandro]
    • Experiment perspective (to check for completeness): [Felix, Llorenc]
  • VERY IMPORTANT: who does the work:
    • Electing a release driver (a benevolent dictator for this release): Any volunteer?
    • Electing a driver for the parts (by default same as specific topics): by default the first person in the list?

Please add anything else left …

Feature freeze

Features for the “A Hack” milestone are frozen as of 2012-05-31.

Things to review after release

Regarding UCI configuration files:

  • Objects having numeric IDs should have previsible identifiers based on those IDs instead of names, e.g. node-1234 but not my-home-node.
  • Identifiers based on numbers can use a descriptive prefix to avoid collisions in the flat UCI namespace, e.g. node-1234 and slice-1234 (the numeric part can be 0-padded like node-01234, though that may cause problems if we later change the size of some ID).
  • Numeric identifiers should use decimal notation to avoid misinterpretation. If hex is used an explicit prefix like 0x or x or a suffix like h should be used. The biggest decimal number we may use is slice #281474976710655, not that long as to justify hex.
  • option ifNN_ipvX_proto in sliver (always static) can be removed, addresses are always assigned statically and known beforehand since otherwise traffic filtering becomes too difficult.
  • Convert option user_pubkey in slice into list user_pubkey or alternatively use user_pubkey_01, user_pubkey02, .. notation .
  • option container_nr in sliver should be hidden or renamed to sliver_nr or just nr, since a sliver being a Linux container is an implementation detail of no interest to the outside.
  • option if00_type internal, change value to private (the name of the RD's bridge and interface is “internal”, the name of the sliver's interface is “private”).
  • option priv_ipv6_prefix in node should go to testbed (although it's a CONFINE-wide immutable value).
  • Add a node section with an id option to slice attributes so that a sliver can know on which node it's running.
  • Convert option rd_if_iso_parents into a list (it's actually a list of interfaces).
  • Rename rd_if_iso_parents in node to rd_direct_ifs or similar (e.g. list rd_direct_if): in the future those interfaces will be used for other types of sliver interfaces.
milestones/a-hack.txt · Last modified: 2015/04/15 16:12 by ivilata