[Thundercloud12]

Motivation

Currently, an IntegrationProfile must be explicitly selected by annotating each individual Integration (or
Pipe) resource with camel.apache.org/integration-profile.id. This requires developers to manually annotate every
resource and prevents namespace administrators from defining standard default profile settings for all integrations
in a given namespace.

Changes

This PR introduces default IntegrationProfile resolution support, allowing integrations to inherit a default
profile without explicit per-resource annotations. The operator now resolves profiles using the following order of
precedence:

1. Resource Annotation: camel.apache.org/integration-profile.id on the resource (Integration, Pipe).
2. Namespace Annotation: camel.apache.org/integration-profile.id on the Kubernetes Namespace.
3. default Profile Convention: An IntegrationProfile named default in the same namespace.
4. Operator Default: Operator baseline configuration if no profile is defined.

Key Updates

• Profile Resolution (pkg/platform/profile.go): Updated findIntegrationProfile to implement the fallback
  sequence (Resource Annotation → Namespace Annotation → default IntegrationProfile → Operator Defaults).

• Constant (pkg/apis/camel/v1/common_types.go): Added DefaultIntegrationProfileName = "default".

• RBAC (helm/ & pkg/resources/config/rbac/): Added get permission on namespaces for descoped roles
  so the operator can inspect namespace annotations.

• Unit Tests (pkg/platform/profile_test.go): Added comprehensive unit tests validating resolution precedence,
  fallback behavior, and missing profile error handling.

• Documentation (docs/modules/ROOT/pages/configuration/integrationprofiles.adoc): Added documentation
  explaining the resolution precedence and showing examples for namespace annotations and the default profile
  convention.

Fixes: #6776

[squakez]

Cool work, thanks!

[github-actions]

✔️ Unit test coverage report - coverage increased from 63.8% to 63.9% (+0.1%)

[Thundercloud12]

@squakez i have done the changes as requested by you!

[github-actions]

✔️ Unit test coverage report - coverage increased from 64.4% to 64.5% (+0.1%)

[squakez]

Maybe it requires a rebase with main as we have fixed issues with registry lately.

[Thundercloud12]

I, along with an ai agent, investigated the CI failures, and the agent suggested the following root cause and fix.

Root cause:

• In namespaced mode, the operator lacks cluster-wide permissions to list/watch Kubernetes Namespaces.
• Fetching a Namespace through the cached client may trigger an informer that fails to synchronize.
• The resulting cache synchronization error is not recognized by the existing Forbidden error check, causing reconciliation to fail.

Proposed fix:

1. Disable caching for corev1.Namespace so namespace lookups use direct API requests.
2. If the namespace lookup fails, continue profile resolution using the default profile or operator configuration instead of failing reconciliation.

Verification reported by the agent:

• The namespaced integration test passed locally.
• Relevant unit tests passed.
• Formatting and lint checks passed.

Before proceesind i want to ask this with you does this diagnosis makes sense? as this is a diagnosis did by an agent i cant trust it completely, although to me it might seem good at first but i am not someone experienced in this repo and might introduce some unintended changes that are not meant to be there in the first place

[squakez]

Not sure about that, it does not really seem a reason for the failure. I invite you to rebase with the actual main before doing any further analysis as there were stability fixes that may solve this situation. It's an easy one we can try before diving more into investigations.

[Thundercloud12]

@squakez rebased it

[github-actions]

✔️ Unit test coverage report - coverage increased from 64.6% to 64.7% (+0.1%)

[squakez]

I think this one depends on the fix done in #6887 . Once that is merged, we probably need to adjust this with the changes required in the other PR in order to avoid the failures seen in this PR.

[squakez]

@Thundercloud12 please, rebase this one as it may be all green after the rebase and we can merge.

[Thundercloud12]

@squakez please have a look now

[squakez]

I will have a look at the check failures and try to solve them on this PR (which, for the rest, seems complete)