Changes between Version 2 and Version 3 of GEC16Agenda/CommonExecutionEnv


Ignore:
Timestamp:
03/27/13 14:55:15 (6 years ago)
Author:
mbrinn@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GEC16Agenda/CommonExecutionEnv

    v2 v3  
    2121
    2222None
     23
     24== Notes and Outcomes ==
     25
     26
     27The "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.
     28
     29The 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.
     30
     31The following are highlights and outcomes from the session:
     32
     33 * The essential distinctions between the InstaGENI and ExoGENI that were discussed:
     34  * Both support bare metal nodes. But IG supports OpenVz containers (shared virtual spaces) and EG supports OpenStack full virtual machines using Xen.
     35  * 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)
     36  * IG supports users coming up as themselves (and must use sudo to run priviileged commands). EG runs users as root.
     37  * 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.
     38  * IG provides a default image, EG does not.
     39  * IG has tunnel forwarding turned on by default, EG does not.
     40
     41 * 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:
     42  * The certificates at the EG racks are expired and all the same at all racks
     43  * The certificates (once regenerated) need to be made available to IG and the GPO
     44  * The EG head node needs to install the Flash security policy
     45  * The certificates need to include the AM URN in the subjectAltName
     46
     47 * 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).
     48
     49 * 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.
     50
     51 * 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.
     52
     53 * 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 (169.254.169.254) to connect from the VM to the host machine to feed this kind of meta-data, plus a scripting post-processor.
     54
     55 * EG and IG took a joint action to agree on whether IP forwarding is on by default or not, and document it.
     56
     57 * 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.
     58
     59 * 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.
     60
     61 * GPO took an action to try to verify that a common image that could run under both IG and EG.