Changes between Initial Version and Version 1 of RavenToProtoGENI


Ignore:
Timestamp:
04/19/10 17:20:22 (14 years ago)
Author:
Vic Thomas
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • RavenToProtoGENI

    v1 v1  
     1=== Emulab differences from planetlab ===
     2
     3 * Looks to be Xen-based instead of vserver-based
     4
     5 * 100+ different types of OS images that can be instantiated - fedora, windows xp, ubuntu, planetlab, bsd, ...
     6
     7 * A subclass of emulab nodes are nodes that are instantiated with planetlab images, so maybe we only support those nodes...
     8
     9 * experiments can be composed of heterogenous types of OS images.
     10
     11 * no /etc/slicename file, but we might be able to derive a slicename from the node's hostname (nodeA.experimentName.projectName.foo.com --> projectName_experimentName)
     12
     13 * where to get user keys from? Login appears to be done by name/password instead of ssh keys. Why then do we upload our SSH key when registering for emulab?
     14
     15 * idle-swap. if an experiment is idle for 2 hours, it will be swapped out. A node is considered non-idle if:
     16
     17{{{
     18     Any network activity on the experimental network
     19     Substantial activity on the control network
     20     TTY/console activity on nodes
     21     High CPU activity on nodes
     22     Certain external events, like rebooting a node with node_reboot
     23}}}
     24
     25 We have two problems -- 1) idle swap will prevent pacmand from running, and 2) running pacmand regularly will prevent idle swap. Problem 2 would solve problem 1 by preventing the idle swap, but probably put us at odds with acceptable use policy.
     26
     27 Emulab experiments do not seem to be long running by design, so maybe 1 isn't an issue. We'd then need to solve 2, to prevent pacmand from keeping an idle slice alive when it should be swapped. A possible solution would be a pacmand that never polls for updates. It could only be updated by pushing to it.
     28
     29
     30=== Protogeni ===
     31
     32 * tutorial at http://www.protogeni.net/trac/protogeni/wiki/Tutorial
     33
     34 * start by creating a certificate at emulab.net, select profile and "generate ssl certificate".
     35
     36 * log into emulab.net using your name and password
     37 
     38 * verify your cert is in /users/<username>/encrypted.pem and /users/<username>/emulab.pem
     39
     40 * put your passphrase in /users/<username>/passphrase
     41
     42 * run some test scripts
     43{{{
     44  cd /usr/testbed/protogeni/test
     45  python ./listcomponents.py -p /users/smbaker/passphrase
     46  python ./createsliver.py -n exampleslice -p /users/smbaker/passphrase
     47  python ./startsliver.py -n exampleslice -p /users/smbaker/passphrase
     48  python ./sliverstatus.py -n exampleslice -p /users/smbaker/passphrase
     49}}}
     50 
     51 
     52 
     53
     54 
     55
     56=== To-Do list ===
     57
     58 * Start off by only supporting planetlab images under emulab. That would let us test protogeni without having to support an exhaustive list of different os types.
     59
     60 * Support for different architectures in rpm packages. This is needed to support heterogenous OS types. Look at how RPM and YUM handle this. Maybe we can leverage our tag support.
     61
     62 * Get the slicename from somewhere, probably from the node's hostname
     63
     64 * Get user keys from somewhere
     65
     66=== Two types of Protogeni nodes ===
     67
     68   * See Rob's tutorial at http://www.protogeni.net/trac/protogeni/attachment/wiki/Tutorial/tutorial.pdf
     69
     70  * Exclusive node
     71      * Whole machine is reserved to one user
     72      * Seems to reboot a lot
     73      * Login using SSH key and emulab username
     74      * Current runs RH9
     75      * mktemp problem in initscript, -t option is not understood  (FIXABLE)
     76      * PYXML dependency issues (FIXABLE)
     77      * missing optparse (REALLY BAD)
     78      * python 2.2 (REALLY BAD)
     79
     80  * Virtualized
     81      * Like planetlab nodes
     82      * Complicated rspec needed to use (http://www.protogeni.net/trac/protogeni/wiki/RSpecExamples#SharedRequest)
     83      * SSH listens on different pors
     84      * Login using SSH key and emulab username to specific port on node
     85
     86=== Feasibility Writeup ===
     87
     88ProtoGENI nodes can be classified as either exclusive nodes or as shared nodes. Exclusive nodes are currently running Red Hat 9, an old operating system, that lacks the appropriate version of python for running the raven tools. These nodes will have to be upgraded to a more modern distribution of Linux, such as Fedora 8, before raven can be used with them.
     89
     90Shared ProtoGENI nodes are already running Fedora 8 and Raven is compatible with these nodes, although several features need to be provided for Raven to be fully supported.
     91
     92  * First, Raven needs a way to identify the name (or HRN or URN) of the node and the slice in which it is operating on. For example, on !PlanetLab/SFA nodes, this is done by providing /etc/node.gid and /etc/slice.gid files containing the GID of the node/slice (which in turn contains the URN and/or HRN). Similar files would need to be made available on ProtoGENI nodes.
     93
     94  * Second, Raven needs a set of public keys for users that are authorized to use the slice. On !PlanetLab/SFA nodes, this is done by making a local XMLRPC call to the nodemanager that runs on the node, asking it for the set of user public keys.
     95
     96  * Third, a method needs to be provided for automatically installing the Raven tools on the nodes. On !PlanetLab/SFA nodes, this is done by the user requesting that the Stork Initscript be used for their slice.