GitLab

via the Geni API, which have hard to guess project names).

	boss> wap perl prereserve emulab.net:testbed 1

At the remote cluster, you prepend the domain of the SA (for the portal,
that is emulab.net) to the project name at the portal.  prereserve will
find the correct project, assuming at least one experiment has ever been
created on the remote cluster. If not, then this trivial little hack will
not work.

reserved_pid set; they now count and get reserved_pid set.

That sort order is: reservations that need nodes, priority, creation date.
It used to be: priority, pid.

The new order makes the most sense for reservations that still need nodes,
so you can see easily where they are going to land first.

This commit is intended to makes the license status of Emulab and
ProtoGENI source files more clear.  It replaces license symbols like
"EMULAB-COPYRIGHT" and "GENIPUBLIC-COPYRIGHT" with {{{ }}}-delimited
blocks that contain actual license statements.

This change was driven by the fact that today, most people acquire and
track Emulab and ProtoGENI sources via git.

Before the Emulab source code was kept in git, the Flux Research Group
at the University of Utah would roll distributions by making tar
files.  As part of that process, the Flux Group would replace the
license symbols in the source files with actual license statements.

When the Flux Group moved to git, people outside of the group started
to see the source files with the "unexpanded" symbols.  This meant
that people acquired source files without actual license statements in
them.  All the relevant files had Utah *copyright* statements in them,
but without the expanded *license* statements, the licensing status of
the source files was unclear.

This commit is intended to clear up that confusion.

Most Utah-copyrighted files in the Emulab source tree are distributed
under the terms of the Affero GNU General Public License, version 3
(AGPLv3).

Most Utah-copyrighted files related to ProtoGENI are distributed under
the terms of the GENI Public License, which is a BSD-like open-source
license.

Some Utah-copyrighted files in the Emulab source tree are distributed
under the terms of the GNU Lesser General Public License, version 2.1
(LGPL).

New option -s datetime to specify a starting time for the pre-reserve.
New option -e datetime to specify a ending time for the pre-reserve.

The idea is that you can schedule a pre-reserve to begin sometime later,
and you can optionally specify a time for a prereserve to terminate.
There is a new script that runs from cron that checks for pre-reserves
that need to be started or terminated.

For example:

boss> wap prereserve -s '2012-09-14 09:08:15' -e '2012-09-15' emulab-ops 50

You can use any datetime string that is valid for str2time. At some point
it would be nice to allow natural language dates ("tomorrow") but that
requires a another bunch of perl packages and I didn't want to bother.

NOTE: when using -e, -r is implied; in other words, when the
pre-reserve is terminated, the table entry is cleared *and* the
reserved_pid of all of the nodes is cleared. Any experiments using
those nodes is left alone, although if the user does a swapmod, they
could easily lose the nodes if another pre-reserve is set up that
promises those nodes to another project.

idea).

New script and table to manage node pre reservations. Lets just look
at the script.

To create a reservation:

    myboss> wap prereserve -t pc850 testbed 2
    Node reservation request for 2 nodes has been created.

To see the reservation status for testbed

    myboss> wap prereserve -i testbed
    Project         Cnt (Cur)  Creator    When               Pri Types
    -------------------------------------------------------------
    testbed         1 (1)      stoller    2011-08-12 12:39:07 0   pc850

    which says 1 node is pending and 1 node has already been
    pre-reserved. 

To clear the above reservation request (and optionally, clean
reserved_pid from the nodes table).

    myboss> wap prereserve -c -r testbed

    The -r is optional, otherwise just the reservation request is
    cleared, and nodes continue to be pre-reserved to the project.

To see a list of all reservation requests:

    myboss> wap prereserve -l


So, when a node is released in nfree, we look at the reservation
status for the node and any pending reservation requests.

1. If the node has a reserved_pid and that request is still pending
   (still in the table), nothing is changed.

2. If the node has a reserved_pid, but the request has been cleared
   from the pending table, then clear reserved_pid.

3. If reserved_pid is null, and there are pending requests, then pick
   the highest priority, most recent dated, request, and set
   reserved_pid to that project.

Options:

* -n <pri> - is how you set a priority. Lowest is zero, choose a
  higher number if you want this reservation request to be considered
  before others. In a tie, look at the date of creation, and use the
  oldest.

* -t <typelist> - a comma separated list of types you want to
  consider. Types are considered in order, but not in the fancy way
  you might imagine.

idea).

New script and table to manage node pre reservations. Lets just look
at the script.

To create a reservation:

    myboss> wap prereserve -t pc850 testbed 2
    Node reservation request for 2 nodes has been created.

To see the reservation status for testbed

    myboss> wap prereserve -i testbed
    Project         Cnt (Cur)  Creator    When               Pri Types
    -------------------------------------------------------------
    testbed         1 (1)      stoller    2011-08-12 12:39:07 0   pc850

    which says 1 node is pending and 1 node has already been
    pre-reserved. 

To clear the above reservation request (and optionally, clean
reserved_pid from the nodes table).

    myboss> wap prereserve -c -r testbed

    The -r is optional, otherwise just the reservation request is
    cleared, and nodes continue to be pre-reserved to the project.

To see a list of all reservation requests:

    myboss> wap prereserve -l


So, when a node is released in nfree, we look at the reservation
status for the node and any pending reservation requests.

1. If the node has a reserved_pid and that request is still pending
   (still in the table), nothing is changed.

2. If the node has a reserved_pid, but the request has been cleared
   from the pending table, then clear reserved_pid.

3. If reserved_pid is null, and there are pending requests, then pick
   the highest priority, most recent dated, request, and set
   reserved_pid to that project.

Options:

* -n <pri> - is how you set a priority. Lowest is zero, choose a
  higher number if you want this reservation request to be considered
  before others. In a tie, look at the date of creation, and use the
  oldest.

* -t <typelist> - a comma separated list of types you want to
  consider. Types are considered in order, but not in the fancy way
  you might imagine.