14:00:41 #startmeeting Weekly Technical Discussion 14:00:41 Meeting started Thu Mar 2 14:00:41 2017 UTC. The chair is bh526r. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:41 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:41 The meeting name has been set to 'weekly_technical_discussion' 14:01:13 #topic Roll Call 14:04:53 #topic Scenario Descriptor and Support of Continuous Delivery Model 14:05:08 #info Uli encourages people to review the patch 14:05:48 #link https://urldefense.proofpoint.com/v2/url?u=http-3A__artifacts.opnfv.org_octopus_review_28443_scenario-2Dlifecycle_index.html&d=DQMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6qPcDOqMgwf1K_r6YIIHhw&m=ofQn5VWnyu1LH6fxFb_-RLlxBg25KSAq4A5i_MZvkVs&s=aHTXbN7WimqSMgOOz4lCQpHo3_DsaEYBQBDVixkmsNk&e= 14:06:13 #link https://gerrit.opnfv.org/gerrit/#/c/28443 14:06:30 #link http://artifacts.opnfv.org/octopus/review/28443/scenario-lifecycle/index.html 14:07:08 #info Bryan Sullivan 14:07:31 #info Uli 14:07:43 #info Fatih Degirmenci 14:08:01 #info Tim will review it and give comments 14:10:40 #info An example of MANO scenario descriptor will be clearer 14:11:05 #info Some other examples of scenario descriptor available in the patch, but not for MANO yet 14:12:05 #info Prakash will look into the patch, and try to come up with an example of MANO 14:13:36 #info Bryan will also post some comments on gerrit 14:15:12 #topic Cross-Community CI Process 14:15:29 Hi all 14:16:13 The Go To Meeting app is frustrating... I was sitting on the wrong channel waiting for an organiser 14:16:50 #info Fatih presented the slides 14:17:38 dneary: glad that you find the right channel. 14:18:01 bh526r, Me too. It's this "even hour/odd hour" thing 14:18:22 The Go To Meeting Android app has lots of historical meeting IDs in it 14:19:28 That's right. The odd/even confused me too 14:19:34 #info rprakash 14:20:16 I was also on the wrong GTM, but fortunately checked the meeting invitation 14:25:36 #info It will be automatically triggered. Developers just need to submit a patch 14:27:08 #info If an upstream developer submits a patch, it will trigger upstream gate jobs and OPNFV gate jobs 14:27:30 #info e.g. OpenStack Ansible 14:27:51 #info e.g. ODL 14:28:48 #info It will make DevOps Model/Continuous Delivery real 14:30:22 #info Ironic is a service in OpenStack using bare metal 14:30:31 #info Not VM 14:31:38 They're pronouncing it wrong! http://norse-mythology.org/cosmology/bifrost/ 14:32:44 #info This work will be concluded in about a week in ODL 14:33:27 #info work in OpenStack is huge, and it will take a while 14:35:09 #info XCI Tool and Scenario Descriptor will help the progress of DevOps/Continuous Delivery Release 14:35:54 dneary: :) 14:35:58 dneary: reference 14:36:01 #link https://docs.openstack.org/developer/bifrost/readme.html#bifrost 14:36:41 #link https://docs.openstack.org/developer/openstack-ansible/ 14:40:47 #topic Milestone Exception Process 14:41:01 #link https://wiki.opnfv.org/pages/viewpage.action?pageId=8690432 14:41:45 #info David summarized the background, and the proposal has been sitting there for a few weeks, and discussed a couple of times within the community 14:42:26 #info The key is how to conduct reviews 14:43:00 #info There are several options, such as TSC, a Committee, by Release Manager, etc. 14:43:26 #info It seems the preference is by a Committee (volunteers) 14:43:57 #info Committee gives suggestion to TSC for quick vote, which saves a lot of time 14:45:41 #info Another option is "No Exception". Then there will be very limited number of projects that can make a release 14:45:58 #info So it will be good to provide some flexibility 14:50:22 #info Then the question is how realistic it is to have volunteer to review the exception process. 14:52:29 bryan_att, Why is your focus on having everyone use stable releases? 14:54:03 #info David will recommend to TSC that we will follow Option 2 14:54:52 dneary: actually the opposite - I would prefer that we develop on the upstream master and periodically cut stable releases for OPNFV, then continue work on master. i.e. we don't develop upon the upstream stable releases since that forces the distros to spend a couple of months rebasing the installers in each release. 14:55:11 #topic E Release Plan 14:55:14 bryan_att, I misunderstood what you said earlier then, apologies 14:55:24 #link https://wiki.opnfv.org/display/SWREL/E-River 14:55:31 it's early here 14:55:51 #info David originally proposed to skip 2.0, 3.0 etc. 14:56:04 #info Some discussion and feedback got from community 14:56:18 #info So the proposal was withdrawn 14:56:48 #info New proposal will be very similar to prior release in terms of schedule 14:56:58 #info and added 2.0, 3.0 15:03:54 I like http://techdiscuss.yunify.org/ :) 15:04:13 thanks 15:04:14 #info MANO update 15:04:17 #link https://wiki.opnfv.org/pages/viewpage.action?pageId=6827111 15:04:52 #info Next week, we will discuss a new project proposal SampleVNF, and followed by MANO WG Update 15:05:19 #info Then we continue to discuss the DevOps/Continuous Delivery Model 15:05:27 #info Meeting adjourned 15:05:31 #endmeeting