Hi, Catherine, To the best of my knowledge, the El Alto containers work. He Peng, Andreas or the Integration team can weigh in here, as well.
Thanks, jimmy From: <onap-tsc@lists.onap.org> on behalf of "LEFEVRE, CATHERINE" <catherine.lefe...@intl.att.com> Reply-To: "onap-tsc@lists.onap.org" <onap-tsc@lists.onap.org> Date: Tuesday, May 12, 2020 at 11:25 AM To: "onap-tsc@lists.onap.org" <onap-tsc@lists.onap.org> Cc: WILLIAM E REEHIL <wr1...@att.com>, "AGGARWAL, MANISHA" <amani...@att.com>, VIVIAN A PRESSLEY <vp1...@att.com>, Steven Blimkie <steven.blim...@amdocs.com>, HARISH V KAJUR <vk2...@att.com> Subject: Re: [onap-tsc] ESR Subproject status ***Security Advisory: This Message Originated Outside of AT&T *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Good morning Jimmy, Thank you for bringing this issue to ONAP TSC’s attention. Considering where we are with the Frankfurt release, we urgently need to stabilize ONAP therefore option #2 is no more viable. I tend to suggest option #1 is aligned with the former TSC decision made on Nov 14th, 2014 i.e. re-use El Alto containers except if any blocking issue are identified during the Frankfurt testing cycle by the Integration Team. Any other finding (security, non-blocking issue) should be documented in the Frankfurt Release Note) Have we a confirmation that ESR El-alto containers are OK? Many thanks and regards Catherine From: onap-tsc@lists.onap.org <onap-tsc@lists.onap.org> On Behalf Of FORSYTH, JAMES Sent: Monday, May 11, 2020 5:20 PM To: onap-tsc@lists.onap.org Cc: REEHIL, WILLIAM E <wr1...@att.com>; AGGARWAL, MANISHA <amani...@att.com>; PRESSLEY, VIVIAN A <vp1...@att.com>; Steven Blimkie <steven.blim...@amdocs.com>; KAJUR, HARISH V <vk2...@att.com> Subject: [onap-tsc] ESR Subproject status ***Security Advisory: This Message Originated Outside of AT&T *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Dear ONAP TSC, There has been an ongoing search for resources to support the ESR subproject, and the lack of an updated and working ESR component in the Frankfurt Release needs attention. Background: The original code was part of Open-O and was originally proposed as a standalone project, but ESR was assigned by the TSC to be a subproject of AAI at Release 1. ESR was fully supported by Zi Li and Qi Sun from ZTE until the Casablanca release. They left the project and for the last few releases I have been trying to find resources who can take responsibility for this subproject. ZTE staff, first Lv Bo and then He Peng, have volunteered to take over and both asked to be committers for the project. Since community rules require that an individual can only be considered for promotion to committer if he or she has a track record of contributions, I have asked both Lv Bo and He Peng to make needed code commits and add design documentation or other planning documents in order to establish a history of significant contribution to the project and provide proof that they are SME on the technologies. Lv Bo was unable to contribute and is no longer active and He Peng has been earnestly trying. He has made good contributions to update 3rd party dependencies and I am hoping to recommend him as committer, but I judge that I cannot until I have an updated and functional ESR component. Earlier in Frankfurt I raised this concern and asked if the project can be de-scoped due to lack of resources, but it was determined by the TSC that ESR was still necessary to support flows in multicloud. At that point it was agreed that ESR would use the El Alto containers in the Frankfurt release with some updates to AAI config to unblock testing. Current issue: The integration team is requiring that containers be updated to run as non-root. He Peng and I tried to produce a container from the Frankfurt branch that would meet the requirement, but to this point we have not seen a successful test with the updated containers. Options in Frankfurt: 1. Use the El Alto version of the ESR containers and get a waiver from SECCOM for security issues 2. Find a resource who can fix the existing ESR containers and bring them inline with Frankfurt security requirements 3. Descope ESR from the Frankfurt release and document a workaround for performing the ESR workflows by directly calling the AAI REST API or using CLI For Guilin: The ONAP Community needs to establish a plan for ongoing support for the ESR component. I have recommended a review by the Arch subcommittee. Thanks, Jimmy Forsyth A&AI PTL -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#6356): https://lists.onap.org/g/onap-tsc/message/6356 Mute This Topic: https://lists.onap.org/mt/74138027/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] -=-=-=-=-=-=-=-=-=-=-=-
