E2EMeetingMinutes31Oct06

COSMOS End-to-End Use Case

Meeting Minutes, 31-Oct-06

Attendees:

• Brian Vetter
• Craig Thomas
• Don Ebright
• Mark Weitzel
• Toni Drapkin

• The need for these use cases is to demonstrate the flow of how the “big pieces” come together.
  • SML is viewed as a key piece of technology that can flow between these pieces
  • “Resource” is a very broad term. SML “could” be used to describe a wide variety of things. The feeling is that we would like a consistent way to describe basic building blocks, e.g. servers, switches, as well as complex things, e.g. a data center.
  • We want to show the entire life cycle and show what will be implemented in COSMOS vs. what will be enabled in COSMOS
    • We will not implement complex analytics, but will enable them
    • We would like to enable the usage of this information in ITIL, e.g. configuration management, but will not implement it. See Commercial Differentiation
• There was a general discussion on how we determine the resource model. This is IT Management’s version of the chicken and the egg: Do I have a resource, b/c I have a set of monitoring information, or do I monitor b/c I have a resource?
  • The conclusion is that the resource model is the lowest layer (or maybe, ‘the most fundamental concept’)
  • Relationships and dependencies are key concepts that need to be reflected in the instrumentation tooling

• There was a discussion on how to use resource models in an “instrumentation model”
  • We would like to define a resource model, and then define an “instrumentation model” that describes the key instrumentation points of the resource
  • We can use the “instrumentation model” to drive the tooling
    • Use for code generation
  • The next step is to “get everything ready” for deployment. This might be where a specific agent infrastructure is bound
  • Deploy and Run
    • This can be an “embedded test environment” in eclipse
    • Production environment

• There was an observation that the kind of information that a developer needs is different from what an admin would need
  • Developers would be closer to configuration
  • Admins close to performance data. This was because performance is affected by a number of factors that a developer may not have, e.g. bigger/faster hardware, more memory, etc…

Action Items

Mark W. agreed to put together a few graphics around the end-to-end flow. They will be posted on the High level architecture page.