used in the database, for backward compatibility.

https://www.protogeni.net/trac/protogeni/wiki/ComponentManagerAPI

to ticket when there were no links in the rspec. 3) Print the rspec
out only when there is an error redeeming it, to reduce the amount of
email. 4) Fix check in updatesliver that looks for existing links; was
tearing them down cause the test was wrong.

test/tuntest.py wrt putting the sliver_uuid into the rspecs.

Added "hostname" to host resolve.
Added check for "protogeni_exclude" attribute when filling a
wildcarded uuid.

support. Can even create multiple jailed nodes on the same physical
node. Sorry, no sharing of physical nodes yet (between slices).
Also no link support yet; coming later.

The syntax is an extension of the current hack syntax:

        " <node uuid=\"" + node_uuid + "\" " +\
        "       nickname=\"geni1\" "+\
        "       phys_nickname=\"geni1\" "+\
        "       virtualization_type=\"emulab-vnode\" " +\
        "       virtualization_subtype=\"emulab-jail\"> " +\
        " </node>"

This only works on sites that already can do jails.

to the Geni Public License at http://www.geni.net/docs/GENIPubLic.pdf,
whose expansion at this time is:

-----
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and/or hardware specification (the "Work") to
deal in the Work without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Work, and to permit persons to whom the Work
is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Work.

THE WORK IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE WORK OR THE USE OR OTHER DEALINGS
IN THE WORK.

its really a hugely stripped down Emulab boss install, using a very
short version of install/boss-install to get a few things into place.

I refactored a few things in both the protogeni code and the Emulab
code, and whacked a bunch of makefiles and configure stuff. The result
is that we only need to install about 10-12 files from the Emulab
code, plus the protogeni code. Quite manageable, if you don't mind
that it requires FreeBSD 6.X ... Still, I think it satisfies the
requirement that we have a packaged clearinghouse that can be run
standalone from a running Emulab site.

meaningfully delegate a subset of available privileges, so that the
delegate is permitted to invoke only a restricted set of operations.

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.