search

HCL-TECH-SOFTWARE / connections-automation

Deployment and upgrade automation scripts for HCL Connections 7.0 based on Ansible
Apache License 2.0
17 stars 31 forks source link

Set K8s default to 1.21.7 #190

Closed sabrina-yee closed 2 years ago

sabrina-yee commented 2 years ago

@nitinjagjivan please review, thanks!

DMW007 commented 2 years ago

Hello,

this merge means that k8s 1.21 is supported now? I'm asking because the documentation still says that the component pack was tested against 1.19, which is already end of life since a few months.

The documentation for the CNX 6.5 CP is even more confusing, it says:

As of HCL Connections version 6.5.0.1, deployments to the latest stable Kubernetes platform (version 1.17) are supported, and that is the version where all development and testing is happening at HCL. However, HCL tested its deployment all the way from Kubernetes 1.11.9 to 1.18.2, and is continuing to test it against any new Kubernetes release.

Having support for the latest stable k8s release would be perfect, but this is currently 1.23! The mentioned 1.17 is very old and EOL since a certain amount of time.

sabrina-yee commented 2 years ago

@DMW007 thanks for the feedback, the default is updated to enable installing K8s 1.21.7 using this repo. Please use the product documentation as the official support statement. Sorry for the confusion.
The version can be overridden using the kubernetes_version var as set in https://github.com/HCL-TECH-SOFTWARE/connections-automation/blob/main/environments/examples/cnx6/db2/group_vars/all.yml#L111

DMW007 commented 2 years ago

@sabrina-yee Thank you for your reply. Using the documentation leads still to the issue that it says the"latest stable Kubernetes platform" is supported, but then mentions a very old release (1.17). So which of them is supported: The latest stable version, which would mean I can use 1.23 at the time of writing? Or 1.17 for 6.5 and 1.19 for 7.0? If the answer is 1.17/1.19 we've another big issue: Both are end of life for some time, which is clearly against the basic best practice of secure environments.

Furthermore, the same documentation page for CNX 7 says:

Starting with version 7, HCL Software is providing Ansible automation tested in house as a preferred way of setting up Component Pack and its dependencies.

I don't want to blame Ansible or this repo. It's a nice tool I'm using for years with and without CNX, but as a user/customer I see various ways how to interpret the requirements, some leading into security issues. I'm aware of the fact that you're maybe not maintaining the CNX docs, but imho this is a big issue: It should be clear what requirements are needed to install the software, and those requirements should be supported if they're from third-party vendors like k8s. So please forward those issues to the responsible persons from HLC, so that they can find a reliable way to resolve them.

In concrete terms, my suggestions are:

  1. The component pack should support at least Kubernetes 1.21, better 1.22 or 1.23. In case of 1.21 there should be a plan when newer versions are tested, and this should be not too far away on the timeline: 1.21 EOL is on 2022-06-28 and customers/admins need some time to upgrade, so the support should be there some time before this date.
  2. We need consistent documentation. According to the docs, you're using this Ansible project inhouse and it's the recommended way for installing. So there should be someone responsible for keeping things up to date. It would make sense for this person to setup a timeline for updates. If you're testing those updates, they work and you're releasing them, they should be consistent on both of the documentation and Ansible. It's good that you've updated the EOL 1.19 version here, but from a customer view, I'd expect that this repo contains the latest supported versions per default, without the need that I need to check the repo against the docs.
  3. This should be extended to ALL used components. You mentioned the example vars file, which refers to helm 2.16.3. It was released nearly 2 years ago and the complete helm v2 branch is EOL since november 2020, where also the CNX 6.5 docs still refers to helm 2.

Is there an update strategy for third-party dependencies? The log4j security hole "log4shell" is an recent example with huge impact what can be the worst case if dependencies are not kept up2date regularly. Also the migration is much more work when it hasn't been done for a certain amount of time.

sabrina-yee commented 2 years ago

I appreciate the feedback @DMW007 and will bring it back to the team to improve this matter.