Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Talk:COSMOSF2F-08-Nov-07

Revision as of 15:01, 7 November 2007 by Carlos.devoto.compuware.com (Talk | contribs) (2. Ensure that all the designs for i7 / i8 / i9 are in order)

Attendees

Wednesday

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

Via Phone

  • Paul Stratton
  • Martin Simmonds
  • John Todd


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.


Priority

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


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


How to monitor COSMOS itself?

Logging

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.

ISSUES & ACTION ITEMS:


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?

ANSWER: TPTP

ISSUES & ACTION ITEMS:


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.

ISSUES & ACTION ITEMS:


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?

ANSWER:

ISSUES & ACTION ITEMS:


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

ANSWER:

ISSUES & ACTION ITEMS:


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

ANSWER:

ISSUES & ACTION ITEMS:


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

broker: URIs and the handshake / advertisements ACTION ITEM:

1. Update the handshake between the Broker and the MDR 2. Define the URIs for the mgmnt capabilities for CMDBf, MDR, and SDMX 3. Support full WSDM implementations 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


(See notes from earlier discussion)


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


   * https://bugs.eclipse.org/bugs/show_bug.cgi?id=205826
   * https://bugs.eclipse.org/bugs/show_bug.cgi?id=205956
   * https://bugs.eclipse.org/bugs/show_bug.cgi?id=205960
   * https://bugs.eclipse.org/bugs/show_bug.cgi?id=205825
   * https://bugs.eclipse.org/bugs/show_bug.cgi?id=208584
   * https://bugs.eclipse.org/bugs/show_bug.cgi?id=208976

Next Subject

Back to the top