Page Comparison

• SECCOM contribution to ONAP qualityincreaseappreciated!!!
• THANK YOU for all the contributions.

DCAE update

REQ-801

REQ-800

REQ-863

REQ-443

• Waivers tracing for SECCOM global requirements:
  • vfc-huawei-vnfm-driver -pending question
  • Wildcard not supported in waiver management (message-router-* was replaced by message-router-kafka and message-router-zookeeper
  • other yellow line
    • framework-artifactbroker remaining in java (dual version)
    • modeling-etsicatalog
    • uui/uui-server
  • pnf-macro-test-simulator shall be very soon run in a different namespace and shoudl disapeear, it is a simulator it coudl also be under waiver (not released with ONAP)
• Security scans: https://logs.onap.org/onap-integration/weekly/onap_weekly_pod4_master/2021-09/14_13-40/

• Nexus upgraded to latest version, LFN decision to use SPDX format and not cyclone or DX
• Research on how the missing information can be collected (plugin to be used?), info.yaml, POM file for Maven and Jira on who submitted the code
• We are not tracking 1to1 contribution tracing in the repository, so the information is upstream when commiter merges the code

• The official policy of the TSC on including unmaintained components in a release: Continue to use the latest version of the component (latest docker) if there is a dependency in other components.
• 3 unmaintained components: portal, portal SDK and VID
• Global Requirements are not tracked well, apart from the SECCOM ones , but Release Manager does not track them ;-(, should be tracked by proper integration tests but it would be problematic for vulnerabilities management (packages upgrades).

From green user perpective - a lot of info is missing on how to install ONAP or upgrade it - lot of missing information from ONAP documentation. Troubleshooting based on logs is painfull... Solution level thinking from user perpective, how to start and what is the sequence to install ONAP.

Sean is exploring POM file and some documented ONAP interdependencies.

In Amy'steam some developer is also doing similar effort.

Pawel to sent an information to documentation team. We need a dependency map.

Jakarta proposed dates

Global Requirements/Best Practice deadline for submission: 2nd of December by SECCOM:

• [REQ-xxx] SECURITY LOGS MANAGEMENT
• [REQ-xxx] Feature intake template
• [REQ-xxx] Using basic image from OOM
• [REQ-xxx] Software BOMs

Portal and VID dependencies (i.e., portal, portal-sdk & vid repos):

Portal -> SDC UI (user authentication) -> Other projects are dependent on SDC (e.g., CLAMP GUI)

VID to be removed , portal SDK as well.

Projects unmaintained shall have their repos excluded from scans.

EoL/EoS nomenclature could be used, open source communities do not maintain older versions, but encouraging to use latest greatest.

SCA automation efforts

New Best practice for Jakarta release – new req to be open for Security logging

Set of questions prepared by Bob, to be addressed.

Sidecar for logging - to be further decided by TSC who is going to maintain it.

Muddasar did not find prove of tracking the feature after its approval.

To reach out PTLs on what could be the best way to tackle Jira template.

Muddasar will propose some initial template, contributions are welcome.

Muddasar will also reach out Alla as a follow up, feedback from testers might be also valuable.

Apart from current global requirements we might want to follow any other requirements:

• Security logging as best practice for Jakarta, it is not exactly REQ-441
  • good feedback from Vijay and Toine
  • our proposed format is from the perspective of logging outbound networks connections.  Bob thinks we may need to add some fields to handle the logging of inbound connections as well as general events that  originate internal to the container
  • Bob shared excel file for logging, container info is missing

Base images provision by Integration team to PTLs as a good foundation for logging and logger helper.

Slides presented by Tony uploaded below.

Requirement to support by DCAE registry for HELM charts. Chartmuseum is maintained by Chart team. 3 types of authentication supported.

Proposal is to restrict the client's list, once they have user names and passwords only ones who have to update/delete charts limits writing and access considerable just for those particular clients. FW to be used to limit the access for reading to strictly ONAP applications.

mTLS could be a solution for read?   Side car with cert could be interesting.

• Angular experience on dependencies (Amy’s team)
• CADI and AAF replacement (Byung)