LOG Meeting Minutes 2019-11-05

Agenda

• In the process of promoting Kevin Smokowski as one of committers for the logging project, voting ends on 06 Nov 2019 6pm EST
• El Alto was officially released on 30 Oct 2019 
• The future of logging project
• Frankfurt status
  • M1 is targeted for 07 Nov 2019 , logging is currently behind  

    T	Key	Summary	Assignee	Reporter	P	Status	Resolution	Created	Updated	Due

    Loading...

    Refresh
  • update to version 3.x of Python
  • update to Java 11 ✅Dave Williamsonto reach out Kevin Smokowski to evaluate the effort required
• Draft Frankfurt spec ONAP Application Logging Specification v1.3 (Frankfurt) - Continuation
  • Is there any components still write log to /var/log/ONAP_EELF? Luke ParkerAny updates? 05 Nov 2019 see below
  • We owe Steve Smokowski an answer for his question on August 30, 2018 (Response Code and Response Description) and September 4, 2018 (Invoke and Invoke-return).
    - Sanjay and Dave Williamson to talk with the AT&T Ops team for the use of Response Code and Response description.
    ✅- Prudence Auto reply to Steve on invoke and invoke-return and add a JIRA ( LOG-1174 - Update reference library to include a sample invoke-return marker OPEN )to update the sample implementation to include invoke-return marker 
  • What is needed for Michael's TODO on November 21, 2018 regarding X-FromAppId?
    ✅Prudence Au to include X-FromAppId as one of the option for PartnerName
  • Still need to address the issue with 2 test environments and only 1 log instance?  Dave Williamson reported it on December 6, 2018
    Sanjay and Dave Williamsonto investigate.  This might be resolved by the tenant isolation feature.
  • The description for p_message should be updated to "standard attribute - defined in logback.xml - Message - used for %msg%" as suggested by Lorraine Welch on  July 3, 2019?
    ✅Agreed to update the description as described by Lorraine.
  • Removing "VirtualServerName" as mentioned by Dave Williamsonon July 23, 2019? 
    ✅Agreed
  • Still need a description for ServiceInstanceID, any taker?
    ✅Suggestion: An unique identifier of a newly instantiated network service instance.
    ----------------------------------------------------------------------------------------
  • Any feedback on Kevin Smokowski's comment on August 6, 2019 regarding the use of User-Agent as PartnerName?
  • Any feedback on Kevin Smokowski's comment on August 5, 2019 regarding the value of ServerIPAddress in the case of docker & kubernetes deployment?
  • Any updates needed for TargetEntity and PartnerName?  Mentioned on August 15, 2019 (a conversation between Dave and Kevin)
  • Any feedback on composite RequestID or NOT composite RequestID (from October 2, 2019)?

Attendees

Notes

Compliance Report

Where:

• Files whose path suggest they're for testing are skipped. 
• XML is sanitized first: 
  • To remove XML comments. 
  • To fix XML that has bad data ahead of <?xml, including a lot of copyright headers. (Java may fare better than Python, but they're technically invalid).
• A few documents (properties and XML both) are unparseable for other reasons, so they're reported as such in Notes.
• Analysis is pattern-based and fairly superficial: 
  • There are 300+ files. 
  • Even within EELF, there's a lot of variation. 
  • For Logback, EELF is identified by characteristic MDC keys, and compliant logging by telltale MDC serialization, markers and escaping (all of which seem to be non-existent in non-compliant logging). 
  • For Log4j, likewise, but slightly more forgiving when sniffing for EELF, and there are no instances of compliant logging for Log4J, so nothing to look for. 
• Summarizing: 
  • Log provider configuration is in shambles. 
  • Ad hoc configurations predominate. 
  • EELF remains ubiquitous. 
  • Log4j, too, and note the number of Log4j properties files (→ Log4j v1, which does not support escaping, and therefore cannot emit logs that can be reliably indexed). 
  • Compliant logging:
    • Is rare in component configuration (i.e. inside projects).
    • Is slightly more common in OOM overrides (which generally take precedence where they exist).