Agenda
- 8:00am Eastern
- Status and Stucks
- Technical Discussion
- Making the PTL Happy
- 8:30am Eastern
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:
- Stories to be formally verified before closure:
- - LOG-778Getting issue details... STATUS
- - LOG-763Getting issue details... STATUS
- - SDNC-475Getting issue details... STATUS : For network resource only and should be split into Network Discovery and ND context builder.
- - LOG-779Getting issue details... STATUS
- - LOG-404Getting 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:
- Bugs in progress:
- Bugs to be verified:
- Bugs closed off since last meeting:
- Dublin
- Technical Discussion
- Consider demo schedules
- J. Ram Balasubramanian will forecast demos as development progresses
Data Dictionary & Network Discovery- Dec 20Done
- L2 Network data (Today!)
- See slides
- Additional enhancement - March 21st
- additional resources and rules
- potentially other enhancements
- J. Ram Balasubramanian will forecast demos as development progresses
- 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
- Before checkins should do a local Robot health check. If this is not clear, documentation needs to be updated.
- This was guidance from PTL and also good practice.
- Steps to ensure PODS are healthy
- Consider demo schedules
- 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.
- There was a bug and the A&AI team fixed it. Integration team tested the fix, but perhaps did not test POMBA
- Release notes being prepared.
- Dublin
- Should look at milestones and ensure we are in good shape.
- Feature commitment Jan 17 → pushed one week. Jan 24th. (M1)
- Prudence is supporting Michael for this activity.
https://wiki.onap.org/display/DW/Logging+Dublin+M1+Release+Planning
- Functionality freeze Feb 21
- Any new APIs are supposed have draft definition, but this doesn't really apply to us
- Michael has filled in the templates for POMBA. Should be good to go.
- API freeze is March 14th (or has this slipped?)
- Feature commitment Jan 17 → pushed one week. Jan 24th. (M1)
- Should look at milestones and ensure we are in good shape.
- Casablanca
- 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
- Currently via service instance id, model id and model invariant id
- 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
- Validation Service
- Action Yong to improve page or create a new one with better steps.
- 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
- 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
Michael O'Brien
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