wsdm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsdm] cases on situation categories
- From: "Vambenepe, William N" <vbp@hp.com>
- To: "Thomas Studwell" <studwell@us.ibm.com>
- Date: Wed, 17 Nov 2004 16:27:02 -0800
Hi Tom,
I didn't realize you had already made such a proposal in
v0.8 (albeit with a SHOULD rather than a MUST). Great minds think
alike...
William
William,
I will be happy to attend your award ceremony.
I am ok
with this although I don't know how to express the XML. I had reordered the
SituationCategories in the WEF V0.8 spec so that the categories are in the order
of relative importance to management functions based on our analysis of system
impacts.
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)
"Vambenepe, William N"
<vbp@hp.com>
"Vambenepe, William N"
<vbp@hp.com>
11/17/2004 06:15 PM |
|
Still in the spirit of trying to find a common ground
(in additional to the Nobel Prize in Literature for best written spec I am also
aiming for the Nobel Peace Prize for getting Igor and Tom to agree) what if we
presented the situation categories as an ORDERED list. Basically we come up in
our spec with a specific order (e.g. 1st "AvailabilitySituation", 2nd
"ConfigurationSituation", 3rd "ConnectSituation", etc).
The process for an event
producer to assign a situation category is to look at the first category in our
list (in my example "AvailabilitySituation") and decide whether this one
applies. If yes, then this is the category to report and you are done. If not
then move on to the next one (in my example "ConfigurationSituation") and repeat
until you've reach the first category that applies to your event. Obviously the
last situation category in this list would be "other", guaranteeing a
convergence of the algorithm.
This would bring more consistency on what category people chose.
If something is both related to availability and configuration it will always be
categorized as availability (in my example). Also, by classifying something as
"ConnectSituation" I also assert that it is neither an "AvailabilitySituation"
nor a "ConfigurationSituation").
Would this added consistency make you more comfortable
Igor?
Obviously
if people like this we now have in front of us the challenge of agreeing on the
actual order, which could be another interesting discussion...
Regards,
--
William
Director, William
Vambenepe Center for Peace of Earth
From: Thomas Studwell [mailto:studwell@us.ibm.com]
Sent: Wednesday,
November 17, 2004 2:57 PM
To: Sedukhin, Igor S
Cc: wsdm@lists.oasis-open.org
Subject: RE: [wsdm] cases on
situation categories
While I hate speculating on an 'Igor' device for which there is
no specification sheet (and who knows what kind of surprising and customer
unfriendly behavior it will exhibit) I will repeat my previous assertion. A
configuration situation is just that - a configurationsituation. If your device
is required to report this then it should report the configuration event. The
results of this configuration could be many, it could be none, but they are
distinct from the configuration. Any results that are event producing, such as
loss of connection, are also distinct and should be reported in their
appropriate categories.
It is not the device's responsibility to
determine how it should be managed, that is governed in large part by the
infrastructure. The device's responsibility is to clearly and distinctly report
the 'stuff' that the infrastructure might care about. The subscribers are in a
much better position to correlate multiple events than to try to resolve pieces
of compound events.
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 05:30 PM |
|
ok. so then if someone switches the wireless off on a
device and that is reflected in a configuration property change event then
should there be
A) one property change event message with
ConfigurationSituation indication
B) two property change event messages one
with ConfigurationSituation indication and another with ConnectSituation
indication
-- 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 5:01 PM
To: Sedukhin, Igor
S
Cc:
wsdm@lists.oasis-open.org
Subject: RE: [wsdm] cases on
situation categories
Response 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 04:31
PM |
|
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?
<tws> yes. The
configuration change is a very distinct event, anything that happens after that
is equally unique and is evaluated on its own merit. Please excuse the poor
phraseology in my original note. I'll rephrase:
<p>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<period></p>
<p>The establishment of
a new connection (and/or the loss of the previous one) is a distinct event and
reported as a ConnectSituation regardless of whether the connection was
established due to external factors (like negotiation with a remote modem) or
due to configuration changes within the resource.</p>
</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 4:01 PM
To: Sedukhin, Igor
S
Cc:
wsdm@lists.oasis-open.org
Subject: RE: [wsdm] cases on
situation categories
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]