Jump to: navigation, search




  • Don Ebright
  • Mark Weitzel
  • Joel Hawkins
  • Carlos Devoto
  • Dennis O'Flynn
  • Jack Devine
  • Jimmy Mohsin
  • Bill Muldoon
  • Valentina Popescu

Via Phone

  • Paul Stratton
  • Martin Simmonds
  • John Todd
  • Hubert Leung
  • Sheldon Lee-Loy
  • David Whiteman


  • Don Ebright
  • Mark Weitzel
  • Joel Hawkins
  • Dennis O'Flynn
  • Jack Devine
  • Jimmy Mohsin
  • Bill Muldoon
  • Valentina Popescu

Via Phone

  • Paul Stratton
  • Martin Simmonds
  • Hubert Leung
  • Sheldon Lee-Loy
  • David Whiteman

Collection of data--Northbound Interfaces

The first part of this discussion was a level set and review of the original charter since some of the members came to the project after the it was started.

The business problem is to simplify and standardize the interfaces that management products use.

The scenario is for a resource to advertise it's existence (event based "discovery"). The state of the resource will be reflected in the SML based MDR. Then COSMOS will begin to Monitor the resource through the standard interfaces. We will be able to control the resource through these interfaces as well.

We discussed ways to integrate with Nagios. We would like to be able to leverage and compliment existing Nagios installations. We need some recommendations from Craig Thomas on the right way to proceed. https://bugs.eclipse.org/bugs/show_bug.cgi?id=188390

We also would like to revisit how to collect information from SNMP and bridge to WSDM.

What resources should we target?

We are interested in working on resources that do not currently have well formed instrumentation and that have a degree of sex appeal in the industry. The two that we've considered are SCA (via the Apache Tuscany project) and virtualization (via Xen).

There was some initial work done by Joel on instrumenting SCA with WSDM. We will resurrect this code, clean it up and put it in the Management Enablement project. Then we'll post on the Tuscany mailing list that we've taken this first step.

Revive JMX bindings for annotations

  • We need to have the JMX collector capture events.
  • Need to have Event capturing / persistence for WEF

No in depth conversation was had on the Xen idea, but everyone agrees that having virtualized requires more information.


  • SCA (because we have some things working)
  • Virtualization (Xen) --Need to do some more exploration
  • SNMP - WSDM bridge
  • LAMP--Everyone already has this, so COSMOS would have limited value here.

How to monitor COSMOS itself?


IF you make any updates, PLEASE prepend your additions with your <LAST NAME, FIRST NAME>

Open Questions

QUESTION 1. Does EACH component write to a local log or a central log? For example, does a Data Manager write to a local location or to where the Management Domain lives?

ANSWER: Log locally; and allow a subset of the messages to be placed centrally. Low value high volume is local; rest is local & central. Each component should be able to describe its log details to a requester. Log file should have a WSDM EPR on top. Logging service should subscribe to the events. Attempt to have each component know as little as possible about logging. ISSUES & ACTION ITEMS: Get info from Valentina with regards to TPTP logging considerations. WEF versus CBE considerations; we do WEF and convert to CBE for TPTP. Need to do brokered notification in the interim.

QUESTION 2. How many levels of messaging do we need? Errors / warning / info? User / application defined?

ANSWER: Leverage what is defined in the WEF specification.


QUESTION 3. Do we have open source tooling for analyzing logs? Or do we need to write some basic tools? Or does "analysis" mean navigating a text file?



QUESTION 4. How do we define the "physical lifecycle" of a log? Is it an application session? Is it a day / week / month? Or is it an ongoing time-stamped entity?

ANSWER: Define and model the log resource; data center example has a start on this. We should treat a log file as a manageable resource, i.e. it should have a WSDM EPR on top.


QUESTION 5. In case the logs end up being stored in small chunks, do we need to ability to merge logs from DIFFERENT sources / times ?

ANSWER: TPTP can do some of this work.

ISSUES & ACTION ITEMS: Follow up with Valentina Popescu for more specifics in terms of TPTP capabilities. TPTP has no Web 2.0 artifacts.

