« Return to Thread: Re: two issues of terminology
Re: two issues of terminology
by Jeff Chase
::
Rate this Message:
It seems we all agree that there is a useful distinction between
"programming tools" and "experimenter tools" for a slice. And we're
still trying to pin down the exact nature of the distinction.
IMHO, we shouldn't work too hard to make the definition precise, because
there is no bright line. There may be tools that cross whatever line we
draw. This definition seems pretty good:
Robert P Ricci wrote:
> ...
> An experimenter tool *sets up* the environment in which a system under
> test runs, a programming tool is (may be?) *part* of that environment.
>
> More specific, but maybe not quite right:
>
> A programming tool is one that is in the "codepath" (broadly defined) of
> the system under test - that is, it's directly involved in the
> experiment because my application calls it as a library, makes syscalls
> into it, sends packets through it, etc. An experimenter tool is outside
> this codepath in that the interaction is one way - the experimenter tool
> might "call into" the SUT to start it, modify its configuration, etc,
> but the SUT doesn't "call into" the experimenter tool. (And in the case
> of collaboration tools and similar things, the tool may never really
> interact with the SUT at all.)
>
>But that almost suggests that the System Under Test cannot notify the
experimenter tools (e.g., slice controller) about events within the
SUT. We can dodge that by saying that the SUT exposes/publishes events
and the external controller subscribes to those events, so that the SUT
does not have to invoke the controller or know about it. But that just
encapsulates the line in a publish/subscribe system somewhere. (Not
that there's anything wrong with that.)
To me it seems most straightforward to think in terms of where code
runs, something like so:
- A "programming tool" consists of or produces
(creates/generates/combines/links) code to run within some sliver.
Different component/sliver technologies might come with their own
programming tools or libraries of off-the-shelf programs or modules
specific to those kinds of slivers. That's one reason why the
distinction seems useful: so we can talk about programming tools for
specific kinds of components or slivers. (Of course, the programming
tool itself could run anywhere.)
- 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.
I emphasize again that it's not a bright line. I could imagine an
experiment tool that does some management or control that is specific to
a particular kind of sliver and/or comes with an agent that runs within
specific sliver types. And we all want long-running slices to be
self-monitoring and self-managing, so there could be families of tools
for programming some kind of reflection into slices---what are they?
One reason to draw the line is to make it more interesting to cross it.
Jeff
_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg
"programming tools" and "experimenter tools" for a slice. And we're
still trying to pin down the exact nature of the distinction.
IMHO, we shouldn't work too hard to make the definition precise, because
there is no bright line. There may be tools that cross whatever line we
draw. This definition seems pretty good:
Robert P Ricci wrote:
> ...
> An experimenter tool *sets up* the environment in which a system under
> test runs, a programming tool is (may be?) *part* of that environment.
>
> More specific, but maybe not quite right:
>
> A programming tool is one that is in the "codepath" (broadly defined) of
> the system under test - that is, it's directly involved in the
> experiment because my application calls it as a library, makes syscalls
> into it, sends packets through it, etc. An experimenter tool is outside
> this codepath in that the interaction is one way - the experimenter tool
> might "call into" the SUT to start it, modify its configuration, etc,
> but the SUT doesn't "call into" the experimenter tool. (And in the case
> of collaboration tools and similar things, the tool may never really
> interact with the SUT at all.)
>
>
experimenter tools (e.g., slice controller) about events within the
SUT. We can dodge that by saying that the SUT exposes/publishes events
and the external controller subscribes to those events, so that the SUT
does not have to invoke the controller or know about it. But that just
encapsulates the line in a publish/subscribe system somewhere. (Not
that there's anything wrong with that.)
To me it seems most straightforward to think in terms of where code
runs, something like so:
- A "programming tool" consists of or produces
(creates/generates/combines/links) code to run within some sliver.
Different component/sliver technologies might come with their own
programming tools or libraries of off-the-shelf programs or modules
specific to those kinds of slivers. That's one reason why the
distinction seems useful: so we can talk about programming tools for
specific kinds of components or slivers. (Of course, the programming
tool itself could run anywhere.)
- 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.
I emphasize again that it's not a bright line. I could imagine an
experiment tool that does some management or control that is specific to
a particular kind of sliver and/or comes with an agent that runs within
specific sliver types. And we all want long-running slices to be
self-monitoring and self-managing, so there could be families of tools
for programming some kind of reflection into slices---what are they?
One reason to draw the line is to make it more interesting to cross it.
Jeff
_______________________________________________
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 |
