Skip to main content
Jump to: navigation, search


COSMOS End-to-End Use Case

Meeting Minutes, 31-Oct-06


  • 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.

Back to the top