Re: CF Requirements: 3) Slice Controller

> 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.
>  
>