« Return to Thread: CF Requirements: 3) Slice Controller
Re: [geni-dev] CF Requirements: 3) Slice Controller
by Jeff Chase
::
Rate this Message:
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
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
« Return to Thread: CF Requirements: 3) Slice Controller
| Free embeddable forum powered by Nabble | Forum Help |
