CF Requirements: 3) Slice Controller

[Harry Mussman]

GENI Control Framework WG Members, interested GENI participants, and
Jeff Chase of Duke,


A first DRAFT (v01.3) of the GENI Control Framework Requirements
document has been completed, and can be found at
http://groups.geni.net/geni/wiki/GeniControlFrameworkRequirements 

A discussion of the document on February 25, 2009 resulted in the
identification of 10 discussion items, which can be found at
http://groups.geni.net/geni/attachment/wiki/GeniControlFrameworkRequir
ements/030609_CFRequireReviewTopics.pdf



This email begins a discussion thread on:  3)  Slice Controller

I would like to invite Jeff Chase of Duke to begin the discussion, and
then others are invited to join in.  



2a)  During the discussion, the key elements in a GENI suite were
discussed, including the "triangle" of Researcher, Aggregate (with
Components) and Clearinghouse.

In his detailed comments for the document, Jeff suggested that a
"Slice Controller" should become a first-class entity (element),
associated with the researcher, that controls and monitors a slice.  
Jeff defined "first class" to mean that it is persistent, so that
other actors in the control framework, or slivers in its slice, can
send unsolicited messages/notifications to it.  And, it may respond by
taking autonomous actions to control the slice on behalf of an
experimenter.
Harry noted that this is in keeping with the current PlanetLab, the
ProtoGENI and ORCA prototypes.

2b)  The current DRAFT talks of:  
"A principal acting from a server utilizing a browser client or a set
of helper tools".  So, there is talk of a "server' and "helper tools",
but no slice controller.

2c)  Discussion:
All of the current prototype implementations include some form of
"slice controller" (or slice manager).
In PlanetLab, it is part of PLC.  
In ProtoGENI, it is associated with the Researcher.  
In ORCA, it is called the Slice Manager.  
All hold state specifying the slice.

2d)  A proposed change to the CF requirements:
Each suite includes one or more Slice Controllers
(this must also be reflected in the GENI System Overview)

Each slice controller:
Associated with one (or more) researchers.
Trusted to properly represent the researcher(s)

"First class" entity
Persistent, so that other actors in the control framework, or slivers
in its slice, can send unsolicited messages/notifications to it.  

Interacts with clearinghouse and aggregates.
Discovers, plans, requests, acquires, and controls resources from
aggregates.
Keeps state.
If gets firm reservations, it keeps a calendar of committed resources.

2e)  Continued discussion:
Is the "slice controller" always required in a GENI suite?
Must the "slice controller" be persistent?
Should the slice controller typically represent one researcher?  One
research organization?  Or?
Is it important to specify where it is located?
Do we need to define the interface between the slice controller and
the researcher?
How does the "slice controller" present a "trust assertion" to an
aggregate?



We look forward to a continuing, lively discussion, working towards a
'rough consensus".

Harry E. Mussman
Control Framework Systems Engineer

GENI Project Office
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[phone] - Office
[phone] - Mobile
[phone] - Fax
hmussman@...
www.bbn.com



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

[Jeff Chase]

Harry asked me to kick off this discussion, so I'll do that by summarizing my views on the discussion questions he asked about "slice controller".  The slice controller corresponds to what we have called "guest controller" or "service manager" in the Orca work and its predecessors (Shirako and SHARP).


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.

So then the question becomes: what is the nature of the SC, i.e., what can/must the other control plane actors assume about an SC?  What qualifies as an SC?  SC could (or should) be a researcher-replaceable (or customizable) entity,  so only the researcher trusts it.  No other part of the system trusts it to maintain hard state or to do anything other than make requests on behalf of the researcher.  However, SC is permitted (but not required) to register and serve callback interfaces for status notifications and the like.  For this reason we generally presume there is exactly one SC per slice (although one SC could control many slices).  I think this accommodation of callbacks to the SC is the only substantive change being proposed here by introducing an SC to flesh out the generic concept of "experiment control tools".

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.

Q2: Must the "slice controller" be persistent?

