wsdm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsdm] cases on situation categories
- From: "Sedukhin, Igor S" <Igor.Sedukhin@ca.com>
- To: "Thomas Studwell" <studwell@us.ibm.com>
- Date: Wed, 17 Nov 2004 16:31:11 -0500
Tom,
The two statements below contradict each other, don't they.
Or am I just not getting something here (which may entirely be the case)... one
says configuration change ->(may)-> ConnectSituation another says
configuration change ->(must)->ConfigurationSituation.
#1 [If the result of the configuration change is the establishment of a new
connection (and/or the loss of the previous one) then these events are distinct
and reported separately as ConnectSituations]
#2 [It gets a configuration
change it generates an event that has a ConfigurationSituation. period. There is
absolutely nothing ambiguous about this.]
Or
does this mean that there may be two separate events generated for the same
occurance of the configuration property change?
-- Igor
Sedukhin
..
(igor.sedukhin@ca.com)
-- (631)
342-4325
..
1 CA Plaza, Islandia, NY 11749
Responses below.
Thomas W. Studwell
Senior Technical Staff Member,
Autonomic Computing Architecture
IBM Software Group
C151/Bldg 500
4205
S Miami Blvd, Durham, NC 27703
(919) 254-7574 Fax: (919) 254-7628 Mobile:
(919) 619-1038
studwell@us.ibm.com
"What marks the mind of the
strategist is an intellectual elasticity or flexibility that enables him to come
up with realistic responses to changing conditions... In strategic thinking, one
first seeks a clear understanding of the particular character of each element of
a situation and then makes the fullest possible use of human brainpower to
restructure the elements in the most advantageous way." (Keniche Ohmae, The Mind
of the Strategist)
"Sedukhin, Igor S"
<Igor.Sedukhin@ca.com>
"Sedukhin, Igor S"
<Igor.Sedukhin@ca.com>
11/17/2004 02:46 PM |
|
Tom,
[If the result of the configuration
change is the establishment of a new connection (and/or the loss of the previous
one) then these events are distinct and reported separately as
ConnectSituations]
I'm not sure it is reasonable
to ask the implementation of a manageability endpoint to make such
distinction.
<tws>we are not asking a
manageability endpoint to distinguish anything. It gets a configuration change
it generates an event that has a ConfigurationSituation. period. There is
absolutely nothing ambiguous about this.</tws> I don't think it will be able to make it in many
cases.<tws> no comment</tws>
This requires very intimate understanding of what the
configuration is about instead of say, providing access to a configuration file
of sorts. We're asking too much from an implementer of the software shich
supports manageeability of resources using WSDM.<tws>I disagree</tws>
Managers should have this
knowledge and ability to classify events, not resources. Again, we're doing a
disservice to the implementers of the WSDM standards who want their resources to
be manageable in order to make life for our management software easier. Is that
reasonable?<tws>Yes! Because, in the end, we do
ALL of this for our respective customers. The alternative is that we have to
swizzle our management products for every new widget that comes along and guess
what? Only widgets from the big guys that are going to sell MILLIONS will get
the swizzling resources because there are too d**n many to do otherwise. So the
little guy who might have a better piece of equipment will not be manageable
unless they copy the behavior of one of the big guys' piece of equipment. You
keep talking about interoperability but then you go out of your way to insure
that there are so many choices and variations with nothing defined or required
so that interoperability is almost impossible. As you say, we'll decide this
tomorrow.</tws>
-- Igor Sedukhin
..
(igor.sedukhin@ca.com)
--
(631) 342-4325 .. 1
CA Plaza, Islandia, NY 11749
From: Thomas Studwell [mailto:studwell@us.ibm.com]
Sent: Wednesday,
November 17, 2004 12:44 PM
To: Sedukhin, Igor S
Cc: wsdm@lists.oasis-open.org
Subject: Re: [wsdm] cases on
situation categories
Igor, responses below. See my reply to Andrea's note as
well.
Thomas W. Studwell
Senior Technical Staff Member, Autonomic
Computing Architecture
IBM Software Group
C151/Bldg 500
4205 S Miami
Blvd, Durham, NC 27703
(919) 254-7574 Fax: (919) 254-7628 Mobile: (919)
619-1038
studwell@us.ibm.com
"What marks the mind of the strategist is
an intellectual elasticity or flexibility that enables him to come up with
realistic responses to changing conditions... In strategic thinking, one first
seeks a clear understanding of the particular character of each element of a
situation and then makes the fullest possible use of human brainpower to
restructure the elements in the most advantageous way." (Keniche Ohmae, The Mind
of the Strategist)
"Sedukhin, Igor S"
<Igor.Sedukhin@ca.com>
"Sedukhin, Igor S" <Igor.Sedukhin@ca.com>
11/17/2004 11:39 AM |
|
#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?
<tws>As I point out in my note to
Andrea, the configuration of a network device may or may not result in the
ability to connect to a different network but is always a
ConfigurationSituation. If the result of the configuration change is the
establishment of a new connection (and/or the loss of the previous one) then
these events are distinct and reported separately as
ConnectSituations.</tws>
#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?
<tws>if the states are substates of
availability then one would always report these as availabilitySituations since
they all belong in that high level category. While these are finer grained and
warrant subcategorization the highest level category is AvailabilitySituation.
Even the precedent rule backs up this conclusion if there was any uncertainty as
to which category to use. ReportSituation would be used only if the state did
not belong to an operational state, such as Printer Ink Low, for
example.
One should
not mistake the categorization as an attempt to exactly replicate the situation
- this can not be done canonically. The purpose of the category is to provide a
means of classifying sets of events into a limited set of categories so a
management function can quickly deal with only situations within a narrow set of
categories, ie, I only want to deal with events that are configuration or
availability related. I'll look at the detail of the availability events to see
if it is DOWN:CRASHED or DOWN:STOPPED.</tws>
-- 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]