RO_configuration

Home > Configuration > RO

---

Disclaimer: The following configuration manual assumes that installation of the whole software has been done according to the installation manual.

Configuration options

The configuration files are located under modules/resource/orchestrator/conf. There are two possible possible running modes for RO: Master RO (MRO) or RO. Configuration differs a little between them.

Configuration for MRO

Some settings must be changed:

• auth.conf:
• In section [clearinghouse]:
  • Verify that the data to access the Clearinghouse is accurate (e.g. if you have N CHs in a server)
• flask.conf:
• In section [general]:
  • Set host and port to proper values, pointing to MRO. Example: 127.0.0.1, 18440
• ro.conf:
• In section [master_ro]:
  • Set mro_enabled = True
• In section [monitoring]:
  • Set address and port to proper values, pointing to MMS. Example: 127.0.0.1, 18448

Configuration for RO

The default settings files (auth.conf, flask.conf, geniv3.conf, log.conf, ro.conf) should be left in their original form.

• Note: some data may be changed to correctly point to your installations (e.g. CH host/port)

Configuration for monitoring

For each component, a *.json.example file is provided for reference. Copy each of them and remove the "example", then fill with proper data.

cp crm.json.example crm.json
cp sdnrm.json.example sdnrm.json
cp serm.json.example serm.json

The result files crm.json, sdnrm.json and serm.json must be filled with appropriate data (e.g. "organisationName" replaced by your real organisation's name, etc) for an RO instance (that is, an instance running as RO, not MRO). These are needed to monitor the physical devices (i.e. servers, OpenFlow switches, Stitching Entity switch) that are advertised through the RMs.

Managing peers

Both MRO and RO keep a list of peers (typically, ROs for MRO and RMs for RO). This list is used to steer the experimenter requests and also to periodically update the resources.

Adding managed peers

The data can be inserted either by the manage.py script or using the configure_rms.sh interactive script:

1. Using the interactive script:

• cd modules/resource/orchestrator/deploy

• ./configure_rms.sh

  • There are four types of resources to choose from: c, sdn, se, tn, ro (the latter one being used only in MRO):

./configure_rms.sh

Configuring Resource Orchestrator... Filling database with config entries... Choose the RM to configure [c,sdn,se,tn,ro] (any other to quit): ```

1. Using directly the admin script:

• cd modules/resource/orchestrator/src/admin/db

• You may add, delete or dump entries so that RO can communicate with your RMs:

  • Syntax: python manage.py [add_route_entry|delete_route_entry|dump] [params]
  • Parameters (only for add/delete):
    • $type can be one of virtualisation, sdn_networking, stitching_entity, transport_network or island_ro (the latter one being used only in MRO)
    • $host_ip, $host_port is the IP and port where the RM is listening
    • $protocol is usually https or http
    • $am_type, $am_version, usually set to type geni and version 3
    • $endpoint URI where the API is exposed, e.g. /xmlrpc/geni/3/
    • Others: --user, --password may be added iff needed to provide BasicAuth
  • Adding entry:

  python manage.py add_route_entry -t "$type" -a "$host_ip" \
  -p "$host_port" --protocol "$protocol" --endpoint "$endpoint" \
  --am_type "$am_type" --am_version $am_version
  

  • Removing entry:

    python manage.py delete_route_entry -t "$type" -a "$host_ip" \
    -p "$host_port" --protocol "$protocol" --endpoint "$endpoint" \
    --am_type "$am_type" --am_version $am_version
    

  • Dumping all entries:

  python manage.py dump
  

Checking managed peers

The list of RMs and ROs managed by RO or MRO can be consulted in two ways:

• Script: admin script (as explained above)
• Web: at the endpoint http://<ro_host>:<ro_port>/peers

SFA and GENI procedures

Allowing requests to the SFA and GENIv3 interfaces

The last step relates to the management of the clients that are allowed to communicate against the GENIv3 API of the RO. As with C RM and SDN RM, RO requires to authorise the certificate of the clearinghouse that issues the credentials of the client you want to allow.

The CH/CA certificate of each allowed clearinghouse must be copied in the trusted folder of RO:

1. Stop the RO or MRO service
2. Add the certificate of the client's clearinghouse in the RO or MRO trusted folder. Depending on the clearinghouse used:

ro_cert_trusted=<path_to_ro>/modules/resource/orchestrator/cert/trusted/

# When using the GENI Control Framework and Clearinghouse...
cp -p ~/.gcf/ch-cert.pem $ro_cert_trusted/felix-<organisation>-gcf-ch.pem
# When using the C-BAS (own island)...
cp -p <path_to_cbas>/deploy/trusted/certs/ca-cert.pem $ro_cert_trusted/felix-<organisation>-cbas-ca.pem
# When using the C-BAS (other island)... Request their CA certificate first!
cp -p ca-cert.pem $ro_cert_trusted/felix-<organisation>-cbas-ca.pem

• Note: ensure that this file is unique, i.e. not previously saved under other name or coincident

1. Restart the RO or MRO service