« Return to Thread: clearinghouses (or not)

clearinghouses (or not)

by Larry Peterson :: Rate this Message:

Reply to Author | View in Thread

We've recently been evaluating our approach to geniwrapper, and
I thought there might be value in getting input from the broader
community.

Our geniwrapper module currently includes an aggregate manager (AM)
that exports the slice interface -- there is (will be) an AM for PlanetLab,
an AM for PlanetLab-Europe, an AM for PlanetLab-Japan, an AM for
VINI, an AM for M-Lab, and so on.

We then have a Slice Manager  (SM) that is configured to know about
a set of Aggregates. It currently runs as a server that happens to be
co-located with the PlanetLab AM. A researcher, using his or her favorite
interface (we currently support a Unix-command line program called
SFI -- Slice Facility Interface) contacts the SM to create/control a slice.
The SM, in turn, contacts one or more AMs carry out the requested
operation. In a nutshell, the SM implements "deals with a slice that
spans multiple aggregates" functionality.

On the one hand, this SM is sort of like the GPO's Clearinghouse -- one
stop shopping for all your slice needs. On the other hand, it has always
been our expectation that there will be multiple SMs, that in the limit,
each user is free to create his or her own private SM. As long as they
have the credentials expected by a given AM, they are free to ask it to
create a slice on their behalf.

As we gain experience with the implementation, we are more and more
coming to realize that there is little value in the shared (server-side) SM.
That each user is better off running the SM-like functionality on his or
her desktop. Each Aggregate announces and enforces its own peering
policy, where the user queries the Registry to learn what Aggregates are
available. The user is free to modify the SM (we assume plenty of open
source SMs are available), and MOST IMPORTANTLY, we remove the
burden of creating a one-size-fits-all SM (and a one-size-fits-all rspec
that describes to that SM exactly what the user wants).

One consequence of having client-side code know about multiple AMs
is that this moves us away from a model where a Clearinghouse
processes credentials on our behalf -- the AMs need to support the full
credential-based authorization mechanism. (I believe this is the right
thing to do in any case, but once you get the Clearinghouse out of the
loop, I think you have to go down this path.)

Anyone care to comment on the general issue of these competing
strategies:

   User manages multiple Aggregates (SM functionality runs on client
   and user requests go directly to the aggregates)

versus

   Clearinghouse manages multiple Aggregates (SM functionality runs
   on server with all user requested funneled through the SM)

Larry

_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg

 « Return to Thread: clearinghouses (or not)