GitLab

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.

parts should be harmless and have little interaction with anything else.

Other small tweaks.

allow delegation by default.

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.

(extensions).

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.

a good thing in production.

just delete the ticket instead of throwing an error.

go into the DB as null.

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.