GitLab

slivers and tickets. There is no way to look into these tables yet.
Need to do something about a web interface to Geni before too long.

allow you to find out the status of your sliver. As you can guess, one
takes a sliver credential and the other takes the slice credential.
See the test scripts test/slicestatus.py and test/slicestatus.py. Both
calls return the same thing. In pythonese:

{'status': 'notready',
 'details': {'de9803c2-773e-102b-8eb4-001143e453fe': 'notready'}
}

The 'status' is a summary of the entire aggregate; if all nodes are
ISUP then the status is 'ready'

The details is an array of the status of each sliver, indexed by the
sliver uuid.

Probably need to define a better set of status indicators, but this is
the one that was bothering me the most.

listusage script gets the list of CMs from the clearinghouse DB, and
calls the ListUsage() method on each one. The return is a list of
slices (gids) and for each slice, a list of slivers that represent
nodes. Currently just for debugging other CMs, but eventually will be
used to populate the clearinghouse DB with an informational snapshot
of the federation.

code.

Also, as a debugging aid, if you request a ticket for a slice, and
that slice already has a ticket, delete the ticket and generate a new
one.

You can now wildcard the node uuid and abd interface name in links:

        <node uuid="*"
              nickname="geni1"
              virtualization_type="emulab-vnode">
        </node>
        <node uuid="*"
              nickname="geni2"
              virtualization_type="emulab-vnode">
        </node>
        <link name="link0" nickname="link0">
         <linkendpoints nickname="destination_interface"
                   iface_name="*"
                   node_nickname="geni1"
                   node_uuid="*" />
         <linkendpoints nickname="source_interface"
                   iface_name="*"
                   node_nickname="geni2"
                   node_uuid="*" />
        </link>

So after the nodes are allocated, fill in the rest of the details in
the link part, including finding interfaces. The rspec is updated for
returned ticket.

The same approach can used for tunnel testing, but in that case you
allocate tickets to get the nodes, dig out the uuids, and then do an
UpdateSliver(), adding the tunnel specs.

Lots of corner cases that I am ignoring and recovery from errors is
just as crude. See xmlrpc/client.py ...

working program agents! Yippie.

vlans.

Checkpoint working swapin of experiments using multiple federated nodes with vlans between them. Now I need to figure out how to swap the experiment out

program protogeni/xmlrpc/client.py ... it is much easier to get a
simple python client running on your desktop then a perl client. Only
package you need to install is M2Crypto, which is easy. Perl needs
about 10 packages installed to xmlrpc over ssl. Sheesh.

completely raw links; just a vlan between two interfaces. No traffic
shaping or anything like that.