It is helpful for the SC to be persistent, and in Orca/Shirako it is persistent, but if it fails permanently or forgets its state, then it does not harm the system.  Except in one way: the resources it has allocated are not reclaimed until their leases expire.

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.

Q4: Is it important to specify where it is located?

No, but it has to be reachable through the GENI control network, e.g., the public Internet.

Q5: Do we need to define the interface between the slice controller and
the researcher?

"Let a thousand flowers bloom."

Q6: How does the "slice controller" present a "trust assertion" to an
aggregate?

The SC holds one or more private keys and it wields credentials anchored in some identity provider to endorse its corresponding public keys.  The credential could be a PKI/509 cert and/or something else...but that is an orthogonal set of questions.

Jeff


Harry Mussman wrote:

> GENI Control Framework WG Members, interested GENI participants, and
> Jeff Chase of Duke,
>
>
> A first DRAFT (v01.3) of the GENI Control Framework Requirements
> document has been completed, and can be found at
> http://groups.geni.net/geni/wiki/GeniControlFrameworkRequirements 
>
> A discussion of the document on February 25, 2009 resulted in the
> identification of 10 discussion items, which can be found at
> http://groups.geni.net/geni/attachment/wiki/GeniControlFrameworkRequir
> ements/030609_CFRequireReviewTopics.pdf
>
>
>
> This email begins a discussion thread on:  3)  Slice Controller
>
> I would like to invite Jeff Chase of Duke to begin the discussion, and
> then others are invited to join in.  
>
>
>
> 2a)  During the discussion, the key elements in a GENI suite were
> discussed, including the "triangle" of Researcher, Aggregate (with
> Components) and Clearinghouse.
>
> In his detailed comments for the document, Jeff suggested that a
> "Slice Controller" should become a first-class entity (element),
> associated with the researcher, that controls and monitors a slice.  
> Jeff defined "first class" to mean that it is persistent, so that
> other actors in the control framework, or slivers in its slice, can
> send unsolicited messages/notifications to it.  And, it may respond by
> taking autonomous actions to control the slice on behalf of an
> experimenter.
> Harry noted that this is in keeping with the current PlanetLab, the
> ProtoGENI and ORCA prototypes.
>
> 2b)  The current DRAFT talks of:  
> "A principal acting from a server utilizing a browser client or a set
> of helper tools".  So, there is talk of a "server' and "helper tools",
> but no slice controller.
>
> 2c)  Discussion:
> All of the current prototype implementations include some form of
> "slice controller" (or slice manager).
> In PlanetLab, it is part of PLC.  
> In ProtoGENI, it is associated with the Researcher.  
> In ORCA, it is called the Slice Manager.  
> All hold state specifying the slice.
>
> 2d)  A proposed change to the CF requirements:
> Each suite includes one or more Slice Controllers
> (this must also be reflected in the GENI System Overview)
>
> Each slice controller:
> Associated with one (or more) researchers.
> Trusted to properly represent the researcher(s)
>
> "First class" entity
> Persistent, so that other actors in the control framework, or slivers
> in its slice, can send unsolicited messages/notifications to it.  
>
> Interacts with clearinghouse and aggregates.
> Discovers, plans, requests, acquires, and controls resources from
> aggregates.
> Keeps state.
> If gets firm reservations, it keeps a calendar of committed resources.
>
> 2e)  Continued discussion:
> Is the "slice controller" always required in a GENI suite?
> Must the "slice controller" be persistent?
> Should the slice controller typically represent one researcher?  One
> research organization?  Or?
> Is it important to specify where it is located?
> Do we need to define the interface between the slice controller and
> the researcher?
> How does the "slice controller" present a "trust assertion" to an
> aggregate?
>
>
>
> We look forward to a continuing, lively discussion, working towards a
> 'rough consensus".
>
> Harry E. Mussman
> Control Framework Systems Engineer
>
> GENI Project Office
> BBN Technologies
> 10 Moulton Street
> Cambridge, MA 02138
> [phone] - Office
> [phone] - Mobile
> [phone] - Fax
> hmussman@...
> www.bbn.com
>
>  

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

