[Oslc-recon] Proposed addition to the specification for representation and reconciliation of clusters

Tue Sep 3 10:08:55 EDT 2013

I think that just means that the crtv type should be the subtype, rather
then Cluster, and the identification rule should be defined for each
subtype.

Joe

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Jazz for Service Management
512-286-8311, T/L 363-8311

From:	Janet Andersen/Raleigh/IBM
To:	Joe Ross/Austin/IBM at IBMUS,
Cc:	oslc-recon at open-services.net, Oslc-Recon
            <oslc-recon-bounces at open-services.net>, Tuan
            Dang/Raleigh/IBM at IBMUS
Date:	09/03/2013 09:03 AM
Subject:	Re: [Oslc-recon] Proposed addition to the specification for
            representation and reconciliation of clusters

I think crtv:name will not be sufficient to uniquely identify a cluster
when there are different types of clusters in the environment.   Some
clusters (e.g.  Microsoft Server Clusters)  have user-defined cluster names
and, if administrators across different cluster types do not coordinate
their naming conventions, there could be conflicts if the same user-defined
name is chosen.   Therefore,  it may be best to use a combination of
crtv:name and a subtype for the naming rule.

Thanks!

Janet S. Andersen
IBM Tivoli Monitoring
Research Triangle Park, NC
Phone:   919-224-1440, T/L 8-687-1440
Internet:  janetand at us.ibm.com

  From:       Joe Ross/Austin/IBM at IBMUS                                                                                                 

  To:         Tuan Dang/Raleigh/IBM at IBMUS                                                                                               

  Cc:         Oslc-Recon <oslc-recon-bounces at open-services.net>, oslc-recon at open-services.net                                           

  Date:       08/31/2013 09:26 AM                                                                                                       

  Subject:    Re: [Oslc-recon] Proposed addition to the specification for representation and reconciliation of clusters                 

  Sent by:    "Oslc-Recon" <oslc-recon-bounces at open-services.net>                                                                       

I think that a crtv:Cluster type makes sense, since this is itself an IT
resource, not just an arbitrary grouping of resources. crtv:name seems like
a good identifying property. Subtypes might make sense if different
identifying propertes are needed for different subtypes or if the same name
can exist in different clusters of different types.

Reuse of rdfs:member for cluster members makes sense, although, I don't
really see the need for the rdfs:Container rdf:type, since crtv:Cluster
itself is presumably defined as making use of the rdfs:member property. As
I mentioned above, these are real-world IT resources and not arbitrary
groupings.

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Jazz for Service Management
512-286-8311, T/L 363-8311

Inactive hide details for Tuan Dang---08/30/2013 02:16:36 PM---Hello all,
Various IBM product development teams are implementinTuan Dang---08/30/2013
02:16:36 PM---Hello all, Various IBM product development teams are
implementing the Reconciliation

From: Tuan Dang/Raleigh/IBM at IBMUS
To: oslc-recon at open-services.net,
Date: 08/30/2013 02:16 PM
Subject: [Oslc-recon] Proposed addition to the specification for
representation and reconciliation of clusters
Sent by: "Oslc-Recon" <oslc-recon-bounces at open-services.net>

Hello all,

Various IBM product development teams are implementing the Reconciliation
spec and would like to represent the concept of "Cluster".
Concrete examples being the machines in a failover/load balancing group, a
set of application servers or even more generically,  a group of resources
as defined by a user.

The use case is that service provider would advertise its knowledge of a
cluster and its members and clients would query for provider specific data
or issue commands against that cluster.
Multiple service providers could know about this cluster and we would also
need to discuss rules for reconciling cluster instances coming from
multiple sources.

Internally, IBM is using rdfs:Container and rdfs:member to represent a
group of systems but also wants to indicate that this is a cluster in the
IT specific sense.

The proposal is to add to CRTV the resource type
http://open-services.net/ns/crtv#Cluster with description "A set of
connected systems (either physical or logical) that work together such that
the set can be viewed as a single system"
We'll also need to discuss whether we should be even more specific and
create resource types for example crtv#MicrosoftFailoverCluster or
crtv#ZsystemCICSPlex

For reconciliation, we need a way to determine if Cluster1 from service
provider 1  is the same object as Cluster2 from service provider 2.  We
could posit that if Cluster1.crtv#name is
the same as Cluster2.crtv#name then Cluster1 and Cluster represent the same
object. Any other potential rules ?

Thanks ! T

Tuan Dang
CS&I Integration Scenarios and OSLC Reconciliation workgroup lead
Internet: tdang at us.ibm.com
phone: (919) 224-1242 T/L 687-1242
_______________________________________________
Oslc-Recon mailing list
Oslc-Recon at open-services.net
http://open-services.net/mailman/listinfo/oslc-recon_open-services.net
_______________________________________________
Oslc-Recon mailing list
Oslc-Recon at open-services.net
http://open-services.net/mailman/listinfo/oslc-recon_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-recon_open-services.net/attachments/20130903/0e95c596/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-recon_open-services.net/attachments/20130903/0e95c596/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-recon_open-services.net/attachments/20130903/0e95c596/attachment-0001.gif>