Date

08 Mar 2018

Duration 90 minutes

Discussion items 

...

...

...

...

...

...

Self merging code - Antipattern

no review by a 2nd developer

no review by a 2nd company

merges that occur between 1 and 59 min after initial commit

...

We have a serious issue where committers are merging their own code - with no review or oversight.

"After a committer gave you +2" should not be "After you gave you a +2"

I might be missing something but this automated check put into place in oct has no effect

https://lists.onap.org/pipermail/onap-discuss/2017-October/005982.html

https://lists.onap.org/pipermail/onap-discuss/2017-October/005832.html

I have tried to keep this low level - but if we are held to rigid deadlines like these teams - we need a level playfield and not an effective 2 tier system.

Analogy 1

those that drive in either the left or right lane

those that just ignore the yellow line and create 3 lanes out of 2

Analogy 2

Those that use the exit lane on the highway only to exit

Those that use the exit lane as an evolutionary advantage to jump the queue and merge back in at a higher position

Q) are those of us following the rules actually doing the right thing in the long run?

projects I have run into are integration, vfc, sdc - I am not targetting these projects - as these are just the ones I have run into so far

This is wrong for several reasons and several of us have raised this in the discuss groups for a while

reviews are meant to share changes

reviews can be incremental so that other developers can consume work in progress

reviews catch potential issues with integrating the change inside and outside the particular onap component.

If we don't enforce the 2 rules that the rest of us are bound by - then those that follow the rules are in a significant disadvantage - for example I would like to merge a script - I need to put it through rigourous review by 5-10 developers over the course of a couple days - If i am working on parallel work that is on top of this commit in progress - then I need to resolve merge conflicts later - this all takes time - time that we could put to working on release details/artifacts

rule 2 - second company - ideally we collaborate between organizations this way

For the developers that just merge their own code and skip both the rules - they can have very high throughput.

