Hello,
here a summary of the discussion about the Availability related topics in
yesterday's WG meeting:
(1) Make AvailabilityCondition as own type or part of AvailabilityResource?
-> We decided to leave the AC as an own resource type and not make its
properties part of the AR.
Reason is because this structure may be necessary for future work like
introducing a history of an AR's conditions.
(2) compoundState - replace with/ additionally introduce consistentState
with type boolean?
-> We decided to transform the compoundState into a better usable
structure. Details will be figured out,
but its likely that we will introduce a "consistentState" property of type
boolean that signals if everything is ok or if there is a problem,
and an additional field with a reference as type, that can be used by
implementors to provide (own defined) Strings with additional information.
(3) rto, mttr, mttf - use integer instead of ems:Measure (much more
simple)? Remove completely?
-> I will talk to Jürgen if he thinks they are important from SA z/OS's
point of view. If not,
these properties will be removed (can be added later for future versions of
the spec again).
If they stay, they will be declared as type integer and the description
will say that this integer value
will be the number of seconds, describing rto/ mttr/ mttf.
(4) SLA not required for scenarios. Is it obvious that it will be required
by most implementors of the spec? Or remove it?
-> Since not required for the scenarios, it will be removed for now.
(5) Make Redundandy{Group, Member} subclass of Availability{Group,
Resource}. I?m not sure, what is the best solution?
-> We decided to make the Redundancy resources a rdfs:subClassOf of the
related Availability resource,
because the Redundancy resources have too few own properties to make sense
as "stand-alone", they're only useful if they are also Availability
resources.
(6) Did I get it right to not use http://open-services.net/ns/ availability
and instead use http://open-services.net/ns/auto, because I would need to
request for this URL at OSLC Core?
-> Martin will ask Core for advice, what would be the best. Possible
solutions are (a) to reserve the http://open-services.net/ns/availability
namespace for us,
(b) move all availability stuff into the automation-ns or (c) introduce a
"sub-namespace" within automation like
http://open-services.net/ns/auto/availability.
(7) Not sure about consequences of memberOf vs. member (direction of
linkage between a group and it?s members).
-> Advice to elaborate the "Guidelines" section for the Availability Draft,
in particular considering questions like how a client will handle groups.
When this questions can be answered exhaustingly, the problem can be
discussed again on the mailing list.
(8) How to express in the spec that a service provider should define it?s
own property values but possibly define a small set of values, that are
enforced (like online/ offline and starting/ stopping for currentState).
-> Question was due to a misunderstanding of Tim how to interpret the Auto
spec, because this is done there, too (for example for the oscl_auto:state
property). Availability Draft will
handle it in the same way.
Thank you!
Mit freundlichen Grüßen / Kind regards
Tim Friessinger
System Automation for z/OS Development
IBM Software Group, Tivoli
IBM Lab Boeblingen, Germany
Phone: 49-7031-16-2535 IBM Deutschland
(Embedded
image moved
to file:
pic16491.gif)
E-Mail: tfri...@de.ibm.com Schoenaicher Str. 220
71032 Boeblingen
Germany
IBM Deutschland
Research &
Development
GmbH /
Vorsitzende des
Aufsichtsrats:
Martina Koederitz
Geschäftsführung:
Dirk Wittkopp
Sitz der
Gesellschaft:
Böblingen /
Registergericht:
Amtsgericht
Stuttgart, HRB
243294
