Good morning Jim, Please find my feedback
· CCSDK – +1 – great progress – keep going · AAF – Need confirmation – Target is to reach 45% by end of El-Alto? What’s the current status today? · Policy – Need clarification – what’s the current status and what’s the target plan for El-Alto · Portal - Need clarification – what’s the current status and what’s the target plan for El-Alto · OOF - fgps - fgps is not being released in El Alto Need clarification. Will it be used for Frankfurt? Will the associated artifacts remove from the OOF El Alto container? Many thanks & regards Catherine From: onap-tsc@lists.onap.org [mailto:onap-tsc@lists.onap.org] On Behalf Of Jim Baker Sent: Monday, August 19, 2019 10:47 PM To: onap-tsc <onap-tsc@lists.onap.org> Subject: [onap-tsc] ONAP Sonar Waiver Requests Folks, Below are the set of waiver requests that I've collected for the El Alto release. There is one more for Multicloud that we'll hear from at the TSC. Please review these and ask any questions of the respective PTLs. I'll ask for approval later this week. Jim = El Alto Sonar Waivers CCSDK I need to request a waiver for the CCSDK ccsdk/dashboard repository. As you know, this repository was at 69.1% coverage before javascript was added. After javascript was added, coverage dropped to 16.9%. We have been able to get the line coverage on that repository up to 41.5%. We are not likely to be able to improve further on that due to resource limitations. Our plan would be to get back to 55% line coverage in the Frankfurt release timeframe. Of course, if we can improve sooner, we will, but at this time the best we can commit to would be Frankfurt. AAF There is no real chance for AAF to increase its JUnits to 55% for El Alto The reasons for this are: · AAF has a very big resource shortage. o The only people contributing REAL code is Sai Gandham and I. There are other Contributors, but they are just working Sonar reported "Concerns". o AT&T has only funded a ".8" person for ONAP, so, according to AT&T rules, we can only spend 40% of our time on ONAP (though, frankly, I contribute a lot more) o Sai will be on 3 weeks vacation soon o I am SUPPOSED to have Vacation soon. I have had no break this year whatsoever. · AAF has massive ONAP required changes already in play o Release process has changed o There is a new Staging Process/env o OOM is being redone · Additionally, I am committed to improving Security for all ONAP Apps o OUT of the "manual Cert" process o INTO the Auto-Gen of Configs and Certs at runtime o These two elements make ONAP MORE Secure by § NOT putting Certs in Repos § 2-way TLS Authentication is Configured in from the start § MORE Apps can move forward on Security, since they don't have to understand · For that reason, I'm asking only to be working on IMPROVEMENT, which may be 45%, but given our absences, it may be hard to promise 50%. · HOWEVER, also part of the Plan is that I have already undertaken to figure out if there is a way to accelerate this work, even with 25-40% Contractor to do the work. o I analyzed WHERE the code could really benefit from JUnits o Not surprisingly, all the people working so far we working "Low Hanging Fruit". There's not much left at the bottom branches. o THEREFORE, I undertook to develop and demonstrate one of the HARDEST areas to Junit, and while it took me more than a Day, I was able to § Develop an Inheritance Strategy and code REUSE strategy so that Good Junits in the most important/least number of JUnits can be built faster and more effectively § I found additional APIs in the JUnit tool which allows us to more easily Isolate the DB, without losing access to the reusable Helper Functions critical for AAF Use. § This strategy also provides MORE coverage of critical code per JUnit, which should make percentages rise faster. § I already showed this to Sai, who will be utilizing when he's not on vacation. I hope these plans will show a path forward that gets us out of JUnit issues faster. Policy Regarding the TSC call today and the policy/engine coverage dropping below 55% due to Javascript coverage. We have assigned one SME resource to working on this as soon as he is free from current requirements. There is a possibility other resources from Bell Canada will be able to help. And we will see if others can jump in on it. The JIRA for this work is covered here: https://jira.onap.org/browse/POLICY-1937<https://urldefense.proofpoint.com/v2/url?u=https-3A__jira.onap.org_browse_POLICY-2D1937&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=ZglJ8LOeAfevY7wWaSximhFMAzXaMdza5QYCg-DW6SU&m=ykFhkGFTGDY3dygGb6FaCe1kpXTDUaRbg5kE_mzwSkI&s=-rlQQ08kJcrlJ4NPSTpzpAwl_YJjgS2OKlNR8QGGs_I&e=> This repo has both Java and Javascript. · The Java coverage is >55%, but extremely difficult to move the needle on this repo due to excessive cyclical complexity and nested if-then-else and try-catch. · The Javascript coverage will require addition of maven plugins to build the tests. So there will be some time to ramp up on the tool and get that integrated. In addition, the javascript is GUI code so may be difficult to build tests around it. Please be aware that this repo is legacy code and is scheduled to be marked as read-only post-Frankfurt. Perhaps a waiver can be considered if time runs out. Portal Facts: · After enabling Javascript (JS) coverage, the portal's coverage dropped from 72.9% to 21.6% - sonar link<https://urldefense.proofpoint.com/v2/url?u=https-3A__sonar.onap.org_dashboard-3Fid-3Dorg.onap.portal-3Aonap-2Dportal-2Dparent&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=ZglJ8LOeAfevY7wWaSximhFMAzXaMdza5QYCg-DW6SU&m=ykFhkGFTGDY3dygGb6FaCe1kpXTDUaRbg5kE_mzwSkI&s=LyHPkcAlDMgxgdX4ZwV0KPdD91SKHgToZFAR5FlbFPE&e=>. Quality: · The team had a deep dive into the source code of Portal and we can see that the existing JUnit code covers most of critical functionalities of backend java code (72.9%). · Also, the robotframework tests cover all the functionalities end-to-end covering frontend and backend code. So I believe the quality of source code is still in good shape. Risk/Benefit: · This is a huge drop, as the project contain good amount of Javascript code. · The risk here is team may not achieve 55% coverage with JS in El Alto – listed as risk here<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_El-2DAlto-2BRisks&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=ZglJ8LOeAfevY7wWaSximhFMAzXaMdza5QYCg-DW6SU&m=ykFhkGFTGDY3dygGb6FaCe1kpXTDUaRbg5kE_mzwSkI&s=Ssh8BVBFzdOWcemQjpcCvKODMqR_WrREorYA3VVnZPY&e=>. Plan forward: · The team is planning to upgrade to latest Angular 6 which is in Typescript (rather than in Javascript), along with this new upgrade. · The team will explore the test coverage process for typescript code and request LF support to enable Typescript support in ONAP’s Sonar. · So, the recommendation is not to invest efforts in adding code coverage for old JS code, rather invest in typescript code. · For El Alto, it is recommended to disable JS code coverage and start enabling coverage for typescript code. · However, achieving 55% code coverage in new Typescript code is aggressive for El Alto release. The team can target for Frankfurt release. Optfra The repo not reaching Sonar goal is fgps - fgps is not being released in El Alto - no waiver required. [https://lh3.googleusercontent.com/qTfCocB_4bX9Urse4X4AcheMe8PcTp-SaxecVzK5xAVN-o_82FFPKUmRohBRmNBzvvAxKrYoKdyOq_8ZvM2jDFy_EVrqhFBeWiABYSwDKgDcDA70QJZreYM-KJs0STHiwqeCWdvM] -- Jim Baker Linux Foundation Networking - Technical Program Manager mobile: +1 970 227 6007 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#5365): https://lists.onap.org/g/onap-tsc/message/5365 Mute This Topic: https://lists.onap.org/mt/32959988/21656 Group Owner: onap-tsc+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
