"Internal" plan

By Order of priority

Passwords

Continue the removal of harcoded credentials, in this (proposed) order:

  • PostgreSQL
  •  Cassandra
    • As long as we're able to set an admin user → maybe need to find a new image → not simple (sad)
  • DMaaP (tentative)
  • AAI (tentative)
  • SDC (tentative)
  • SO (tentative)

Certificates

Start the certificates hunting and (try to) uses "aaf init" template.

Fyi, current "known" hardcoded certificates: https://github.com/onap/oom/blob/master/docs/oom_hardcoded_certificates.rst

Upgrade

let's work to have "ONAP Core" (AAF, AAI, SDC, SDNC, SO, DMaaP) fully upgradable from F to G (with their databases components, cassandra, mariadb, ...).

Current status is AAI and SO already there, SDN-C should be good for F release.

Allow choice of subcomponents during "big" components installation

Today, we can select what we want for deployment on DMaaP, AAI and soon contrib.

let's add the same for SDC, SO, Multicloud, SDNC, APPC, VFC, Policy and maybe other.

Should be "simple".

Follow version proposed by SECCOM

SECCOM Version Board

Kubernetes 1.18

Reuse all our templates to make ONAP 1.16+ (and then 1.18) compatible (can be long)

Mariadb upgrade

Move to 10.2+ (change base image, can be long)

PostgreSQL upgrade

Move to 12.2, should be "simple"

Cassandra upgrade

Move to 3.11.6, should be "simple"

External plan (A.K.A expectations from other projects)

  • All logs to STDOUT
  • Certificates
  • Crash when Issue (and not "wait for I don't know" or exit with status 0)

  • AAF integration must be settable to off

  •  MSB integration must be settable to off

  • Well formatted commit messages --> with format:
    • title: [NAME_OF_COMPONENT|DOC|GENERIC] Real Title
    • blank line
    • at least one sentence explaining the change done in this patch, cause and consequences and possibly more of course
    • blank line
    • Issue-ID, Change-ID, Signatures, ...

Tentative / PoC

  • Make Ingress default deployment
  • Make Deployment with storage class default deployment
  • check storage asked for PVC is consistent with actual deployments
  • Service Mesh PoC continuation
  • All pods have requests/limits
  • request/limits bad values hunting


  • No labels

5 Comments

  1. Andreas Geissler

    Here some points:

    • Is MSB obsolete, when using Ingress?
      If yes, MSB dependencies have to be removed
    • Is Logging component obsolete or should all components be forced the right configurations (filebeat.yaml,...) ?
    • What's about AAF, when changing to Service Mesh ?

  2. Sylvain Desbureaux

    MSB has no value add when on Kubernetes, so we can propose to make it "optional"

    For logging, I believe centralised logging is very important but I need hand and brains to tackle (wink)

    Service Mesh (when we'll manage to make it work) will only work without AAF

  3. Andreas Geissler

    • Regarding logging we have a project with TechMahindra ongoing regarding central logging. 
      We have an overview about the current logging support in the projects.
      They currently support the projects (SO,?) to enable logging.
      I will keep you informed....
    • MSB as option would be good... 
    • One thing came to my mind is the future of consul, which could be discussed

       

  4. Sebastien Premont-Tendland

    For centralized logging we should really consider the option that all components simply log to STDOUT and then let the operator use any external tools to consume kubernetes logs. This is much easier to handle as you don't need to have a filebeat sidecar container on every components and it's also the "cloud native" way of handling logging.

    1. Andreas Geissler

      Understood, thanks for the clarification.
      So it would be good to have kind of "Developer Guidelines" for all ONAP projects to fulfill these kind of requirements
      Like:

      • Security guides (Interface security, password, certificate,...)
      • API design guidelines (as already in planning Proposed OpenAPI 2.0 / Swagger Style Guide)
      • Logging guides
      • Interface registration (MSB, Ingress)
      • Monitoring and healthcheck
      • Component version handling (update,...)