Omni Configuration File Structure

Configuration file structure

An Omni configuration file is constructed from the following sections:

• [omni]: mandatory, it includes general information, including which control framework to use by default, and which users should have access to allocated resources
• [<Control Framework>]: at least one should be present, the one mentioned in the omni section. Provides information about the CF the user has a GENI account with
• [<user>]: optional, although a configuration file is valid with no user sections, all users that are specified in the omni section should be present. Note: If no users are specified in the configuration file, no SSH keys are going to be uploaded to compute resources (e.g. ProtoGENI hosts) and thus you won't be able to access the hosts.
• [aggregate_nicknames]: optional, this section includes nicknames for commonly used AMs

[omni] section

There is only one [omni] section and it has general configuration parameters for Omni. It includes the following attributes:

Attribute	Required?	Description
default_cf	yes	Default Control Framework used if not specified on the command line. The value of this attribute should correspond to a section in the file that provides details about the CF. E.g. if default_cf=pgeni, there should be a [pgeni] section later in the file.
users	no	A comma separated list of users. Each user should correspond to a section in the file that provides user details. E.g if users = nriga, sedwards ; sections [nriga], [sedwards] should be present later in the file.
aggregates	no	When the '-a' command line option is not provided, Omni will contact all AMs that are listed here. This should be a comma separated list of URLs. If this is not present and the '-a' command line option is not provided, Omni will ask for a list of AMs from the Control Framework that is currently being used.

[<Control Framework>] section

As a user in order to be able to reserve resources in GENI, you need to have credentials from at least on of the GENI clearinghouses. A clearinghouse is part of a control framework. A control framework section in Omni provides information to Omni on how to contact different parts of the control framework as well as what credentials to use to authenticate you with the control framework. If you have credentials from multiple clearinghouses, you can have multiple control framework sections and can switch between control frameworks using the '''-f''' option of Omni and the name of that section of the config file. E.g. if there is a section called [pgeni], you can choose to use this framework by running omni.py -f pgeni.

There should be at least one control framework section, the one that is pointed to by the default_cf attribute of the [omni] section.

There are three types of Control Frameworks supported:

• sfa CF: this is the PlanetLab control framework and should be used if you have an account with PlanetLab
• pg CF: this is the ProtoGENI control framework and should be used if you have an account with any ProtoGENI cluster (e.g Utah, GPO)
• gcf CF: this is the prototype GENI control framework and should be used only if you run a local gcf to test, for example, the installation of Omni. The gcf software is distributed along with Omni.

Based on the type of control framework different attributes are available:

Attribute	Required?	Framework	Description
type	yes	all	specifies the type of the control framework; options: sfa, pg, gcf
verbose	no	pg	this specifies how verbose the control framework should be, it is used for debugging purposes
ch	yes	pg, gcf	this attribute provides the URL for the clearinghouse
registry	yes	sfa	this attribute provides the URL for the clearinghouse
sa	yes	pg, gcf	this attribute provides the URL for the slice authority
slicemgr	yes	sfa	this attribute provides the URL for the slice authority
authority	yes	gcf, sfa	The HRN (Human Readable Name) of the the site that issued the user credentials, e.g. plc.bbn
user	yes	sfa	the username with the CF, for PlanetLab this is usually the authority '.' username, e.g. plc.bbn.nriga
cert	yes	all	the location on the local host of the file that contains your SSL certificate that will authenticate you with the clearinghouse and the slice authority. For ProtoGENI control frameworks you would need to generate and download the certificate from the web UI. For Planetlab control frameworks the certificate will be downloaded the first time the user interacts with the clearinghouse. For gcf control frameworks the cert is created when you run the gen-cert.py script.
key	yes	all	the location on the local host of the file that contains the private key that matches the user certificate. For ProtoGENI control frameworks the private key is usually part of the certificate file, so you need to point this to the same place as the cert attribute. For Planetlab control frameworks this is the key that corresponds to the public key that is uploaded to your account with Planetlab.

[<User>] section

Each user section corresponds to a user of the slice. Each section provides information to the aggregates that care about who will be logging in and how. This information is used only in the createsliver call. There can be multiple user sections in a configuration file. The ones that are used when createsliver is invoked are the ones that are specified in the users attribute of the omni section.

The attributes of a <user> section are:

Attribute	Required?	Description
urn	yes	the user urn from the control framework that gave you your credentials. The urn is part of your certificate, look here for how to get your urn.
keys	yes	a comma separated list of the locations on the local host of public SSH keys that are going to be installed on compute resources so that the user can access the hosts using ssh (as well as the location of the corresponding private keys).

[aggregate_nicknames] section

This section contains a list of nicknames for Aggregate Manager (AM) URLs. When interacting with a specific AM, the URL of the AM should be provided to Omni through the '-a' option. Remembering the exact URL becomes a daunting task. In this section you get to assign easy-to-remember nicknames for the AMs you want to use. The syntax is : <nickname>=URN, URL. The URN is optional.

Examples :

[aggregate_nicknames]
# Nickname=URN,URL
# You can leave the URN out
pg-gpo=urn:publicid:IDN+pgeni.gpolab.bbn.com+authority+am,https://pgeni.gpolab.bbn.com:12369/protogeni/xmlrpc/am
pg-utah=,https://www.emulab.net:12369/protogeni/xmlrpc/am
plc=,https://www.planet-lab.org:12346