The first one is the result of running sync-manifest.sh and finding someone else deliver stuff prior to me but did not run synced manifests.
The second one corresponds to the update of the PM version that now sorts the issues with DB2 that prevented a successful installation of PM in ROKS. Main changes are:
PM instance version from 12.0.0.3 to 12.0.0.4
IAF Core Operator from version 1.2 to 1.3
Their respective catalog versions so that those latests versions are available to install. IMPORTANT: I have updated the common services catalog to use the docker image in the official IBM repo --> icr.io as opposed to the dockerhub version. I guess this will have an impact on everyone's work as we're pulling from Common Services from a different location but the Common Services being installed should be the same.
On the catalogs, @csantanapr and @hollisc, I would also like to make another comment. I believe we need to do some refactoring to the catalogs and clean them up to only use the main IBM Operator Catalog:
As all catalogs should be delivered to this main IBM Catalog in the same manner all IBM Software docker images should be delivered to icr.io. Hence, we should not be defining specific tailored versions of certain catalogs. This is something that some products sneakily recommend and document in KC since I guess they have tested and GA'ed their products with specific versions of the IAF or DB2 catalogs. But this ties with the conversation that @csantanapr brought up the other day in the standup. New versions of the catalogs, at least not major-world-changing versions, should be backwards compatible. That is, if PM in this case tested his 12.0.0.4 version of their product with the DB2 version being shipped in the DB2 catalog version x.y.z, that same PM version should work with the DB2 catalog version latest. That is, the latest versions of each catalog should be backwards compatible in the sense that PM can rely on the latest version of catalogs to be able to deploy whatever specific version of DB2 it needs. At least for minor version updates very much like the newer version of the PM Operator still allows you to deploy older PM versions such as 12.0.0.3.
Not sure I explained well my point here but happy to discuss it on Webex and start to tackle these version updates, dependencies, etc so that we can drive development towards not requiring specific pinned versions of anything as that would break installing different capabilities in a cluster.
jesusmah
commented
2 years ago
There are two commits here.
The first one is the result of running
sync-manifest.shand finding someone else deliver stuff prior to me but did not run synced manifests.The second one corresponds to the update of the PM version that now sorts the issues with DB2 that prevented a successful installation of PM in ROKS. Main changes are:
12.0.0.3to12.0.0.41.2to1.3icr.ioas opposed to thedockerhubversion. I guess this will have an impact on everyone's work as we're pulling from Common Services from a different location but the Common Services being installed should be the same.On the catalogs, @csantanapr and @hollisc, I would also like to make another comment. I believe we need to do some refactoring to the catalogs and clean them up to only use the main IBM Operator Catalog:
As all catalogs should be delivered to this main IBM Catalog in the same manner all IBM Software docker images should be delivered to
icr.io. Hence, we should not be defining specific tailored versions of certain catalogs. This is something that some products sneakily recommend and document in KC since I guess they have tested and GA'ed their products with specific versions of the IAF or DB2 catalogs. But this ties with the conversation that @csantanapr brought up the other day in the standup. New versions of the catalogs, at least not major-world-changing versions, should be backwards compatible. That is, if PM in this case tested his12.0.0.4version of their product with the DB2 version being shipped in the DB2 catalog versionx.y.z, that same PM version should work with the DB2 catalog versionlatest. That is, the latest versions of each catalog should be backwards compatible in the sense that PM can rely on thelatestversion of catalogs to be able to deploy whatever specific version of DB2 it needs. At least for minor version updates very much like the newer version of the PM Operator still allows you to deploy older PM versions such as12.0.0.3.Not sure I explained well my point here but happy to discuss it on Webex and start to tackle these version updates, dependencies, etc so that we can drive development towards not requiring specific pinned versions of anything as that would break installing different capabilities in a cluster.