Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Cosmos Architecture Meeting 10-December-08"

(New page: Attendees: * David (IBM) * Mark J. (IBM) * Jason (SAS) * Brad (CA) * Mark McCraw (SAS) * Jimmy (CA) Agenda: * Reconciliation Taxonomy (RTx) ** Mark J. started by giving background. Said ...)
 
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
Attendees:
+
These are the minutes for the [[COSMOS_Architecture_Meetings|COSMOS Architecture Meeting]] held on December 10, 2008.
 +
 
 +
==Attendees==
 
* David (IBM)
 
* David (IBM)
 
* Mark J. (IBM)
 
* Mark J. (IBM)
Line 7: Line 9:
 
* Jimmy (CA)
 
* Jimmy (CA)
  
Agenda:
+
==Agenda==
 +
* Mark J. to report on Management Developers Conference
 +
* Mark J. to drive discussion of [[COSMOS Reconciliation Taxonomy]]
 +
** Hierarchy in the RTx for software objects?  The annotations allude to this, but it is not implemented.
 +
** SDD could benefit from hierarchy [https://bugs.eclipse.org/bugs/show_bug.cgi?id=257430 257430]
 +
*** For example, SoftwareContainer hosts SoftwareAsset hosts SoftwareModule hosts ... etc.
 +
* Jimmy to report on CA World
 +
* Around the room
 +
 
 +
==Discussion==
 
* Reconciliation Taxonomy (RTx)
 
* Reconciliation Taxonomy (RTx)
 
** Mark J. started by giving background.  Said that early in the CMDBf process, they realized that getting data model convergence for purposes of federation was a "non-starter".  Many vendors have failed internally and externally at this.  For this reason, the CMDBf APIs are data model agnostic.  Consequently, there isn't a good way to determine when various repositories are managing the same resources.  Many implementations try to address this by not just using the name, but rather looking at the fundamental properties of a resource.  Some of these might include machine type & model, asset tag, MAC address, etc.  It turns out most people are using the same subset of properties for identification.  In Sept., IBM and CA did an interop and found that while they had wildly different data models, the key identifying properties were quite similar.  This allows for true federation and correlation of resources in disparate repositories.
 
** Mark J. started by giving background.  Said that early in the CMDBf process, they realized that getting data model convergence for purposes of federation was a "non-starter".  Many vendors have failed internally and externally at this.  For this reason, the CMDBf APIs are data model agnostic.  Consequently, there isn't a good way to determine when various repositories are managing the same resources.  Many implementations try to address this by not just using the name, but rather looking at the fundamental properties of a resource.  Some of these might include machine type & model, asset tag, MAC address, etc.  It turns out most people are using the same subset of properties for identification.  In Sept., IBM and CA did an interop and found that while they had wildly different data models, the key identifying properties were quite similar.  This allows for true federation and correlation of resources in disparate repositories.

Latest revision as of 10:56, 10 December 2008

These are the minutes for the COSMOS Architecture Meeting held on December 10, 2008.

Attendees

  • David (IBM)
  • Mark J. (IBM)
  • Jason (SAS)
  • Brad (CA)
  • Mark McCraw (SAS)
  • Jimmy (CA)

Agenda

  • Mark J. to report on Management Developers Conference
  • Mark J. to drive discussion of COSMOS Reconciliation Taxonomy
    • Hierarchy in the RTx for software objects? The annotations allude to this, but it is not implemented.
    • SDD could benefit from hierarchy 257430
      • For example, SoftwareContainer hosts SoftwareAsset hosts SoftwareModule hosts ... etc.
  • Jimmy to report on CA World
  • Around the room

Discussion

  • Reconciliation Taxonomy (RTx)
    • Mark J. started by giving background. Said that early in the CMDBf process, they realized that getting data model convergence for purposes of federation was a "non-starter". Many vendors have failed internally and externally at this. For this reason, the CMDBf APIs are data model agnostic. Consequently, there isn't a good way to determine when various repositories are managing the same resources. Many implementations try to address this by not just using the name, but rather looking at the fundamental properties of a resource. Some of these might include machine type & model, asset tag, MAC address, etc. It turns out most people are using the same subset of properties for identification. In Sept., IBM and CA did an interop and found that while they had wildly different data models, the key identifying properties were quite similar. This allows for true federation and correlation of resources in disparate repositories.
    • The RTx does not attempt to go beyond the identifying properties. A goal of it is to achieve consensus on this set of properties. It is intended to be simple. It is flat because having any depth results in impedance mismatches. Mark is unsure if in the future we will be able to stick to making it flat, but we will follow that approach for now until we really have to.
    • A first cut of the RTx has been submitted to CVS
    • Jason started talking about what SDD needs, which is a backend information model. There is a topology where all resources for a deployment are described. They are currently using a profile, which is a flat listing of resources and properties to be referred to in the SDD. The SDD runtime scans through the profile to see if it can handle all those resources, to know whether it can handle the deployment. This profile is based on CIM. They would like to move away from it due to its massive size.
    • The SDD runtime writes out what was deployed to an MDR. A critical requirement is to valid host and hosted by relationships. A hierarchy can help validate these.
    • Mark mentioned that relationships in CMDBf can type the source and target. This might help address SDD's needs. There may be a need for profiles to constrain types on relationships in the RTx.
    • Jason thinks that would get them most of the way there. However, he thinks inheritance would be needed for software subtype specific requirements. He thinks the RTx might be useful in determining what is written out to the MDR if we can't add inheritance to the RTx; perhaps inheritance only belongs in the SDD profile.
    • Mark's reaction is that putting the hierarchy in the SDD profile might lead to reinventing CIM and not knowing where to stop. He said that the part of the profile that would be useful would be a mapping to other models. Also he said that one thing that would help RTx robustness would be feedback on identifying properties. They deliberately kept the model on the thin side to keep it simple and limit growth.
    • Jason said that the set of software properties looked pretty robust, considering the examples they have seen commonly used
  • MDC
    • Mark said they did 3 sessions on CMDBf: overview, technical dive, joint with Fujitsu
    • Interop with Fujitsu used WSRR, CCMDB, and a Fujitsu repo. They federated data between those three using a subset of the RTx, with success. They showed a camtasia video showing screen captures. It was quite well received, and COSMOS was mentioned in 2 or 3 of the presentations as part of the architecture. Pretty good attendance at MDC.
  • CA World
    • Jimmy apparently dropped off the call, so we will need to get his trip report at another time.

Back to the top