Agenda

Notes

  • Status and Stucks
    • Current POMBA Dublin Stories (Logging Project) -

    • Current Code Inspections

    • POMBA 6 hour healthcheck (full 200G CD deployment) - http://kibana.onap.info:5601/app/kibana#/dashboard/AWAtvpS63NTXK5mX2kuS
    • General Status

      • Dublin
        • Stories in progress: 
          • LOG-958 - Getting issue details... STATUS
          • LOG-957 - Getting issue details... STATUS
          • SDNC-637 - Getting issue details... STATUS
        • Stories to be formally verified before closure:
          • LOG-778 - Getting issue details... STATUS
          • LOG-763 - Getting issue details... STATUS
          • SDNC-475 - Getting issue details... STATUS : For network resource only and should be split into Network Discovery and ND context builder.
          • LOG-779 - Getting issue details... STATUS
          • LOG-404 - Getting issue details... STATUS
        • Stories closed since last meeting:
        • Bugs to enter:
          • Latest security scan results show ~9 medium issues that should be recorded (but aren't severe enough to merit immediate work).
        • Bugs entered in last week:
          • LOG-976 - Getting issue details... STATUS
          • LOG-975 - Getting issue details... STATUS
        • Bugs in progress:
          • LOG-852 - Getting issue details... STATUS
          • LOG-967 - Getting issue details... STATUS
          • LOG-966 - Getting issue details... STATUS
          • LOG-916 - Getting issue details... STATUS
          • LOG-965 - Getting issue details... STATUS
        • Bugs to be verified:
          • LOG-807 - Getting issue details... STATUS
          • LOG-803 - Getting issue details... STATUS  (Verify in OOM fails, assigned back to design)
          • LOG-808 - Getting issue details... STATUS
          • LOG-981 - Getting issue details... STATUS

        • Bugs closed off since last meeting:
          • LOG-933 - Getting issue details... STATUS
          • LOG-893 - Getting issue details... STATUS
          • LOG-881 - Getting issue details... STATUS
          • LOG-917 - Getting issue details... STATUS
          • LOG-931 - Getting issue details... STATUS
  • Technical Discussion
    • Consider demo schedules
      • J. Ram Balasubramanian will forecast demos as development progresses
        • Data Dictionary & Network Discovery-  Dec 20
          • Done
        • L2 Network data (Today!)
          • See slides
        •  Additional enhancement - March 21st
          • additional resources and rules
          • potentially other enhancements
    • Note we have discovered a number of discrepancies between the model definition in the wiki and the code. We are now raising bugs on specific issues found and will resolve as appropriate.
    • OOM submissions
      • Steps to ensure PODS are healthy
        • Before checkins should do a local Robot health check. If this is not clear, documentation needs to be updated.
          • action Yong
      • This was guidance from PTL and also good practice.
  • Making the PTL Happy
    • Casablanca
      • Release notes being prepared.
        • Still seems to be open.
      • Data router version was upped.  So, POMBA needed to update its version. This was integrated.
        • There was a bug and the A&AI team fixed it.  Integration team tested the fix, but perhaps did not test POMBA
          • J. Ram will quickly test.
          • Michael O. did test already that the POD comes up and passes health check.
    • Dublin
  • Demo
    • Slides
    • Dublin Test lab configuration
    • POMBA audit is trigger
      • Currently via service instance id, model id and model invariant id
        • This enables some good validation
      • This information can be hard to find in cases.  An audit trigger based on information a more typical user has should be considered
        • Both could be supported
        • Brian thinks he previously raised something on this. If not, Sharon will add something to the backlog to track.
          • LOG-983 - Getting issue details... STATUS
    • The demo data is roughly based on vfw, but modified to ensure we have violations to show
    • Integration team can create their own rules. The steps are defined
    • Openstack keystone needs to be version 3, or shortly no one will be able to use it
      • Network Discovery is using v3, so we are ok
    • Currently Openstack coordinates are part of the helm chart. There is a way the URL information can be discovered
      • Action Sharon to add something to the backlog for this
    • Openstack passwords are obfuscated.
    • Ideally, it would be good to network discover using meta-data
      • This information gets associated to the VM
      • Openstack does support filtering on field values. Depending on how the meta data is stored in openstack, this would be possible to implement.
        • Currently network discovery is triggered out resource type and id.
      • There is a heatstack to metdata association that is critical
      • More analysis of this is required.

1 Comment

  1. for next meeting -

    LOG-985 - Getting issue details... STATUS

    for

    TSC TSC 2019-02-21

    Discuss docker-manifest.csv and oom values.yaml sync procedures

    1) shared docker images - conflict/ambiguity - is a 1:m relationship not a 1:1

    example: onap/data-router,1.3.3

    https://git.onap.org/integration/tree/version-manifest/src/main/resources/docker-manifest.csv?h=casablanca#n39

    There may be a case like there was for the 3.0.0-ONAP tag where AAI and POMBA vary - AAI took 1.3.2, pomba stayed with 1.3.1 because of issues deploying 1.3.3

    The current manifest does not always account for 2 projects using different versions of common images

    Result:

    integration is running with 1.3.3 across both projects before both projects themselves have upgraded.

    If you apply the manifest - it will overwrite both of these versions - but we may want a variance.

    we get

    aai:
      image: onap/data-router:1.3.3
    pomba:
      image: onap/data-router:1.3.3

    we may want

    aai:
      image: onap/data-router:1.3.3
    pomba:
      image: onap/data-router:1.3.2


    2) docker version responsibility

    PTLs should be responsible for their docker image versions in OOM - however since the manifest drives the version truth some images are updated at the last minute during the manifest/oom sync - these should be better coordinated/tested with the team

    Yesterday there was a last minute change to sync POMBA with AAI because the manifest lists the common data-router version as 1.3.3. Regression testing may have been done for POMBA under 1.3.3 but the POMBA team was not aware of the new version - Ideally the project team themselves test new docker versions to be sure it works. Changing the image tag at the last minute before 3.0.1-ONAP is tagged is problematic - as I am kind of doing this blind without a fully vFW post audit (HC and CD deploy were ok) - this has happened twice so far.

    3.0.0 = 1.3.1 reverted from 1.3.2 auto-up-rev for LOG-932

    LOG-932 - pomba-data-router pod does not come up in Casablanca MR CLOSED

    https://git.onap.org/oom/tree/kubernetes/pomba/charts/pomba-data-router/values.yaml?h=3.0.0-ONAP#n30

    3.0.1 = 1.3.3

    dup

    INT-901 - Bring OOM image version in sync with docker-manifest.csv for Casablanca MRIN PROGRESS

    submitted 20190220:2000EST for CMR

    LOG-982 - Align POMBA data-router from 1.3.1 (pre 3.0.0) with 3.0.1 aai change under 1.3.3SUBMITTED

    https://git.onap.org/oom/tree/kubernetes/pomba/charts/pomba-data-router/values.yaml?h=casablanca#n30


    example

    I recommend we work out the details of MRs before we do the DMR.

    Fix #2

    Another option would be to duplicate/label common images so they can vary independently - but this would defeat the offline installer and the CIA initiative - but would follow what dmaap does for the DR