TSC 2017-11-09

Date

09 Nov 2017

Recording

IRC Minutes

Full IRC log

Full zoom chat log

Full IRC Log 

14:45:50 <kennypaul> #startmeeting tsc 2017-11-09
14:45:50 <collabot> Meeting started Thu Nov  9 14:45:50 2017 UTC.  The chair is kennypaul. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:45:50 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:45:50 <collabot> The meeting name has been set to 'tsc_2017_11_09'
14:45:59 <kennypaul> #chair phrobb
14:45:59 <collabot> Current chairs: kennypaul phrobb
14:58:49 <cdonley> #info Chris Donley, Huawei
14:59:10 <SteveT> #info Stephen Terrill, Ericsson
14:59:29 <Susana> #info Susana Sabater, Vodafone
15:00:36 <RannyHaiby> #info Ranny Haiby, Nokia
15:00:44 <Huabing> #info Huabing Zhao, on behalf of Zhaoxing Meng, ZTE
15:01:11 <frankbrockners> #info Frank Brockners, Cisco
15:01:22 <JasonHunt> #info Jason Hunt, IBM
15:01:30 <RajeshGadiyar> #info Rajesh Gadiyar Intel
15:01:44 <Berezin> #info, Arthur Berezin, Cloudify
15:01:45 <gilbert> #info mazin gilbert (AT&T)
15:01:49 <jamil> #info jamil for Orange
15:01:54 <davidsauvageau> #info David Sauvageau, Bell
15:01:55 <phrobb> #info Alla Goldner for Amdocs
15:02:07 <munish> #info proxy Stephen Terrill, Munish Ericsson
15:02:16 <DhananjayPavgi> #info Dhananjay Pavgi, Tech Mahindra
15:04:57 <Chengli> #info proxy Lingli, China Mobile
15:06:13 <kennypaul> #startvote Does the TSC approve the creation of the Control Loop Subcommittee as per the proposal submitted by Pamela Dragosh on Oct 11? Please reply with #vote +1, 0 -1
15:06:13 <collabot> Begin voting on: Does the TSC approve the creation of the Control Loop Subcommittee as per the proposal submitted by Pamela Dragosh on Oct 11? Valid vote options are Please, reply, with, vote, +1, 0, -1.
15:06:13 <collabot> Vote using '#vote OPTION'. Only your last vote counts.
15:06:28 <RajeshGadiyar> #vote +1
15:06:31 <gilbert> #vote +1
15:06:32 <Berezin> #vote +1
15:06:33 <RannyHaiby> #vote +1
15:06:37 <JasonHunt> #vote +1
15:06:41 <Chengli> #vote +1
15:06:46 <munish> #vote +1
15:06:47 <frankbrockners> #vote +1
15:06:48 <cdonley> #vote +1
15:06:51 <DhananjayPavgi> #vote +1
15:06:53 <jamil> #vote +1
15:07:18 <davidsauvageau> #vote +1
15:07:18 <Susana> #vote +1
15:07:20 <Huabing> #vote +1
15:07:32 <kennypaul> #endvote
15:07:32 <collabot> Voted on "Does the TSC approve the creation of the Control Loop Subcommittee as per the proposal submitted by Pamela Dragosh on Oct 11?" Results are
15:07:32 <collabot> +1 (14): davidsauvageau, frankbrockners, jamil, Susana, RajeshGadiyar, DhananjayPavgi, JasonHunt, Huabing, Chengli, cdonley, Berezin, gilbert, RannyHaiby, munish
15:07:43 <kennypaul> #agreed the TSC approves the creation of the Control Loop Subcommittee as per the proposal submitted by Pamela Dragosh on Oct 11
15:08:01 <kennypaul> #startvote Does the TSC confirm the promotion of Mark Gibson to be a Committer for the External API Project?
15:08:01 <collabot> Begin voting on: Does the TSC confirm the promotion of Mark Gibson to be a Committer for the External API Project? Valid vote options are Yes, No.
15:08:01 <collabot> Vote using '#vote OPTION'. Only your last vote counts.
15:08:01 <kennypaul> Please reply with  #vote +1, 0 -1
15:08:07 <Berezin> #vote +1
15:08:11 <Huabing> #vote +1
15:08:12 <JasonHunt> #vote +1
15:08:13 <DhananjayPavgi> #vote +1
15:08:16 <gilbert> #vote +1
15:08:19 <Chengli> #vote +1
15:08:19 <RannyHaiby> #vote +1
15:08:21 <cdonley> #vote +1
15:08:31 <Susana> #vote +1
15:08:41 <munish> #vote +1
15:08:44 <davidsauvageau> #vote +1
15:09:04 <jamil> #vote +1
15:09:29 <kennypaul> #endvote
15:09:29 <collabot> Voted on "Does the TSC confirm the promotion of Mark Gibson to be a Committer for the External API Project?" Results are
15:10:31 <kennypaul> #agreed the TSC confirms the promotion of Mark Gibson to be a Committer for the External API Project.
15:11:05 <kennypaul> #topic RC2 Milestones
15:12:38 <kennypaul> #info gildas reviewed rthe spreadsheet
15:12:43 <kennypaul> #info rows 2-18 are green
15:13:30 <kennypaul> #info rows 19-23 are yellow - missing some info but not high/highest priority bugs
15:20:47 <kennypaul> #info rows 24-27 are red due to high/highest priority bugs
15:22:56 <kennypaul> #info questions about jenkins CSIT environments
15:23:04 <kennypaul> #link http://12.234.32.117/jenkins/job/healthcheck/lastBuild/robot/
15:24:15 <kennypaul> #info above is for Helen's server for healthchecks not eh LF instance
15:25:20 <kennypaul> #info it is believed that there is an error in the job definitions
15:25:50 <kennypaul> #info green projects are passed
15:26:51 <kennypaul> #info yellow projects are being given until the end of the week
15:29:42 <kennypaul> #topic integration testing
15:30:04 <kennypaul> #helen reviewed her slide deck
15:30:19 <kennypaul> #info helen reviewed her slide deck
15:30:57 <kennypaul> #info passed all health test and flow for vFW
15:31:09 <kennypaul> #info vDNS 90%
15:31:21 <kennypaul> #info vCPE 90%
15:31:39 <kennypaul> #info VoLTE only blocker remains
15:31:56 <kennypaul> #info on track for 11/16
15:36:45 <kennypaul> #info discussion of integration healthcheck jenkins
15:38:44 <kennypaul> #topic release notes
15:39:06 <kennypaul> #info greg shared his slides
15:39:36 <kennypaul> #info need support form usecaseui
15:39:44 <kennypaul> #undo
15:39:44 <collabot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2cd3750>
15:39:56 <kennypaul> #info need info from usecaseui
15:44:35 <kennypaul> #topic Branching Discussions
15:45:15 <kennypaul> #link https://docs.google.com/presentation/d/1YfljsGiDpXOeNzs2czybhxNL_fEbUxMlUYUOYaItmj0
15:45:26 <kennypaul> #info Frank reviewed the slides
16:09:12 <phrobb> #info Discussion on slides and branching. The proposal, create AMS branch on Nov. 10th, create an AMS Maint release on Jan. 18th; may only have one maint release, depending on bugs reported. Regardless, support for AMS would be completed at the introduction of Beijing
16:09:15 <kennypaul> Does the TSC approve the Option 3 branching proposal recommendations for having Amsterdam service releases one month apart with the first release targeted for Jan 17, 2017, terminating with the Beijing release
16:09:35 <gilbert> #vote +1
16:09:41 <RajeshGadiyar> #vote +1
16:09:43 <kennypaul> #startvote Does the TSC approve the Option 3 branching proposal recommendations for having Amsterdam service releases one month apart with the first release targeted for Jan 17, 2017, terminating with the Beijing release? Please reply with #vote +1, 0 -1
16:09:43 <collabot> Begin voting on: Does the TSC approve the Option 3 branching proposal recommendations for having Amsterdam service releases one month apart with the first release targeted for Jan 17, 2017, terminating with the Beijing release? Valid vote options are Please, reply, with, vote, +1, 0, -1.
16:09:43 <collabot> Vote using '#vote OPTION'. Only your last vote counts.
16:09:50 <jamil> #vote +1
16:09:50 <RajeshGadiyar> #vote +1
16:09:51 <gilbert> #vote +1
16:09:52 <DhananjayPavgi> #vote +1
16:09:54 <munish> #vote +1
16:09:55 <JasonHunt> #vote +1
16:09:58 <cdonley> #vote +1
16:09:58 <frankbrockners> #vote +1
16:09:59 <Huabing> #vote +1
16:09:59 <Susana> #vote +1
16:10:03 <phrobb> #vote +1
16:11:02 <cdonley> Just to clarify, we’re only committing to ONE maintenance release with an option for additional ones or independent releases to be determined later, right?
16:11:12 <phrobb> #info phrobb vote is for Alla Goldner of Amdocs
16:12:25 <kennypaul> #endvote
16:12:25 <collabot> Voted on "Does the TSC approve the Option 3 branching proposal recommendations for having Amsterdam service releases one month apart with the first release targeted for Jan 17, 2017, terminating with the Beijing release?" Results are
16:12:25 <collabot> +1 (11): frankbrockners, jamil, Susana, RajeshGadiyar, JasonHunt, cdonley, Huabing, phrobb, DhananjayPavgi, gilbert, munish
16:12:53 <davidsauvageau> #vote +1 (you can add me)
16:13:13 <RannyHaiby> #You made add my vote +1
16:13:34 <kennypaul> #agreed the TSC approves the Option 3 branching proposal recommendations for having Amsterdam service releases one month apart with the first release targeted for Jan 17, 2017, terminating with the Beijing release.
16:15:16 <kennypaul> #info discussion over when to branch
16:17:05 <kennypaul> #agreed branch will be planned for Nov 16.
16:20:23 <kennypaul> #info cist and documentation strategy needs to be established
16:20:49 <kennypaul> #topic R2 use cases/requirements endorsement
16:21:05 <kennypaul> #alla reviewed her slides
16:23:38 <kennypaul> #info alla reviewed her slides
16:24:00 <kennypaul> #info ajay reviewed network function change management
16:40:57 <kennypaul> #info alla will send out info to the TSC for review
16:41:03 <kennypaul> #endmeeting

