Re: CF Requirements: 3) Slice Controller

I mostly agree with your statements here, so I'll only point out the
places where my opinion differs.

Thus spake Jeff Chase on Thu, Mar 19, 2009 at 12:18:40PM -0400:
> Q1: Is the "slice controller" always required in a GENI suite?
>
> I suggest we use the term "slice controller" (SC) for any entity that
> speaks control plane protocol in the role of an "experimenter".  That is, a
> "slice controller" is any entity that issues resource discovery requests to
> a Clearinghouse (CH), or requests tickets from a CH broker service, or
> presents tickets to a component/aggregate manager (AM), etc.

I believe that elsewhere in GENI documents, this is referred to as a
"Slice Manager" (SM).
 
> That's a pretty minimal set of assumptions, and it would accommodate a wide
> range of implementations to play the role of "slice controller" in the
> control framework.  It could be a standalone program that a researcher
> runs, or it could reside within a web server operated by the testbed or a
> participating institution.  In Orca/Shirako it can be either of these
> things---same code.  
> So my answer would be yes, SC is always required, unless we decide to
> introduce more terms to distinguish among different flavors of what I am
> calling SC.

ProtoGENI provides a number of simple command-line scripts for creating
slices, allocating slivers, etc. I don't really think of these as an
SC/SM, just a thin wrapper around the API calls themselves. I'm not sure
when something crosses the line between a simple client for the
CM/CH/etc. API to an SC/SM, but I don't think that every standalone tool
that a research might use is necessarily an SC/SM.

So I would say an SC/SM is not strictly required - a suite without one is
going to be harder to use, since it's going to require users to roll
their own tools more, but I think it's still a complete, usable suite.
 
> Q3: Should the slice controller typically represent one researcher?  One
> research organization?  Or?
>
> The SC operates on behalf of a slice owner, whatever that is.  In our code
> today it is limited to operate on behalf of one user, but it should not be
> architecturally limited in that way.

The set of users that are allowed to look at, manipulate, etc. a slice
is defined only by who hold credentials allowing them to do these
things. It's not the SC/SM's role to make any decisions regarding this.
So I would make a subtle distinction with what you say above - it's not
operating on behalf of the slice owner, it's operating on behalf of
anyone who has the appropriate credentials to control the slice.
 
--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

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