Notes

  • Last week - LOG Meeting Minutes 2018-06-19
  • POMBA scope change vote Thu morning at 0245 EDT (GMT-5) at TSC beijing meet
    • Note from Michael O'Brien on June 21: At 0510 (20 min over) Alla clarified that we do not need a vote (usually we do) – we all heard an OK – I mark this issue as closed – thanks Alla for the final push.
  • No pending commits for logging-analytics repo
  • board - https://jira.onap.org/secure/RapidBoard.jspa?rapidView=53&view=planning&selectedIssue=LOG-471&epics=visible
  • Casablanca release planning - Logging Casablanca Scope
  • RequestID:
    • Example code in the 1.2 spec (ONAP Application Logging Specification v1.2 (Casablanca)#MDC-RequestID) is out of date. Still refers to X-RequestID, should be X-ONAP-RequestID. 
    • Agreed to specify all three – past and future – headers for the duration of Casablanca, and standardize on one – X-ONAP-Request-ID after Casablanca release. 
    • Debated cutover versus supporting all three, and agreed that the impact on existing behavior would be unpalatable for many teams. 
    • TODO: go back and update specification. (LP: done).
  • Casablanca:
    • Machine-readable format:
      • Pipe-separated format vs. tab-separated → pipe-separated.
      • Original agreement was to revert to pipe-separated as per the Text Output example in the specification. That's the final decision.
      • Once provider configuration is templated, we can put the separator in values.yaml, 
    • Streams transports:
      • Options were logstash (native) and syslog. 
      • If we want to provide one out of the box, it has to be one that doesn't incur new dependencies in the classpath → syslog. 
      • This still leaves us with the problem of persistent queues at the logstash end. 
      • Assumption: syslog (since appenders are always available) AND logstash queues for persistence AND the ability to turn off any appender using values.yaml. 
      • TODO: find out where we are with log4j 1.X. (Since its support is likely limited without extra classes). 
    • Finalizing the specification:
      • But for typos and example code pending update, it's final. 
      • TODO: X-Request-ID (again)
    • Security:
      • Files owned by root (elasticsearch, filebeat, logstash). - the norm is not be root - but be "ubuntu" for example - see  LOG-481 - Getting issue details... STATUS
      • Credentials and other sensitive information to K8s secrets.
      • General hardening and port closure.
      • Search Guard:
        • FOSS.
        • RBA for log entries. 
        • AT&T have a sample implementation.  
    • Templated provider configuration:
      • (Helm)
      • Submit templated logback configuration for next week. 
      • TODO: add syslog appender under the control of values.yaml. 
      • TODO: by next week! (LP: will be the week after, new ETA July 10th.)
    • Compliance and backporting:
      • Limited developer capacity. 
      • Options:
        • Make changes ourselves → insufficient capacity. 
        • Raise bugs → obnoxious. 
        • Rate compliance → compliance matrix. Still requires us to do the analysis. 
        • Encourage adoption of reference libraries. 
        • Bring the architecture committee to bear on the problem. 
  • No labels

1 Comment

  1. LOG-634 - Getting issue details... STATUS

    see
    https://wiki.onap.org/display/DW/LOG+Meeting+Minutes+2018-06-26
    and the spec
    https://wiki.onap.org/pages/viewpage.action?pageId=28378955#ONAPApplicationLoggingSpecificationv1.2(Casablanca)-MDC-RequestID

    we need a way to support client/server calls between pods running the old or new versions of the http headers

    [~pau2882] is running into this during communication from pomba aggregator to context builder (based on AAI which is using the pre-casablanca headers)

    Larger issue is teams are not aware of the spec change - because we not communicated it yet.

    Plan is to support non-casablanca spec in casablanca and communicate the spec in dublin