Zoom Chat Log 

07:21:54 From Frank Brockners : http://12.234.32.117/jenkins/job/healthcheck/lastBuild/robot/
07:24:40 From Pamela Dragosh : Perhaps we modify the RC checklist to add Integration Lab health check failures.
07:25:51 From Brian Freeman : it does make sense - I thikn we are focusing on helen's testing (which makes snese) and not so much the csit jenkins jobs
07:29:46 From Michael O'Brien (LOG) : can we mark aai/aai-service as a locked repo - it has no jenkins job and is currently failing in master
07:30:46 From Michael O'Brien (LOG) : Can we post all the workarounds getting vFW up in INT-106
07:46:33 From Dhananjay Pavgi : Support and like option 3
07:47:01 From Dhananjay Pavgi : Reason : There may be CSPs trying out ONAP in POCs on Amsterdam rel.
07:49:16 From Randa Maher : My vote is for Option 3
07:49:40 From Pamela Dragosh : I think all the PTL’s should be allowed to vote for this, if there is going to be a decision. In addition to TSC members.
07:50:23 From Vimal Begwani : Option 3 is cleaner as we achieve architecture alignment
07:51:59 From ramki krishnan : Option 3 seems the most attractive
07:52:03 From Mazin : PTLs can provide input through this chat.
07:52:09 From jianguo zeng : TSC had agreed to solve openECOMP issues right after amsterdam release,
07:52:41 From Michael Lando : i think op 3 is the only way to go , since the other options will couse a dellay for bejjing.
07:54:41 From jianguo zeng : But may I suggested a limited timeline for option3, e.g. 3-4 months, so maintenance won't occupy too much develops human resources.
07:54:45 From Martial (AT&T) : I'am with Michael I vote 3
07:54:55 From Dhananjay Pavgi : Option 3 also helps us to get in a structured and incremental manner to achieve Carreir Grade objective.
07:55:01 From Jimmy Forsyth : I support option 3, provides more flexibilty to dev teams
07:55:02 From Lusheng Ji (DCAE) : Opt3 +1
07:55:38 From Catherine Lefevre : I am not sure everybody can vote on IRC
07:55:43 From Chris Donley : I think we're going to see some changes in Beijing wrt harmonization between ECOMP/OPEN-O plus some new projects around S3P (e.g., resiliency). I think we want to make sure we have enough time for changes, so Option 1 or 3.
07:55:45 From Seshu : option 3 looks ok
07:56:00 From Lusheng Ji (DCAE) : given the holidays, really not much can be planned in december and jan.
07:56:46 From Catherine Lefevre : option 3 if we do not want 1 month on the openecomp/onap migration work as part of the Beijing release
07:57:10 From Catherine Lefevre : AT the end, PTL should be the responsible of branching or not
07:57:10 From Jason Hunt : So, I think we’d agree that there will be bugs found in Amsterdam and we would want to be able to address some of those. Likewise, I think we do expect Beijing to have substantial changes incompatible with Amsterdam.
07:57:17 From Pamela Dragosh : Option 3 is easier for developers. But hard to do another release one month from now due to holiday/vacation schedules. Then another month due to Beijing planning.
07:57:18 From Dhananjay Pavgi : That's right, Phil. And there are some CSPs that are going to start their ONAP POCs with Amsterdam.
07:57:45 From Catherine Lefevre : jason - only showstoppers
07:57:50 From Catherine Lefevre : only highest
07:57:54 From Jason Hunt : Catherine - agree
07:58:07 From Randa Maher : Option 3 provide maximum flexibility. removing openecomp references will be disruptive for a time; leaving the amsterdam release allows integration to continue testing, possible uncovering issues that we can address in Beijng release, they could help to continue hardening the release to help get to an enterprise goals
07:58:14 From Steven Wright : can we put the thee choices back on the screen
07:58:18 From Brian Freeman : Option 3 - plan a SR1 and maybe a SR2
07:58:49 From Munish Agarwal : How long would Amsterdam mantained in case of option 3?
07:58:52 From Jason Hunt : key is how do project teams prioritize their time between Amsterdam defects and Beijing improvement
07:58:55 From Catherine Lefevre : only showstoppers highest + security/vulnerability issues. we need to reduce backporting work
07:59:05 From Dan Timoney : Please put options back on screen
07:59:59 From Phil Robb : Munish, the proposal was to only support Amsterdam until the Beijing release.
08:00:08 From Munish Agarwal : ok.
08:00:12 From Catherine Lefevre : too long Robb
08:00:18 From Catherine Lefevre : too long Phil sorry
08:00:20 From Chris Donley : Maintain AMS through M1 and then pivot development towards Beijing
08:00:41 From Pamela Dragosh : Up to the project to determine if bug fixes need to be cherry-picked.
08:00:49 From Chris Donley : We could still allow independent releases if necessary
08:01:05 From Catherine Lefevre : 1 month - opt3 - highest + security - PTL to decide
08:01:27 From talasila : Hybrid option from 1 and 3 seems to be good. Fix bugs in Beijing rather than maintaining Amsterdam release to avoid cherry picking. And focus on hardening the ONAP projects along with approved new features.
08:01:28 From Dhananjay Pavgi : makes sense Catherine.
08:01:35 From ramki krishnan : Bugs in Amsterdam may not be necessarily be bugs in Beijing since we are converging on a common architecture across all use cases in Beijing
08:03:42 From Pamela Dragosh : and the conference
08:04:36 From Catherine Lefevre : M1 - great idea !
08:04:42 From Pamela Dragosh : +1 for M1 thanks!
08:05:09 From Seshu : +1 M1 Beijing
08:05:51 From Dan Timoney : +1 M1
08:06:17 From Dhananjay Pavgi : +1 Option 3 +1 M1
08:06:57 From Mazin : PTLs, please provide your feedback before TSC votes. Is Option 3 + M1
08:07:05 From Martial (AT&T) : +1 M1
08:07:06 From Catherine Lefevre : 1 branch + Master - no more otherwise our dev and testers will blow up
08:07:12 From Brian Freeman : those VIM owner to provide test resources
08:08:29 From Jamil Chawki/ Orange : +1 for Frank proposal
08:08:37 From Catherine Lefevre : excellent summary Frank .... +1 +2 +3 +4 +5 :-)
08:09:29 From Kenny Paul : Does the TSC approve the Option 3 branching proposal recommendations for having Amsterdam service releases one month apart with the first release targeted for Jan 17, 2017, terminating with the Beijing release
08:11:52 From Catherine Lefevre : can we make Frank's strategy part of our ONAP dev practices so we do not rediscuss this for Cassandra etc?
08:13:31 From talasila : @Andy - The Portal team do not want LF team to branch “portal” or “portal/sdk” repos for Amsterdam. Because the team has already done that branching for Amsterdam stable code and the Jenkins jobs are also created for them.
08:13:34 From Eric Debeau : I agrre with Franck for the message. We need to inform the community
08:14:09 From Catherine Lefevre : yes Eric and make it standard for any release
08:14:13 From Alla Goldner : yes, agree with Eric. This is something major and we should inform the whole community appropriately
08:14:14 From Pamela Dragosh : +1 for branching early next week.
08:14:23 From Pamela Dragosh : Still a bit more testing happening
08:14:44 From Alla Goldner : @standard for any Release - we may later decide to include some additional scope into advanced versions
08:14:54 From Pamela Dragosh : we are already holding back - per last week TSC decision
08:15:06 From Alla Goldner : not for Amsterdam, but for the following Releases
08:18:33 From Pamela Dragosh : Integration would have to branch also. Those CSIT issues would be resolved possibly?
08:21:41 From talasila : The heat scripts under “demo” repos may also be impacted after the branching. If the “demo” repo is branched for Amsterdam, then the scripts require appropriate updates.
08:30:37 From Frank Brockners : sorry - need to drop
08:31:49 From Rajesh Gadiyar @ Intel Corp : I have to drop
08:31:55 From Rajesh Gadiyar @ Intel Corp : Have a good day every body
08:32:03 From Dhananjay Pavgi : Sorry need to drop off now
08:32:08 From Michael O'Brien (LOG) : Michael O'Brien for (logging-analytics) - need to drop
08:34:32 From Vimal Begwani : This is an important requirement to make ONAP carrier grade
08:37:03 From Vimal Begwani : Are we going to review other user case requirements?
08:37:15 From Susana (VF) : is the locking/no-locking something detailed in the VNF template?