[ptp-dev] Attributes

[Nathan DeBardeleben <ndebard@xxxxxxxx>]

I intend to change the way attributes are used in our system (not the 
implementation *of* the attributes, just how they're used).  I believe 
Randy's committed (or committing) some new Attribute code so I wanted to 
see how we can fit together on this.

Currently the UI (I think it's just the UI code) assumes certain 
attributes are there at all times.  It assumes for a node we know the 
node number, the owner of the node, the state, etc.  Some attributes 
probably need to be required (node number, process ID) but many others 
might not (node temperature, node owner (many systems have no concept of 
this)).  As such, I was thinking the runtime subsystem should send back 
attributes as a tuple of the [DISPLAY_NAME, ATTRIBUTE_VALUE].  An 
example would be ["Process Identifier",12345] and ["Node Temperature", 
"100 degrees F"] and ["Node Number", 64]

Since some of the code uses things like the PID (I can think of the 
debugger, mainly) we would need some way to define that hardcoded.
I would suggest a define somewhere (static public constant string, 
whatever :)) like this:
static public constant string PID = "Process Identifier";
Then we could change the string internally if we needed , but the 
debugger (and other similar tools) would always have this there.

The UI would have to become a bit more robust.  If new attributes were 
there, it would need to display them.  If none were there (see last 
email) it would have to be able to handle that.

Imagine a system where upon startup the runtime subsystem has sent us 
back info about each node - Node Number, Node State, Node Owner (in 
bproc system), Node Group (again, bproc).  So we've got these 4 attribs, 
and the UI is showing them accordingly.  Then, suppose, there is a 
temperature monitor on the system that  only reports when the node gets 
sufficiently hot.  This occurs and the runtime system sends up a new 
attribute - ["Node Temperature", "120 degrees F"].  I would want the 
attribute and UI infrastructure to handle this, add the attribute in, 
and just display the new stuff accordingly.  Further suppose there's a 
plugin on the Eclipse side that looks for this.  It would need to be 
coded in such a way that it can handle it not being there (such as 
before this event occurred) but then when it sees it, wham, it wakes up 
and does something magical.

In truth, most of the attribute system works like this - well, perhaps 
50% like this.

First I want to know from Randy how this fits in with his "new 
attributes".  Then I wanted just general feedback about this approach.

Thoughts?

I've been designing most of this out using a snapshot from Monday, so 
once I get some feedback I'll try and integrate it with what Randy's 
committed (or is about to commit) and see if I can work out the 
subsequent major breakage that will occur.

--
-- Nathan
Correspondence
---------------------------------------------------------------------
Nathan DeBardeleben, Ph.D.
Los Alamos National Laboratory
Parallel Tools Team
High Performance Computing Environments
phone: 505-667-3428
email: ndebard@xxxxxxxx
---------------------------------------------------------------------