[Robert P Ricci]

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

[Jeff Chase]

Robert P Ricci wrote:
> I mostly agree with your statements here, so I'll only point out the
> places where my opinion differs.
>  
The idea of Slice Controller as I characterized it would not rule out
that there could be other supporting tools that the researcher uses.  
So I don't think we differ in any substantial way.

Can you (or someone) offer a cite for the definition of "Slice Manager"
in other GENI docs?

thanks,
Jeff

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

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

[Robert P Ricci]

Thus spake Jeff Chase on Thu, Mar 19, 2009 at 01:35:09PM -0400:
> Can you (or someone) offer a cite for the definition of "Slice Manager"
> in other GENI docs?

I don't think it's really defined anywhere, only mentioned - and I think
the main mention of it is in documents produced by the PlanetLab folks
which have gotten rolled into GENI documents such as the CFA. For
example, it's mentioned on pages 72 and 82 of the CFA 1.4 available
here:
    http://groups.geni.net/geni/wiki/GeniControlFrameworkArchitecture

My point wasn't that there is an actual definition we ought to be using
- we still need to come up with that definition. But if an SC and an SM
are really the same thing, we can at least reduce confusion by sticking
with one of those terms (I personally don't care which one).

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

[Jeff Chase]

Jeannie,

Your message raises a number of interesting issues about the structure
of slice controllers.  I'm cc'ing the services-wg because I think it
points the way for a discussion there about the "ecosystem" of
experiment control tools and how they interface to the control framework.

To answer your question, I do consider Gush to be a "full-blown" slice
controller (SC) in the best way: it serves as the experimenter's primary
interface to the control framework (CF), it is programmable, and it
persists to monitor the slice and adapt it as needed to meet the
experimenter's objectives.

I agree that the SC is largely independent of the underlying CF.   For
example, most of the heavy lifting in Gush involves interacting with the
experiment itself and supporting code running within the slivers.  That
part is generally independent of the CF.

Even so, the connection to the CF is crucial: from the point of view of
other entities (actors) in the CF, Gush is the thing that issues the
user's requests to obtain resources and launch slivers and stitch them
into a slice.    That is why it is important to have a name in the CF to
talk about that thing.

And I prefer the name "slice controller" over "experiment controller"
for that purpose, for two reasons.   First, when we talk about it from
the point of view of the CF, we only care about its interactions with
the CF, and those interactions focus on controlling the slice,
independent of any richer experiment control functions it might also
have.  Second, it will someday be that not every slice is an experiment.
  Anyway, as noted in an earlier message, for GENI there could be many
different experiment control tools involved, but from the point of view
of the CF it seems reasonable to talk about each SC as a single logical
actor, especially if it defines an endpoint for receiving callbacks.  

Moving outside of control-wg and into services-wg, we should consider
how tools and functions can be layered above a common programmable SC
core to build more sophisticated controllers that control the experiment
and the slice it runs in together.   Gush is a good example that shows
how the programmable toolkit approach can work.  I like to think of it
as a single controller actor that has both slice control and experiment
control functions.  I persist in thinking of it that way even though the
Gush-over-Orca implementation is a little awkward because Gush is
written in C++ and the Orca core (Shirako) is written in Java, so we had
to run two separate processes and lash them together with XML-RPC.  

Since a key objective is to make GENI easy to use, we want the
slice/experiment controllers to be easy to program and we want the code
to be maximally reusable.   That is always hard, but declarative
representations of experiments (like your ExpSpec suggestion) seems the
right ideal to pursue.   Orca's slice controller toolkit is more
procedurally oriented, so it is rather primitive in that
respect...unless it is running something like Gush layered above it.  
But that is one area where I think Orbit really excels (cf. Max Ott's
slides from the GEC 3 services-wg meeting).  Gush and Orbit are the
right places to start from with that, IMHO, unless there are other
ExpSpecs that I am not yet aware of.

Jeff



Jeannie Albrecht wrote:

> Hi Jeff,
> Just to make sure I'm understanding your views, would you consider
> Gush a SC?  If seems to me that Gush is a slice controller, and if
> that is the case, I also mostly agree with your ideas.
>
> One point that I'd like to emphasize is that I think the functionality
> of the SC should be largely independent of the underlying control
> framework.  I realize that we have all been assigned to control
> framework clusters, which may make this difficult, but ultimately I
> feel that the needs of the SC and more generally the
> experimenter/researcher should be an almost entirely separate
> discussion from that of the underlying control framework structure.
> Clearly some of the implementation details (e.g., communication with
> the Clearinghouse) might be tied to a specific control framework in
> the short term, but I believe that a single SC could actually work
> across Clearinghouses.  Or maybe there needs to be an Experiment
> Controller that is built on top of a Slice Controller, so the slice
> controller handles only CF-specific actions. (This is basically how
> we've structured Gush to work with both PlanetLab and Orca using the
> same front-end.)  Then multiple control frameworks could essentially
> co-exist in GENI, and researchers would only have to know one
> interface/front-end for managing experiments.
>
> As we flesh out the requirements of the SC, at some point we should
> start thinking about what defines a GENI experiment.  (Although
> perhaps the experiment workflow working group is a better place for
> that discussion.)  We have had numerous discussions on RSpecs, for
> example, but as far as I know we have yet to talk about an ExpSpec
> (experiment specification language).  How should a GENI researcher
> define a GENI experiment?  I personally believe that one component of
> an ExpSpec is an Rspec, but there are many other factors to consider
> here as well.  Similarly, as we move forward with the discussion of
> Slice Controllers, it might be useful to talk about exactly what level
> of control are we defining.  I'm assuming that the SC is responsible
> for controlling experiments.  Are Experiment Controllers and Slice
> Controllers the same thing, or should they actually be viewed as
> separate components in the GENI architecture?
>
> Jeannie
>
>
>  

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

[Max Ott-2]

I guess this is the area where most of my energy has gone over the  
last few years :)

