Subject: Re: AgentX Charter/Milestone Update

From: Randy Presuhn <[email-masked]>
Date: Fri, 20 Apr 2001 10:16:31 -0700 (PDT)

Hi -

> From: Frank Strauss <[email-masked]>
> To: Randy Presuhn <[email-masked]>
> Cc: [email-masked]
> Subject: Re: AgentX Charter/Milestone Update
> References: <[email-masked]>
> Date: 20 Apr 2001 17:31:20 +0200
> In-Reply-To: <[email-masked]>
> Message-ID: <[email-masked]>
...
> Randy> Consider the job of assiging execution priorities in an
> Randy> embedded system.  Putting the schedule and script mibs into the
> Randy> same process as the master agent would probably not be a good
> Randy> idea.
> 
> For the Schedule MIB there is no problem with a single agent process.

Only if the implementors want their SNMP engine and the
scheduler to have the same priority, address space, etc.
For some implementation environments this is not a problem.
For other implementation environments it could be a big
problem.  All I'm saying is that we should permit modular
implementations.

> For the Script MIB there is only a problem with the executing scripts,
> not with the Script MIB implementation itself.

This depends strongly on the implementation architecture.  In
this particular case, I'm more concerned about the real-world
situation where the SNMP master agent and the script execution
environments could come from different vendors.

> BTW, this is how our Script MIB and Schedule MIB implementations work,
> and I never felt a need to change this.

I'm not saying you should change.  I'm just saying that this
particular approach is not the only one possible, and that
in some environments there are reasons to want to support
others.

> But I can slightly imagine that the needs in embedded systems may vary
> from those on hosts with a traditional operating system. Unfortunately,
> I have no experience with embedded systems.

Embedded systems have become much more Unix-y over the years,
but in hard real-time environments, knowing which task will
be doing what is still very important to ensure that deadlines
will be met under all load conditions.  When processing is
divided among multiple processors running on hot-swappable,
field-upgradable cards, there is often little choice but to
go to some kind of subagent/master agent architecture.

...
> Randy> Not true.  For years have been commercially available products with
> Randy> capabilities remarkably similar to the disman script MIB.
> 
> What commercially available products do you think of?

BMC PATROL comes to mind.  It'd really be nice to permit
folks to manage it using the disman script MIB in addition
to our enterprise MIB.

> Randy> It would be really nice to be able to manage these things using
> Randy> standard MIBs.
> 
> [Since I'm not aware of the answer to my question 4 lines above, I
>  assume we are talking about a process execution environment like the
>  usual OS process management subsystem.]

No.  Part of what PATROL does is done by intelligent agents executing
scripts.  The PATROL agent can be managed as an SNMP subagent.

> Yes, but the DISMAN-SCRIPT-MIB is probably not the right choice. The
> Script MIB is not designed to manage scripts in existing runtime
> environments. It is designed for the special purpose of delegating
> management functionality to mid-level managers. Such scripts have a
> very special focus and thus the runtime environment and the Script MIB
> have some special characteristics.

This is exactly what PATROL does.

> A MIB which is to some degree comparable and which is used for
> monitoring (and to a very limited degree controlling) processes on a
> host is the HOST-RESOURCES-MIB, which is `of the other kind' and which
> (at least in theory) makes sense to be implemented using
> AgentX. Unfortunately, the `program' that would have to be
> instrumented in this case is the OS kernel, which could pose a
> problem. ;-)

We're talking about very different things.

> Randy> The fact that a particular resource that will need to be
> Randy> managed is newly developed is no reason to assume that
> Randy> the instrumentation should be built into the master agent.
> Randy> Consider newly developed commercial or custom hardware and
> Randy> software that is to be installed on platforms that already
> Randy> have their own agents.
> 
> Here, you are talking about "hardware" or "software" that is going to
> be managed. This "hardware" or "software" *does exist* and is going to
> be instrumented for management. I agree that AgentX is reasonable in
> this situation. This situation is different from the Script MIB (at
> least in my opion) or the Schedule MIB or some other MIBs.

I'm missing something here.  How is it that the implementation
of a script or schedule MIB that is being managed doesn't
"exist"?  After all, a scripting engine is just another piece
of software.  In causing other programs to be run based on
its input stream, it's really no different from lpr or emacs.

> >> For example, on the NET-SNMP platform the capability of dynamically
> >> loadable modules is my favorite choice.
> 
> Randy> You must have more clout with the owners of the systems running those
> Randy> agents than I do with the IS department that runs our servers.  :-)
> 
> To some degree I'm both in one person. Hope I'm not to schizophrenic. ;-)
...

