...

Duration 90 minutes - https://zoom.us/j/661303200

...

...

Zoom Chat Log 

Anchor
zoom zoom

05:54:29 From Kenny Paul (LFN) : #topic rollcall
05:56:22 From Milind Jalwadi : #info Milind Jalwadi, Tech Mahindra
05:59:12 From Yan Chen : #info
05:59:50 From Yan Chen : #info Yan Chen, China Telecom
06:00:28 From Chaker Al-Hakim : #info Chaker Al-Hakim
06:00:52 From Andreas Geissler (Deutsche Telekom) : #info Andreas Geissler (DT)
06:01:06 From Jason Hunt : #info Jason Hunt, IBm
06:01:09 From Murat Turpcu,Turk Telekom : #info, Murat Turpçu Turk Telekom
06:02:06 From hxmTnsq2Kkg1dDj8BdUr+/SOslr1iPH2xVX+afeM25I= : #info Morgan Richomme (Orange) - Proxy Eric Debeau
06:02:09 From ALLAGO : #info Alla Goldner, Amdocs
06:02:17 From Catherine Lefevre : #info Catherine Lefevre, AT&T
06:02:22 From Susana (VF) : #info Susana Sabater, Vodafone
06:02:42 From Srini Addepalli (Intel) : #info Srinivasa Addepalli, Intel
06:03:14 From Timo Perala (Nokia) : #info Timo Perala proxy Nokia
06:03:16 From Stephen Terrill : #info Stephen Terrill, Ericsson
06:03:27 From Alexis de Talhouët : #info Alexis de Talhouët, Bell Canada
06:04:48 From Kenny Paul (LFN) : #topic agenda
06:04:57 From Yan Chen to Kenny Paul (LFN)(Privately) : Thank you, Happy lunar new year. I have to mute myself as child is still awake
06:05:19 From Kenny Paul (LFN) : no votes today due to Chinese New Year
06:08:05 From Kenny Paul (LFN) : #topic IT ticket review
06:10:09 From Stephen Terrill : https://jira.onap.org/secure/RapidBoard.jspa?rapidView=103&view=detail&selectedIssue=SECCOM-101
06:15:58 From Michael O'Brien(Amdocs,LOG,OOM) : the board is locked for access
06:16:01 From Michael O'Brien(Amdocs,LOG,OOM) : https://jira.onap.org/secure/RapidBoard.jspa?rapidView=103&view=detail&selectedIssue=SECCOM-101
06:16:09 From Kenny Paul (LFN) : #topic security.
06:16:11 From Mandar Sawant (AT&T) : I am able to access the security vulnerabilities wiki space this morning. Thanks.
06:16:25 From Michael O'Brien(Amdocs,LOG,OOM) : 2 levels of security
06:16:25 From Michael O'Brien(Amdocs,LOG,OOM) : Error

