gansheer commented on issue #4569:
URL: https://github.com/apache/camel-k/issues/4569#issuecomment-1641774580
The openshift image registry is composed of multiple custom ressources. Some
of them are namespaced - those we use are `ImageStream` and `ImageStreamTag`,
some are not namespaced - like `Image`.
`Image` resource is clearly not meant to be modified easily:
- there is no notion of image tag in its datas so there is no way to know if
any `camel-k-runtime-quarkus-builder` image is the right one
```
dockerImageMetadataVersion: "1.0"
dockerImageReference:
image-registry.openshift-image-registry.svc:5000/default/camel-k-runtime-quarkus-builder@sha256:873a5580b0ffed32321e7020da4ae6906d9046dc713f3a9019987393284bf868
kind: Image
metadata:
annotations:
image.openshift.io/dockerLayersOrder: ascending
image.openshift.io/manifestBlobStored: "true"
openshift.io/image.managed: "true"
creationTimestamp: "2023-07-19T09:11:39Z"
name:
sha256:873a5580b0ffed32321e7020da4ae6906d9046dc713f3a9019987393284bf868
resourceVersion: "57031"
uid: 4457cf52-debd-4acb-b849-d7d8517b7a46
```
- access to the `Image` resources is restricted to a level when even
extending the openshift specific role of the operator is not enough to list them
- adding specific camel labels `metadata` is not available in Openshift CLIs
- adding specific owner reference in `metadata` is ignored when the
referenced object is deleted
All these observations leads me to the conclusion that the two possibilities
I listed are not valid in openshift. If we were in a normal production use case
the `ImagePruners` would do the job of cleaning the image registry.
I believe trying to add any code to manage this use case described would do
more harm than good.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
