Version 51 (modified by Ahmed El-Hassany, 9 years ago) (diff)


Demo on Feb 5, 2013: Progress Towards GEMINI v2(beta) Release

February 5, 2013, 1pm - 4pm

Via webex

DRAFT (2/1) Agenda:



1) Service to service authentication and authorization, using proxy certs



2) Instrumentize script

Ezra and Hussam

+ configuration (figure)

Hussam's slice will be pre-created and look like

+ summary of demo steps

There will be two version of the demo due to state of the code being worked on. Hussam's version of the instrumentize will have all code related to active measurement installation, configuration disabled, where as Ezra's version of the same instrumentation script will have the active measurements with the AA Stuff enabled.

demo Plan

  • A slice will be pre-created.
  • GN is loaded with a custom image called “GEMINI_GN”
  • All MP Nodes are loaded with a custom image called “GEMINI_MP”
  • Show the scripts that comprise the whole instrumentize process
  • Start the Instrumentize Process
  • Start
  • Start

Executing the demo: Hussam & Ezra

current interfaces to other entities, and message flows (like “AA-workflow”)

Both version of the instrumentation code will talk to the GENIDESKTOP Parser Service to obtain User information, Slice/Slice Credential Information and Manifest information thus making the instrumentation process somewhat independent of the Control Frameworks. NO communication between AMs/SAs and the User's instrumentation code is required since this now the work of the Parser service. A Detailed list of the Parser API and its return values is provided in this document ParserAPI.pdf.

features available now (2/5)

  • All previous Passive data collection functionality still available.
  • Drupal CMS to display passive data collected on the GN available
  • Passive data archive to irods using GSI and proxy certs

features expected to be available by GEC16 (3/19)

  • Convert Parser API backend to use OMNI inorder to make it compatible with different Control Frameworks and AMs
  • Add new Parser API call to allow the parser to store the AM list provided by the user. This is required since OMNI requires that user provide this list or else it polls every AM in its list obtained from the Clearing House, which would slow down the parser.

issues that need to be resolved before GEC16 (3/19)

  • Deploy and test the complete merged Active and Passive instrumentation code in the User Workspace and from the GeniDesktop.

3) Configuring GEMINI services, from GUI in GN, to UNIS, to services

Ahmed + others?

+ configuration (figure)

Configuration Workflow

+ summary of demo steps

No demo is shown, because the configuration web interface was blocked on getting the BLiPP configuration format finalized.

+ current interfaces to other entities, and message flows (like “AA-workflow”)

perfAdmin has already AA integrated into it, little modifications are needed to make it work with the new AA mechanism.

+ features available now (2/5)

The old perfAdmin, no need to demo it again

+ features expected to be available by GEC16 (3/19)

Ability to configure BLiPP by adding new Probes, deleting Probes or modifying existing Probes.

+ issues that need to be resolved before GEC16 (3/19)

4) Measurements, BLiPP in nodes, to MS in GN, to GUI on GN


+ configuration (figure)

Blipp Components

Blipp Data Flow

Configuration Workflow

+ summary of demo steps

Depends on what sort of interfaces we have. The plan is to port the existing perfAdmin GUI to work with the new configuration in the new UNIS. If that happens we can do a similar demo to last time as far as how it looks. All the names of different tools should look a bit more streamlined since everything is going through blipp, and there is only one measurement store, but since most of the work has been on generalizing the backend code, the demo shouldn't change much.

Now that the configuration structure has mostly settled, we can start working on interfaces to configure BLiPP. If we aren't able to port in time, the old tools are still available. It should also be pretty easy to write a quick client tool that can get and post new config from and to UNIS.

+ current interfaces to other entities, and message flows (like “AA-workflow”)

BLiPP interacts with UNIS and the MS through their well defined APIs, it doesn't expose any interface itself, although this might be something to think about in the future so that it can be commanded to reload config rather than waiting for it to poll UNIS. See figures above for details.

Blipp does reload it's config file at the same time it reloads config from UNIS, so it can be reconfigured that way, but anything that's already in UNIS will override changes in the file.

+ features available now (2/5)

+ generic scheduling
+ passive probes

+ cpu
+ memory
+ network

+ active probes

+ ping

+ more unit tests
+ measurement aggregation
+ flexible, cascading configuration structure

+ features expected to be available by GEC16 (3/19)

+ metadata reuse, either from service summary, or caching locally
+ net probe to gather port info and merge with what's already in unis
+ bandwidth probe
+ one way ping probe

+ issues that need to be resolved before GEC16 (3/19)

+ AA
+ Many more tests
+ Configuration interface

5) GENI Desktop, initing global node, displaying topology, instrumentize, displaying measurements

UKentucky Charles


  • Logon to GENI Desktop using credentials.
  • See list of existing slices.
  • Visit a new slice.
    • Page layout with map view.
    • Alternate views.
    • SSH to a node.
    • Send command to node(s).
  • Instrumentize a slice.
  • Visit an instrumentized slice.
    • Show passive graphs.
    • Show MC page.



  • Current
    • Login with credentials.
    • View list user's slices.
    • View slice's topology. Logical only if no GN.
    • SSH to nodes.
    • Send commands to nodes.
    • View MC pages.
    • View passive graphs.
  • Future
    • Transfer files to nodes.
    • View active measurement graphs.
    • Refined user interface.

Issues to be resolved before GEC16 (3/19)

  • caching for quicker page view
  • active graphs
  • more logical, cleaner, friendlier menu

6) Steps for accessing iRODS from GN via GSI

Hussam, Wesley, Jeanne, Shu

+ configuration (figure)

+ summary of demo steps

+ current interfaces to other entities, and message flows (like “AA-workflow”)

Uses proxy certs generated during the instrumentize process and copied onto the GN Node.

+ features available now (2/5)

  • Current version on archives passive measurement data and metadata.
  • There is no web-interface for the user to run this archive process
  • I am not sure if the web-interface supports GSI authentication to view the data and metadata. If this feature is not available, then it would be a really huge task for the user to view the data and metadata since the icommands are complicated form a user's viewpoint.
  • Irods account creation is outside the scope of the GEMINI Instrumentize process. The user is expected to have this account before hand.

+ features expected to be available by GEC16 (3/19)

  • Web-interface to initiate the archive process

+ issues that need to be resolved before GEC16 (3/19)

  • If there are plans for archiving Active measurement data, then that itself is a huge amount of work.

Features needed by GEC16 (3/19)


+ Image for GN

+ Image for other nodes

+ Basic host measurements, using BLiPP

+ Some active network measurements, using BLiPP

Issues that need to be resolved before GEC16 (3/19)


+ Usable on InstaGENI racks; also protoGENI?

+ Approach to first tutorial session: all demo (agree?)

+ Small-group topics for second tutorial session


Attachments (17)