QUESTION 6. Are there any metrics to archive or purge the logs?



QUESTION 7. Are any automatic action required in case a critical error is logged, e.g. an email to an application / system / network administrator?



QUESTION 8. Do we capture / entertain log messages from non-COSMOS artifacts, e.g. corporate components? Does COSMOS send log messages corporate components?



2. Ensure that all the designs for i7 / i8 / i9 are in order

  • Ensure that we agree on the delineation between the MDRs and the Broker; and the exact role of the Management Domain
    • COSMOS_Design_205658
    • COSMOS_Design_204921


1. Update the handshake between the Broker and the MDR

2. Define the URIs for the management capabilities for CMDBf, MDR, and SDMX

3. Support full WSDM implementation

4. Broker needs to store the meta data about the capabilities

5. Define the query APIs on top of the Broker, e.g. give me all the DMs that do X capability

==> Mark: Update this section a bit more.

(See notes from earlier discussion)

(We all agree this function should be there and the enhancement was updated.)

We need to have more detailed description of what this is and the deliverables. For example, does this include adding capabilities to the wsdm tooling, what about packaging etc..

These two bugs are related. We agree that these are good and should be i9.

Agree this is good. +1 but move to i9.

Valentina will update the description and we'll revisit.

==> Need new ER for adding property change listners to the MDR

Agree this is good. +1 but move to i8.

We'll discuss this as part of the programming model discussion. Please refer to COSMOS Design 208976

Agree: But need more details

==> Mark to open new ER for defining contract b/t DC and DR

Agree: Look at XLIFF http://docs.oasis-open.org/xliff/v1.2/cs02/xliff-core.html

Discussion deferred to programming model discussion on CMDBf

Discuss as part of Friday's discussion

3. M2 / Leveraging CMDBf Use Case - Wednesday 1:00 PM

4. COSMOS Programming Model - Thursday 8:00 AM

Hubert discussed the new programming model:

How do we use annotations? How do adopters use COSMOS? How do we use WSDM tooling?

Hubert showed a demo of the WSDM tooling and showed how to define capabilities (from WSDL, standard, or custom), generate code, and export a WAR file for deployment.


1. Annotations vs. tooling?

Roadmap: both will converge to support JAX WS Decision: use the annotations path

Required ERs:

  • support for J2EE, standard capabilities
  • setup workgroup for details

2. Data manager - assembly?

3. Data broker & domain?


Need an overall security architecture and design. This requirement is captured in Enhancement 209337 Security Scope Documentarget for completion in i8.

209337 will address/consider:

  • What open security solutions are available?
  • Idenify security "must dos".
  • Define COSMOS roles.
  • Deployment of security solution. How external security is hooked in.
  • web servers to target.
  • Physical infrastructure.
  • How authentication and authorization works.

On completion of 209337

An ER (AKA ER1) or ERs for the design and basic implementation of Authentication and Encryption and the design of Authorization. Completion in i9.

Basic implementation will provisionally target an LDAP/Active directory default implementation.

Approach for declarative categorization of the authorizations.

On Completion of ER1

An ER (AKA ER2) or ERs for the implementation of Authorization for completion in i10.

Next Subject

Action Items

  • Joel will coordinate with Dennis and Carlos to draft initial roadmap/plan/set of tasks to define this work. This will tie into the reconciliation of the WSDM annotations and JAX-WS work. (The enhancement requests and plan will be prepared for the DC call on Tuesday Nov 13.). We also need to include the generation of a client from an annotated interface. This must include the roadmap to the "hybrid". Balan will need to be involved. We need documentation on how it works, use the annotations, et. Must document and prioritize the requirements...
  • Mark will create a wiki page with the visual of the scenario
  • Mark to draft initial roadmap/plan/set of tasks to define the virtualization work

(The enhancement requests and plan will be prepared for the DC call on Tuesday Nov 27.)

  • Don to re-engage with Bob Natalie from the IETF MIB2RDML project.