On 20/03/2009, at 5:24 AM, Jeannie Albrecht wrote:
> One point that I'd like to emphasize is that I think the functionality
> of the SC should be largely independent of the underlying control
> framework.

This won't be possible as the SC needs to interface with it. It needs  
to obtain the resources the experimenter wants and needs to  
(optionally) tracking the state of the assigned resources.

Now, given that we are trying to come up with a common architecture  
and common data/resource models it shouldn't be that difficult to  
target a specific SC to a different control framework.

You mentioned that you have done that already for more than one and it  
also didn't take us long to get our version of the SC running on top  
of Planetlab. We haven't tried any other ones.

> but I believe that a single SC could actually work
> across Clearinghouses.

Yes, that is very important and it's one of our deliverables (not in  
the GENI context) to support experiments across federated testbeds  
which will have separate CHs.

> Or maybe there needs to be an Experiment
> Controller that is built on top of a Slice Controller, so the slice
> controller handles only CF-specific actions. (This is basically how
> we've structured Gush to work with both PlanetLab and Orca using the
> same front-end.)  Then multiple control frameworks could essentially
> co-exist in GENI, and researchers would only have to know one
> interface/front-end for managing experiments.

That's more a pragmatic approach. You either wait for all the control  
frameworks to agree on common interfaces or you write your own glue to  
the common abstraction you think is most useful. Should be a pretty  
easy choice :)

> As we flesh out the requirements of the SC, at some point we should
> start thinking about what defines a GENI experiment.  (Although
> perhaps the experiment workflow working group is a better place for
> that discussion.)  We have had numerous discussions on RSpecs, for
> example, but as far as I know we have yet to talk about an ExpSpec
> (experiment specification language).  How should a GENI researcher
> define a GENI experiment?  I personally believe that one component of
> an ExpSpec is an Rspec, but there are many other factors to consider
> here as well.

I fully agree that we need ways to describe experiments. However,  
there is no pressing need to standardize that or agree on one as this  
will initially be just between the researcher and their tool. Having  
said that, I have been preaching for years that a fundamental  
requirement for supporting repeatable experiments is the ability to  
describe it and fully capture all externalities. What I want to see at  
some stage is that any graph in a paper showing experimental results  
is referencing the experiment description it used - enabling others to  
repeat the experiment.

