Subject: script mib autostart feature

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Jun 2000 18:15:05 +0200

One of the open issues in the RFC 2592 (DISMAN-SCRIPT-MIB) revision is
the autostart feature. The latest proposal was to add a new column
smLaunchFlags to the smLaunchTable. A special bit in the smLaunchFlags
would indicate that a launch button is implicitly pressed when the script MIB
(sub-) agent reinitializes itself.

Today, Frank and I looked at our implementation and we did came up
with some observations and finally with an alternate proposal to
achieve a similar thing. First our observations:

Automatically launching a script requires that the launch entry has
the smLaunchOperStatus enabled. In our implementation, every launch
entry starts with the smLaunchOperStatus set to disabled since the
implementation first has to bring the corresponding smScriptOperStatus
into the enabled state. Note that this can take quite some time since
this may include fetching a script from a remote site. Once the
smScriptOperStatus transitions into the enabled state, we loop through
all launch table entries for the script table entry in order to set
the smLaunchOperStatus to enabled if the smLaunchAdminStatus is
enabled.

This basically means that the transition of smLaunchOperStatus from
disabled to enabled is the point in time where we can automatically
launch a script. So the idea came up to bind the auto start feature to
the disabled -> enabled state transition of smLaunchOperStatus, which
happens automatically during initialization (as explained above), but
which may also happen at other points in time. This has in fact some
nice side effects. For example, it is possible to install entries in
the smScriptTable and the smLaunchTable in a single SNMP set operation
in such a way that the implementation launches scripts automatically
once the source has been loaded and all entries change into the
enabled operational state.

Going a bit further, Frank came up with the idea to drop the new
smLaunchFlags object altogether and instead introduce a new
smLaunchAdminStatus status 'auto'. The 'auto' status will work similar
to the 'enabled' status. The only difference is that the 'auto'
administrative status launches a script during the disabled -> enabled
operational state transition while the 'enabled' administrative status
does not.

Now to the proposal:

- Add a new 'auto' enumeration to the smLaunchAdminStatus which brings
  the smLaunchOperStatus into the enabled state and launches the script
  during the script's disabled -> enabled transition.

- Add clarifying text about the interactions between
  smScriptOperStatus and smLaunchOperStatus state transitions. Some of
  the state transitions we have implemented are not clearly defined in
  RFC 2592. You sometimes have to infer the behavior from the more
  declarative description of the various states.

In fact, Frank and I started to draw state transition diagrams and it
might be helpful to put them into the RFC 2592 revision.

Comments?

Frank and Juergen

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Eamonn McManus <[email-masked]>
Date: Wed, 14 Jun 2000 14:26:58 +0200

> the smLaunchOperStatus to enabled if the smLaunchAdminStatus is

Interesting.  My implementation doesn't do this, since it was not clear from my
reading of the document that smLaunchOperStatus was tied to the state of the
underlying script.  The relevant text, I think, is in the description of that
variable, where it says:
  An `enabled' launch table entry can be used to start scripts
  while a `disabled' launch table entry will refuse any attempts
  to start scripts.
Your interpretation is reasonable but I think it needs to be spelled out more
clearly, since it is not obvious.

> For example, it is possible to install entries in

In the absence of your proposed addition of "auto", I'm not sure how this can
work.  Ordinarily, scripts are launched when the smLaunchStart variable is
written.  That variable can't be written if smLaunchOperStatus is not enabled,
which is the case you're talking about.  If you don't write it at the same time
as you write smLaunchAdminStatus, how can you distinguish between the case where
you want a script launched when the button becomes enabled and the case where
you don't?

The proposed addition of "auto" solves this problem, so maybe I'm just
nitpicking.

> operational state transition while the 'enabled' administrative status

Sounds workable to me, and as you mention it allows for a single
download-script-and-launch-it-when-done operation in an SNMP "set".

>   during the script's disabled -> enabled transition.

Writing "auto" shouldn't set smLaunchOperStatus to "enabled" immediately, should
it?  That would imply that you could launch scripts with the button, which is
not yet true in the case of interest.  I think writing "auto" is exactly the
same as writing "enabled", except that if it causes a transition of the launch
button from disabled to enabled, at that moment or later, it also pushes the
button as if a 0 had been written to smLaunchStart.

>   declarative description of the various states.

As I mentioned, this does seem to be necessary.

I see no problems with this proposal and it is cleaner, simpler, and more
general than the two other proposals for auto-launch, so it looks like the way
to go.

Éamonn

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Jun 2000 15:07:58 +0200

>>>>> Eamonn McManus writes:

Eamonn> My implementation doesn't do this, since it was
Eamonn> not clear from my reading of the document that
Eamonn> smLaunchOperStatus was tied to the state of the underlying
Eamonn> script.  The relevant text, I think, is in the description of
Eamonn> that variable, where it says: An `enabled' launch table entry
Eamonn> can be used to start scripts while a `disabled' launch table
Eamonn> entry will refuse any attempts to start scripts.  Your
Eamonn> interpretation is reasonable but I think it needs to be
Eamonn> spelled out more clearly, since it is not obvious.

Yes. Not all these state transitions and the dependencies between them
are clearly described in the current version of the document. This
needs to be fixed so that we get better interoperability here. We
probably have to work through a state transistion diagram to make sure
we catch them all.

>> For example, it is possible to install entries in the smScriptTable
>> and the smLaunchTable in a single SNMP set operation in such a way
>> that the implementation launches scripts automatically once the
>> source has been loaded and all entries change into the enabled
>> operational state.

Eamonn> In the absence of your proposed addition of "auto", I'm not
Eamonn> sure how this can work.  Ordinarily, scripts are launched when
Eamonn> the smLaunchStart variable is written.  That variable can't be
Eamonn> written if smLaunchOperStatus is not enabled, which is the
Eamonn> case you're talking about.  If you don't write it at the same
Eamonn> time as you write smLaunchAdminStatus, how can you distinguish
Eamonn> between the case where you want a script launched when the
Eamonn> button becomes enabled and the case where you don't?

Eamonn> The proposed addition of "auto" solves this problem, so maybe
Eamonn> I'm just nitpicking.

Yes. My statement above assumed that the "auto" state is available.
So being able to install and lauch a script in a single set operation
is a feature we get from the "auto" addition to smLaunchAdminStatus.

>> Now to the proposal:
>> 
>> - Add a new 'auto' enumeration to the smLaunchAdminStatus which
>> brings the smLaunchOperStatus into the enabled state and launches
>> the script during the script's disabled -> enabled transition.

Eamonn> Writing "auto" shouldn't set smLaunchOperStatus to "enabled"
Eamonn> immediately, should it?  That would imply that you could
Eamonn> launch scripts with the button, which is not yet true in the
Eamonn> case of interest.  I think writing "auto" is exactly the same
Eamonn> as writing "enabled", except that if it causes a transition of
Eamonn> the launch button from disabled to enabled, at that moment or
Eamonn> later, it also pushes the button as if a 0 had been written to
Eamonn> smLaunchStart.

Correct. "auto" delays the start of the script until the disabled ->
enabled state transition of smLaunchOperStatus happens. The only
difference to "enabled" is during this state transition.

Eamonn> I see no problems with this proposal and it is cleaner,
Eamonn> simpler, and more general than the two other proposals for
Eamonn> auto-launch, so it looks like the way to go.

Great that you like the proposal. Lets see if we get more positive
feedback from other WG members and implementors.

/js