Versions Compared

Old Version 51

changes.mady.by.user cl664y@att.com

Saved on

compared with

New Version 52

changes.mady.by.user cl664y@att.com

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

DurationAgenda ItemRequested byNotes / Links
START RECORDING

Info.yaml

 Linux Foundation

Transfer of "info.yaml" file management at project level, ensuring immediate alignment with the project team composition and Open Source Best practices

<1/21/2019>: PTL agree to take over the ownership of the info.yaml file


Casablanca Maintenance Release

  • Timeline
  • Remaining Open Issues
  • Integration Status
  • Release Note

cl664y@att.com

Yang Xu

Sofia Wallin

Remaining Open Issues: https://lists.onap.org/g/onap-release/message/992

Integration Status: Casablanca Maintenance Release Integration Testing Status

  • 6 Use cases not yet confirmed by the Use Case Owners that they will perform the regression tests - to be followed-up
  • Stability issue on WindRiver (SB00) -Stephen Gooch has been triggered. Update: Stephen confirmed compute node 11 reboots itself every other day and caused the issue, and he takes it out today 01/21/19.
  • Integration Blockers: Casablanca Maintenance Release Integration Test Blocking Issues

Inter-dependency of some components i.e. DMaaP, CCSDK, etc. can generate some problems. PTLs should send a note if they are updating their version in the Manifest. The Manifest is the true source.

Release Note - Target: January 24th, 2019:

  • Please update the Security Vulnerability wiki page if you have updated anything: /wiki/spaces/SV/pages/16090044
  • Request to update the latest Readthedoc and then to cherry pick to Casablanca branch
  • Do an "Append" so the previous Casablanca content is included but add the Casablanca Maintenance Release tag - 3.0.1 and the date: January 31st, 2019

Dublin Release - M1 Preparation

Documentation

cl664y@att.com

Sofia Wallin

Additional M1 Security Checklist Items approved by TSC on 1/17

Deliverables for Planning Milestone Checklist Template

M1 Milestone Review with TSC: January 24th except Integration, January 31st, 2019

Please complete your M1 Release Plan/Checklist/etc no later than January 23rd, End of your Day 

As part of your M1 activities,

Any concern/question for your M1?

Documentation Plan Proposal - please send feedback to Sofia prior the next TSC call (1/31)

Potential Dublin branch target date: RC1? To be reviewed at that time.

minor

DEV reduced deployment footprint

through ReplicaSet: 1

Michael O'Brien

Continue dev.yaml adjustment for ReplicSet: 1

This reduction of 20+ containers is easier - just need a signoff on several PTLs that the remaining clusters actually run with 1 instance enough for dev.

DEV environment deployment footprint reduction by reducing remaining ReplicaSet clusters to 1 from 2/3/5/7 - only in dev.yaml override

OOM-1578 - DEV mode dev.yaml override for all remaining ReplicaSet counts still above 1 In Progress

https://lists.onap.org/g/onap-discuss/topic/running_onap_in_dev_with_all/29018548?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,29018548

medium

K8S Deployment Dependencies - enforcement through conditional (see AAI)

To help deployment

Michael O'Brien

2 S3P points - conditional dependencies and one found by James MacNider when testing appc healthcheck - explicit init container dependencies required by non-atomic healthchecks

(1)

Discussion on state of enforced dependencies - SDNC and AAI are good examples - for SDNC it will not deploy unless dmaap, consul and sdc are pre-deployed, however other projects that have compile-time/injection-time pom.xml dependencies are not reflected.

Some projects have explicit deployments set in their init containers - others do not yet.

Issues:

Enforced dependencies block a module for dev testing unless dependencies are up

For example - everyone needs AAI up - but there are no init containers referencing AAI so any module can deploy without AAI - but functionality will be limited.

Proposal:

Follow - as usual - AAI example - where they put in a conditional on the --set enabled flag - and don't enforce the dependency - not blocking bringing up just a single module. However if the dependency is enabled in dev/values.yaml then the dependency is checked.

https://git.onap.org/oom/tree/kubernetes/aai/charts/aai-traversal/templates/job.yaml#n42

Code Block
themeMidnight
    spec:      initContainers:
        {{ if eq .Values.global.aafEnabled true }}
        - --container-name
        - aaf-locate
        {{ end }}


The deployment profile is useful for module-level deployments, consistent sequential deployments, CD and dev environments

current state

https://lists.onap.org/g/onap-discuss/topic/oom_sdnc_just_deploy_sdnc/28989874?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,28989874

or higher level

LOG-924 - Kubernetes chart dependencies - make all 105 in 87 files conditional - post yaml for cd In Progress

with aboveS3P dependencies and non-atomic health check

Michael O'Brien

James MacNider

non-atomic healthcheck requires init container dependencies

3 flavors (defined, missing, non-hc inherent)

