Changes between Version 3 and Version 4 of GiB-to-ProtoGENI


Ignore:
Timestamp:
10/05/12 14:39:19 (12 years ago)
Author:
Vic Thomas
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GiB-to-ProtoGENI

    v3 v4  
    44
    55== Similarities ==
    6   * All experimenter nodes have 3 NICs available to the experimenter.  These are in addition to a fourth NIC that is used by the aggregate control plane.
     6  * All experimenter nodes have 3 NICs available to the experimenter.  These is, in addition, a fourth NIC that is connected to by the aggregate control network.  This network should not be used for experiment traffic.
    77  * Experimenters get root access to their virtual machines.
    88  * Virtual machines from both aggregates are implemented as OpenVZ containers running Fedora 15.  The Ubuntu flavor of GENI-in-a-Box provides OpenVZ containers running Ubuntu.   
     
    1010
    1111== Differences ==
    12   * Both GENI-in-a-Box and ProtoGENI return manifest rspecs that  includes the MAC addresses and the device names associated with the network interfaces on each host.  For example, see the {{{<in the snippet of a manifest rspec below, the host has a
    13   * Aggregate URN in rspec.  ''Note: You can use your ProtoGENI rspec with the URN for a ProtoGENI aggregate in your GENI-in-a-Box rspec.  The GENI-in-a-Box aggregate manager does not check the aggregate URN in the rspec.''
     12  * '''Mapping of device name to experimenter specified interface name'''.  The mapping of the experimenter specified interface name to the operating system device name is available in the manifest rspec.  For example, the {{{<interface>}}} element in the snippet of a manifest rspec shown below tells us that the interface with the experimenter specified name {{{left:if0}}} is mapped to {{{eth1}}} by the operating system (see the last part of the component_id for this interface).  In the ProtoGENI aggregate this mapping is not guaranteed to be correct i.e. it might actually be mapped to a different operating system interface such as {{{eth2}}} or {{{eth3}}}.  With GENI-in-a-Box the mapping will be correct.
     13{{{
     14<node client_id="left" component_id="urn:publicid:IDN+geni-in-a-box.net+node+pc101" component_manager_id="urn:publicid:IDN+geni-in-a-box.net+authority+cm" exclusive="false" sliver_id="urn:publicid:IDN+geni-in-a-box.net+sliver+101">   
     15        <sliver_type name="virtual-pc">     
     16            <disk_image name="urn:publicid:geni-in-a-box.net+image//FEDORA15-STD"/>     
     17        </sliver_type>   
     18        <services>     
     19            <install file_type="tar.gz" install_path="/local" url="http://groups.geni.net/geni/attachment/wiki/GiB-gettingStarted/iperf-execute-script.tar.gz?format=raw"/>     
     20            <execute command="/local/iperf-execute-script.sh" shell="sh"/>     
     21            <login authentication="ssh-keys" hostname="pc101.geni-in-a-box.net" port="22" username="alice"/>     
     22        </services>   
     23        <interface client_id="left:if0" component_id="urn:publicid:IDN+geni-in-a-box.net+interface+pc101:eth1" mac_address="00:0C:29:B4:DF:A7" sliver_id="urn:publicid:IDN+geni-in-a-box.net+sliver+1011">     
     24            <ip address="10.0.3.101"/>     
     25        </interface>   
     26        <rs:vnode name="pc101" xmlns:rs="http://www.protogeni.net/resources/rspec/ext/emulab/1"/>   
     27        <host name="pc101.geni-in-a-box.net"/>   
     28</node> 
     29}}}
     30  * '''Aggregate URN in rspec.'''  As you might expect, the aggregate URN in a GENI-in-a-Box rspec will be different from that in a  ProtoGENI rspec.  However, you can use your ProtoGENI rspec, with the URN for a ProtoGENI aggregate, in your GENI-in-a-Box rspec.  The GENI-in-a-Box aggregate manager does not check the aggregate URN in the rspec.  This is a feature and not a bug.  It is so you can use your ProtoGENI rspec with GENI--in-a-Box with very little or no changes.
     31  * '''Running commands as root in startup scripts'''.  The startup script specified by the experimenter as an {{{<execute>}}} element of the request rspec is executed with root privileges in the GENI-in-a-Aggregate.  You therefore do not require to sudo to run commands that require root privileges.  In fact, such scripts with sudo in them will fail as the VMs are set up to disallow sudo'ing without a tty.