Exceptions: there have been some when critical fixes needed to get in to restore the build (we don't have proper CD E2E integration testing yet) - perhaps even these exceptions should not occur.

some more history on this ongoing issue

Myself

https://lists.onap.org/pipermail/onap-discuss/2018-February/008068.html

Avi

https://lists.onap.org/pipermail/onap-discuss/2018-February/008181.html

The LF

https://lists.onap.org/pipermail/onap-tsc/2017-May/002341.html

A good random example of following proper procedure

https://lists.onap.org/pipermail/onap-sdnc/2017-August/000052.html

see

Committer Best Practices

and

"It is also a best practice to never have a Committer review and/or approve their own contribution into the repository."

https://lists.onap.org/pipermail/onap-tsc/2017-May/000476.html

...

docker hub

nexus3

repos are inconsistent

...

docker image names are different between our repos.

This is causing a problem when swapping out the repo URL - we need special handling for particular projects

example:

policy-db for nexus3
policy-policy-db for dockerhub

Action items

Date

08 Mar 2018

Recording

IRC Minutes

Full IRC Log

Zoom Chat Log

Full IRC Log 

Anchor
irc irc

13:47:12 <kennypaul> #startmeeting tsc-2018-03-08
13:47:12 <collabot`> Meeting started Thu Mar  8 13:47:12 2018 UTC.  The chair is kennypaul. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:47:12 <collabot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:47:12 <collabot`> The meeting name has been set to 'tsc_2018_03_08'
13:47:39 <kennypaul> #chair phrobb, gildaslanilis, SteveT
13:47:39 <collabot`> Warning: Nick not in channel: gildaslanilis
13:47:39 <collabot`> Current chairs: SteveT gildaslanilis kennypaul phrobb
13:47:57 <kennypaul> #topic rollcall
14:01:27 <gilbert> #info mazin gilbert
14:01:30 <davidsauvageau> #info David Sauvageau, Bell
14:03:06 <SteveT> #info Stephen Terrill, Ericsson
14:03:06 <susana> #info Susana Sabater Vodafone
14:03:10 <xinhuili> #info Xinhui Li, VMware
14:03:13 <frankbrockners> #info Frank Brockners, Cisco
14:03:19 <Zhaoxing_Meng> #info Zhaoxing Meng, ZTE
14:03:34 <kennypaul> #info Chris Donley, Huawei
14:03:34 <JasonHunt> #info Jason Hunt, IBM
14:03:36 <RajeshGadiyar> #info Rajesh GAdiyar Intel
14:03:47 <jamil_> #info jamil for Orange
14:03:48 <RannyHaiby> #info Ranny Haiby, Nokia
14:03:56 <Sanchita> #info proxy Sanchita Pathak, TechMahindra
14:05:33 <Xiaojun> #info Xiaojun Xie, China Telecom
14:08:34 <kennypaul> #topic CLA Process
14:09:48 <kennypaul> #info Phil reviewed restrictions that will be in place
14:09:50 <frankbrockners> quick question on housekeeping: US switches to daylight savings time next week. Though the wiki says that the TSC meeting is at 14:00 UTC. Will the time of the TSC meeting change for folks in the US?
14:10:45 <kennypaul> #info suggestion to enable after code freeze
14:11:12 <kennypaul> #info suggestion to wait until after release
14:11:38 <Sanchita> +1
14:12:36 <kennypaul> #startvote Does the TSC approve enabling thye CLA enforcement after the Beijing release? +1, 0 -1
14:12:36 <collabot`> Begin voting on: Does the TSC approve enabling thye CLA enforcement after the Beijing release? Valid vote options are +1, 0, -1.
14:12:36 <collabot`> Vote using '#vote OPTION'. Only your last vote counts.
14:12:39 <susana> #vote +1
14:12:41 <cdonley> #vote +1
14:12:47 <frankbrockners> #vote +1
14:12:52 <SteveT> #vote +1
14:12:56 <RannyHaiby> #vote +1
14:12:57 <JasonHunt> #vote +1
14:13:01 <RajeshGadiyar> #vote +1
14:13:09 <Zhaoxing_Meng> #vote +1
14:13:10 <xinhuili> #vote +1
14:13:21 <Sanchita> +1
14:13:40 <jamil> #vote +1
14:13:42 <Sanchita> #vote +1
14:13:47 <kennypaul> #endvote
14:13:47 <collabot`> Voted on "Does the TSC approve enabling thye CLA enforcement after the Beijing release?" Results are
14:13:47 <collabot`> +1 (11): susana, jamil, frankbrockners, RajeshGadiyar, JasonHunt, xinhuili, SteveT, cdonley, RannyHaiby, Sanchita, Zhaoxing_Meng
14:14:31 <kennypaul> #agreed the TSC approves enabling CLA enforcement after the Beijing release.
14:14:33 <gilbert> #vote +1
14:15:02 <kennypaul> #topic TSC Composition
14:24:07 <kennypaul> #info discussion of whether LFN Platinum members can appoint reps to the TSC.
14:26:51 <kennypaul> #action kenny work with TSC on new language for the charter regarding "active" TSC member participation.
14:30:46 <phrobb> #action phrobb and kennypaul to start and email vote on when to change the TSC composition
14:31:45 <kennypaul> #info decision on whether to retain the current composition of the TSC structure until after after the Casablanca release will be moved to an email vote.
14:32:21 <kennypaul> #topic HPA Capabilities
14:34:42 <kennypaul> #Alex Vul reviewed his slides
14:35:22 <kennypaul> #info Alex Vul reviewed his slides
15:02:28 <kennypaul> #agreed the TSC accepts the proposed solution.
15:02:57 <kennypaul> #topic M3 Review
15:03:23 <kennypaul> #info Gildas Lanilis reviewed his slides.
15:05:36 <kennypaul> #info action kenny/phil provide info on vulnerability with ODL
15:06:13 <kennypaul> #info No blockers for M3
15:14:03 <kennypaul> #info discussion of SO code merge that is still pending.
15:14:46 <kennypaul> #info AAI scope changed -
15:15:15 <kennypaul> #info will be addressed in Casablanca
15:15:44 <kennypaul> #info DCAEgen2 scope changed.
15:16:22 <kennypaul> #info stretch golas will be descoped
15:16:39 <kennypaul> #info OOF scope changed
15:17:04 <kennypaul> #info vnf scaleout removed from Bejing
15:17:21 <kennypaul> #info SDC scope change
15:17:58 <kennypaul> #info will meet stretch goals
15:18:34 <kennypaul> #info logging - no update
15:18:55 <kennypaul> #info M2 action items closed
15:21:17 <kennypaul> #agreed all projects other than logging and vvp are approved to pass M3 gate.
15:22:28 <kennypaul> #topic VVP inclusion in Beijing
15:24:15 <kennypaul> #info VVP is standalone - ONAP is not dependent upon it
15:24:41 <kennypaul> #info code is packaged as containers.
15:26:08 <kennypaul> #info unclear what S3P requirements would actually apply to VVP
15:27:37 <kennypaul> #info discussion
15:29:03 <kennypaul> #info need to get agreement on what checklist / S3P items apply.
15:31:03 <kennypaul> #info team top meet and discuss - Steven Wright to drive.
15:34:09 <kennypaul> #topic meeting times
15:34:37 <kennypaul> #agreed the TSC meeting will be aligned with UTC
15:35:07 <kennypaul> #action kenny to make time chages for the TSC
15:35:48 <kennypaul> #action kenny check into modifying TSC time for ONS
15:35:55 <kennypaul> #endmeeting

...

Zoom Chat Log 

Anchor
zoom zoom

06:11:02 From Brian : Agree - integration phase time is critical
06:11:11 From Randa Maher : +1 for after release
06:11:13 From Brian : do it at start of Casablanca
06:11:13 From Helen Chen : +1
06:11:32 From Seshu : +1
06:11:51 From Sanchita Pathak : +1
06:12:41 From Tony Hansen : please spell out acronyms
06:12:55 From Zhaoxing : +1
06:18:24 From Lingli : why not?
06:24:17 From Brian : seems like all of the LFN projects will have the same issue
06:24:24 From Brian : opendaylight for example
06:24:53 From Stephen Terrill : At least the ones that are in the "startup phase" the ones that in in the "steady state" phase elect from teh community
06:24:58 From Chris Donley : ODL and OPNFV already switched to meritocratic elections
06:28:59 From Frank Brockners : Minor modification... OPNFV is about to move: Full meritocratic TSC will be in place in September this year
06:29:24 From Stephen Terrill : When does DST start in US? Is that next week? I see in Europe it starts March 25th
06:29:48 From Frank Brockners : Next weekend from what I know
06:29:51 From Helen Chen : 3/11/2018
06:30:04 From Lingli : next week as I was told
06:30:13 From Frank Brockners : This was my earlier quesiton (on TSC): US switches to daylight savings time next week. Though the wiki says that the TSC meeting is at 14:00 UTC. Will the time of the TSC meeting change for folks in the US?
06:30:31 From Frank Brockners : Haven't seen an answer yet
06:30:52 From Chris Donley : Can we move it back to 7 am pacific?
06:31:49 From Frank Brockners : Chris, this would naturally happen if we 14:00 UTC is the TSC meeting time, wouldn't it?
06:32:14 From Chris Donley : yes
06:47:30 From Tina Tsou @Arm : My first thought is to look at how container orchestration deals with this today and make sure we're not reinventing the wheel. Some other thoughts: - The first level of platform awareness is to pick the VNF compiled for the right architecture (Arm, x86) - Some (such as smt, vCPU pinning) are architecture agnostic and could be common - Some are architecture specific (ISA features such as AVX etc.). Surely we don't need to rediscover that list but there is a list known by the Linux kernel. Why maintain that list here vs referencing Linux? - Some of them don't seem to make any sense. For example 'TXT' (which is an Intel security feature). What does it actually mean for the VNF to have a TXT dependence? - Same question for SGX. What is the use-case for technology like SGX in a VNF and how is calling it out separately useful? The security ones cause the most head scratching. If there was a simple thing to push for to make this Arm agnostic I would say it would be: - The list of key/value pairs needs
06:48:40 From Thinh Nguyenphu (Nokia) : HPA support is in ETSI NFV SOL001.
06:48:55 From Tina Tsou @Arm : to be extensible and not hard-coded anywhere, so that the barrier to enabling new platform features is low - The extensible list needs to be split into arch specific (one for each arch) and non arch-specific. Non arch-specific will need to be agreed jointly and the arch specific stuff gets maintained by an appropriate owner. - Ideally there would be a vendor specific list as well Does that make sense?
06:49:21 From Tina Tsou @Arm : SGX could be an optional feature, but perhaps we should be pushing for a set of generic key-value pairs: Security- Feature 1 Security- Feature 2 … Security-Feature N, where some of these are general security types, applicable to both architectures, but then implementations are underneath. In other words, I do not think SGX or any other vendor feature should be mentioned in any top level model specification
06:54:34 From Srini Addepalli (Intel) : Hi Tina, you are right. There is no mention of hardware features in the model. HW feature itself is value for the TOSCA parameter. Hence, it is generic and extensible. Any features invented in future don't require changes to the model.
06:59:53 From Tina Tsou @Arm : Thanks Srini and Alex, I will send more comments after this meeting
07:00:52 From Pamela Dragosh : Please don’t delay M3
07:01:31 From Steven Wright : This consideres the TOSCA DM, buit for BEijing, ONAP must also support HEAT. IS there some impact tehre, or someone working on this ?
07:03:16 From Alexander Vul : HEAT will not support HPA...
07:03:35 From Alexander Vul : the decission was to make HPA work using TOSCA...
07:06:50 From Tina Tsou @Arm : So are you going to change TXT and SGX?
07:08:24 From Stephen Terrill : I looks like I will not get to present the CII Badging program status. PLease have a look at https://wiki.onap.org/download/attachments/25434810/2018-03-08%20CII%20Badging%20program.pptx?version=2&modificationDate=1520435345000&api=v2 as some projects have a bad url to the GERRIT repo for the project.
07:10:47 From Michael O'Brien : logging M3 - https://lf-onap.atlassian.net/wiki/display/DW/Logging+Beijing+-+M3+API+Freeze+Milestone+Checklist
07:15:23 From Seshu : Hi sir
07:15:51 From Stephen Terrill : You can see the overall status with Tony's tool :-) (working to bring this into nexus): http://tlhansen.us/onap/cii.html
07:20:13 From Brian : helen - do we have RCx week1 environments assigned for folks in windriver or Tlab ?
07:20:51 From Helen Chen : At Windriver, they still have their old env
07:21:10 From Helen Chen : We are trying to setup some maturity testing tools for them
07:21:36 From Brian : cool
07:21:48 From Helen Chen : TLAB is ready for them to apply, need to check with Rich how many people are there
07:22:33 From Helen Chen : Beijing is not stable enough for Integration team to do too much. We are playing with Amsterdam MR for Maturity testing
07:23:19 From Helen Chen : testing our tools and measurement (kind of PoC)
07:29:03 From Michael O'Brien : Helen, yes, when running the vFW - I use amsterdam only so far
07:30:32 From Helen Chen : Expecting all projects pass the health check and vFW/vLB before M4
07:32:48 From Brian : i have been wrestling with amsterdam on OOM only
07:32:58 From Brian : those startup race conditions are a pain :(
07:33:12 From Helen Chen : :-(
07:33:37 From Michael O'Brien : pullPolicy will need to be IfNotPresent - jira
07:33:41 From Brian : Micheal are folks fixing that for beijing master ? helm charts seem to let things come up out of order so AAI, SO and SDNC cant talk to dmaap
07:33:51 From Michael O'Brien : oom-722