Skip to content. | Skip to navigation

Personal tools


You are here: Home / Wiki / Serviceimplementersguide


Service Implementer's Guide

Service Implementer's Guide

This is a guide for projects implementing services in ProtoGENI slices (such as monitoring, measurement and instrumentation services), about how best to use the ProtoGENI APIs to hook in their services.

General Notes

Part of the job of the type of services envisioned will be to behave as an agent, invoking ProtoGENI operations on behalf of the user. The remainder of this document assumes familiarity with the basic ProtoGENI API -- please consult the Tutorial for an introduction.

Service Strategies

One effective technique for constructing higher level ProtoGENI services is to allow the user to allocate resources within a slice in the conventional fashion, and then provide tools which automatically augment the slice with additional software and/or additional GENI resources to provide new functionality. Please refer to the INSTOOLS project for an example of this strategy, with working source code.

Certificates and Credentials

Generally, each user should be responsible for managing his or her user certificate and corresponding private key. Your service software can assume that the user will provide both of these (as well as the passphrase to decrypt the key, when necessary). For example, the ProtoGENI test scripts assume both the certificate and the key are stored in the file $HOME/.ssl/encrypted.pem. Your code can do the same thing, or a reasonable equivalent.

However, credentials are often managed in a way that is transparent to the user. Given the certificate, it is possible to obtain a slice authority credential (and then any existing slice credentials) through the XMLRPC interface. This is generally a sensible default mode of operation, since your software can frequently obtain all the credentials required without further interaction with the user.

In certain cases (particularly when unusual credentials or delegation is involved), it will be impossible to obtain all relevant credentials automatically. Therefore, it is important to allow the user the option of supplementing (or replacing) the automatically retrieved credentials with others that are supplied manually, too.

Frequently Asked Questions

Is there a way to look up all the slices a user has activated at a particular CM?

Not directly, but a Resolve call at the user's slice authority will yield all slices created by that user. You could then iterate over all CMs of interest, asking for a Resolve on each slice name. Each one will give you the corresponding sliver, if it exists.

Is it possible to determine a user ID given only one of their credentials?

Yes. The owner field of the credential gives the ID of the principal to whom it belongs. See the protogeni/test/ script for an example of how to find the owner of a credential.

Are there examples of the slice_urn, rspec, keys and credentials[] parameters to the CM CreateSliver and DeleteSlice operations, and examples of return values?

slice_urn is a string of the form:

rspec is a string containing an XML document which might look like this:

    <?xml version="1.0" encoding="UTF-8"?>
    <rspec xmlns=""
           type="request" >
      <node virtual_id="my-node"
        <node_type type_name="pc" type_slots="1"/>
        <interface virtual_id="control"/>

keys (if used) is an XMLRPC array of structs containing type and key members (both strings), e.g.:

    [{'type': 'ssh', 'key': 'ssh-rsa
3CZpXG6DytATEapYcsKhkuok6uX9P5+IreZe0FNsKXAfJncatw== user at host'}]

where the above is shorthand for XMLRPC arrays and structs.

credentials in the most common case will simply be a list with one element (the slice credential). This will typically come directly from the SA, so the client does not need to generate it (and perhaps not even inspect it), but it will look like this:

    <?xml version="1.0" encoding="UTF-8" standalone="no"?>
     <credential xml:id="ref1">
      ---XML Signature elements (signatures and certificates) go here---

As far as responses go, the CreateSliver response (on success) is an XMLRPC struct with two members (sliver and manifest). The sliver member is a sliver credential, which looks almost identical to the slice credential example above except that the target_urn is a sliver URN instead of a slice URN, and it is signed by the CM instead of the SA. The manifest member looks like this:

    <rspec xmlns="">
      <node virtual_id="geni1" virtualization_type="raw" exclusive="1"
         sliver_urn="" />

See the docs for the specification of how the value is embedded in the XMLRPC methodResponse structure.

The return value for DeleteSlice is very simple, since it is just an indication of success or failure. The code element will be 0 on success, and non-zero otherwise (in which case output should be some descriptive string) -- again, see the ProtoGENI XMLRPC docs to see how code and value should be inserted into methodResponse.

If CreateSliver is called twice consecutively, are more resources added to the sliver, or is a new sliver created with new resources?

Actually, if a sliver already exists, a subsequent CreateSliver() call should fail with code GENIRESPONSE_REFUSED (7).

Why would the listcomponents script complain about an M2Crypto.SSL.Checker.WrongHost error?

This can indicate an incompatibility between certain versions of the ProtoGENI software and the M2Crypto Python library. Please consult the Host Name Mismatch errors page.

Is it possible to get information about which CMs my slivers currently exist on?

Yes. If you know which slice the slivers belong to, invoke a Resolve operation for that slice at the appropriate slice authority. The component_managers field in the return value will give you a list of CM URNs.

Note that this is considered informational only, not an absolute guarantee since this info can be stale (for any number of reasons).

How should I describe a slice spanning multiple CMs? Should all CMs be provided the complete rspec?

There are a number of possibilities. If you provide your whole request to a CM, it will just allocate the nodes tagged for that CM and give you a manifest with information added to those nodes. The only time it is necessary to give a CM a more complete view of your topology is when you are stitching CMs together (as with tunnels).

With a tunnel, you should send a request with nodes on both sides of the tunnel to both CMs. Usually, the easiest thing to do is create one large request and send it to everyone.

Further Information

Online Documentation

Contact Details

Questions about service implementation should be directed to the mailing list. Archives of the list are also available.