14:01:05 #startmeeting Weekly Technical Discussion 14:01:05 Meeting started Thu Feb 16 14:01:05 2017 UTC. The chair is bh526r. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:05 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:01:05 The meeting name has been set to 'weekly_technical_discussion' 14:01:14 #topic Roll Call 14:01:19 #info Bin Hu 14:01:25 #info Al Morton 14:01:33 #info Georg Kunz 14:01:42 #info Juha Oravanien 14:01:51 #info Prakash Ramchandran 14:02:02 #info Uli Kleber 14:02:04 #info Dan Radez 14:03:19 #info Aimee Ukasick 14:03:25 #info Bryan Sullivan 14:05:47 #info rprakash 14:06:07 exit 14:07:10 #topic Proposal of DevOps Mode; 14:07:31 #info One of the topic is Keystone integration 14:08:08 #info If I need to have an OPNFV build, should I be able to pull from stable branch or from master with more recent feature 14:08:28 #info rprakash 14:08:40 #info This assumption needs to be validated 14:09:28 #info (Uli) we can try it to validate the feasibility 14:10:47 #info (Bryan) another implication is, e.g. if I have a test, but dovetail cannot pick it up for a few months, how stable will be the test and python library while we are moving forward 14:11:32 #info So we don't leave behind the community too far, while we don't have to wait just for the sake of stable release 14:11:46 #info We need to really understand who the users are 14:11:54 #info (Uli) we have 2 types of users 14:12:16 #info One type is to use the coolest features 14:12:52 #info The other type is to use the newest features 14:13:32 #info Larry Lamers 14:13:35 #info Tapio 14:14:14 #info We need to measure the user community proactively and understand their needs 14:14:58 #info Talking about the first type of users, some are still trying to use Brahmaputra, even if we don't support it any more 14:15:39 #info We need to test feasibility of deploying OPNFV scenarios on trunk? Which installers support that? 14:17:50 #info (Bryan) I am looking for a stable development environment with stable features that enable me to move forward 14:21:47 #info ability to devlopoment on trunk on Openstack like with Congress 14:23:24 #info (rprakash) ability to development on trunk with OpenStack Murano, Manila etc. 14:24:10 #info (aimeeu) using Quickstart with trunklevel developement and Dan says in Newtorn Tacker is in 14:26:26 #info (Bryan) ability to develop with multiple components from different upstreams to work together from trunk to suport new features 14:28:48 #info (Bryan) Dvelopment envrionment like RDO, triple-O, Packstack, Quickstart and understand which one are suitable for different features and test plus continuous Devlopment to support OPNFV community 14:30:23 #info (bryan) Feature Devlopment role is different from Packaging and Delivering different upstreams to the releases 14:31:41 #info (Bryan) Resilliancy is imporant for getting Control Plane stability and needs simplicty and flexibility of control plane 14:33:07 #info (Bryant) ability add drop Cielometer for say Billing , Add drop Congree like Policy usgae is different etc. So customization of target deployment is one aspect 14:34:31 #info (Bryan) How light the Control Plane can be with flexibility of installers to choose some of the options from OpenStack for specialized environment that Service Provider needs 14:35:25 #info Uli will try to put those wishes into scenario consolidation 14:36:02 #info scenario definitions 14:38:32 #info (Bryan) Orchestrator like JujU, Puppet have ability to slect OpenStack Modules and establish relationships and if Scenarios can configure similarly that will be the goal 14:40:27 #info look at scenario descriptor file and pod descriptor file 14:42:34 #info (uli) ability to orchetsrate in layers for Hardware(POD), Infra(descriptor), VNFD/NSD (MANO descriptor) etc 14:43:13 #info (Bryan) mentions like L4 service depends of L3 , L2, so there may be cross layer dependency 14:44:11 #info (Bryan) Its possible to add and remove Charm using Juju and similar can be done with Puppet, Ansible playbook etc. 14:46:28 #info (Bryan) Ability to add reomove Tacke eg. could be using VNF using Tacker once and next using JuJu dynamically 14:47:08 #info (Dan Radez) Why do we need this is there value to this? 14:48:18 #info (Bin) How we can leverage Scenarios to do flexible Control plane objectives and lets discuss and come up with some solutions 14:49:12 #topic Update of Scenario Consolidation 14:49:32 #info (Uli) has submitted a patch in Octopus to be reviewed- request for reveiew 14:49:32 #info Uli submitted a patch of skeleton of scenario document set 14:49:57 go ahead, Prakash to write the notes 14:49:59 #link https://gerrit.opnfv.org/gerrit/#/c/28443 14:50:00 bryan_att: sry to derail right at the end of your time, just to put it on the table, I'm not against your proposal, was just curious to look at it from a different angle 14:50:49 radez: np, any ability to customize needs to be balanced against the cost, for sure. 14:51:37 #info Uli will send an email to mailing list so that everyone can review the patch 14:52:04 #info Then we can move forward to review scenario descriptor patches 14:53:24 #info to summarize what we will be doing toward the last topic areas (1) assessing developer-focused options for OpenStack, ODL test envs simpler than full OPNFV deploys, and providing advice on the wiki. (2) assessing over time whether that gives us more dev freedom at a good balance wrt re platform stability 14:54:55 #info (Bryan) mentioned that there was good discussion in MANO WG. 14:55:06 #topic MANO Update 14:55:11 #info (3) looking at how flexible the installers can be for customizing the deployment (e.g. thru the descriptor files); (4) how modeling concepts can be applied to the control plane as well, e.g. how well the blueprint model can cover the needs of the various descriptors we use in CI/CD 14:56:18 #info the goal of (4) being to someday have a common abstraction/specification for the intended control plane deployment, that the installers can "onboard" and then take action to deploy; 14:57:06 Prakash, can you type your update on IRC as well? Thanks 14:58:01 #info David M is not present, so Milestone Exception Process discussion deferred to next time (March 2) 14:59:34 #info Cross-Community CI process will be on March 2 14:59:45 #info and E release plan 15:00:01 #info (rprakash) MANO release E has learining from vIMS VNF about different approach to orchestartion through installers and without it, plus testing 15:00:37 #inof (rprkash) the other aspect realted to keystone v 3 v 2 usage based on installers support 15:00:55 #info (rprkash) the other aspect realted to keystone v 3 v 2 usage based on installers support 15:01:53 #info (rprakash) the bestpractices is still under review for VNF packaing, onboarding, LCM etc. 15:02:53 #info Next week (Feb 23), we will be dedicated to discuss 2 new project proposals 15:04:06 #info (rprakash) About the Architecture tehre are different views from different work groups like pipeling of CI,CT,CV, CD form iintegration, Test, Vlaidation to Deployment and Tapio has a Software Architecture viewpoint and thus we need to reflect the upstream integration aspect as we are looking now at Bifrost and working through up[straem Trunk in CI 15:04:27 #info On March 2, we will discuss (1) DevOps/Continuous Delivery and How Scenario Descriptor can enable/support it (2) Cross-Community CI Process (3) Milestone Exception Process (4) E Release Plan 15:04:55 #info And the perhaps (5) MANO WG Update and MANO Architecture if time permits 15:05:09 #info Meeting adjourned 15:06:52 #endmeeting