On all the docker containers, we set the FIXPACKS environment variable on each container (app) to a space separated list of fixpack names to load (per documentation).  In the past, we have only used the configuration container and not a snapshot manager.  Hence, we just put those fixpacks under /var/shared/fixpacks on the config container.

Now that we are using snapshot managers instead of a central config container, I have found we need to put the fixpacks on the snapshot managers under the fixpacks directory.  However, I believe from my previous testing pushing the fixpacks has to be manually done to each snapshot manager.

Is there a way to make the configuration container push the fixpacks to all the snapshot managers, say when publishing the latest configuration (snapshot)?  Or is the process for fixpacks to always have to put the fixpacks on each snapshot manager manually?

Thanks!

@Scott Exton Thanks for confirming.  I just wrote a quick shell script I can run from the configuration container to use it's list of snapshot managers and credentials and sync the fixpacks across all the snapshot managers.

One additional question, I noticed the DELETE method does not work against the snapshot manager.  However, the operator documentation seems to indicate it should work.  I don't see a DELETE method defined for the Python http server that is used for the snapshot manager.

Is this something that can be corrected?  Should I open an L2 support case, or an RFE?  Thanks!

10.125.132.100 - - [03/Oct/2023 21:04:24] "DELETE /fixpacks/IJ45492_10050v2.fixpack HTTP/1.1" 501 -
10.125.132.100 - - [03/Oct/2023 21:04:24] code 501, message Unsupported method ('DELETE')

Reference:

https://github.com/IBM-Security/verify-access-operator/blob/master/README.md#delete

@Scott Exton you are correct, I was referring to the standalone manager.  I had assumed the code base would be similar but apparently not.  I'll open an RFE/idea for it.  The idea # is ISAM-I-1250.

I'd like to get to the point of using the operator.  However, we have some challenges internally here that make it difficult to load anything onto our OpenShift infrastructure.  The IAM team doesn't maintain any sort of admin access on the OpenShift environments we run on top of, so it makes it time consuming to get anything outside of the standard OCP installation going.

------------------------------
Matt Jenkins
------------------------------