cte-k8s-operator:v1.5.2 is stuck in "queued for security scan" on quay.io/operatorhubio

[ssandur-thales]

I submitted my operator for certification and the PR #5409 was merged.

However, the operator is not updated on operatorhubio-catalog. When I checked, quay.io/operatorhubio, I can see that my operator is stuck in the "Queued for security scan" state for the more than 72 hours now. https://quay.io/repository/operatorhubio/cte-k8s-operator?tab=tags

How do I get it resolved?

[ssandur-thales]

So now I see that my operator cte-k8s-operator:v1.5.2 is available via operatorhubio-catalog on my Kubernetes cluster. It was not updated in the catalog until yesterday. The earlier version v1.4.13 used to show up.

[ssandur-thales]

I filed a ticket with Redhat since they manage quay.io. They asked the following information:

`Can you please provide the following info for further investigation? Thanks.

Quay Registry CRD yaml file

#oc get quayregistry <quayregistry_name> -n  quay-project-name -o yaml > quayregistry.yaml

Quay config file
~~~
#oc exec -it quay-pod-name -- cat /quay-registry/conf/stack/config.yaml > quayconfig.yaml

oc rsh -- cat /conf/stack/config.yaml >> quay-config.yaml

• Config Bundle secret

#oc get secret oc get quayregistry quay-registry-name -o json | jq -r '.spec.configBundleSecret' -o yaml > custom-config-bundle.yaml

• If your quay was deployed in OCP, please provide the inspect data from quay project, please enable the DEBUG and LDAP debug modes following this article[1]

#oc adm inspect ns/quay-project-name

    Can you please also provide the clair config yaml to the case?
`

[Allda]

@ssandur-thales The operator release process that is part of this repository is not related to any Quay scanns. If you have an issue with Quay I would suggest open a support case with Quay team.

In terms of the operator being available in the hub, I am glad that you already see it there. Are you ok with closing the issue now?

[ssandur-thales]

@Allda doesn't the operator release process of this repository use quay.io as a container registry to host the operator images that are packaged by the operatorhubio-catalog on Kubernetes?, I see this in the describe pod output for operatorhubio-catalog pod

`# kubectl describe pod operatorhubio-catalog-mspqp -n olm
Name: operatorhubio-catalog-mspqp
Namespace: olm
Priority: 0
Service Account: operatorhubio-catalog

Controlled By: CatalogSource/operatorhubio-catalog
Containers:
registry-server:
Container ID: containerd://bf3a2e77a760e0263115a5b101cefef4f5e87c39011f590174fa3536024b4d0c
Image: quay.io/operatorhubio/catalog:latest
Image ID: quay.io/operatorhubio/catalog@sha256:2d991f5ba23911505e2d623fc780c157ba1a62b76b15c4483521e6181d54cf20

`

I opened this issue here, so that I can provide information to the Redhat team on any questions asked about the registry. I wold have been in a position to provide the information, if I had used my own instance of quay.io registry to host the operator image.

If this issue is closed now, will it impact future releases?

-Suresh

[ssandur-thales]

@Allda another issue I noticed while checking the Actions on the PR was this failure https://github.com/k8s-operatorhub/community-operators/actions/runs/12261678191/job/34210994913.

Is this in anyway related? What does this "Out of Sync" operator found mean? How do I ensure this does not occur again?