21 Jan 2019	PTL Recordings	Zoom Chat Log

Duration 60 minutes

Zoom Bridge https://zoom.us/j/283628617

Duration	Agenda Item	Requested by	Notes / Links
START RECORDING
	Info.yaml	Linux Foundation	Transfer of "info.yaml" file management at project level, ensuring immediate alignment with the project team composition and Open Source Best practices <1/21/2019>: PTL agree to take over the ownership of the info.yaml file
	Casablanca Maintenance Release Timeline Remaining Open Issues Integration Status Release Note	cl664y@att.com Yang Xu Sofia Wallin	Remaining Open Issues: https://lists.onap.org/g/onap-release/message/992 Integration Status: Casablanca Maintenance Release Integration Testing Status 6 Use cases not yet confirmed by the Use Case Owners that they will perform the regression tests - to be followed-up Stability issue on WindRiver (SB00) -Stephen Gooch has been triggered. Update: Stephen confirmed compute node 11 reboots itself every other day and caused the issue, and he takes it out today 01/21/19. Integration Blockers: Casablanca Maintenance Release Integration Test Blocking Issues Inter-dependency of some components i.e. DMaaP, CCSDK, etc. can generate some problems. PTLs should send a note if they are updating their version in the Manifest. The Manifest is the true source. Release Note - Target: January 24th, 2019: Please update the Security Vulnerability wiki page if you have updated anything: /wiki/spaces/SV/pages/16090044 Request to update the latest Readthedoc and then to cherry pick to Casablanca branch Do an "Append" so the previous Casablanca content is included but add the Casablanca Maintenance Release tag - 3.0.1 and the date: January 31st, 2019
	Dublin Release - M1 Preparation Documentation	cl664y@att.com Sofia Wallin	Additional M1 Security Checklist Items approved by TSC on 1/17 Deliverables for Planning Milestone Checklist Template M1 Milestone Review with TSC: January 24th except Integration, January 31st, 2019 Please complete your M1 Release Plan/Checklist/etc no later than January 23rd, End of your Day As part of your M1 activities, Please review your M1 S3P Actual and provide your S3P M1 target: https://lf-onap.atlassian.net/wiki/display/DW/Dublin+Release+Platform+Maturity Please update any risk/issue (if any): https://lf-onap.atlassian.net/wiki/display/DW/Dublin+Risks Please provide your commitments on the centralized wiki: https://lf-onap.atlassian.net/wiki/display/DW/Dublin+Release+Requirements Any concern/question for your M1? Documentation Plan Proposal - please send feedback to Sofia prior the next TSC call (1/31) Potential Dublin branch target date: RC1? To be reviewed at that time.
