Please find below the Minutes of Meetings and recording for the SECCOM meeting that was held on 5th of May 2020.
| Jira No | Summary | Description | Status | Solution |
|---|---|---|---|---|
New Notary v2 project - address container image signing | Tero shared a week ago info about this new project. Notary v2 use cases: https://github.com/notaryproject/requirements/blob/master/scenarios.md Dedicated SECCOM meetings around this topic (requirements and features) could be organized if only we have a core team to work on it and ONAP contributions to Notary v2. We should look on how ONAP would use Notary v2, especially in CNF context, like onboarding. | WE take some extra time to analyse and consider if we could contribute. | ||
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 12th OF MAY'20. |
