The COSMOS Project is a project proposed incubate under the supervision of the Technology PMC at Eclipse.org and once reaching full project status will become a top level project. This proposal is in the project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare its intent and scope. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment and/or join the project. Once announced, please send all feedback to the eclipse.technology.cosmos newsgroup. The project will follow the structure and guidelines as outlined by the Technology PMC.
In the IT industry there is a long history of tools being developed for specific roles or tasks. It has often been the case that these tools did not integrate with each other, even though they are all working with the same end resource. Systems management is no different. In the past, there have been efforts to declare common API or data formats to facilitate integration and open communications. These efforts generally focused on a particular subset of resource types, execution environments, or management domain. However, the activities involved in managing the entire life cycle of an IT resource span a wide set of domains. Viewed holistically, systems management encompasses many disciplines and user roles that can be divided into several high level categories, such as:
Configuration change tracking
COSMOS is being proposed to facilitate the first steps in the next evolutionary move in the integration in the area of systems management.
The mission of the Eclipse COSMOS Project is to build a generic, extensible, standards-based components for a tools platform upon which software developers can create specialized, differentiated, and inter-operable offerings of tools for system management.
It is important to focus the initial project efforts on specific problems. The domain of system management as shown above is very large and there is plenty of work to be done. Initially the key problem areas COSMOS intends to target can be described as follows.
In the area of resource monitoring there are already many ways to observe information about common resources. In fact many resource providers support several of the current standard APIs in an effort to publish informationto the widest audience possible. However there is a constant trade off of performance and other factors against providing all the data to anyone requesting it. This has lead to support for purpose driven APIs have been standardized in order to try to focus the amount of data being requested. However although often APIs have been agreed and implemented, the data made available via these interfaces is not always consistent. The units of measure as well as the meaning of the terms are critical. For example is "available memory" of 2000 a measure of megabytes of RAM or gigabytes of disk space.
Historically it has been the case that each data consumer leveraged some mechanism, often a local agent, to manage it's access to the resource through some published api, and these agents would be in conflict with each other, causing customers to pick specific vendor solutions which implicitly excluded others. Because the use of the data is often greatly varied, and vendors typically do not cover every single user use case, this is a significant problem for end users. Users were also left with the cost of ownership and administration of these agents as they had to mix and match agents with run times depending on the tools they wanted to use. End users are now demanding agentless environments when environments provide native collection systems.
In order to address this set of problems, COSMOS intends to provide a data staging server that will exploit existing infrastructure and APIs to access data and normalize it into a single agreed form. In cases where local agents are required existing infrastructure will be used to access the data. COSMOS will promote standards based data collection systems and work with the community to select the optimal standards to follow.
In order to provide a complete out of the box user experience, and to demonstrate the value of the data that can be collected, COSMOS will also provide a BIRT based web interface as well as an RCP client. These user interfaces are being provided as reusable examples for browser or thick client tools. These will provide an exemplary out of the box experience to the COSMOS user.
There are times when data from multiple resources need to be correlated in order analyze one resource in the context of another. A typical example is transaction decomposition of a distributed application. Standards such as ARM from Open Group are intended to address this need, however this is an example of the previously mentioned purpose driven APIs. As a run time component it provides a way to define correlation tokens and present them in logged events, however each implementation is unique and the run time needed to pass the correlation data is redundant with each provider.
COSMOS will leverage the work done by various run times and the TPTP project to advocate a standard correlation mechanism that can be used in distributed decomposition scenarios. COSMOS will consume this correlation data and support the consumption and provisioning of ARM events using this data. This will be done in the data collection component.
In order to allow data providers, be they existing resources or new applications, to more easily develop any new code needed to expose data through the standard interfaces COSMOS will provide developer targeted tools, if they do not exist, to simplify the task. COSMOS will manage a dependancy on tools and services in other open source projects when they exist rather than develop new ones. When COSMOS does need to develop technology in the area of enablement it will be done in the build to manage component.
In most tools that monitor resources there is an awareness of some of the more static features of a resource as well. For example the physical location and the IP address, in addition to the actual data being extracted from the resource is often known. Yet each tool has it's own representation of this information. With the growing presence of distributed and componentized applications this information also includes the overall topology of the application. This is redundant information between the tool used to debug a performance bottleneck and the tool that is used to deploy components of the application, or the tool that is doing load testing and monitoring of the application. Just as with the data collection scenarios discussed earlier there are also purpose driven formats for this kind of information. An example is the SCA composition model which is intended to describe the composition and relationship of the components making up the application, but at some point it is not intended to model the asset tags used in the inventory of a data center or abstract design views of the application. The resolution of this redundancy can once again be addressed by having a canonical representation of the resources. To that end SML is proposed as a constrained extension of XML to be used as the language to interchange this kind of information. COSMOS will provide a reference implementation of a Service Modeling Language Interchange Format (SML-IF) storage and validation system as well as basic tools to manipulate such data.
The project will contain several components; monitoring user interface, data collection and server, build to manage, and resource modeling.
The goal of this proposal is to generate interest among companies involved in systems management so that the project can be defined by the community with an agreed upon scope. However, it is key to practically set the limits of the project at the outset. This project will deliver support for each of the categories described earlier, and do this via the components previously outlined. This is a significantly large domain and the COSMOS end user function will be limited to monitoring and data collection components needed to support application health monitoring and debugging as well as initial support for validating and manipulating Service Modeling Language (SML) based models.
In building an ecosystem and fostering community growth, it is important to provide a fundamental level of management function that offers immediate "out of the box" value to consumers and development tooling for vendors, resource providers, and system administrators. This is the objective of the first release of Cosmos. Following releases will add value for subsequent categories of use at the framework and end user function level.
Each component is complimented by set of development tools that facilitate the creation of extensions or authoring of key artifacts, e.g. resource models, agent configurations, etc. For example, the BIRT tooling can be used to create "canned" reports that can be deployed in the Web UI or re-used within the RCP client. The components of COSMOS will expose extension points to allow for both run time extension as well as tooling value add.
It will provide immediate "out-of-the-box" value with workable solutions for resource monitoring and modeling upon open standards. These capabilities are useful in themselves for monitoring, and basic management needs, but are even more useful as building blocks for constructing higher-level management functions. The combination of tooling and run time offer a distinct advantage for COSMOS as no other open source offering effectively covers multiple aspects of the management life cycle.Integration with other Eclipse projects adds to the application life cycle already supported by those projects. This unique advantage over other open source projects directly benefit users who will extend the framework and tooling.
COSMOS will follow a 7 week iteration cycle leading to a 1.0 release in March and a 1.5 release in June 2007 aligned with the Eclipse platform. The initial commitment will be to deliver the systems monitoring support and SML validation described earlier. As more committers are confirmed, the PMC will determine if more function can be provided on the same schedule. The next priority after systems monitoring support will be resource modeling, beginning with support for the emerging SML standard. The first iteration, due in Oct 06, will be focused on establishing the project infrastructure. Transferring function from other eclipse projects such as TPTP, will be discussed as possible deliverable in 1.5. The following are the current iteration complete dates.
|I0||11/09/06 - 27/10/06||Establish infrastructure|
|I1||30/10/06 - 15/12/06|
|1.0 Shutdown||15/01/07 - 02/03/07||1.0 GA|
|I2||15/01/07 - 02/03/07||1.5 Feature/API freeze|
|I3||05/03/07 - 20/04/07||Documentation freeze|
|I4||23/04/07 - 01/06/07||Candidate GA|
|1.5 Shutdown||02/06/07 - 29/06/07||1.5 GA|
The following companies are helping to shape the project and may contribute committers to get the project started:
The following companies have expressed interest in the project:
Back to the top