« Return to Thread: Re: two issues of terminology
Re: two issues of terminology
by Robert P Ricci
::
Rate this Message:
Yeah, I agree with John on this one, where it runs isn't the right place
to make the distinction.
As an example, Emulab offers a lot of tools that are clearly
experimenter tools - they install software, help launch processes,
distribute events, etc. We have a portal that lets you create slices on
PlanetLab using Emulab, and one of the things that comes along is all
these experimenter tools. They do exactly what you describe below, and
bootstrap themselves inside of the slice. They get installed by
'pushing' them in from outside the slice, and much of the control
infrastructure resides outside, in Emulab, but the tools themselves
pretty clearly run inside the slice.
Thus spake Jeff Chase on Mon, Feb 23, 2009 at 04:42:42PM -0500:
> But that almost suggests that the System Under Test cannot notify the
> experimenter tools (e.g., slice controller) about events within the
> SUT.
Yeah, this is definitely a weakness with this definition, but maybe it
points out the place (roughly) where something crosses from a pure
experimenter tool and starts blurring into a programming tool.
> - An "experiment tool" is a tool that manages a slice on the
> experimenter's behalf, but does not run within a sliver or produce code
> that runs within a sliver. That sort of makes sense...certainly a
> slice can't pull itself up by its own bootstraps, i.e., the code that
> initially sets up a slice can't run within any of the slice's slivers.
> Experiment tools should strive to be general across many
> component/sliver technologies, although they will have to "talk about"
> various component/sliver technologies, i.e., they might have to produce
> and consume various metadata or representations.
--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------
_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg
to make the distinction.
As an example, Emulab offers a lot of tools that are clearly
experimenter tools - they install software, help launch processes,
distribute events, etc. We have a portal that lets you create slices on
PlanetLab using Emulab, and one of the things that comes along is all
these experimenter tools. They do exactly what you describe below, and
bootstrap themselves inside of the slice. They get installed by
'pushing' them in from outside the slice, and much of the control
infrastructure resides outside, in Emulab, but the tools themselves
pretty clearly run inside the slice.
Thus spake Jeff Chase on Mon, Feb 23, 2009 at 04:42:42PM -0500:
> But that almost suggests that the System Under Test cannot notify the
> experimenter tools (e.g., slice controller) about events within the
> SUT.
Yeah, this is definitely a weakness with this definition, but maybe it
points out the place (roughly) where something crosses from a pure
experimenter tool and starts blurring into a programming tool.
> - An "experiment tool" is a tool that manages a slice on the
> experimenter's behalf, but does not run within a sliver or produce code
> that runs within a sliver. That sort of makes sense...certainly a
> slice can't pull itself up by its own bootstraps, i.e., the code that
> initially sets up a slice can't run within any of the slice's slivers.
> Experiment tools should strive to be general across many
> component/sliver technologies, although they will have to "talk about"
> various component/sliver technologies, i.e., they might have to produce
> and consume various metadata or representations.
--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------
_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg
« Return to Thread: Re: two issues of terminology
| Free embeddable forum powered by Nabble | Forum Help |