minor	DEV reduced deployment footprint through ReplicaSet: 1	Michael O'Brien	Continue dev.yaml adjustment for ReplicSet: 1 This reduction of 20+ containers is easier - just need a signoff on several PTLs that the remaining clusters actually run with 1 instance enough for dev. DEV environment deployment footprint reduction by reducing remaining ReplicaSet clusters to 1 from 2/3/5/7 - only in dev.yaml override OOM-1578 - DEV mode dev.yaml override for all remaining ReplicaSet counts still above 1 In Progress https://lists.onap.org/g/onap-discuss/topic/running_onap_in_dev_with_all/29018548?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,29018548
medium	K8S Deployment Dependencies - enforcement through conditional (see AAI) To help deployment	Michael O'Brien	2 S3P points - conditional dependencies and one found by James MacNider when testing appc healthcheck - explicit init container dependencies required by non-atomic healthchecks (1) Discussion on state of enforced dependencies - SDNC and AAI are good examples - for SDNC it will not deploy unless dmaap, consul and sdc are pre-deployed, however other projects that have compile-time/injection-time pom.xml dependencies are not reflected. Some projects have explicit deployments set in their init containers - others do not yet. Issues: Enforced dependencies block a module for dev testing unless dependencies are up For example - everyone needs AAI up - but there are no init containers referencing AAI so any module can deploy without AAI - but functionality will be limited. Proposal: Follow - as usual - AAI example - where they put in a conditional on the --set enabled flag - and don't enforce the dependency - not blocking bringing up just a single module. However if the dependency is enabled in dev/values.yaml then the dependency is checked. https://git.onap.org/oom/tree/kubernetes/aai/charts/aai-traversal/templates/job.yaml#n42 spec: initContainers: {{ if eq .Values.global.aafEnabled true }} - --container-name - aaf-locate {{ end }} The deployment profile is useful for module-level deployments, consistent sequential deployments, CD and dev environments current state https://lists.onap.org/g/onap-discuss/topic/oom_sdnc_just_deploy_sdnc/28989874?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,28989874 or higher level LOG-924 - Kubernetes chart dependencies - make all 105 in 87 files conditional - post yaml for cd In Progress
with above	S3P dependencies and non-atomic health check	Michael O'Brien James MacNider	non-atomic healthcheck requires init container dependencies 3 flavors (defined, missing, non-hc inherent) for example SDC will not pass HC unless DMaaP is deployed - this is defined in it's dependency set above But APPC also needs AAF - this is not defined - a conditional init would not help here - as aaf "must" be up for the 3rd - most pods need AAI - they do not check that it is up in their HC - and they don't define it in the init container - all fine - but a conditional init would help.
	Review of previous action items	cl664y@att.com	Helm Chart Transfer: 4 projects have been identified for trial: Log, Policy, APPC and Clamp. Mike Elliott will work with PTL to gather/transfer knowledge and create training materials. Training to be done the week of Jan 14 and PTL to provide their commitment or not by M1 on Jan 24. <1-7/2019>: Work in progress. Schedule might shift to another week. Michael will follow-up with Mike. Training will be open to everybody. The objective is that each team will take over the management of their Helm Charts. K8S: Ensure labs are updated to relevant K8S version <1-7/2019>: Ongoing. K8s 1.11.5; Rancher 2.0 - parameters set in the Heat template to bring the VMs related to K8S. <01/13/2019> From Integration, here are the related versions: docker_version: type: string default: "17.03.2" rancher_version: type: string default: "1.6.25" rancher_agent_version: type: string default: "1.2.11" kubectl_version: type: string default: "1.11.5" helm_version: type: string default: "2.9.1" k8s scripts here https://git.onap.org/integration/tree/deployment/heat/onap-oom and secondary here https://git.onap.org/logging-analytics/tree/deploy - under https://jira.onap.org/browse/OOM-1496 https://lf-onap.atlassian.net/wiki/display/DW/Security+Space+Wiki+Access+List Oom values.yaml or integration repo manifest ( TSC-86 - Lock down docker image tag name source of truth - oom values.yaml or integration repo manifest - A: both but manifest is the source Submitted ) if not covered - see TSC 2019-01-10 Quick discussion on nailing down whether we need a yaml override of the deployable docker image tags in the oom repo (understanding is no) - with the integration docker manifest (manifest is currently a copy of the oom values.yaml tags - not the reverse) If not - then we need a documented procedure wiki/RTD on running a derived values.yaml override for the entire system before deployment AAF is only an example here https://git.onap.org/oom/tree/kubernetes/aaf/charts/aaf-service/values.yaml?h=casablanca#n28 image: onap/aaf/aaf_service:2.1.8 drives https://git.onap.org/integration/tree/version-manifest/src/main/resources/docker-manifest.csv?h=casablanca#n11 onap/aaf/aaf_service,2.1.8 <1-7/2019> Integration team to document the procedure. <01/13/2019> Answer from Integration team: docker manifest under integration repo is the source of truth, and is used by Integration team to override OOM values.yaml when deploying ONAP in Openlab. See the instructions at the bottom of page https://onap.readthedocs.io/en/casablanca/submodules/integration.git/docs/onap-oom-heat.html#onap-oom-heat-template <1-21/2019> Procedure should include Timers, dependencies, etc. just need to define all the --set and -f overrides like the following sudo helm deploy onap local/onap --namespace $ENVIRON -f $DISABLE_CHARTS_YAML -f $DEV0_YAML $APPENDABLE_ENABLED_FLAGS --verbose  WindRiver Lab Management - Please provide feedback to Stephen Gooch no later than January 31st, 2019 if you need to keep your tenant space, VMs: user-usage.txt
	Any Help-desk ticket in the queue?		Unreleased images will only be kept in Nexus3 for 25 days.
	Recommendation/Requirement of the RESTful implementation - does ONAP require Spring Framework? Or does it just recommend Spring Framework version via oparent?	Pamela Dragosh	I would like PTL input here because if using SpringFramework is required, then let's have PTL's vote on this as they are the ones implementing it. Also, as with oparent, the requirement to upgrade/change to SpringFramework in some current projects may have development costs. Do we grandfather those in? <1/21/2019>: Need to follow-up with LF if any preference (licensing) Springboot preferred by PTLs? AAI, LOG, CCSDK, SO, Policy, etc. – need to align the version via oparent 1.5 will not be supported after August, so the target for us is 2.x in Dublin Spring Boot supports an embedded launch script that can be used to easily run the application as a systemd or init.d linux service. The script included with Spring Boot 1.5.9 and earlier and 2.0.0.M1 through 2.0.0.M7 is susceptible to a symlink attack which allows the "run_user" to overwrite and take ownership of any file on the same system. In order to instigate the attack, the application must be installed as a service and the "run_user" requires shell access to the server. Spring Boot application that are not installed as a service, or are not using the embedded launch script are not susceptible.

