20181025: update: originally we decided to continue the casablanca version v111 of ONAP Application Logging Specification v1.2 (Casablanca) in Dublin but after feedback/pushback from some parts of the AT&T based Acumos community and feedback/pushback from some parts of the AT&T based ECOMP community. I have received tremendous support and spec/JIRA work from Lorraine A. Welch, Spondon Dey, Shishir Thakore and Luke Parker (all the marker/mdc work and slf4j library). Creating a combined specification that meets the needs of private AT&T ECOMP that consumes Open Source ONAP, public Open Source Acumos that consumes parts of ONAP and even ONAP itself with it's several Logging implementations across Portal, SO, AAI is not really working or will take too long to accept a new library that everyone can accept. Since I am the current PTL, I have decided that an "ONAP first" direction is required. Any implementation/spec changes will need to be prototyped in public first and accepted directly into affected projects as we change the spec - not as an exercise after we have finalized the spec. I recommend that the way forward as suggested by the core of my coworkers in Acumos is to take an existing library and slowly iterate that library to match an "ONAP" specific spec that includes markers and MDC's and only if possible keep the older formats by the ONAP consuming projects. I will start from the bottom up for Dublin - using the portal/sdk library and adjust it in sync with any spec changes in parallel (no spec changes without first prototyping them in existing use cases by users of the portal/sdk library). For the E release we can increase adoption to the rest of the components not currently using portal/sdk. What is critical this time around is working with the team(s) affected by any adjustment to their library first. Secondary consideration will be given to non-opensource consumers of this specification inside corporations that privately wrap ONAP. This will mean becoming part of the public portal and policy weekly meetings as a de-facto sub-project.
General
Content
Integrations