[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [hyades-dev] Notes from the Hyades Data Collection Engine mee ting for 8/5/2004

Andy,
 
One other implementation detail I forgot to mention on the call yesterday...
>>The "Agent registry" will probably be implemented as a series of XML files deposited in "Metadata" directories under agent directories in the HCE installation tree (following the config model in Hyades 3.0).  The precise details of how this will be structured and what will be contained in the metadata needs to be fully documented (soon).<<
We may want some kind of secure API to copy these files remotely, to make thing easier at Agent install time.
 
-Dan
-----Original Message-----
From: hyades-dev-admin@xxxxxxxxxxx [mailto:hyades-dev-admin@xxxxxxxxxxx]On Behalf Of Kaylor, Andrew
Sent: Thursday, August 05, 2004 5:22 PM
To: hyades-dev@xxxxxxxxxxx
Subject: [hyades-dev] Notes from the Hyades Data Collection Engine meeting for 8/5/2004

Notes from the Hyades Data Collection Engine meeting for 8/5/2004

 

Attendees:

Intel

   Andrew Kaylor

   Hoang M. Nguyen

   Karla Callaghan

   Vishnu Naikawadi

   Srinivas Doddapaneni

 

Compuware

   Don Ebright

   Luc Plaetinck

 

IBM

   Kim Coleman

 

 

Hoang introduced Sri as the latest developer joining the effort from the Intel side of things.

 

We reviewed the Hyades Protocol Specification document (Rev. 0.5), beginning with the Agent Manager interface.

 

 

**Important**

At the end of the meeting, Andy requested that this be the last review of this protocol specification document and that from here on out we will discuss only changes and additions to the document and otherwise assume that the document as it stands will form the basis of our implementation.  If you have concerns about this, raise them now.

 

 

The "Agent registry" will probably be implemented as a series of XML files deposited in "Metadata" directories under agent directories in the HCE installation tree (following the config model in Hyades 3.0).  The precise details of how this will be structured and what will be contained in the metadata needs to be fully documented (soon).

 

We discussed the reference counting scheme and noted the continued need to incorporate details as to how agents may keep themselves around.  The topic of bound vs. unbound agents was also mentioned as something to be included in this document whereever needed.

 

The distinction between CID_QUERY_AVAILABLE_AGENTS and CID_QUERY_RUNNING_AGENTS was discussed, and we agreed that it will not be necessary for clients to use both.  The two options are provided for flexibility.

 

We discussed the fact that CID_QUERY_RUNNING_AGENTS is intentionally non-specific.  It is up to the client and agent to negotiate further details, such as the agent's name, any process it is bound to, etc.

 

We discussed the fact that the data returned by CID_GET_AGENT_REGISTRY is cacheable.  In the first implementation, this data will not change at runtime.  If it does in the future, an event can be added to notify the client of such changes.

 

The distinction between getting an agent reference and attaching to an agent was discussed.  It seems that the precise behaviors involved might need to be clarified.

 

It was noted that the description of the CID_REGISTER_AGENT command doesn't indicate where the Agent ID came from.  That needs to be documented.

 

We talked about whether it would be possible for an agent to de-register itself and shutdown if a client is attached to it or has a reference to it.  I believe that such should be possible, and we need to have a mechanism for notifying the client when this happens.  The agent should only do this when necessary.

 

We also discussed the need for robust error handling in the case where an agent goes away without deregistering.  It was agreed that the protocol specification can insist that agents must deregister, but the implementation needs to gracefully handle the fact that this won't always happen.

 

I believe that a general document on error handling strategies is needed.

 

We discussed the event listener handling and the fact that this will become a separate interface to define system wide event behavior.

 

At next week's meeting we will begin reviewing the base agent and collector interface specification.




The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.