Action Items:

PTLs will take over the ownership of the info.yaml file
Casablanca Maintenance Release

(Catherine - ongoing): Follow-up with the Use cases Owners concerning their regression test plan: https://lf-onap.atlassian.net/wiki/display/DW/Casablanca+Maintenance+Release+Integration+Testing+Status.
(PTLs by 1/24): Please update the Security Vulnerability wiki page if you have updated anything: /wiki/spaces/SV/pages/16090044
(PTLs by 1/24): Please update the latest Readthedoc and then to cherry pick to Casablanca branch. Do an "Append" so the previous Casablanca content is included but add the Casablanca Maintenance Release tag - 3.0.1 and the date: January 31st, 2019

Dublin Release
- 1/24: M1 review for all the projects except Integration. Final checklist submitted no later than Wednesday Jan. 23^rd End of your day
- 1/31: M1 review for Integration.Final checklist submitted no later than Wednesday Jan. 23^rd End of your day
  As part of your M1 activities,
- Review your M1 S3P Actual and provide your S3P M1 target: https://lf-onap.atlassian.net/wiki/display/DW/Dublin+Release+Platform+Maturity
- Update any risk/issue (if any): https://lf-onap.atlassian.net/wiki/display/DW/Dublin+Risks
- Provide your commitments on the centralized wiki: https://lf-onap.atlassian.net/wiki/display/DW/Dublin+Release+Requirements
- Add M1 Security Checklist Items to your M1 Deliverables for Planning Milestone Checklist Deliverables for Planning Milestone Checklist Template
Send feedback to Sofia about Documentation Plan Proposal prior the TSC call (1/31)
(Catherine by 1/28): Need to follow-up with LF Legal concerning Spring Framework - any licensing preference?
(PTLs): Review ONAP codebase license scan, Jan. 2019 sent by Steve Winslow on 1/18
See also previous action items

Zoom Chat Log