for example SDC will not pass HC unless DMaaP is deployed - this is defined in it's dependency set above

But APPC also needs AAF - this is not defined - a conditional init would not help here - as aaf "must" be up

for the 3rd - most pods need AAI - they do not check that it is up in their HC - and they don't define it in the init container - all fine - but a conditional init would help.



Review of previous action itemscl664y@att.com
  •  Helm Chart Transfer: 4 projects have been identified for trial: Log, Policy, APPC and Clamp. Mike Elliott will work with PTL to gather/transfer knowledge and create training materials. Training to be done the week of Jan 14 and PTL to provide their commitment or not by M1 on Jan 24.
    <1-7/2019>: Work in progress. Schedule might shift to another week. Michael will follow-up with Mike. Training will be open to everybody. The objective is that each team will take over the management of their Helm Charts.

  •  K8S: Ensure labs are updated to relevant K8S version
    <1-7/2019>: Ongoing. K8s 1.11.5; Rancher 2.0 - parameters set in the Heat template to bring the VMs related to K8S. 
    <01/13/2019> From Integration, here are the related versions:

    docker_version:
    type: string
    default: "17.03.2"

    rancher_version:
    type: string
    default: "1.6.25"

    rancher_agent_version:
    type: string
    default: "1.2.11"

    kubectl_version:
    type: string
    default: "1.11.5"

    helm_version:
    type: string
    default: "2.9.1"


    k8s scripts here https://git.onap.org/integration/tree/deployment/heat/onap-oom
    and secondary here https://git.onap.org/logging-analytics/tree/deploy  - under https://jira.onap.org/browse/OOM-1496
    https://wiki.onap.org/display/DW/Security+Space+Wiki+Access+List
  •  Oom values.yaml or integration repo manifest ( TSC-86 - Lock down docker image tag name source of truth - oom values.yaml or integration repo manifest - A: both but manifest is the source Submitted )

    if not covered - see TSC 2019-01-10

    Quick discussion on nailing down whether we need a yaml override of the deployable

    docker image tags in the oom repo (understanding is no) - with the integration docker manifest

    (manifest is currently a copy of the oom values.yaml tags - not the reverse)

    If not - then we need a documented procedure wiki/RTD on running a derived values.yaml override for the entire system before deployment

    AAF is only an example here

    https://git.onap.org/oom/tree/kubernetes/aaf/charts/aaf-service/values.yaml?h=casablanca#n28

    image: onap/aaf/aaf_service:2.1.8

    drives

    https://git.onap.org/integration/tree/version-manifest/src/main/resources/docker-manifest.csv?h=casablanca#n11

    onap/aaf/aaf_service,2.1.8

    <1-7/2019> Integration team to document the procedure.

    <01/13/2019> Answer from Integration team: docker manifest under integration repo is the source of truth, and is used by Integration team to override OOM values.yaml when deploying ONAP in Openlab. See the instructions at the bottom of page https://onap.readthedocs.io/en/casablanca/submodules/integration.git/docs/onap-oom-heat.html#onap-oom-heat-template
    <1-21/2019> Procedure should include Timers, dependencies, etc.
    just need to define all the --set and -f overrides like the following
    sudo helm deploy onap local/onap --namespace $ENVIRON -f $DISABLE_CHARTS_YAML  -f $DEV0_YAML $APPENDABLE_ENABLED_FLAGS --verbose

  •  WindRiver Lab Management - Please provide feedback to Stephen Gooch no later than January 31st, 2019 if you need to keep your tenant space, VMs: user-usage.txt

Any Help-desk ticket in the queue?


Unreleased images will only be kept in Nexus3 for 25 days. 


Recommendation/Requirement of the RESTful implementation - does ONAP require Spring Framework? Or does it just recommend Spring Framework version via oparent?Pamela Dragosh

I would like PTL input here because if using SpringFramework is required, then let's have PTL's vote on this as they are the ones implementing it. Also, as with oparent, the requirement to upgrade/change to SpringFramework in some current projects may have development costs. Do we grandfather those in?

<1/21/2019>: Need to follow-up with LF if any preference (licensing)

Springboot preferred by PTLs? AAI, LOG, CCSDK, SO, Policy, etc. – need to align the version via oparent

1.5 will not be supported after August, so the target for us is 2.x in Dublin

Spring Boot supports an embedded launch script that can be used to easily run the application as a systemd or init.d linux service. The script included with Spring Boot 1.5.9 and earlier and 2.0.0.M1 through 2.0.0.M7 is susceptible to a symlink attack which allows the "run_user" to overwrite and take ownership of any file on the same system. In order to instigate the attack, the application must be installed as a service and the "run_user" requires shell access to the server. Spring Boot application that are not installed as a service, or are not using the embedded launch script are not susceptible.


...

Action Items:

  •  

    PTLs will take over the ownership of the info.yaml file

  •  Casablanca Maintenance Release

...