Version 48 (modified by ibaldin, 5 years ago)


ORCA and RSpec

ORCA supports requests submitted in RSpec v2. Requests in NS2 and RSpec v1 are possible, but require a manual use of the NDL converter and Flukes.

RSpec v2 Requests

ORCA supports a limited set of RSpec expressions. The example below shows a representative sample of what can be said. This RSpec describes a slice with two nodes connected by a single link.

<?xml version="1.0" encoding="UTF-8"?>
<rspec type="request" 
<node client_id="geni1" component_manager_id="urn:publicid:IDN+uncvmsite+authority+cm">
 <sliver_type name="m1.small">
version="ba15fa6f56cc00d354e505259b9cb3804e1bcb73" />
 <interface client_id="geni1:0">
    <ip address="" netmask="" />
<node client_id="geni2" component_manager_id="urn:publicid:IDN+uncvmsite+authority+cm">
 <sliver_type name="m1.small">
version="ba15fa6f56cc00d354e505259b9cb3804e1bcb73" />
 <interface client_id="geni2:0" >
   <ip address="" netmask="" />
<link client_id="center">
  <interface_ref client_id="geni1:0" />
  <interface_ref client_id="geni2:0" />

NOTE: The example above is provided for informational purposes only and needs to be modified to use a valid disk image.

Request conversion conventions

  • Disk images - in ORCA users are allowed to specify their own images that can be placed on any webserver to be picked up by ORCA (downloaded and installed on user instances). This functionality is supported via ImageProxy. From the user's perspective what is required is to (see ImageProxy documentation for details):
    • Create an image
    • Create an xml file describing the image
    • Take SHA1 hash of the xml file
    • Place the url of the xml file and the SHA1 sum into the RSpec request. Since RSpec does not natively support this, the URL must be put into the 'name' attribute of the image and the SHA1 sum into the 'version' attribute of the image (see above)
    • We maintain a small library of stock images that can be used as a starting point for customizing an image.
  • Node services:
    • RSpec install and execute services: both are supported. Install service can handle .tar, .tar.gz, .tgz, .zip, .deb and .rpm formats (assuming the OS image has the tools to unpack those formats).
      • Both of these services use ORCA's post-boot scripts internally. Notably, the execute service obeys Velocity template substitution rules, used by post-boot scripts. This also means that these services can be debugged as post-boot scripts, by using the command (on the booted instance).
        $ neuca-user-script
    • ORCA allows specifying templated post-boot actions in post-boot scripts. You can specify an entire multi-line boot script as part of 'secvices_post_boot_script' element (note the script text must be HTML-escaped):
      <rspec xmlns=""
       <node client_id="foo">
           <pbs:services_post_boot_script type="velocity">
      echo "Hello from post boot script" &gt; $FILENAME
      echo "Executed on $DATE" &gt;&gt; $FILENAME
      curl $TARURL &gt; $TARFILE
      tar -zxf $TARFILE -C /some/directory
  • Dataplane IP address - ORCA allows the user to specify the IP address of an interface in a slice dataplane (not to be confused with the management address through which the user logs in). This can be done by adding an 'ip' element within an interface definition (see example above)
  • Management IP address - the address from which the user can have ssh access the sliver. This cannot be specified and is reported as 'service' element within the manifest RSpec. Note that the port may not be 22, as some sites lack direct access to the Internet and use NAT. For these sites Gush may not work well as it requires a listening port open on the sliver which in this case will not be NATted.
  • Domain binding - you can bind different parts of your request to different sites. You can use standard ORCA site names (uncvmsite, rencivmsite, acisvmsite, dukevmsite). Note that nodes in a request can be bound to different domains to create an inter-domain topology. The domain can be specified as part of component_manager_id:
    <node component_manager_id="urn:publicid:IDN+uncvmsite+authority+cm"
        <sliver_type name="m1.small" />
    • NOTE: for better consistency with the rest of GENI, the domain names should be prepended with ''. It is optional in the requests, however the manifest will return component manager IDs in this format (with site name prepended with ''.
    • Domain names are:
      • BBN Rack: bbnvmsite
      • RENCI Rack: rcivmsite
      • Duke: dukevmsite
      • UNC: uncvmsite

Color extensions

In order to support arbitrary annotation of RSpecs by user tools ExoGENI uses 'color' extensions. They allow to attach properties to nodes and links in RSpec requests and also create dependencies between elements of requests marked with a `color' label that denotes the application namespace. The annotations can take the form of property lists, XML text and plain text. There is a complete example shown in this file.


ORCA GENI AM compatibility API produces manifests consistent with GENI RSpec v3 schema and the stitching schema.

What is not supported

The following ORCA features are not supported in RSpec requests and/or API.

  • Nodegroups and nodegroup ORCA-driven splitting, automated dataplane address assignment
  • Functional dependencies between nodes
  • Slice modifications