Uploaded image for project: 'ONAP TSC'
  2. TSC-15

Acumos and ONAP collaboration - ONAP as a driver of spec/artifacts to 3rd party LF projects


      I'll fill this out shortly.
      Key deliverables are - how we manage consumption of artifacts and specs by 3rd party open source projects that use ONAP.

      The code freeze of acumos is slightly behind onap - proposal is to work the Dublin spec during RCx in onap - ready for ONAP consumption without further changes - as we work it out with Acumos during the end of casablanca
      Note the acumos personnel from AT&T are the same one involved with Portal in ONAP

      Key points are spec and implementation
      spec is complete
      but implementation in ONAP is not - as expected because we will iterate adoption of the spec - starting in onap portal/sdk. Until then acumos has started iterating the spec - hence our tight integration and the benefit to ONAP

      An example is
      onap needs support from the JAX-RS spec for jackson library upgrades (as part of Java EE 8/9)
      and acumos needs support from the Casablanca/Dublin release of ONAP - where we need to define the timeline and size of work to implement a reference logging library by retrofitting the portal/sdk library with the proposed dublin spec.

      Currently Acumos pulls artifacts and architecture (logging, some kubernetes, ELK stack...) from ONAP (they keep in sync)
      We currently have no formal process for maintaining this relationship.
      Currently the PTLs and developers involved that work on both sides manage this.


            allagoldner allagoldner
            michaelobrien michaelobrien
            0 Vote for this issue
            4 Start watching this issue