Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 51 Next »

PTL RecordingsZoom Chat Log

Duration 60 minutes

Zoom Bridge https://zoom.us/j/283628617

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

    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

Zoom Chat Log 


09:01:31 From Michael O'Brien(LOG,Amdocs) : change your repo hame in https://git.onap.org/logging-analytics/tree/INFO.yaml
09:02:52 From Michael O'Brien(LOG,Amdocs) : add using a template from above https://git.onap.org/integration/tree/INFO.yaml
09:09:40 From Michael O'Brien(LOG,Amdocs) : part of https://jira.onap.org/browse/OOM-1053
09:09:46 From Michael O'Brien(LOG,Amdocs) : for AAI-2090
09:10:15 From Michael O'Brien(LOG,Amdocs) : same as issue in POMBA
09:11:19 From Keong Lim k00759777 : does OOM-1053 also include AAI-2091?
09:12:06 From Michael O'Brien(LOG,Amdocs) : https://gerrit.onap.org/r/#/c/75910/1
09:12:50 From Michael O'Brien(LOG,Amdocs) : data-router went in on 18th jan
09:14:59 From Yang Xu : https://wiki.onap.org/display/DW/Casablanca+Maintenance+Release+Integration+Testing+Status
09:19:52 From Michael O'Brien(LOG,Amdocs) : like this line
09:19:53 From Michael O'Brien(LOG,Amdocs) : sudo helm deploy onap local/onap --namespace $ENVIRON -f $DISABLE_CHARTS_YAML -f $DEV0_YAML $APPENDABLE_ENABLED_FLAGS --verbose
09:29:49 From ALLAGO : Hi Yang,
09:29:59 From ALLAGO : I tied to approach you several times by emails
09:30:02 From ALLAGO : 3 times I think
09:30:12 From ALLAGO : You didn't provide any response during the whole last week
09:30:25 From ALLAGO : It is CRITICAL FOR USECASE SUBCOMMITEE WORK
09:30:40 From ALLAGO : WE NEEDED TO KNOW WHETHER YOU AND YOUR TEAM WILL BE ABLE TO ATTEND THIS AND NEXT WEEK MEETYINGS
09:30:59 From ALLAGO : Yang, please respond
09:32:11 From Yang Xu : Previously use case subcommittee meeting was on Monday, and I had conflict
09:32:19 From Yang Xu : now is it moved to Friday?
09:32:19 From ALLAGO : it is on MOndays
09:32:24 From ALLAGO : you could at least reply
09:32:35 From ALLAGO : I sent emasil 3 times begging for your reply
09:32:42 From ALLAGO : it is still on Mondays
09:32:53 From Yang Xu : sorry, it may be filtered to different folder I didn’t see
09:33:01 From ALLAGO : OK
09:33:14 From ALLAGO : so, is it possible for you and your team to attend
09:33:17 From ALLAGO : next hour meeting
09:33:30 From Michael O'Brien(LOG,Amdocs) : https://wiki.onap.org/display/SV/Casablanca+Maintenance+Release
09:33:31 From Michael O'Brien(LOG,Amdocs) : will do
09:33:37 From ALLAGO : we needed to understand integration team resources/work plan for each requirement/use case
09:34:14 From ALLAGO : please reply, I REALLY need to know
09:35:40 From ALLAGO : Yang, please reply
09:35:42 From Yang Xu : Allago, I think new use case usually need to find its test resource for their use cases, and report to integration team. I will join today
09:35:54 From ALLAGO : OK, thank you!
09:36:01 From ALLAGO : let's discuss it during the call today
09:36:14 From ALLAGO : what exactly needed and what is status per each requirement/use case
09:36:18 From ALLAGO : Thanks!!!
09:39:37 From Yang Xu : Allago, did you send to yang.xu3@huawei.com? I search my email and don’t see any email from you
09:44:34 From Michael O'Brien(LOG,Amdocs) : logging/pomba project - I will definitely be there for the fully day (barring any critical meeting overlap) - In the capacity of validating/running anything we write up on running systems
09:49:44 From Brian : is someone from SDC on ?
09:50:15 From Brian : how do we restart SDC-BE to have it recheck its DMaaP interface ?
09:50:26 From Brian : DMaaP: None on HC but DMaaP is up for write/read
09:55:35 From Brian : https://onap.readthedocs.io/en/casablanca/submodules/integration.git/docs/index.html?highlight=docker%20manifest%20csv
09:56:59 From Michael O'Brien(LOG,Amdocs) : log has been using JAX-RS via jersey but a more streamlined spring-boot would be the way to go - my opinion
09:57:56 From Brian : SO uses springboot as well
09:58:06 From Michael O'Brien(LOG,Amdocs) : logging=jax-rs-2.0, pomba using spring-boot
09:59:21 From Michael O'Brien(LOG,Amdocs) : +1 Pamela's spring-boot (log was looking at 2.0 like Jimmy states
09:59:54 From Brian : so-container/pom.xml: <springboot.version>1.5.13.RELEASE</springboot.version>
10:00:40 From Amy Zwarico : 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.
10:00:56 From Jimmy Forsyth (AT&T) : We are using 1.5.18 in Casablanca Maintenance Release
10:01:10 From Jimmy Forsyth (AT&T) : Anything older than that has a lot of nexusiq vulnerabilities
10:01:23 From Michael O'Brien(LOG,Amdocs) : pomba using spring-boot 1.5.17
10:01:42 From Dan Timoney : I think spring boot 1.5 is based on spring 4, and spring boot version 2.x is based on spring 5
10:01:54 From Matthieu Geerebaert - EXTAPI - Orange : On EXTAPI we planned to try to upgrade to spring boot 2.x
10:02:04 From Jimmy Forsyth (AT&T) : 1.5 will not be supported after August, so the target for us is 2.x
10:02:14 From Jimmy Forsyth (AT&T) : In Dublin
10:02:51 From Matthieu Geerebaert - EXTAPI - Orange : ( and using spring mvc with jackson on APIs )
10:02:59 From Jimmy Forsyth (AT&T) : the audio is dropping out on the bridge

  • No labels