Version 4 (modified by, 6 years ago) (diff)


Towards a Common GENI Execution Environment


Thursday, 1.30pm - 2.30pm

Session Leaders

Marshall Brinn, GENI Project Office Victor Orlikowski, RENCI Rob Ricci, U. of Utah Niky Riga, GPO

Agenda / Details

The goal of this session is to review similarities and differences between the different GENI compute platforms. The intent is to allow aggregates to advertise significant value-added differences while narrowing the set of 'gratuitous' (non-value-added) differences. We refer to differences in RSpec, AM API semantics, I&M tooling, Linux environment configuration and other dimensions.



Notes and Outcomes

The "Towards a Common Uniform Execution Environment" session was held Thursday afternoon 3/21 at GEC16. The session was chaired by Marshall Brinn of the GPO and the lead participants were Victor Orlikowski of RENCI and Rob Ricci of Utah/Flux.

The goal of the session was to identify areas of the experimenter experience of using InstaGENI (IG) and ExoGENI (EG) that would are different and to try to allow the experimenter to know about and take advantage of these differences where they are value-added and to try to narrow the gaps between these environments where the differences are not value-added.

The following are highlights and outcomes from the session:

  • The essential distinctions between the InstaGENI and ExoGENI that were discussed:
    • Both support bare metal nodes. But IG supports OpenVz containers (shared virtual spaces) and EG supports OpenStack full virtual machines using KVM.
    • IG supports a standard RSpec mechanism for post-boot scripts whereby a file can be downloaded, untarred and running a command. EG supports an extension with a script to be run, supplied inline (with XML quoting and Velocity-based pre-processing)
    • IG supports users coming up as themselves (and must use sudo to run priviileged commands). EG runs users as root.
    • IG seeks to provide promised bandwidth, EG provides a dedicated L2 network with QoS support for networking. Neither makes CPU guarantees except where one has a dedicated (exclusive) bare metal resource.
    • IG provides a default image, EG does not.
    • IG has tunnel forwarding turned on by default, EG does not.
  • Matt Strum and Victor Orlikowski took an action to enable EG racks to be represented in the Flack UI. There were three issues to be resolved:
    • The certificates at the EG racks are expired and all the same at all racks
    • The certificates (once regenerated) need to be made available to IG and the GPO
    • The EG head node needs to install the Flash security policy
    • The certificates need to include the AM URN in the subjectAltName
  • We discussed the desirability of allowing users to use the same image on IG and EG. This is possible, in principle, on bare-metal nodes but difficult in virtual machines (because of the differences between containers and full VM's).
  • Max Ott raised concerns about reproducibility: given that the images change and the S/W baselines change, can I be assured that I can run exactly the same experiment I ran a year (or five ago)? There were mixed responses. There is an effort to support backwards compatibility (especially with IG) but it is limited, and some images and distributions versions are no longer supported after some period.
  • Niky Riga indicated that it is good for an aggregate to advertise unavailable resources (e.g. bare-metal resources currently in use) in their advertisement RSpecs. IG does this, EG does not.
  • We discussed the desirability of having common interfaces to view configuration information (e.g. the name of my slice, the name of the data interface, the request or manifest RSpec). IG puts many of these things on the image in special locations. EG uses a data service ( to connect from the VM to the host machine to feed this kind of meta-data, plus a scripting post-processor.
  • EG and IG took a joint action to agree on whether IP forwarding is on by default or not, and document it.
  • The group agreed that EG should support a default image of the same (current) OS as IG. It should be useful for new/naive users.
  • The group agreed that EG and IG should support scripts to be downloaded, or to be supplied inline - through the same mechanism. To that end, GPO took an action to try to identify a common approach to post-boot scripts based on the current IG and EG capabilities.
  • GPO took an action to try to verify that a common image that could run under both IG and EG.