Release of new versions.

[AndriMar]

Hello,
I have a question regarding the release pipeline and how the versions are bumped.
I was using the 7.4.0 version and notice a bug that I reported and really happy about how quick that was fixed.

I notice you have a Release branch Release-7.4 and after the initial release, changes keep on coming in which is fine but the patch number is not bumped in dockerhub and 7.4.0 images is overwritten.

I was expecting to need to change the deployment of X-Rode and point to the 7.4.1 image.

This is not affecting me that much because I want to keep my images in a private ECR but for those that are pulling directly from dockerhub, this could have big implications getting unwanted patches when container goes down and comes back up.

Is this an oversight or some other reason the patch number is not bumped?

[petkivim]

Hi @AndriMar,

The patch number is bumped when there's a change in the X-Road application code and a new version of the X-Road application is released. In this case, the bug was in the Security Server Docker image and not in the application code. Therefore, the Docker image was updated without making changes to the application code and therefore, the version number wasn't updated.

Also, monthly security updates to image are provided without bumping the version number. The updates are released monthly on the 25th, with additional releases for critical vulnerabilities. The updates include the latest base image with up-to-date packages and security fixes. There are no changes to X-Road Security Server software and its packages inside.

[bensi94]

Hi @petkivim,

I just want to weigh in and give my personal opinion on this matter.
I think you should really reconsider this decision it could have serious implications on production systems. It's very often the case that Docker images are used directly from Docker Hub and developers and system admins trust that the tags from trusted entities do not change. You have to note that with container images your software is not only your application code it includes the Docker images, and it should be really important that tagged images are not changed.

[petkivim]

@bensi94 Thank you for your feedback and sharing the insights!

The challenge with the current version numbering is that it's the X-Road application version number and the same number is used on all the supported platforms (Docker, Ubuntu, RHEL). Therefore, the version number must be aligned between the platforms and it cannot be increased for one platform only. One potential solution is to introduce an additional Docker image version number that's used in the tags, e.g., niis/xroad-security-server-sidecar:7.4.0-0, niis/xroad-security-server-sidecar:7.4.0-1, niis/xroad-security-server-sidecar:7.4.0-0-slim, niis/xroad-security-server-sidecar:7.4.0-1-slim, etc. We'll consider this in the future.

[AndriMar]

That sounds like a solution. 👍

For example we had a custom CMD command to fix this in the earlier version, later we deployed this at a customers infrastructure and had no idea that we did not need this because the fix was already deployed.
Like @bensi94 mention, we need to know what we have running in production.

Thank you for you time and answers and hope to see immutable docker tags in the coming future 🙂