Default Kamelets are not found when creating a binding

[rhuss]

When creating a binding with e.g. kn source kamelet binding create my-source --broker default --kamelet chuck-norris-source and a global installation for the Camel-K operator, and the chuck-norris-source is available in the camel-system namespace, then the following error appears:

kn source kamelet binding create my-source --broker default --kamelet chuck-norris-source
Warning: v1apha1.Kamelet is deprecated, please, use v1.Kamelet instead
Error: kamelets.camel.apache.org "chuck-norris-source" not found
Usage:
  kn-source-kamelet binding create NAME [flags]

Examples:

  # Create Kamelet binding with source and sink.
  kn source kamelet binding create NAME

  # Add a binding properties
  kn source kamelet binding create NAME --kamelet=name --sink|broker|channel|service=<name> --property=<key>=<value>

Flags:
      --broker string             Uses a broker as binding sink.
      --ce-override stringArray   Customize cloud events property in the form of "<key>=<value>"
      --ce-spec string            Customize cloud events spec version provided to the binding sink.
      --ce-type string            Customize cloud events type provided to the binding sink.
      --channel string            Uses a channel as binding sink.
      --force                     Apply the changes even if the binding already exists.
  -h, --help                      help for create
      --kamelet string            Kamelet source.
  -n, --namespace string          Specify the namespace to operate in.
      --property stringArray      Add a source property in the form of "<key>=<value>"
      --service string            Uses a Knative service as binding sink.
  -s, --sink string               Sink expression to define the binding sink.

kamelets.camel.apache.org "chuck-norris-source" not found
Error: exit status 1

This is because the validation doesn't check the kamelet in the "system namespace". The challenge here is to find out what the system namespace is.

Several solution could be possible:

• A cluster-wide resource, like a KameletCatalog that would store all available kamelets from the system namespace either in the spec: or in the status: field, and gets populated by the operator.
• Alternatively (and that is what people usually do with cluster-wide resources), have an additional type ClusterKamelet that is a real cluster-wide resource (and not a namespaced resource in a special namespace that is not necessarily fixed). This might pose a problem for multi-tenant setups, but it's the easiest thing to lookup
• What would be also possible (but not so nice): Have an extra-field in the Kamelet spec, that indicates whether this is a "default" kamelet. Then you could do something like k get kamelet -A and check those field whether it could be used.

If nothing of this work, then there should be at least a way to skip the validation (like e.g. with a --force option)

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[rhuss]

/remove-lifecycle stale