Subject: Re: AgentX Charter/Milestone Update

From: Randy Presuhn <[email-masked]>
Date: Thu, 19 Apr 2001 12:56:53 -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: 19 Apr 2001 21:21:04 +0200
> In-Reply-To: <[email-masked]>
> Message-ID: <[email-masked]>
> Lines: 86
...
> Randy> I think it would be very nice to be able to put the disman event,
> Randy> schedule, script, and expression mibs into subagents.  
> 
> Why? -- In general, I feel more comfortable if all aspects of a
> service are covered by one process, just for clarity and resource
> consumption. 

I find it very hard to think of the event mib and the schedule mib
as being a single service.  I can imagine that vendors would want
to be able to sell script and expression MIB implementations as
distinct products.  Implementing them within a single process
is plausible, but not necessarily desirable.

> In some other areas, criteria like robustness of the whole system if
> one subsystem is buggy, or performance if threading is not available,
> are mentioned. I'm not convinced that these are real arguments for
> sub-agents.

They are very real arguments for subagents, especially in
multi-processor and embedded systems.  Consider the job
of assiging execution priorities in an embedded system.
Putting the schedule and script mibs into the same process
as the master agent would probably not be a good idea.

> Randy> The only thing that currently makes that difficult is the need
> Randy> to remember credentials and to consult the (abstract)
> Randy> isAccessAllowed service.
> 
> I agree that these two aspects should be carefully considered for
> being conveyed by the AgentX protocol, although they would probably
> drop a general concept of AgentX: The subagent could not remain "SNMP
> ignorant", I assume.

I wouldn't want to put them into the AgentX protocol.  I think
a separate protocol that can operate in parallel with AgentX
would be easier to define, would also permit a more modular
implementation, and would avoid overly complicating the state
machine for set request processing.

However, if we go down this path, I think the agentx working group
would be the right place to do it.

> Randy> Building all these MIBs into the master agent implementation
> Randy> would be a configuration management (in the software sense)
> Randy> nightmare.
> 
> Why? -- In general, I prefer to see all aspects of an agent
> configuration covered by one scheme.

I mean "configuration management" in the software engineering sense:
being able to track and control versions of the various components
needed to build a system.  Forcing implementation within the master
agent locks customers into a single-vendor solution, and potentially
results in the pain and anguish of "forklift" upgrades of the software.

...
> If each sub-agent (no matter whether internal or via AgentX) registers
> its "capabilities rows", there is no need for a sub-agent that serves
> the whole capabilities table and a new protocol extension that allows
> other sub-agents to register their capabilities with this capabilities
> sub-agent.

We're in violent agreement here.

...
> >> In cases where there is no instrumented entity, there is no need to
> >> move the implementation away from the master agent.
> 
> Randy> In cases where there is no instrumented entity, a MIB would
> Randy> be pointless.
> 
> Sorry, I've probably used the wrong words. By "cases where there is no
> instrumented entity" I mean those MIB objects that are not related to
> a piece of source code that already exists.
> 
> Examples: If you want to implement the WWW-MIB or the MTA-MIB, then
> you usually do this for a specific service application. This
> application has data structures from which you can more or less easily
> derive your MIB object implementation. Here, AgentX would be my
> favorite choice.  On the other hand, if you implement something like
> the DISMAN-SCRIPT-MIB or the any of the SNMP-???-MIBs there is no code
> that already exists going to be instrumented. 

Not true.  For years have been commercially available products with
capabilities remarkably similar to the disman script MIB.  It would
be really nice to be able to manage these things using standard MIBs.

>                                               Everything has to be
> done from scratch. Here, I see no need to create a new program and run
> a separate process for questionable reasons. 

The fact that a particular resource that will need to be
managed is newly developed is no reason to assume that
the instrumentation should be built into the master agent.
Consider newly developed commercial or custom hardware and
software that is to be installed on platforms that already
have their own agents.

>                                              For example, on the
> NET-SNMP platform the capability of dynamically loadable modules is my
> favorite choice.
...

You must have more clout with the owners of the systems running those
agents than I do with the IS department that runs our servers.  :-)

 -------------------------------------------------------
 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: Frank Strauss <[email-masked]>
Date: 20 Apr 2001 17:31:20 +0200

Hi!

>> are mentioned. I'm not convinced that these are real arguments for

Randy> They are very real arguments for subagents, especially in
Randy> multi-processor and embedded systems.  

Well, I just don't believe that multiple processes are a solution
to all these situations.

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.
For the Script MIB there is only a problem with the executing scripts,
not with the Script MIB implementation itself.

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

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.

>> drop a general concept of AgentX: The subagent could not remain "SNMP

Randy> I wouldn't want to put them into the AgentX protocol.  I think
Randy> a separate protocol that can operate in parallel with AgentX
Randy> would be easier to define, would also permit a more modular
Randy> implementation, and would avoid overly complicating the state
Randy> machine for set request processing.

I have not yet a biased feeling whether and how these new features
should be addressed.

Randy> However, if we go down this path, I think the agentx working group
Randy> would be the right place to do it.

Agreed.

>> that already exists going to be instrumented. 

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?

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.]
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.

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. ;-)

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.

>> 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. ;-)

 -frank

---

From: Ken Andrews <[email-masked]>
Date: Fri, 20 Apr 2001 14:38:54 -0400

Hello,

I thought that I'd drop in my $.02 since I am caught in a reald world
situation that is very applicable.  We have implemented agentX to make our
development more modular.  rught now I think that we have about 20 or
so sub-agents being developed in the U.S., Belgium, and India.  Aside
from makeing the development modular agentX made the overall system more
fault tolerent since the restart of a single sub-agent does not stop the
rest of the system from being managed.

One of these sub-agents provides operations very similar to DISMAN-SCRIPT-MIB.
The problem is how do you allow an admin to control everyones tasks and
allow only users to control thier own tasks?  It looks like our plan will
be to use vacmFilters.  This means that I (The Master Agent developer) will
need to create "special" vacmViewFilter entries every time a usmUser is 
created. ugh!

It would be a lot cleaner if I could pass security information in the 
AgentX request that would allow the sub-agent to do its additional security
processing.  For example I would like to be able to pass information about
the authentication method (USM vs Community string or other) and some data
such as the community string (and maybe source address) or the security
name used in the SNMP request.

Regards,
Ken

-- 
Ken Andrews [email-masked]
Office #  703-679-6476
Fax #     703-679-6450
We all ride the same road