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