Done
Details
Assignee
Former userFormer user(Deactivated)Reporter
Former userFormer user(Deactivated)Fix versions
Priority
Medium
Details
Details
Assignee
Former user
Former user(Deactivated)Reporter
Former user
Former user(Deactivated)Fix versions
Priority
Created November 7, 2018 at 3:42 PM
Updated August 12, 2023 at 3:48 AM
Resolved April 10, 2019 at 1:59 AM
filling out shortly - talking with first
issue: any change to the rancher, kubernetes, kubectl, docker versions should be managed, curated, tested, staged and communicated to the 6 other installs and the community - for alignment
Details 20181109
Rancher 1.6.18 to 1.6.22 – upgrades Kubernetes from 1.10.3 to 1.11.2
This fix was required from what i understand was a clustering issue - it fixes it - and we require it
We are currently aligning read the docs, the TSC-25 CD script, the other integration and logging scripts with
https://gerrit.onap.org/r/#/c/71375/1
via
OOM-1496
btw new versions run well - https://wiki.onap.org/display/DW/Cloud+Native+Deployment#CloudNativeDeployment-Example15node(1master+14nodes)OOMDeployment
For Dublin
As you know – Rancher 1.6 is our reference implementation across the teams (there are other installs like kubeadm) – there are at least 5 separate installation scripts across 3-4 repos (integration, azure, logging-aws/azure/rancher, msb, vagrant that are kept in sync with the version numbers – including a 6th – the CD work coming in via the LF under TSC-25. Upgrading the RI should be managed with the rest of affected parties in the loop and communicated with an upgrade path to onap-discuss. The integration build has a special status here - in that it runs the onapci daily build and healthcheck - which all other teams must align with. We could run 2 clusters where one is a staging system known only to integration where they can test out new k8s versions - then move these changes to production along with the community when verified.
The traditional procedure we did in the past for 1.6.14 and 1.6.18 early in the release was to curate the upgrade, determine what is fixed/required, document it, test it and communication to the ONAP team via an Epic and onap-discuss discussion. See the past upgrade around July
https://lf-onap.atlassian.net/browse/OOM-1299
dups https://lf-onap.atlassian.net/browse/OOM-1141
dups https://lf-onap.atlassian.net/browse/OOM-1133
At the time we also did a helm 2.9.1 upgrade from 2.8.2 to solve some issues and raised jiras for project affected to mirror the change
https://lf-onap.atlassian.net/browse/MSB-278
Essentially – if a rancher/kubernetes/helm upgrade is required as part of a larger change – break out the jira into a separate issue so we can track it.
20181109 with Gary, Gildas, Jessica in the CD meet at 1000 EST
we are ok with the current version - works well - we will just send out a mail pointing to the update read the docs shortly
just to notify other users to upgrade so they are aligned with the latest used by onapci.org and the healthchecks - in addition to clustered behaviour fixes
next version 1.6.23 fixes an internal jetty CVE - https://www.eclipse.org/jetty/documentation/9.4.x/security-reports.html
https://forums.rancher.com/t/rancher-release-v1-6-23/11991
https://github.com/rancher/rancher/issues/14554