The requested board cannot be viewed because it either does not exist or you do not have permission to view it.
06:18:05 From Stephen Terrill : Michael, if you go to: https://jira.onap.org/ can you select the SECCOM board?
06:18:47 From Stephen Terrill : maybe the link I sent was my view.
06:19:05 From Tony Hansen : all containers SHOULD run as non-root, unless there is a very very good reason that it needs root
06:19:07 From Michael O'Brien(Amdocs,LOG,OOM) : I have seen it presented once - as It looks familiar - about 2+ months ago - just didn't implement each section yet - my docker container only has a FROM and COPY line
06:19:11 From Michael O'Brien(Amdocs,LOG,OOM) : https://lf-onap.atlassian.net/wiki/display/DW/Best+Practices
06:19:26 From Pamela Dragosh : With 2 weeks left until M2, and this being a new requirement. Then this is added scope for the teams who are already busy implementing what they promised for M1.
06:20:05 From Michael O'Brien(Amdocs,LOG,OOM) : I don't have root outside the container - there is no config for root
06:21:01 From Michael O'Brien(Amdocs,LOG,OOM) : I run as ubuntu/non-root on my mac - on all kubernetes environments I run as non-root - I can run as root on ubuntu though
06:21:27 From Michael O'Brien(Amdocs,LOG,OOM) : These are best-practices - not checklist items - they are optional
06:22:04 From Srini Addepalli (Intel) : Running root in container is not a good practice : https://medium.com/@mccode/processes-in-containers-should-not-run-as-root-2feae3f0df3b
06:22:16 From Michael O'Brien(Amdocs,LOG,OOM) : I currently use the tomcat container and alpine - both
06:23:49 From Michael O'Brien(Amdocs,LOG,OOM) : docker gets the non-root user in its config during kubernetes install
06:23:49 From Michael O'Brien(Amdocs,LOG,OOM) : https://git.onap.org/logging-analytics/tree/deploy/rancher/oom_rancher_setup.sh#n90
06:23:57 From Michael O'Brien(Amdocs,LOG,OOM) : sudo usermod -aG docker $USERNAME
06:24:12 From Michael O'Brien(Amdocs,LOG,OOM) : where $USERNAME can be ubuntu
06:24:46 From Michael O'Brien(Amdocs,LOG,OOM) : https://lf-onap.atlassian.net/wiki/display/DW/OOM+NodePort+List
06:24:58 From Michael O'Brien(Amdocs,LOG,OOM) : external port list
06:26:44 From Dan Timoney : We really should not be changing the checklists after M1 … since by adding new criteria, we’re effectively changing scope
06:26:46 From Pamela Dragosh : All checklist changes should be discussed and voted upon well before the whole release starts. So the PTL’s can gauge how many resources are going to be needed to satisfy any new items.
06:28:18 From Catherine Lefevre : These checklists are not approved
06:28:32 From Michael O'Brien(Amdocs,LOG,OOM) : single SSL/HTTPS config point in common oom is a better idea + 1 Mike - option to enable for #PTL meet
06:28:38 From Catherine Lefevre : we are currently discussing their content
06:29:00 From Srini Addepalli (Intel) : +1 on Mike suggestion to have TLS from application containers optional.
06:29:09 From Catherine Lefevre : No commitment expected by the PTLs at this stage
06:29:17 From Catherine Lefevre : but we need to collect the information
06:29:54 From Srini Addepalli (Intel) : In Industry (Micro services), it is becomign best practice to decouple security from applications
06:31:47 From Srini Addepalli (Intel) : For example, Prometheus and few popular applications don't support TLS encryption at all and expect outside parties (such as ISTIO) to take care of that.
06:32:12 From Michael O'Brien(Amdocs,LOG,OOM) : +1 on Pamela - we should adopt a tick/tock cycle on checklists - discussions of El-Alto could be finalized at this point (tick) - and we implement Casablanca agreed lists now in dublin (tock)
06:34:21 From Mike Elliott : @Srini fully agree
06:35:48 From Mike Elliott : Is the plan to have all non-java micro services also integrate with AAF to meet the TLS requirement? Currently AAF integration was only available for java-based applications
06:36:42 From Kenny Paul (LFN) : proposed lchecklist https://lf-onap.atlassian.net/wiki/display/DW/Proposed+Updates+to+Release+Templates+%28Dublin%29+-+Security+Questions
06:39:13 From Pamela Dragosh : Gary - where is the docker base image defined? In a wiki? Or is it generated by integration and located in a repo?
06:41:01 From Michael O'Brien(Amdocs,LOG,OOM) : My 3 ELK stack containers (elasticsearch, kibana, logstash + filebeat - but not https) - are direct dockerhub images and are not using AAF yet
06:41:10 From Gary Wu : Currently there's no centrally defined "base image". Each project composes their own docker images.
06:41:38 From Keong Lim k00759777 : the problem is that the CIA team is doing both at the same time: arm64 build and new base images
06:42:06 From Brian Hedstrom : @Keong, what is the problem?
06:42:23 From Michael O'Brien(Amdocs,LOG,OOM) : unoptimized so far for LOG - as I am using JAX-RS 2.0 with Tomcat - not spring controllers with spring boot - but I can use either
06:42:23 From Michael O'Brien(Amdocs,LOG,OOM) : https://git.onap.org/logging-analytics/tree/reference/logging-docker-root/logging-docker-demo/DockerFile
06:43:02 From Keong Lim k00759777 : @brian, @catherine just said those 2 things should be separate?
06:43:25 From Michael O'Brien(Amdocs,LOG,OOM) : My tomcat image is 450g - unoptimized
06:43:26 From Brian Hedstrom : @Keong, I’m unclear what the problem is?
06:43:39 From Michael O'Brien(Amdocs,LOG,OOM) : and the backend for a dashboard is 570g
06:43:40 From Michael O'Brien(Amdocs,LOG,OOM) : oomk8s/kubernetes-viewport 0.0.1 39169a918573 14 hours ago 575 MB
06:44:04 From Michael O'Brien(Amdocs,LOG,OOM) : 0.5mb
06:44:12 From Catherine Lefevre : @Keong - ARM = Multi-support
06:44:36 From Catherine Lefevre : footprint optimization - should be handled by LF infra jenkins
06:44:43 From Catherine Lefevre : since it is a reqiirement
06:44:51 From Michael O'Brien(Amdocs,LOG,OOM) : 80G disk required on each VM in the cluster - just for docker images
06:45:02 From Catherine Lefevre : Footprint and multi-archi support - 2 separated reqs
06:45:22 From Michael O'Brien(Amdocs,LOG,OOM) : nexus3.onap.org:10001/onap/org.onap.dcaegen2.deployments.tca-cdap-container 1.1.0 837801571f4f 8 months ago 2.72 GB
06:45:33 From Catherine Lefevre : only footprint is part of the Dublin release scope
06:45:41 From Michael O'Brien(Amdocs,LOG,OOM) : nexus3.onap.org:10001/onap/ccsdk-odlsli-image 0.3.1 27afbf98c819 3 months ago 1.83 GB
06:45:44 From Catherine Lefevre : the multi-archi = experimental
06:45:54 From Brian Hedstrom : Footprint Optimization and Multi-Arch support are implemented together and are one and the same under CIA
06:46:38 From Keong Lim k00759777 : @brian @catherine hence my confusion at your statements
06:46:39 From Brian Hedstrom : However, Multi-Arch support integration testing requires the parallel pipeline
06:46:42 From Jim Baker (LFN) : CIA ENABLES multi-arch - the testing and support by all the projects is the POC component
06:49:42 From Keong Lim k00759777 : @srini does that mean adding more build jobs for different base images?
06:51:03 From Catherine Lefevre : well
06:51:26 From Catherine Lefevre : well it depends on you integrate Alpine
06:51:39 From Michael O'Brien(Amdocs,LOG,OOM) : I understand that the CIA docker retrofit is a phased migration - some core projects are in the POC - the rest are optional - from the last special meeting we had 2 weeks ago
06:51:45 From Catherine Lefevre : Multi-Archi is experimental
06:51:58 From Catherine Lefevre : see https://lf-onap.atlassian.net/wiki/display/DW/Dublin+Release+Requirements
06:52:09 From Catherine Lefevre : footprint = dublin requirements
06:52:12 From Catherine Lefevre : must have
06:53:33 From Brian Hedstrom : https://lf-onap.atlassian.net/wiki/pages/viewpage.action?pageId=16293201
06:54:24 From Michael O'Brien(Amdocs,LOG,OOM) : bottom line is we want smaller images <!00m and arm/i64 compatible - but as long as our current code (jax-rs still works to start)
06:54:48 From Michael O'Brien(Amdocs,LOG,OOM) : Target all Tomcat docker images and involve the projects
06:55:18 From Catherine Lefevre : (Footprint Optimization Task Force): Define clear strategy - can Alpine be optional? The current strategy is that the Integration Team will use the Alpine for the Dublin Certification - how shall we move forward based on today's feedback?
06:57:01 From Morgan Richomme (Orange) : +1 with Michael, PoC with SDNC currently in progress, next tries: portal and dmaap and maybe robot for Dublin. Not possible to have a full swap, components shall keep on working...
06:57:21 From Brian Hedstrom : https://lf-onap.atlassian.net/wiki/display/DW/Best+Practices
06:58:19 From Brian Hedstrom : https://lf-onap.atlassian.net/wiki/display/DW/Container+Image+Minimization+Guidelines
07:01:40 From Yang Xu : My original question was about SECCOM endorsement on base image, I think that still needs answer from SECCOM
07:01:46 From Srini Addepalli (Intel) : I feel it is okay, if ONAP is delivered on both Ubuntu and Alpine. BTW, that was my understanding that all ONAP containers would be delivered as Ubuntu and Alpine docker images. But, in today meeting, I get an impression that in long run, only Alpine based docker images are supported. And hence the raised my concern.
07:01:47 From Kenny Paul (LFN) : #topic POC definition
07:03:00 From Yang Xu : Integration team can only test/certify one set of images
07:04:00 From STEVEN Wright : should PoC code be kept in separate branch to avoid impact on main dev activities?
07:04:23 From Srini Addepalli (Intel) : @Yang Xu, I agree with you completely. My opinion is to do full test on Ubuntu based docker images and do some regression (automated tests) on Alpine images.
07:05:22 From Keong Lim k00759777 : is the multi-arch experiment also a POC in this scheme?
07:05:43 From Brian Hedstrom : @keong, No
07:06:12 From Alex’s iPhone 6 : we
07:06:49 From Keong Lim k00759777 : if it's code, it could be a branch rather than a repo
07:06:51 From Alex’s iPhone 6 : +1 srini
07:07:59 From Srini Addepalli (Intel) : Need to drop. Thanks
07:10:31 From Michael O'Brien(Amdocs,LOG,OOM) : in reality a lot of poc code is on github - so we are only talking about part of the pocs here
07:11:21 From Keong Lim k00759777 : it could just be level 0 of s3p?
07:13:52 From Michael O'Brien(Amdocs,LOG,OOM) : Team, proposing that the CD POC be moved to every 2 weeks as Orange/LF work is going well outside of the meet - for our meeting at 1430 EST GMT-5
07:13:53 From Michael O'Brien(Amdocs,LOG,OOM) : https://jira.onap.org/browse/TSC-25
07:14:47 From Pamela Dragosh : Could we just have a “catch up” release? Where we get all these “must have” mandatory requirements that come in from the TSC, S3P, Security, CIA, Integration projects??
07:16:37 From Shankar Narayanan : it would also be good to have a formal phasing-in process for new functional features.
07:17:49 From Keong Lim k00759777 : "secondary" in the sense that it would be first to be cut if need be
07:19:11 From Arash Hekmat (Amdocs) : If everything is a PoC then what is a Committed Feature in a release?
07:21:53 From Pamela Dragosh : There is no such thing is have a PTL approve something. They are doing reviews, filling out checklists, supporting integration, its a lot of work.
07:22:07 From Keong Lim k00759777 : then a poc cannot be a contribution, it should be a private extension?
07:26:10 From Jonathan Gathman : The answer is Gang of 4 Patterns. The answer is… Interface. Interface of Transaction, or Interface of Code Component. If you don’t have an interface to it right now, convert it to one, make the current Implementation AN implementation, and move forward.
07:26:41 From Morgan Richomme (Orange) : a PoC shall use a stable version of ONAP. If it is not possible, and requires dev on the components, then it is feature development of the component(s), including an E2E use case to illustrate the new feature. But twisting a solution for a PoC is very confusing and misleading...you do not know at the end what is part of ONAP what is not.
07:26:49 From Michael O'Brien(Amdocs,LOG,OOM) : Curiously, When I develop in/around pocs - especially hands on code - certain types of "endorphins" flow over my brain - the work POC gives me a very good feeling.
07:29:02 From Jonathan Gathman : (Michael) agree. :)
07:29:53 From Michael O'Brien(Amdocs,LOG,OOM) : +1 on Jim - provoking good discussion
07:29:55 From Pamela Dragosh : +1 Alex - these 6 month cycles are very difficult to manage.
07:32:15 From Pamela Dragosh : tick tock release. One release on Model. Next supports Model. One release on Service design/instantiation, next release on Control Loop for that Service.
07:32:35 From Michael O'Brien(Amdocs,LOG,OOM) : +1 CMR work overlap with Dublin to M2
07:34:30 From Michael O'Brien(Amdocs,LOG,OOM) : +1 tick/tock like intel
07:35:19 From Yang Xu : We should have half day lockdown to get conclusion of this directional discussion