That's perhaps a good part of the difference in our
perspectives.  I work with software deployed into multi-vendor
environments where different organizations may have control
over which software is used to perform the various functions
in a system.  Specifically, I'm  considering the case where
schedulers and script execution engines are deployed into
environments with SNMP infrastructure that is on a separate
maintenance / upgrade cycle, and perhaps even provided by a
completely different vendor.

The current situation results in multiple SNMP master agents
installed on a box, resulting in confusion, administrative
annoyances, and even such evils as proxy.  :-) * 0.5

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

---

From: Bob Natale <[email-masked]>
Date: Fri, 20 Apr 2001 15:10:06 -0400

At 4/20/2001:01:16 PM, Randy Presuhn wrote:

><...deleted most of an argument I agree with 100%...>
>

Right.  And has also, IMHO, done a lot to retard the
expansion of SNMP into devices/applications for which
it is otherwise an excellent choice.  Continuing
implementation, interoperability, deployment, and
development of AgentX products (commercial or otherwise)
and promoting the specs to Draft Standard status still
promises to help rectify that situation.  Fortunately,
in the time it has taken for us to come this far with
AgentX, not a lot seems to have changed in the marketplace
-- at least not in any dominant way -- so the basic
problem/opportunity is still there.

BobN

---

From: Frank Strauss <[email-masked]>
Date: 21 Apr 2001 12:55:15 +0200

Hi!

Randy> [...] All I'm saying is that we should permit modular
Randy> implementations. [...]
Randy> I'm just saying that this
Randy> particular approach is not the only one possible, and that
Randy> in some environments there are reasons to want to support
Randy> others.

I absolutely agree.

>> I have no experience with embedded systems.

Randy> Embedded systems have become much more Unix-y over the years,
Randy> but in hard real-time environments, knowing which task will
Randy> be doing what is still very important to ensure that deadlines
Randy> will be met under all load conditions.  When processing is
Randy> divided among multiple processors running on hot-swappable,
Randy> field-upgradable cards, there is often little choice but to
Randy> go to some kind of subagent/master agent architecture.

Ok. I understand. Thank you, Randy.

>> What commercially available products do you think of?

Randy> BMC PATROL comes to mind.  It'd really be nice to permit
Randy> folks to manage it using the disman script MIB in addition
Randy> to our enterprise MIB.

>> usual OS process management subsystem.]

Randy> No.  Part of what PATROL does is done by intelligent agents executing
Randy> scripts.  The PATROL agent can be managed as an SNMP subagent.

Ok. I understand this argumentation. However, in the architecture of
our DISMAN-SCRIPT-MIB implementation this would probably just lead to
an additional PATROL runtime engine talking SMX to the agent.

[For the rest of this topic it's now obvious that I made the wrong
assumption and we were talking about different things.]

>> least in my opion) or the Schedule MIB or some other MIBs.

Randy> I'm missing something here.  How is it that the implementation
Randy> of a script or schedule MIB that is being managed doesn't
Randy> "exist"?  After all, a scripting engine is just another piece
Randy> of software.  In causing other programs to be run based on
Randy> its input stream, it's really no different from lpr or emacs.

I understand your argument. I was too much prejudiced by the architecture
of our implementation. Now, I can also imagine an architecture, where
a runtime system as a spearate process registers Script MIB objects 
via AgentX (although some nasty questions come to my mind, but let's
not delve into the details any further at this point. ;-)).

But how about some other MIB examples: DISMAN-SCHEDULE-MIB,
SNMP-NOTIFICATION-MIB, DISMAN-EXPRESSION-MIB, DISMAN-EVENT-MIB.  Can
you think of any piece of real hardware or software being managed via
these MIBs or would you say these MIBs themselves give a functionality
that people want to use?

Let me pick the DISMAN-SCHEDULE-MIB example: Sure, in the end there is
a scheduler, and managers can use the management interface to make use
of this managable scheduler. But the initial need for the user is to
have a MIB that allows to schedule management actions. It is not to
manage the scheduler. Hence (despite from other reasons you have
conviced me of, like software configuration management) I see no
reason to set up a separate process. This is different from printer or
web services.

I thank you, Wes and Ken for enlighten me, that there are other
reasons for using a sub-agent architecture than those that came to
my mind in the first place.

 -frank