Sorry for the poor quoting below. Notes doesn't behave nicely (if someone
knows how to make Notes quote nicely, please let me know).
In general, please open a separte feature for each of these so that we can
track them better. Also, aside from yours and Phil Willoughby's notes, the
other notes from the STAF development team (predominantly Sharon Lucas) are
detailing how we actually plan to implement specific features, as opposed
to requesing that a new feature be added. It would probably be handy if we
kept a list somewhere of the features that we plan to include in STAF V3.0,
huh?
Regarding Point 1:
With the, possible, exception of the domain/scoping, you could really
already do this today. STAF provides a which will send queued messages
when STAF starts up or shuts down. You can enable these via the NOTIFY
ON[START|SHUTDOWN] configuration statement. Ideally you would probably
send these to an application running on a common system. This application
would turn around a generate an event (via the Event service) so that many
people could be notified. This approach doesn't make it easy to do the
domain/scoping, although the application receiving the message could
retrieve a variable from the remote system and send that as part of the
event. We've been thinking about adding direct Event Service support into
this notification mechansim. This means you wouldn't need the intermediate
application to receive notifications. At that point, we could also allow
some arbitrary data to be passed as part of the event, which would enable
your domain/scoping.
Either way, you still probably need an application (or service) listening
for the Events so that it can keep an inventory of available systems, etc.
Regarding Point 2:
Yeah, we thought about this when we added a lot of the file system support
to the FS service in STAF V2.3.0. It just didn't make the cut. It's
straightforward, but non-trivial work (it probably requires an addition to
the STAF network protocol to efficiently handle this). In the near term,
this might make a good service, or an addition to an existing one (like
FSEXT). All the facilities (basic LIST and COPY support) to do it are
available in the FS service, they just need a good wrapper.
Regarding Point 3:
Well, assuming you have somebody ready to receive it, you can tell STAF to
send the stdout/stderr somewhere when the process ends. This is enabled
via the RETURNSTDOUT and RETURNSTDERR options. However, they require that
you use the NOTIFY ONEND option(s). Typically, the application that starts
the process uses these options and then checks its queue for the results,
which can then be written or logged somewhere else. We are looking at
adding tempfile support in the future so that you don't have to make up
your own filenames. We've also looked at providing generic
open/read/write/close file support in the FS service in a future release.
At that point, we might be able to provide "pseudo-file" support for
stdout/stderr (which would allow you to use the new file read commands).
Another alternative is to provide some more generic network pipe support
through which stdout/stderr could be redirected. This latter approach
needs some significant thought put into though. If you have some other
ideas, please include them when you open the feature.
Regarding Point 4:
I'm not sure I completely understand what you mean here. Having said that,
perhaps this "trick" might be handy. You could use variables in your
requests that define the log server and the log file. This would perhaps
allow some flexibility. For example,
staf {LogServer} log log global logname {LogName} level info message
whatever
You can then define LogServer and LogName to be whatever you want, and they
can be changed on the fly. You could have defaults on each system like
var LogServer=logsrv.my.domain.com
var LogName=CommonTestLog
You can override these on a per process basis, although overriding LogName
won't work if LogServer is not "local" due to a psuedo-bug to be fixed in
STAF V3.0 (feature #464843). Many people don't realize that the machine
name and service name used in a STAF request can be (or contain) variables.
If that doesn't help, please provide a little more detail or another
example.
Thanks for your input.
Charles Rankin
Well,
Since everyone seems to be sending requests for STAF 3.0, I thought I
might give a few requests. These are some of the things I have needed
as I have used staf. Also, I'm not sure your interested, but I would
like to contribute a mail service I have been working on in Java. If
there is interest, I will try to get it into a descent form, and
contribute it. Here are my requests:
1. Some way of either discovering other machines on the network using
staf, or a registration service.
2. FS service able to recursively copy directories.
3. Remote Process output logged or returned somewhere.
4. (would like, but I realize it's hard to implement) Default logging
for a test / process
Details:
1. I have needed to have a list of computers, that I don't want to
compile by hand. I have thought of a couple ways to do this:
- dynamic discovery through some type of broadcast
- registration with a server upon startup, deregistration on shutdown
Along with this, it would be nice to have some type of scope, meaning on
install you define your testing scope (or domain), and you can be
organized via that domain or scope.
I was working on this once with writing a slp registration service
(using openslp http://www.openslp.org). However, I really like the idea
of staf being as self contained as possible (with the obvious exception
of languages like perl and java). It would be better done in staf
itself. I might be able to write this myself, but I am unsure at this
point.
2. I have needed to transfer whole directories, and their contents
during a test. I thought that staf fs service could do this, but I
can't seem to find any documentation on it. Let me know if this
functionality is already in there.
3. When using staf to run a remote process, the only way currently to
get the output of the process is to redirect the output to a file, then
copy the file the the machine calling the process. Couldn't there be a
way to get the output another way?
4. Ok let me explain this one. When I'm running a test, no matter what
machine I make a staf service request to, I want all logging to go to a
log that the current machine is logging to. I've written in ways to do
this, but it's pretty messy, to be able to define some type of default
logging file to log to would be good, but I'm not even sure under the
current architecture how to do this cleaner.
_______________________________________________
staf-devel mailing list
staf-devel@...
https://lists.sourceforge.net/lists/listinfo/staf-devel
|