gitPratikSingh commented on PR #6926: URL: https://github.com/apache/camel-k/pull/6926#issuecomment-6663198675
Thanks — I started on the scheme-based resolution and it works for almost everything: building the scheme with `apis.AddToScheme` and indexing its registered types resolves the built-ins, the Camel types, and the KEDA/Knative duck types (ScaledObject, Trigger, Subscription, serving Service, SinkBinding) to their real GVKs, so the version table can go away. One gap I found while checking coverage against the role files: four types the operator roles grant delete on have no Go type registered anywhere — Camel K creates them as unstructured objects only: - `eventing.knative.dev/v1` Broker (`brokers`) - `messaging.knative.dev/v1` Channel (`channels`) and InMemoryChannel (`inmemorychannels`) - `serving.knative.dev/v1` Route (`routes`) Pure scheme resolution would drop these four from the deletable set, which looks like a regression — an integration's Broker or Channel would no longer be collected. Two options as I see them: 1. Scheme-first, with a tiny fallback list covering just these unstructured-only types (all stable at v1); if they're ever registered in the scheme, the scheme wins. 2. Pure scheme resolution and accept losing those four. I have option 1 implemented locally and the coverage checks out — it also picks up two OpenShift types (ImageStreamImage and ImageStreamMapping) that the role file grants delete on and my hand-written table had missed. But since it reintroduces a small fixed list, I wanted your call before pushing. Which way do you prefer? -- 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]
