OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsdm] cases on situation categories


Sedukhin, Igor S wrote:
Fred, do you really think that [If not, the developer makes a call on which situation most accurately conveys the situation.] is possible and will help interoperability in some way?
Yes, I do.  I think that there will exist two types of managers in the world -- those that are dedicated to a particular management system and those that are open.  The former don't care [much] about WSDM, so ...

The second will come in a variety of differing levels of sophistication.  These will probably understand some things extremely well, but have only a vague understanding of other areas.  In these latter cases, they can say,
Gee, I got an event that's situated itself as a configuration change.  Since I know about the generic list of situations, I know how to do that.  My trained human can figure out the rest -- I don't grok that level of detail.

meanwhile, our trained human enters the picture and sees the message.

Gee, says the human, there's a report here into which I shall look.  Look, those morons at yuckoNetworks.com have reported that a configuration situation that says device down.  What idiots.  I shall report a bug & tell purchasing to avoid them like the plague.

But, WOW, those fine folks at Cisco have noted a configuration situation because someone changed the number of valid connections, and have included lots'o'detail about who got trashed as a result.  Meesa likes them.  I could understand if they reported that as a connection situation, too, but I know how to deal with it and my genericManager.com put it where I could see it.
 
If two network devices report changes of properties of their network connection configuration, one as ConnectSituation and another device reports it as ConfigurationSituation because the rule indicated above was in effect, is that helpful?
Yes, it is.  1) Both reported it, and 2) I could rule out the some other things (like dependency about which I don't care).  Yes, another example can introduce confusion -- such is the way with broadening scopes.
 
It is much worse here than in your SQL example. Those in SQL are errors and I may not necessarily care.
"Those are tweaky network resources and I, the humble SQL programmer, don't care.  Pick a domain...
In WSDM this is the situation that needs to be reported on events that are not errors and that is many more events than just errors that need to be classified.
Being somewhat familar with database systems, they have lots'o'interesting events, too.  The higher level errors help sort things out.  Ambiguity exists -- the way of the world. potayto/potato and all.
In many cases with SQL, the client would not care what error there was and so this classification is for those who can deal with it.
Ditto for the specialized ServiceAvailabilityViewManager application.  Couldn't care less about those piddly little configuration crap -- someone else's problem. 
Here, in WSDM it is for everything that happens one has to decide what class of situation it falls into in order to let someone else know about what happened.
Yup.  But you had to decide a bunch of stuff anyway.  Like whether to implement code that noticed...
In the real world if one faces this, one may likely decice to be silent instead of going through the decision process.
One's such as these will tend to get fewer customers.

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749 

 


From: fred carter [mailto:fred.carter@amberpoint.com]
Sent: Wednesday, November 17, 2004 3:00 PM
To: wsdm@lists.oasis-open.org
Subject: Re: [wsdm] cases on situation categories

IMHO, this makes it worse.

I thought the idea was to provide a broad indicator, not a complete list of everywhere it might be appropriate.

As Tom indicated previously in this thread, if something fits a couple of places, there are really probably two different events going on, each of which has a situation.  If not, the developer makes a call on which situation most accurately conveys the situation.

These are always gray areas, no matter what anyone does. The broad in broad indicator says that its a gross measurement.  Those interested in the details are required to dig deeper.  Those not so interested, won't.

I don't see how this is any different than, for example, standard SQL errors.  To translate,
If the database has to abort a transaction because it could not get enough disk space to extend the table, is that a resource error or a transaction error?  IMNSHO, that's a transaction error:  that's because the transaction is the effect closest to/with the most effect on the user (they just got a bunch of work tossed).  If it didn't abort the transaction, but just returned it couldn't perform the, say, insert, it'd be a resource error.
The value, though, is the same:  The user writing code [in our case, a manager, in the SQL case a db app developer] doesn't care about the details unless they want to dive in and see more stuff.  But, if they've dived in and understood Oracle errors and then run their app against Sybase, they get some nice portability until they dive into the Sybase pool.

/fred

Sedukhin, Igor S wrote:
Ok, if we accept what you propose I may let this go. It is not getting any better, it seems...
 
I suggest that we decice this on the call tomorrow.

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749 

 


From: Vambenepe, William N [mailto:vbp@hp.com]
Sent: Wednesday, November 17, 2004 1:39 PM
To: Sedukhin, Igor S; wsdm@lists.oasis-open.org
Subject: RE: [wsdm] cases on situation categories

Igor,
 
Do you think that allowing more than one situation category would cover your examples better? If events are related to more than one it can be expressed in the message...
 
William


From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
Sent: Wednesday, November 17, 2004 8:40 AM
To: wsdm@lists.oasis-open.org
Subject: [wsdm] cases on situation categories

#1 there is a property which is mydevice:ConnectedTo which indicates the name of the network which the device is currently connected to e.g. Nothing, GSM900, GSM1900, GSM 1800, 802.11g, 802.11.b etc. Such property is writeable and could be set by the manager, so this is configuration. When a property change event has to be generated by an manageability implementation for this device, what would be the situation category to put in the event data: Configuration, Connection or Report? What part of the WSDM spec will be sufficient to describe the choice for an average developer?
 
#2 there is an OperationalState property and an event is generated for this property change when state transition from DOWN:CRASHED to DOWN:STOPPED. What does one put as a situation category: Availability, Stop or Report? In this case, availability did not change so it is just a report, but the operational state certainly defines the availability. DOWN:STOPPED is a state which indicates that resource is stopped, but its availability didn't really change in case of this transition. However this would not be true if transitioning from UP to DOWN:STOPPED, in that case the availability changes. A) What in the spec would lead one to be crystal clear on which situation category to pick in this case? B) What if the event generator has no knowwledge of the actual resource state model? How would it decide between UP->DOWN:STOPPED and DOWN:CRASHED->DOWN:STOPPED?
 

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749 

 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]