Please find below the Minutes of Meetings and recording for the SECCOM meeting that was held on 12th of May 2020.
| Jira No | Summary | Description | Status | Solution |
|---|---|---|---|---|
| Synch meeting with Requirements Subcommittee | We had a meeting on May 11th where we presented SECCOM requirements for Guilin release. | We were asked to fulfill our non functional requirements on this wiki. Jira Epics to be started for each project. | ||
TSC logging presentation – discussion point | 20_04_30_ONAPLoggingGuilin_V1.pptx We need to bring it to the Architecture Subcommittee. ONAP component retirement and replacement still requires discusssion at the TSC level. Logging is not just a collection of logs but also analysis and the retention. FluentD - we need to check if full logging needs could be fulfilled. | ONAP project use of Logging | 2 next steps: -Understand logging and upgrade path to Java 11. In order to move forward, we have to identify logging project representative. -Consider open source projects as equivalent for logging and impact on other ONAP projects - we would need a proxy/representative for logging open source. | |
| OOM requirements for Guilin | VErsions required are inline with SECCOM recommendations. As the AAF usage (or rather not using it at all) statement seems to collect different points of view, Sylvain proposal was shared with SECCOM distribution list, so we could conclude the discussion at the next SECCOM (on 12th of May). Rephrase proposal: for the purpose of using an alternative solution to AAF, whatever this solution would be. OOM requirements are acceptance criteria for submitted patches and shall be know to the ONAP projects in advance - before Guilin release: for example if patch would require root access to DB - it would be rejected as it would be not compliant with OOM requirement for Guilin release. | |||
| Service mesh and ingress feature | We we speak about an external https - in the future this feature will be used and deployed and feature will be used with ingress that is why we don't want to use https for an external communication for each component we need it. For Kubernetes we just need to deploy ingress feature. And we already have ingress in the source code (it came with F release). For now we are doing SSL redirect , if service support https. It is also a valid deployment option if you do SSL termination at the ingress gateway, not at the component. Internal request - if you use in the future service mesh, we do not want to have double https and mTLS in the same way but only one point to manage certification. In this case sidecar will be managing TLS | |||
| CII Badging requirement | Jira tickets to be created info to be shared with Krzysztof. | Jira tickets to be created info to be shared with Krzysztof. | ||
| Components upgrades | Jiras to be created per each projects | Planned by Amy in incoming days. | ||
| Password removal for PostrgeSQL | Krzysztof submitted patches | Tony to review patches. | ||
| OUR NEXT SECCOM MEETING CALL WILL BE HELD ON 19th OF MAY'20. |