Upgrade external container dependencies (Mongo & Keycloak)

[Backdraft2100]

Reason/Context

Some containers not managed by Microcks are outdated and should be kept up to date more often.

Description

For the default installation there are 2 containers that require action.

1. centos/mongodb-36-centos7
   This image is no longer maintained since 3 years. Can it no be replaced by a proper supported version or perhaps even other storage rethinkdb, CouchDb ...
2. quay.io/keycloak/keycloak:22.0.3 This version has a reported security vulnerability see here.

Implementation ideas

No response

[lbroudoux]

Thanks for raising this issue.
It's true that MongoDB is a bit old and we'd probably better include a fresher one 😉

That said, the MongoDB image - as well as the Helm Chart or Operator related part - provided by Microcks are there for commodity purpose only. Our take is that you shouldn't rely on them for crucial "production" workload but rather use an external component. You can override the default image OR completely disable MongoDB installation in our chart or Operator.

We're focused on embedding the freshest MongoDB driver possible in the microcks image (with less CVE as possible) but the database itself is an external component. As a project, we can't - and we think this out of our scope - guarantee operational excellence at the level of commercial providers or community projects that are
focused on that goal.

But definitely looking to update the image ;-)

[lbroudoux]

What version of MongoDB would you like to see in Microcks? And - above all - what kind of upgrade process you'd like to see in the near future:

• Upgrade to the latest (6.x?) and let the user handle the upgrade issues?
• Upgrade to closest (4.4.29) with less CVE and less risk of breaking upgrade?
• Apply a systematic upgrade at each and every release or try to do the less upgrades possible?

The next Microcks release will be a minor one (1.9.1), do you feel it's ok to have this upgrade embedded into it? Or should we plan it for a future 1.10?

I'd really love to have community opinions on those questions!

[Backdraft2100]

Hi a more recent version is definitely important. It will for sure gives a better first impression on the tool.
Mongo requires step-by-step upgrades. That means you can't go straight from 3.6.23 to 6 e.g. Following instructions from mongodb the proper path would be incremental upgrades 3.6.23 -> .. -> .. -> .. -> 6.0 and so on.
From microcks point of view I guess a breaking change would be an acceptable way forward. And from then on keep the backing dependencies up to date. Trying to incrementally upgrade is probably not going to work for all installations out there anyways. How microcks is used/installed not the responsibility of this project. It's always possible someone decides to override and stick with an older version.
I guess advice on how to upgrade the breaking change would be appropriate and appreciated by the community.

[lbroudoux]

I've just run some tests, trying to upgrade an existing Microcks install using MongoDB 3.6 to MongoDB 4.4.29, and the upgrade cannot be an in place replacement ... The data files cannot be re-used directly by the new engine version, and a dump-restore procedure must be absolutely done before.

So I wonder if doing an upgrade in 1.9.1 version (that is supposed to be a minor with no major change) is really a good idea. What do you think?

[Backdraft2100]

Hi, I wouldn't introduce a breaking change for minor upgrade.
Guess this requires a major version upgrade as breaking changes are expected.

[lbroudoux]

I think we're aligned. Planning this upgrade for the next 1.10.