...

Action Items:

•  (TSC) Finalize discussions about the Infrastructure Role
•  (Owners/PTLs) Close the actions captured on the Dublin Requirements wiki
•  (Jim): Provide Finalize POC Definition to be reviewed approved by TSC
•  (Amy Zwarico): Security by design - work with the PTLs on missing JIRA vulnerability issues
•  (TSC): Create a Task force to work on the ONAP component dependency
•  (TSC): To review project maturity (incubation, etc.)
•  (TSC ): To send Integration/Pair-wise testing proposal again
•  (TSC & Modeling Chairs): Finalize Dublin M2-M4 Modeling Checklist Review
  
•  (TSC & Security Subcommittee): Finalize Dublin M2-M4 Security Checklist Review
  
•  (SECCOM): Collect feedback from PTLS concernig running dockers as non-root prior the next PTL Call (2/11)
  
•  (Michael O'Brien): Remind PTLs about the wiki page where we are consolidating the external port list - OOM NodePort List
•  (Jason): Upgrade path not committed; work with PTLs to define the strict minimum?
•  (SECCOM): Footprint Optimization - is there any recommendation/concern from SECCOM?
•  (Footprint Optimization Task Force): Define clear strategy - can Alpine be optional? The current strategy is that the Integration Team will use the Alpine for the Dublin Certification - how shall we move forward based on today's feedback? 
  https://lists.onap.org/g/onap-tsc/message/4605
  
•  (TSC): Kick-off discussions to change the ONAP SW Delivery Model for the next releases i.e. El-Alto