Now, I'm not sure if ExpSpec has the right connotation. First of all,  
RSpec won't be sufficient as we need to capture relationships as well,  
but I'm repeating myself.

I believe it needs something more like a language. In Orbit we have  
OIDL, which is effectively a domains specific language (DSL) built on  
top of Ruby, but most experimenters need to know very little about  
that. What is more important is the programming model. In our case the  
experimenter first describes all the resources they need (here is the  
link to resource descriptions and what's need to be requested from the  
various AMs and their respective CHs) and then they describe the  
"orchestration" of the experiment. n most cases this is along a time  
line but given that measurement collection is tightly integrated we  
can also easily describe "steerable" experiments (e.g. increase load  
by x% every y seconds until the error rate is above z%)

The orchestration is modeled as a state machine which makes it easier  
to deal with errors, or more generally with events coming from the  
resources inside the slice (e.g. an application crashing), or from the  
control framework (e.g. a sliver crashed). This way we can, for  
instance, maintain a certain level of resources by requesting new ones  
when we fall below a certain threshold. A state machine allows me to  
add all that outside my "main" experiment description. Right now, most  
users in Orbit don't even know that their experiment has quite a bit  
of failure recovery built in this way.

>  I'm assuming that the SC is responsible
> for controlling experiments.  Are Experiment Controllers and Slice
> Controllers the same thing, or should they actually be viewed as
> separate components in the GENI architecture?

That's an excellent point. Especially for short experiments (or trying  
to get something to work) we want the slice to be more persistent to  
keep the overhead down.

One idea we have been throwing around for a while is that of a  
"virtual" testbed. In all of our installations an AM represents an  
entire testbed and it's the AM the experimenter is directly talking  
to. Now if the AM manages a set of resources, and slivers are  
essentially resources as well (virtualization is supposed to be  
transparent) is the interface for an experimenter to manage all it's  
resources fundamentally different?

I assume one of the reasons for Jeff to bring the SC into the  
discussion is that the control framework needs a way to send  
information to the experimenter when things change, or whatever. A  
classical web service abstraction doesn't provide a simple to send  
asynchronous messages. We could do polling as we do with many web  
services, but given that we want a decentralized architecture there  
would be a lot of that, so why not have something for ET to call.

Now it's way past my bedtime to argue against web services as well and  
I'm not sure if these last few paragraphs make much sense anymore.

Cheers,

-max
>

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

[Robert P Ricci]

Thus spake Jeff Chase on Thu, Mar 19, 2009 at 07:08:03PM -0400:

> Since a key objective is to make GENI easy to use, we want the
> slice/experiment controllers to be easy to program and we want the code
> to be maximally reusable.   That is always hard, but declarative
> representations of experiments (like your ExpSpec suggestion) seems the
> right ideal to pursue.   Orca's slice controller toolkit is more
> procedurally oriented, so it is rather primitive in that
> respect...unless it is running something like Gush layered above it.  
> But that is one area where I think Orbit really excels (cf. Max Ott's
> slides from the GEC 3 services-wg meeting).  Gush and Orbit are the
> right places to start from with that, IMHO, unless there are other
> ExpSpecs that I am not yet aware of.

The obvious one missing from your list is the Emulab NS file (based on
NS-2), which in addition to describing network topologies, can also
describe software to distribute, programs to run, packet traces to
gather, etc. and lets you script all this stuff as well. Some
documentation:
    http://users.emulab.net/trac/emulab/wiki/nscommands
    http://users.emulab.net/trac/emulab/wiki/AdvancedExample

There's also the "Expermenter's Workbench" on Emulab which extends the
above with notions like formal parameters to experiments, a more
complicated experiment structure (for example, breaking up experiments
into potentially multiple "runs"), as well as adding a bunch of other
abstractions:
    http://www.cs.utah.edu/flux/papers/workbench-nsdi07-base.html

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