[GKO] ApiDefinition in a different namespace

ivank commented 5 months ago

Describe the bug

ApiDefinitions that are in a different namespace than GKO (and gateway) do not appear to be picked up when evaluating paths. Everything seems to be configuring OK, but isn't actually visible ones started and deployed.

To Reproduce

to-reproduce

Steps to reproduce the behaviour:

Follow the steps of https://documentation.gravitee.io/apim/guides/gravitee-kubernetes-operator/test-gko-after-deployment but create the ApiDefinition in a different namespace
curl -i http://<YOUR_GATEWAY_URL>/gateway/k8s-basic-with-ctx 404 "No context-path matches the request URI"

Expected behaviour

expected-behaviour

Either show an error pointing to the issue, or should resolve resources as normal.

Current behaviour

current-behaviour

ApiDefinition resources not resolvable on the gateway after creation.

Useful information

useful-information

Since it is obvious the ApiDefinition is configured properly even if it is in a different namespace, it seems to me this feature should work. It is either a bug, or a lack of documentation. If the latter, maybe there is no point to specifying a namespace for ref resources in the ApiDefinition, as it must be the same namespace anyway.

Environment

environment

| Gravitee | 4.3.1 | | GKO | 0.13.1 |

a-cordier commented 5 months ago

Hi @ivank,

Thank you for your feedback.

Do you get a config map created in your API definition namespace matching the name of the API definition resource ?

I think the issue might be that, by default, when installing the gateway with our Helm charts, the gateway service account gets associated to a role, which does not allow synchronising the config maps created by the operator in another namespace.

The helm chart allows you to use your own service account that you can bind to a cluster role. You can check our default values for more information on this config.

ivank commented 5 months ago

Hmm, we switched to only using the namespace where GKO resides as a workaround.

Not sure what is the recommended way to do it, but I think the current situation is rather hard to debug - since the API appears in the console without any visible problems, but doesn't actually work. If there was an error message in the console (preferred) or at least in GKO with some hints how to fix - would have saved us quite a lot of debugging.

ivank commented 4 months ago

The team recommended us to use local: false to resolve this issue. The problem was that in local: true GKO would create config maps that it then tries to use, and it can't fine because its in a different namespace. By using local: false this shouldn't be an issue

gravitee-io / issues