09:01:31 From Michael O'Brien(LOG,Amdocs) : change your repo hame in https://git.onap.org/logging-analytics/tree/INFO.yaml
09:02:52 From Michael O'Brien(LOG,Amdocs) : add using a template from above https://git.onap.org/integration/tree/INFO.yaml
09:09:40 From Michael O'Brien(LOG,Amdocs) : part of https://jira.onap.org/browse/OOM-1053
09:09:46 From Michael O'Brien(LOG,Amdocs) : for AAI-2090
09:10:15 From Michael O'Brien(LOG,Amdocs) : same as issue in POMBA
09:11:19 From Keong Lim k00759777 : does OOM-1053 also include AAI-2091?
09:12:06 From Michael O'Brien(LOG,Amdocs) : https://gerrit.onap.org/r/#/c/75910/1
09:12:50 From Michael O'Brien(LOG,Amdocs) : data-router went in on 18th jan
09:14:59 From Yang Xu : https://lf-onap.atlassian.net/wiki/display/DW/Casablanca+Maintenance+Release+Integration+Testing+Status
09:19:52 From Michael O'Brien(LOG,Amdocs) : like this line
09:19:53 From Michael O'Brien(LOG,Amdocs) : sudo helm deploy onap local/onap --namespace $ENVIRON -f $DISABLE_CHARTS_YAML -f $DEV0_YAML $APPENDABLE_ENABLED_FLAGS --verbose
09:29:49 From ALLAGO : Hi Yang,
09:29:59 From ALLAGO : I tied to approach you several times by emails
09:30:02 From ALLAGO : 3 times I think
09:30:12 From ALLAGO : You didn't provide any response during the whole last week
09:30:25 From ALLAGO : It is CRITICAL FOR USECASE SUBCOMMITEE WORK
09:30:40 From ALLAGO : WE NEEDED TO KNOW WHETHER YOU AND YOUR TEAM WILL BE ABLE TO ATTEND THIS AND NEXT WEEK MEETYINGS
09:30:59 From ALLAGO : Yang, please respond
09:32:11 From Yang Xu : Previously use case subcommittee meeting was on Monday, and I had conflict
09:32:19 From Yang Xu : now is it moved to Friday?
09:32:19 From ALLAGO : it is on MOndays
09:32:24 From ALLAGO : you could at least reply
09:32:35 From ALLAGO : I sent emasil 3 times begging for your reply
09:32:42 From ALLAGO : it is still on Mondays
09:32:53 From Yang Xu : sorry, it may be filtered to different folder I didn’t see
09:33:01 From ALLAGO : OK
09:33:14 From ALLAGO : so, is it possible for you and your team to attend
09:33:17 From ALLAGO : next hour meeting
09:33:30 From Michael O'Brien(LOG,Amdocs) : https://lf-onap.atlassian.net/wiki/display/SV/Casablanca+Maintenance+Release
09:33:31 From Michael O'Brien(LOG,Amdocs) : will do
09:33:37 From ALLAGO : we needed to understand integration team resources/work plan for each requirement/use case
09:34:14 From ALLAGO : please reply, I REALLY need to know
09:35:40 From ALLAGO : Yang, please reply
09:35:42 From Yang Xu : Allago, I think new use case usually need to find its test resource for their use cases, and report to integration team. I will join today
09:35:54 From ALLAGO : OK, thank you!
09:36:01 From ALLAGO : let's discuss it during the call today
09:36:14 From ALLAGO : what exactly needed and what is status per each requirement/use case
09:36:18 From ALLAGO : Thanks!!!
09:39:37 From Yang Xu : Allago, did you send to yang.xu3@huawei.com? I search my email and don’t see any email from you
09:44:34 From Michael O'Brien(LOG,Amdocs) : logging/pomba project - I will definitely be there for the fully day (barring any critical meeting overlap) - In the capacity of validating/running anything we write up on running systems
09:49:44 From Brian : is someone from SDC on ?
09:50:15 From Brian : how do we restart SDC-BE to have it recheck its DMaaP interface ?
09:50:26 From Brian : DMaaP: None on HC but DMaaP is up for write/read
09:55:35 From Brian : https://onap.readthedocs.io/en/casablanca/submodules/integration.git/docs/index.html?highlight=docker%20manifest%20csv
09:56:59 From Michael O'Brien(LOG,Amdocs) : log has been using JAX-RS via jersey but a more streamlined spring-boot would be the way to go - my opinion
09:57:56 From Brian : SO uses springboot as well
09:58:06 From Michael O'Brien(LOG,Amdocs) : logging=jax-rs-2.0, pomba using spring-boot
09:59:21 From Michael O'Brien(LOG,Amdocs) : +1 Pamela's spring-boot (log was looking at 2.0 like Jimmy states
09:59:54 From Brian : so-container/pom.xml: <springboot.version>1.5.13.RELEASE</springboot.version>
10:00:40 From Amy Zwarico : Spring Boot supports an embedded launch script that can be used to easily run the application as a systemd or init.d linux service. The script included with Spring Boot 1.5.9 and earlier and 2.0.0.M1 through 2.0.0.M7 is susceptible to a symlink attack which allows the "run_user" to overwrite and take ownership of any file on the same system. In order to instigate the attack, the application must be installed as a service and the "run_user" requires shell access to the server. Spring Boot application that are not installed as a service, or are not using the embedded launch script are not susceptible.
10:00:56 From Jimmy Forsyth (AT&T) : We are using 1.5.18 in Casablanca Maintenance Release
10:01:10 From Jimmy Forsyth (AT&T) : Anything older than that has a lot of nexusiq vulnerabilities
10:01:23 From Michael O'Brien(LOG,Amdocs) : pomba using spring-boot 1.5.17
10:01:42 From Dan Timoney : I think spring boot 1.5 is based on spring 4, and spring boot version 2.x is based on spring 5
10:01:54 From Matthieu Geerebaert - EXTAPI - Orange : On EXTAPI we planned to try to upgrade to spring boot 2.x
10:02:04 From Jimmy Forsyth (AT&T) : 1.5 will not be supported after August, so the target for us is 2.x
10:02:14 From Jimmy Forsyth (AT&T) : In Dublin
10:02:51 From Matthieu Geerebaert - EXTAPI - Orange : ( and using spring mvc with jackson on APIs )
10:02:59 From Jimmy Forsyth (AT&T) : the audio is dropping out on the bridge