Description of problem: Are the Docker certified operator index versions correct? ie v4.5 > v4.6 > v4.7 are not increasing against the git checkins (may be my misunderstanding): skopeo inspect docker://registry.redhat.io/redhat/certified-operator-index:vXXX: registry.redhat.io/redhat/certified-operator-index:v4.5: "BUILD_VERSION=v4.5.0", "KUBE_GIT_VERSION=v1.13.0+bc4c9f8", "SOURCE_GIT_TAG=v1.12.5-17-gbc4c9f8f", registry.redhat.io/redhat/certified-operator-index:v4.6: "BUILD_VERSION=v4.6.0", "SOURCE_GIT_TAG=v1.14.3-34-gd0b49148", registry.redhat.io/redhat/certified-operator-index:v4.7: "BUILD_VERSION=v4.5.0", "KUBE_GIT_VERSION=v1.13.0+bc4c9f8", "SOURCE_GIT_TAG=v1.12.5-17-gbc4c9f8f", Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Continuing problems trying to get all images for TrilioVault operator; may be related?
This should be assigned to ISV Operators
Has something changed? ie, I repeated above command and am not getting same result, v4.7 tags look better: $ for i in 4.5 4.6 4.7;do echo -e "\nregistry.redhat.io/redhat/certified-operator-index:v$i:";sudo skopeo inspect docker://registry.redhat.io/redhat/certified-operator-index:v$i%7Cjq '.Env'|grep "=v" ;done; registry.redhat.io/redhat/certified-operator-index:v4.5: "BUILD_VERSION=v4.5.0", "KUBE_GIT_VERSION=v1.13.0+bc4c9f8", "SOURCE_GIT_TAG=v1.12.5-17-gbc4c9f8f", registry.redhat.io/redhat/certified-operator-index:v4.6: "BUILD_VERSION=v4.6.0", "SOURCE_GIT_TAG=v1.14.3-34-gd0b49148", registry.redhat.io/redhat/certified-operator-index:v4.7: "BUILD_VERSION=v4.7.0", "SOURCE_GIT_TAG=v1.15.4-6-ga97d366a", regs,
Hi Damon, The indexes are in a constant state of flux. They're rebuilt repeatedly throughout the day, according to the build job queue from the IIB (Index Image Builder) service which is used internally. This service is called whenever a partner publishes a bundle image to the index, and the respective index image is then rebuilt to include the net-new operator bundle. Note that there is a certified-operators index and a redhat-marketplace index for each OCP version from 4.5 onwards. What you're seeing with the BUILD_VERSION changing is likely just a difference with the API calls being made to IIB. I believe some calls (manual publishing calls, especially) have an operator-registry base or "binary" image hard coded to v4.5.0 (thus you're noticing the build set explicitly in some cases). The base image doesn't matter too much, from what I understand and the IIB maintainers had recently made the "binary_image" parameter optional when making a call to the service. If the opm it's unset it will default to the version of the OCP release that the index image is being built for. What you're seeing is not a bug, as these index images are in an ever-changing state. IIB works in a sequential FIFO type of queue, where it does one operation at a time on a single index (ex: add "example-operator-bundle:v1.0.1 to the certified-operators index for OCP v4.5).
Just a quick correction: "If the opm it's unset" should read "If the parameter is unset".