14:04:36 <bh526r> #startmeeting Weekly Technical Discussion
14:04:36 <collabot> Meeting started Thu Nov 16 14:04:36 2017 UTC.  The chair is bh526r. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:36 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:04:36 <collabot> The meeting name has been set to 'weekly_technical_discussion'
14:06:54 <bh526r> #topic Roll Call
14:06:59 <bh526r> #info Bin Hu
14:07:09 <timirnich> #info Tim Irnich
14:07:28 <bh526r> #info Bryan Sullivan
14:07:36 <bh526r> #info Claudio Serra
14:07:44 <bh526r> #info Dave Neary
14:07:51 <bh526r> #info Pierre Lynch
14:08:41 <bh526r> #info Tapio Tallgren
14:08:57 <bh526r> #info Dan Radez
14:09:31 <bh526r> #topic Deep Dive of Release Goals of Model and VES Projects in Fraser Release
14:09:42 <bh526r> #info Background:
14:09:57 <bh526r> #link https://lists.opnfv.org/pipermail/opnfv-tech-discuss/2017-November/019254.html
14:10:51 <bh526r> #info Bryan reviewed briefly the background and evolving of OPNFV with the new era of ONAP emerging on market
14:13:36 <bh526r> #info Tim asked if we do integration and testing in OPNFV, will we end up with still developing some components that are not in ONAP? Is it still the same situation as of today?
14:14:42 <bh526r> #info Bryan mentioned that we may not use installer-based approach, but more focus on container, k8s, etc.
14:15:06 <bh526r> #info So it is more like VIM-agnostic approach
14:15:22 <bh526r> #info e.g. Model experiment now is not dependent on OpenStack
14:15:41 <bh526r> #info Narinder Gupta
14:17:37 <bh526r> #info In a word, stop relying on installers
14:18:16 <bh526r> #info Then what should OPNFV do for ONAP? For example, testing, certification, more complex use case such as hybrid cloud
14:22:12 <bh526r> #info Tim understands the frustration in the past, e.g. pain of installers. OPNFV is not expected to be production-ready.
14:22:39 <bh526r> #info Happy to see the path of evolution, e.g. evolution to more VIMs such as k8s
14:25:22 <bh526r> #info Dave Neary indicates that we still need something to manage k8s instead, so not sure if simplification can be achieved even if we evolve to k8s. Installer just provides a way to install and deploy.
14:27:20 <bh526r> #info Tim understands the complexity is not expected, and wants some level of simplification.
14:28:34 <bh526r> #info The question is whether to focus on simplification, or to focus on support of more VIMs
14:29:23 <bh526r> #info Bryan indicated less dependencies, and some more internal collaboration
14:30:37 <bh526r> #info Tim thinks it is very important topic, and if VES/Models finds a way to simplify the experience, we OPNFV needs to look into it
14:32:16 <bh526r> #info Dan mentions that maybe we need to see if this issue is shared by broader community, or is specific to the practice that one specific project needs. Then we can address it at broader community level or support specific project(s)
14:33:49 <bh526r> #info Tapio understands because Nokia experienced the same when using different installers. For example, if anything goes wrong, we need to go back to the beginning of re-install which takes another 2 hours
14:34:15 <bh526r> #info So it would be good to separate into different layers/modules
14:39:33 <bh526r> #info Tim thinks it is ideal to put it on the agenda of PlugFest because of the complexity of this topic, i.e. (1) supporting multiple VIMs/Clouds in integration instead of OpenStack-centric (2) Improve user experience.
14:41:20 <bh526r> #info Bryan mentions that it is really not to give actions to installers, but to reduce the dependency of feature projects on installers
14:42:40 <bh526r> #action Tim will arrange a session in PlugFest for this topic. Bryan will help scope this right, and give the right objective
14:44:32 <bh526r> #topic Discuss Collected Feedback on Hardware Requirements and Improvements on Pharos Specification
14:44:39 <bh526r> #info Background:
14:44:59 <bh526r> #link https://wiki.opnfv.org/display/pharos/Pharos+Specification
14:45:24 <bh526r> #link https://etherpad.opnfv.org/p/Pharos_Specification2.0
14:46:27 <bh526r> #info Tim mentions that there has been discussions of integration of L2 gateway of OpenStack, and more testings in HA projects.
14:47:21 <bh526r> #info SmartNIC is another example
14:48:01 <bh526r> #info We try to figure out a way of how to deal with it, and avoid situation that certain thing only works in certain lab
14:48:14 <bh526r> #info One element of this is Pharos spec
14:49:41 <bh526r> #info Others include CI engine (intelligent to differentiate labs), test framework (intelligent to activate or deactivate test cases automatically)
14:54:36 <bh526r> #info Bryan mentions "programmable lab", i.e. users can use interface for lab to present some production features
14:56:42 <bh526r> #info Tim indicates that today's Pharos Spec describes server features
14:58:00 <bh526r> #info Tim will advocates it in several places such as infra, testing, etc.
14:58:21 <bh526r> #info Bin will follow up with Jack Morgan regarding Phraos Spec 2.0
14:59:44 <bh526r> #topic AOB
14:59:53 <bh526r> #info Nothing else, meeting adjourned
14:59:57 <bh526r> #endmeeting