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.
Difference between revisions of "Cosmos Architecture Meeting 01-Nov-07"
(→General Error Handling and Logging across COSMOS components) |
(→Next Steps) |
||
| (10 intermediate revisions by 2 users not shown) | |||
| Line 16: | Line 16: | ||
* Localization | * Localization | ||
* Namespaces (how do we choose this) | * Namespaces (how do we choose this) | ||
| + | * Lay the groundwork for serviceability | ||
=== General Error Handling and Logging across COSMOS components === | === General Error Handling and Logging across COSMOS components === | ||
'''Logging Requirements''' | '''Logging Requirements''' | ||
| + | * We would like to have consistency from the log to the component to the code | ||
| + | ** We should also be consistent in identification, including the instance identifier | ||
| + | ** Tie the instance identifier to the management endpoint (WSDM) that can be used to control the component | ||
* What is the structure of the logs--a physical view? | * What is the structure of the logs--a physical view? | ||
* Need to define the "logging architecture" | * Need to define the "logging architecture" | ||
| Line 31: | Line 35: | ||
* Symptoms | * Symptoms | ||
| − | + | ''' Error/Exceptions Requirement ''' | |
| − | '' | + | * Must log these |
| − | * Jimmy will put together | + | * Examples of design documents that can be used as templates: |
| + | http://wiki.eclipse.org/index.php?title=COSMOS_Design_200222 <br/> | ||
| + | http://wiki.eclipse.org/index.php?title=COSMOS_Design_204959 | ||
| + | |||
| + | === Next Steps === | ||
| + | |||
| + | *[[COSMOS internal logging use cases]] Jimmy will put together | ||
** Post mortem debugging | ** Post mortem debugging | ||
** Day to day operation | ** Day to day operation | ||
| − | + | * Prepare review & demo of existing tooling | |
| − | * | + | ** Valentina to show/walk through TPTP in Detroit |
| − | * | + | |
| + | |||
| + | * Start identifying the "low hanging fruit" for the logging architecture (Jagmit w/Valentina's help) | ||
| + | |||
| + | * First step of implementation would be to take all the "noise" currently going to the console to the logs (target i8) | ||
Latest revision as of 11:51, 1 November 2007
Contents
Attendees
- Bill Muldoon
- Saraub Dravid
- David Whiteman
- Balan Subramanian
- Valentina Popescu
- Jack Devine
- Jimmy Mohsin
- Hubert Leung
- Don Ebright
- Ali Mehregani
- Mao Sheng
- John Todd
Minutes
- Localization
- Namespaces (how do we choose this)
- Lay the groundwork for serviceability
General Error Handling and Logging across COSMOS components
Logging Requirements
- We would like to have consistency from the log to the component to the code
- We should also be consistent in identification, including the instance identifier
- Tie the instance identifier to the management endpoint (WSDM) that can be used to control the component
- What is the structure of the logs--a physical view?
- Need to define the "logging architecture"
- Tracing/Logging levels
- Need to have description of error log.
- Would like to have one logical view of the log.
- Standardized log format
- Do we choose CBE or WEF
- Symptoms
Error/Exceptions Requirement
- Must log these
- Examples of design documents that can be used as templates:
http://wiki.eclipse.org/index.php?title=COSMOS_Design_200222
http://wiki.eclipse.org/index.php?title=COSMOS_Design_204959
Next Steps
- COSMOS internal logging use cases Jimmy will put together
- Post mortem debugging
- Day to day operation
- Prepare review & demo of existing tooling
- Valentina to show/walk through TPTP in Detroit
- Start identifying the "low hanging fruit" for the logging architecture (Jagmit w/Valentina's help)
- First step of implementation would be to take all the "noise" currently going to the console to the logs (target i8)