IKO & The Compatibility Version Gotcha

With the world (as well as our own technology) moving to the cloud at such a fast pace it is easy (at least for myself) to get caught up in the little details. One thing I, and some clients of ours, had run into a couple of times was the necessity to specify the version of the images one plans to use with the IKO.

For example, one issue that often gets overlooked is the compatibilityVersion field for the IKO. Depending on which IKO you are using there is a default value (for IKO 3.6 this happens to be 2023.2.0, and for IKO 3.5 this is 2022.3.0). If you intend to use a different version of an IRIS container you must specify this. Otherwise, you may run into errors such as the following one:

log: 07/01/23-18:39:58:652 (769) 3 [Utility.Event] Invalid parameter name 'ArbiterURL', LINE:'ArbiterURL=webinar-arbiter-0.iris-svc.default.svc.cluster.local:2188' at line 39

Note that this is level 3 – fatal. The pod could not even get started! This client had their IRIS pod in a CrashLoopBackOff status as they had been using IKO 3.5 on a 2023 IRIS version and not specified the compatibilityVersion, thus the IKO took the default value which was inherently older.

Why is the error relating to ArbiterURL you ask? Great question!

A slight change in how IRIS expects configurations occurred between 2022 and 2023. Many parameters that used to appear in the [Startup] section of the CPF are now placed under the ConfigMirror action parameter, for example ArbiterURL.

And how does this relate to our problem, exactly?

With no IRIS version explicitly specified, the IKO assumes the default - which in this case meant setting up the CPF file to an older standard that was not suited to the IRIS version the client was attempting to run. The IKO creates the CPF such that the ArbiterURL appears in the aforementioned [Startup] section. The newer IRIS version sees this and does not recognize it as the ArbiterURL parameter is only supposed to appear under ConfigMirror. It therefore logs it as an invalid parameter name, and since the configuration is critical to the IRIS setup the process fails, as does the pod.

Just a small miscommunication in something like this can deal a critical blow to your setup. Therefore it is good practice to always specify the compatibilityVersion, regardless of what version you are using. But of course, take note that not all IKOs are compatible with all versions of IRIS.

Speaking of containers, note that we have recently changed how we tag and distribute them in order to improve your experience. Have a look here for more info.