TSC 2018-12-13
- cl664y@att.com
- Kenny Paul
- Michael O'Brien
Duration 100 minutes
| Agenda Items | Presented by | Time | Notes/Links | JIRA Tasks |
|---|---|---|---|---|
| Incoming ONAP Events | 10 mins | Jan 8-11 - Dublin Release F2F Developer Design Forum (France): https://wiki.lfnetworking.org/pages/viewpage.action?pageId=8257579 Feel free to request your VISA: http://events.linuxfoundation.org/visa-request Submit your proposal: https://wiki.lfnetworking.org/display/LN/OPNFV-ONAP+January+2019+Session+Proposals Please register and submit any proposal before Dec 21st, 2018 Reminder - No TSC Call on December 27th, 2018 | ||
| Casablanca Maintenance Release | 5 mins | |||
| Any Infrastructure/Improvement Plan | Linux Foundation | 5 mins | Any LF showstopper #64966 (CLM Issues) | |
| Dublin Release | TSC | 30 mins | One of our 2019 Challenges: Continued demand for functional requirements and expanding ONAP scope versus Platform flexibility, stability and reducing technical debt | |
| Toolchain Matters |  | 15 mins | TSC-25 meet last week- we are at the step of getting the LF VM server pool up |
TSC-25
-
Getting issue details...
STATUS
|
| TSC Focus | Alex Vul | 15 mins | Modelling - Rules for the poll ? find email in https://lists.onap.org/g/onap-discuss/search?q=modelling+rules | https://lists.onap.org/g/onap-modelingsub/message/100 |
| PTL Update | Steven wright | 20 mins | VNF Certification | |
| TSC Activities and Deadlines | TSC Vice-Chair Election: Alla, Chaker and Lingli Voting ends 8AM Pacific, Wed. Dec. 19. | TSC-3 - Getting issue details... STATUS | ||
| Additional Housekeeping | Linux Foundation | Michael O'Brien - Q) confirm LF shutdown - Meeting TSC on the 20th - verified - (but no TSC meet on the 27th, no PTL meet on the 24th or 31st) - take advantage of a quiet week from the 21th on...) |
Zoom Chat Log
05:58:54 From Bin Yang (Wind River) : #info Bin Yang, Wind River
05:59:02 From Andreas Geissler (Deutsche Telekom) : #info Andreas Geissler, DT
05:59:05 From Viswa KSP : #info Viswa, Verizon
05:59:09 From Yan Chen : #info Yan Chen, China Telecom
05:59:12 From Morgan Richomme : #info Morgan Richomme (proxy Eric Debeau)
05:59:24 From Kenny Paul (LFN) : #info Murat Tupcu, Turk Telecom
06:00:51 From Jason Hunt : #info Jason Hunt, IBM
06:01:01 From Kenny Paul (LFN) : #Chaker Al-Hakim, Huawei
06:01:13 From Susana (VF) : #info Susana Sabater, Vodafone
06:01:16 From Catherine Lefevre : #info, Catherine Lefevre, AT&T
06:01:17 From Lingli-CMCC : #info Lingli, CMCC
06:01:29 From Stephen Terrill : #info Stephen Terrill, Ericsson
06:02:43 From Kenny Paul (LFN) to Stephen Terrill (Privately) : seen. thank you.
06:02:56 From Alexis de Talhouët : #info Alexis de Talhouët, Bell Canada
06:03:09 From Kenny Paul (LFN) to Alexis de Talhouët (Privately) : seen. thank you.
06:04:49 From Srinivasa Addepalli (Intel) : #info Srinivasa Addepalli, Intel
06:05:45 From Lingli-CMCC : Thank you for the kind consideration.
06:06:14 From Lingli-CMCC : How many parallel sessions there would be?
06:06:38 From Lingli-CMCC : will all the sessions provide remote
06:06:54 From Kenny Paul (LFN) to Srinivasa Addepalli (Intel) (Privately) : #topic Paris F2F
06:07:12 From Kenny Paul (LFN) : #topic Paris F2F
06:08:13 From Kenny Paul (LFN) : Please register https://events.linuxfoundation.org/events/onap-ddf-opnfv-plugfest/
06:08:27 From Lingli-CMCC : OK
06:08:42 From Kenny Paul (LFN) : Please submit session proposals https://wiki.lfnetworking.org/display/LN/OPNFV-ONAP+January+2019+Session+Proposals
06:09:35 From Kenny Paul (LFN) to Srinivasa Addepalli (Intel) (Privately) : seen. thank you/
06:10:00 From Kenny Paul (LFN) : #topic Casablanca Maint Release.
06:10:38 From Kenny Paul (LFN) : Gildas shared the slide deck
06:10:40 From Kenny Paul (LFN) : scope locked.
06:12:20 From Kenny Paul (LFN) : Remember to update the release notes.
06:15:08 From Kenny Paul (LFN) : #topic Infrastructure - #64966-Ongoing (CLM Issues)
06:15:47 From Kenny Paul (LFN) : https://lists.onap.org/g/onap-release/message/885
06:15:51 From Keong Lim k00759777 : are the jobs named as "master" actually running on "casablanca" branch? e.g. aai-aai-common-maven-clm-master
06:15:57 From Catherine Lefevre : reconnected
06:16:08 From Keong Lim k00759777 : https://jenkins.onap.org/view/CLM/job/aai-aai-common-maven-clm-master/configure
06:16:31 From Kenny Paul (LFN) : must add the string casablanca to run in casablanca
06:17:23 From NingSo : #info Ning So, Reliance Jio
06:18:45 From Kenny Paul (LFN) : #topic Dublin Release Challenges
06:19:10 From Sanchita Pathak : #info proxy Sanchita Pathak, TechMahindra
06:19:38 From Kenny Paul (LFN) to Sanchita Pathak (Privately) : seen. thank you
06:20:11 From Kenny Paul (LFN) : Discussion of technical debt versus new feature/functionality
06:20:25 From Keong Lim k00759777 : no screens shared?
06:20:46 From Kenny Paul (LFN) : nothing being shared right now
06:21:18 From Michael O'Brien : agree kubernetes based deployment and long-duration stability is a top priority
06:22:57 From Kenny Paul (LFN) : primary issue is that as a community we are resource constrained in terms of people to do the work.
06:24:40 From Lingli Deng : There has been a confustion between usecases and functional requirements.
06:24:59 From Alexander Vul : Lingli +1
06:25:24 From Lingli Deng : HPA, change managment, etc. those are functional requirements that could be part of multiple usecases.
06:25:51 From Steven Wright : E-E use cases should be written in terms of external operations onto the ONAP platform, not platfrom internal operations
06:25:56 From Kenny Paul (LFN) : suggestion that that work which impact multiple usecases be given priority
06:26:06 From Lingli Deng : While we are targeting at functional enhancements for platform, a running usecase is the chance to verify its fulfillment.
06:26:33 From Lingli Deng : And making sure that the new ones does not break existing ones.
06:26:56 From Lingli Deng : We need both.
06:27:33 From Steven Wright : Where the platform has multiple paths to achieve some external capability, and E-E use case above, then this is technical debt to be eliminated and we need to understand whether the internal options provide functional equivalence.
06:27:35 From Viswa KSP : While use cases are good to showcase values, use case when tend to specific, breaks the platform
06:27:41 From JessicaW : confirmed...aai-aai-common is running on casablanca. The project is using a stream variable to name the job but the branch variable in this case is setting up the actual revision to run in.
06:27:55 From Murat Turpcu ( Turk Telekom) : first we should show as a community what this platform can do.
06:28:15 From Lingli Deng : +1
06:28:29 From Viswa KSP : I want to believe ONAP can be used as a platform for any network service / use case, not for a specific use case….
06:28:43 From Lingli Deng : dll2014@139
06:28:58 From Lingli Deng : sorry, please ignore.
06:29:37 From Murat Turpcu ( Turk Telekom) : if we should also look for sp requests to add new funtional requirements to support their usecases
06:30:00 From Murat Turpcu ( Turk Telekom) : like 5g
06:30:08 From Lingli Deng : Agree.
06:30:17 From Viswa KSP : @Alex +1
06:30:27 From Ranny Haiby : Another aspect we can improve is project lifecycle. We don't seem to enforce the lifecycle as defined in section 3.3 of the technical community document: https://lf-onap.atlassian.net/wiki/display/DW/ONAP+Technical+Community+Document#ONAPTechnicalCommunityDocument-3.3ProjectLifecycle
06:30:46 From Ranny Haiby : Project seem to go directly to the "mature" state without proper review gates
06:31:11 From Ranny Haiby : This makes integration tests more and more complex with each release
06:31:32 From Stephen Terrill : Ranny, All projects are formally in "incuabation" state
06:31:47 From Ranny Haiby : My point exactly
06:31:51 From Jason Hunt : @Ranny - good point that we have not looked a project states since putting into incubation
06:31:52 From Gildas Lanilis : Yes, all proeject ar ein incubation.
06:31:54 From Ranny Haiby : They cannot all be in the same state
06:32:18 From Stephen Terrill : you have a good point. Rany, we should look at that during this time.
06:33:10 From Alexis de Talhouët : Yes, we don’t have a well define project lifecycle
06:33:18 From Jason Hunt : Saturday Jan 5th
06:33:23 From Alexis de Talhouët : or maybe it’s defined but not enforced
06:33:45 From Keong Lim k00759777 : if we want a comprehensive platform, it will need to test hundreds/thousands of combinations/permutations
06:33:46 From Jason Hunt : sorry
06:33:47 From Ranny Haiby : It is well defined in the community document: https://lf-onap.atlassian.net/wiki/display/DW/ONAP+Technical+Community+Document#ONAPTechnicalCommunityDocument-3.3ProjectLifecycle
06:33:52 From Kenny Paul (LFN) : the lifecycle is defined in Section 3.3 - it has never been exercised.
06:34:03 From Alexis de Talhouët : Yes, I corrected myself :)
06:34:09 From Alexis de Talhouët : Thanks for the pointed
06:34:58 From Srinivasa Addepalli (Intel) : We have duplication in some use cases. For example, we have vFW use case, vFWCL use case, vFWHPA use case. Best to have one use case here vFWCLHPA use case instead of three use cases.
06:34:58 From Kenny Paul (LFN) : well, not used beyond Proposal -> Incubation :-)
06:36:24 From Murat Turpcu ( Turk Telekom) : what frightening is every new usecase need new functional requirements.
06:36:47 From Keong Lim k00759777 : so rather than new use case, it will be reworking old use cases?
06:36:58 From Michael O'Brien : I Logging - will definitely help onap stability of the undercloud and deployment - with OOM - So I can consistently run/demo the vFW for example - which is causing me stress right now - I would like to get back to how it was in amsterdam for the UC - (mostly my lack of knowledge at this point)
06:37:03 From Murat Turpcu ( Turk Telekom) : we should focus on a platform that can support multiple usecases easly
06:37:33 From Michael O'Brien : My focus is the 3.0.0-ONAP tag right now - this week
06:37:34 From Gildas Lanilis : Not sure to understand how projects lifecycle is related to the scope we decide to put in. Agree though that Integration is the bottleneck, due mainly to the lack of rigorous early pair testing and continuous delivery.
06:38:36 From Michael O'Brien : The well architected framework at AWS is our playbook - yes
06:38:39 From Keong Lim k00759777 : but aws only developed after they did their shopping cart use cases...
06:39:06 From Michael O'Brien : https://aws.amazon.com/architecture/well-architected/
06:39:54 From Michael O'Brien : we would do well to review this - I am doing another pass https://d1.awsstatic.com/whitepapers/architecture/AWS_Well-Architected_Framework.pdf
06:41:05 From Murat Turpcu ( Turk Telekom) : we should focus on platform and generate a model to add new vnf x, that can mean concentrating on standards or a new idea from community
06:41:59 From Keong Lim k00759777 : "might" find them useful?
06:42:33 From Viswa KSP : Adding new use cases shouldn’t be bloating ONAP…rather extend ONAP…
06:43:36 From Michael O'Brien : Michael O'Brien (Amdocs/Logging) - can join the platform group
06:43:37 From Keong Lim k00759777 : building out platform without usecases == lots of unused platform functions
06:44:04 From Stephen Terrill : Keong is right as well, extremes in approaches is not correct
06:44:32 From Viswa KSP : unstable platform with N use case doesn’t do any good either
06:44:34 From Gildas Lanilis : We should use Usecase as a way to convey a story but ultimatly these Usecase should support platform improvement.
06:45:01 From Michael O'Brien : vFW is currently my sanity for platform - I can use any use case as long as I can get it working - I would like to use a real one like vCPE or 5G but it is a matter of being able to effectively demo - I am open
06:45:45 From Lingli Deng : We need to have all usecase owners to clarify what functional requirements are embedded for their D planning.
06:46:37 From Gildas Lanilis : +1 Lingli.
06:46:56 From Murat Turpcu ( Turk Telekom) : if we want to show what platform can do, maybe we should focus on ONAP success stories
06:47:07 From Lingli Deng : For each shared functional requirement, we need to have a consistent plan of supporting it.
06:47:19 From Lingli Deng : So usecases do not break one another.
06:50:14 From Arash Hekmat (Amdocs) : ONAP usability is also a big issue. The question is: could someone or some company, who is not involved in ONAP development, deploy run and use ONAP with minimal effort? The answer today is NO.
06:52:24 From Srinivasa Addepalli (Intel) : In my view, we also need to have more use cases that can be replicated by anybody. That is, it is best if all use cases proposed in ONAP should make scripts, VNF binaries available in ONAP demo repository for others to replicate.
06:52:40 From Kenny Paul (LFN) : Catherine notes her agreement w/ Lingli’s “not break” chat.
06:53:20 From Michael O'Brien : ONAP currently uses tier 1 of Amazon (EC2, EFS) - in the future it could use more managed native services like EKS all the way to Lambda but we are mostly cloud agnostic right now - I can work with anyone who is keen on AWShttps://wiki.onap.org/display/DW/Cloud+Native+Deployment
06:53:50 From Kenny Paul (LFN) : Alex suggests a modular, model driven approach.
06:53:51 From Keong Lim k00759777 : does model-driven approach stop teams from going their own way?
06:55:23 From Alexander Vul : @keong - look at AWS development model
06:55:26 From Kenny Paul (LFN) : oit of time - Still an open discussion - Not ready for new usecases but instead need to improve the platform.
06:55:51 From Alexander Vul : There is a common foundation with separate teams building LCM functionality around managed entity X
06:56:06 From Kenny Paul (LFN) : #topic toolchain
06:56:21 From Keong Lim k00759777 : AWS development model did not precede their shopping cart uses cases though
06:56:46 From Alexander Vul : You are right… there is still a set of common components
06:56:56 From Alexander Vul : that gets used in a cross cutting way...
06:57:23 From Kenny Paul (LFN) : Moving towards CICD
06:57:28 From Alexander Vul : For example -UX/CX (shopping carts), security, data management, etc...
06:58:16 From Alexander Vul : the model driven approach actually requires a model…
06:58:33 From Kenny Paul (LFN) : https://jira.onap.org/browse/TSC-25
06:59:02 From Kenny Paul (LFN) : Coding standard checks
07:01:19 From Kenny Paul (LFN) : https://jira.onap.org/browse/TSC-58
07:02:02 From Kenny Paul (LFN) : sandbox oat LF - most of the code is writen for CICD
07:02:42 From Kenny Paul (LFN) : Currently provisioning services.
07:03:54 From Kenny Paul (LFN) : #action Michael O’Brien provide demo (virtually) at Paris F2F - add session to the proposal list
07:05:26 From Kenny Paul (LFN) : #action to community- Catherine requests the community provide input to TSC-58 to add “wish-list” tools / infrastructure by Jan 5
07:07:08 From Keong Lim k00759777 : is it a "resource" or is it a "service" question
07:07:29 From Kenny Paul (LFN) : https://lists.onap.org/g/onap-modelingsub/message/100
07:10:45 From Andy Mayer (AT&T) : https://lf-onap.atlassian.net/wiki/display/DW/Vote+for+NS+domain+and+Internal+NS+Descriptor
07:11:13 From Stephen Terrill : from our charter
07:11:14 From Stephen Terrill : 4.4.2 Advisory role Subcommittees are advisory in nature, and not authoritative. They provide advice to projects and to the TSC. Subcommittees operate on a rough consensus basis. If the subcommittee is unable to reach consensus on what advice to offer, the subcommittee Chair shall raise the issue with the TSC, where a formal vote can be taken, or advise the project that the subcommittee cannot reach consensus.
07:13:14 From Keong Lim k00759777 : "There has been a long debate on whether NS belongs to service or resource"
07:13:51 From Michael O'Brien : BTW ) the Linux Foundation upgrade of Confluence to AWS and the version - was excellent - and faster than expected - thank you
07:14:14 From Andy Mayer (AT&T) : The new TSC has an action item on Subcommittee Membership Governance. See: https://lf-onap.atlassian.net/wiki/display/DW/TSC+2018-08-30?preview=%2F36962652%2F43386042%2FTSC-Agenda-2018-0830.pdf
07:14:48 From Kenny Paul (LFN) : Alex suggests one vote per company plus some level of domain expertise.
07:17:26 From Kenny Paul (LFN) : Issue: looking for the TSC to provide the definition of “Rough Consensus”
07:17:32 From Arash Hekmat (Amdocs) : 1 vote per company is the way to go in ONAP in all committees.
07:18:02 From margaret chiosi : denghui sent email challenging having this call when it was evening for china.. so that is why he isn't on
07:18:07 From Gildas Lanilis : Rough Consensus: https://en.wikipedia.org/wiki/Rough_consensus
07:19:04 From Catherine Lefevre : thanks Margaret
07:19:59 From Alexander Vul : @gildas that definition assumes equal levels of expertise
07:20:29 From Gildas Lanilis : @yes Alex. Expert opinion.
07:21:01 From Kenny Paul (LFN) : Regarding the Modeling debate- one more meeting and if no agreement- take decision to the TSC in January.
07:21:06 From Alexander Vul : @gildas, this is felt different, hence my e-mail to the TSC…
07:22:12 From Kenny Paul (LFN) : #action- TSC provide a definition of rough consensus for the subcommittees
07:22:41 From Kenny Paul (LFN) : #topic VNF Certification
07:24:17 From Michael O'Brien : btw I have been asked twice about VNF cerification recently by companies - so definitely requires review from myself
07:25:11 From Kenny Paul (LFN) : adding VNF certification expands the scope or the VNFRQTS project.
07:37:19 From Srinivasa Addepalli (Intel) : Would VNF/CNF certification include security checks (on packages used in CNF/VNF) too (if not now, in future)?
07:40:01 From Lingli : It should be included, not sure about the current status now.
07:40:05 From Stephen Terrill : Srini, how to build a VNF should be out of scope
07:40:27 From Lingli : But certification need to be veriable with running code, not only specification.
07:41:04 From Lingli : How to build a VNF is part of VNF guidelines not specified as mandatory requirements for now.
07:41:11 From Lingli : @Srini
07:41:37 From Michael O'Brien : yes, automated CI/CD for vnfreq as well - can assist - no manual testing/certification if possible - but a big ask in my opinion but doable
07:42:35 From Stephen Terrill : VNF reqs should focus on what is required for a VNF to connect to ONAP - that is what is important.
07:43:00 From Alexander Vul : Vnc requirements should focus on VNF onboarding
07:43:28 From Stephen Terrill : agree that is part of it Alex. I was loose in my wording.
07:43:29 From Alexander Vul : And a way to represent VNFs in a portable and interoperable way
07:43:51 From Alexander Vul : the internal representation of of VNFs is “domain specific”
07:44:04 From Alexander Vul : Happy Festivus!!!!
07:44:12 From Susana (VF) : Happy Holidays!
Zoom Attendance Log
TSC Members Attendance based on Zoom Chat Log: 94%
05:58:54 From Bin Yang (Wind River) : #info Bin Yang, Wind River
05:59:02 From Andreas Geissler (Deutsche Telekom) : #info Andreas Geissler, DT
05:59:05 From Viswa KSP : #info Viswa, Verizon
05:59:09 From Yan Chen : #info Yan Chen, China Telecom
05:59:12 From Morgan Richomme : #info Morgan Richomme (proxy Eric Debeau)
05:59:24 From Kenny Paul (LFN) : #info Murat Tupcu, Turk Telecom
06:00:51 From Jason Hunt : #info Jason Hunt, IBM
06:01:01 From Kenny Paul (LFN) : #Chaker Al-Hakim, Huawei
06:01:13 From Susana (VF) : #info Susana Sabater, Vodafone
06:01:16 From Catherine Lefevre : #info, Catherine Lefevre, AT&T
06:01:17 From Lingli-CMCC : #info Lingli, CMCC
06:01:29 From Stephen Terrill : #info Stephen Terrill, Ericsson
06:02:56 From Alexis de Talhouët : #info Alexis de Talhouët, Bell Canad
06:04:49 From Srinivasa Addepalli (Intel) : #info Srinivasa Addepalli, Intel
06:17:23 From NingSo : #info Ning So, Reliance Jio
06:19:10 From Sanchita Pathak : #info proxy Sanchita Pathak, TechMahindra
06:30:27 From Ranny Haiby (seen online)
TSC Decisions
Action Items
- Request to PTLs to review the e-mail sent by Jessica regarding CLM/Casablanca Maintenance Release - https://lists.onap.org/g/onap-release/message/885
- TSC to review project state (ONAP Technical Community Document#3.3ProjectLifecycle) and to finalize Dublin priorities
- Request to PTLs (including Integration Team) to submit their tool requests no later than Jan 5th, 2019 (TSC-58)
- Michael O’Brien to provide demo (virtually) at Paris F2F - add session to the proposal list (TSC-25)
- Modeling Chairs to provide an updated on January 3rd, 2019 to the TSC about their conclusions (NS domain / Internal NS Descriptor)
- TSC to provide guidelines about "Rough Consensus" and review Subcommittee Membership Governance (TSC 2018-08-30)