13:00:10 #startmeeting Weekly Technical Discussion 148 13:00:10 Meeting started Mon Aug 12 13:00:10 2019 UTC. The chair is bh526r. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:10 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:00:10 The meeting name has been set to 'weekly_technical_discussion_148' 13:00:21 #topic Roll Call 13:00:27 #info Bin Hu 13:00:33 #info Fu Qiao 13:00:54 #info Manuel Buil 13:02:18 #info Mark Shostak 13:02:48 #info Mike Fix 13:03:04 #info Xu Dan 13:03:25 #info Yangguangzhi y00302298 13:04:11 #info Trevor Cooper 13:04:25 #info Murtuza Khan 13:04:42 #info Zhang Hong Li 13:05:07 #info Mark Beierl 13:06:03 #topic Continue Discussion on How to Support CNTT in OPNFV (Qiao Fu) 13:06:40 #info Discussion starts with "Levels of CNTT Artefacts" by Mark Shostak 13:07:19 #link https://github.com/cntt-n/CNTT/blob/master/artefacts/CNTT_intro.pdf 13:07:27 #info Rex Lee 13:08:55 #info Fu Qiao recalled Frank B (Cisco) had some questions last week. But Frank is absent today 13:09:53 #info Mark Shostak briefly introduced the slides of 6 levels of CNTT artifacts 13:10:17 #info Each level below is more specific with more details than level above 13:11:40 #info Mark Shostak described e.g. L1, L2, L3 as examples 13:13:41 #info Trevor Cooper thinks it is not clear what OPNFV needs to do, and how to map this model to OPNFV projects in order to support this model in OPNFV 13:14:11 #info Mark Shostak has another diagram to share 13:15:00 #info Trevor Cooper thinks it is not necessary to solve it today, but we need to think of the work of how to make it work in OPNFV 13:15:33 #info Mark Shostak thinks it is definitely a topic CNTT will pursue 13:16:15 #info Mark Shostak shares another picture (which is availabe in Github CNTT repo) 13:18:29 #info Fu Qiao summarized that CNTT may not know how and what capability OPNFV can work, and OPNFV may not know how how CNTT works, and what to expect from CNTT 13:19:13 #info Mark Shostak expects mutual communication 13:21:29 #info Fu Qiao mentions the slides deck that Fu Qiao, Bin Hu and Mike Fix worked out for Paris meeting, and it covers OPNFV project structure although the work started with OVP activity 13:22:23 #topic Fu Qiao switched gear to present the slides of how OPNFV can be structured to support CNTT 13:22:57 #info Fu Qiao presented the slides of how OPNFV can be structured to support CNTT 13:33:13 #info Trevor Cooper asked how Ref M and Ref A can be integrated into OPNFV releases 13:34:21 #info One Ref A can a feature project in OPNFV, which can be implemented as one scenario by multiple installers 13:36:34 #info Trevor Cooper mentioned hardware profiles, if there are several h/w profiles, when in implementation, we need to pick one, e.g. compute profile, and interfaces and extensions, then we have to make decision in implementation, then set up lab etc. 13:37:11 #info So not sure if it is feasible to have one profile that is enough, or we need variations etc. 13:37:29 #info Then who makes decision, TSC or projects etc 13:37:57 #info Mark Shostak says that CNTT will give guidance regarding profile and variations. 13:38:29 #info Trevor Cooper thinks it important to have guidance from CNTT 13:39:17 #info Fu Qiao thinks it is exact reason to have feature project in OPNFV and communicate 13:40:38 #info Trevor Cooper has one more question regarding installers. Now there is one installer project targeted for CNTT implementation, e.g. Airship 13:42:50 #info Fu Qiao answered that it is not restrictive 13:44:15 #info Bin mentioned that ideally, we encourage all installers to implement Ref A. Of course, if installer is willing to implement it or not is another question. But we encourage all installers to implement all Ref A. 13:45:19 #info Fu Qiao mentioned that if one installer is not willing to implement CNTT, then TSC should decide if OPNFV still needs to host that installer that does not support CNTT 13:46:03 #info Manuel asked if Ref A has 3 profiles 13:46:36 #info Bin mentioned Ref M has 3 profiles. Ref A work just started. Mark S confirmed it is correct 13:53:48 #info Trevor gives an example: for h/w profile, compute-intensive and network-intensive specify different RAM requirement 13:54:10 #info profile specifies different RAM size as h/w requirement 13:54:22 #info Then we need 2 different implementation 14:01:04 #info Bin mentioned that it is only one implementation for this specific example. When installer starts to deploy the NFVi based on Ref A, the very 1st step is to check h/w capability, e.g. RAM size, vCPU etc. 14:01:41 #info For compute-intensive, it checks if RAM size meets the minimum RAM requirement. The same for network-intensive. 14:02:08 #info If h/w capability meets the minimum requirement, then move on to continue rest steps of deployment 14:02:45 #info If h/w capability does not meet the minimum requirement, then reports an error: Insufficient RAM or vCPU or something else 14:03:17 #info So in this case, there is only one implementation, and the implement checks h/w capability as the 1st step in deployment 14:03:57 #info Those h/w profile are in configuration, nothing is hard-coded. So the implementation is scalable 14:04:27 #info Bin suggested that we continue to discuss it next week. 14:05:21 #info Trevor Cooper and Mark Shostak may prepare more examples of variations, and we can further discuss whether or not those mean different implementations or actually one implementation to support multiple variations in runtime 14:05:30 #topic AOB 14:06:02 #info We continue to discuss next week with more examples from Trevor C and Mark S 14:06:08 #info Meeting adjourned 14:06:12 #endmeeting