Closed sabrina-yee closed 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.
@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
@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:
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.
I appreciate the feedback @DMW007 and will bring it back to the team to improve this matter.
@nitinjagjivan please review, thanks!