v1.4 installation observations

[lauriseitsonen]

Hi,

While running scripted Creodias install for release v1.4 on our cluster I noticed some issues:

• It could be added to the documentation that IDENTITY_GATEKEEPER_ENCRYPTION_KEY must be either 16 or 32 characters long, otherwise protection installations will fail
• Application hub installation puts hard-coded OAUTH_CLIENT_SECRET to secret (https://github.com/EOEPCA/deployment-guide/blob/d78b4256ebc8b077ea03461fadea7214cf9eeb6b/deploy/eoepca/application-hub.sh#L123)
• EOEPCA Portal install fails due to hard-coded chart path (https://github.com/EOEPCA/deployment-guide/blob/d78b4256ebc8b077ea03461fadea7214cf9eeb6b/deploy/eoepca/eoepca-portal.sh#L33)
• Harvest Creodias data example on https://deployment-guide.docs.eoepca.org/v1.4/quickstart/creodias-deployment/ produces an error. Command kubectl -n rm exec -it deployment.apps/data-access-harvester -- python3 -m harvester harvest --config-file /config.yaml Sentinel2 seems to work

BR , Lauri

[rconway]

Hi Lauri,

Thanks for progressing with v1.4 and for the helpful feedback - which I'll take into account in the main branch.
Note that we have already remedied a few issues that we noted - which are itemised on the 'current' version of the deployment - so you may want to take a look at the Changelog here - https://deployment-guide.docs.eoepca.org/current/.

Richard

[lauriseitsonen]

Hi Richard,

Thanks, I took a look the Changelog when I started but it seems to be a good idea to check it regularly as there are now more items.

Our installation seems so far otherwise ok but the data access component does not work correctly. The view server page opens but the searches fail, in the search results tab there are messages "TypeError: Failed to fetch". From the browser network traffic I can see that it makes suspicious opensearch calls that are blocked (mixed content) like
http://data-access-renderer.rm.svc.cluster.local/opensearch/collections/L8L1GT/atom/...

It also does https wmts calls to our data access server with responses
status: 404
content-type: image/jpgpng
x-mapcache-error: received request with invalid style "(null)" (expecting "default")

Any ideas what might cause this?

BR, Lauri

[lauriseitsonen]

It seems that this was caused by ingress dropping information from proxied calls. With the following modifications the view server client started to work (calls going to the correct server url and query parameters delivered to the back-end server, somehow they were dropped on the way before)

  # Open access to renderer...
  location ~ ^/(ows.*|opensearch.*|coverages/metadata.*|admin.*) {
    proxy_pass http://data-access-renderer.rm.svc.cluster.local:80;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Method $request_method;
    proxy_set_header X-Forwarded-URI $request_uri;
    proxy_busy_buffers_size 64k;
    proxy_buffers 8 32k;
    proxy_buffer_size 32k;
  }
  # Open access to cache...
  location ~ ^/cache/(.*) {
    rewrite ^/cache(.*)$ $1 break;
    proxy_pass http://data-access-cache.rm.svc.cluster.local:80;
  }

The viewer works in principle but visualizing S2 data is slow. There seems to be a problem with S2 seeding, the cloud masked layers cause problems (error message that the layer does not exist).

[rconway]

Hi Lauri,
Can you clarify that you believe these settings are needed for all deployments - or something specific to your deployment?

[lauriseitsonen]

Hi Richard,
We are using Creodias managed kubernetes cluster with the nginx provided by Creodias (in the WAW3-1 region). It would probably need more testing but I'd say there's a risk that they are needed also for others with similar setup.

[rconway]

Hi Lauri,

After spending some time looking into this I established an alternative approach with the identity-gatekeeper that does not require to directly perform the open proxying - instead more relying on that defined within the ingress.

This is supported by an updated chart for the identity-gatekeeper at version 1.0.12 - which allows to specify a list of request uri paths for open access - https://github.com/EOEPCA/helm-charts/blob/main/charts/identity-gatekeeper/values.yaml#L106.

For example, the Deployment Guide has been updated to exploit this - https://github.com/EOEPCA/deployment-guide/blob/main/deploy/eoepca/data-access.sh#L1314.

[rconway]

The first three bullets have been remedied at commit - https://github.com/EOEPCA/deployment-guide/tree/864d1036cdd10b28379323f2ab20a483f4f870ac.

The final bullet is resolved in commit - https://github.com/EOEPCA/deployment-guide/tree/f1a68bf59341afcbaa0c2336b251be37f6193fea.

[lauriseitsonen]

Hi,
Is there an easy way to enable CORS for all the hosts that get generated?
BR, Lauri

[rconway]

There's an nginx annotation - but needs to be applied to all ingress - e.g. https://github.com/EOEPCA/deployment-guide/blob/main/deploy/eoepca/data-access.sh#L73

[rconway]

Maybe there's a global nginx setting - ref. https://github.com/EOEPCA/deployment-guide/blob/main/deploy/cluster/ingress-nginx.sh#L21

[lauriseitsonen]

Thanks, I'll have a look! It seems that keycloak and zoo ingresses allow CORS out of the box while resource-catalogue does not. I'll dig into its configuration next.

[lauriseitsonen]

I managed to solve the resource-catalogue CORS problem by modifying the open access snippet in the ingress configuration as shown below. It seems that proxied open access requests did not get the required headers.

  # Open access...
  location ~ ^/ {
    proxy_pass http://resource-catalogue-service.rm.svc.cluster.local:80;
    if ($request_method = OPTIONS) {
      return 200;
    }
    add_header Access-Control-Allow-Origin $http_origin always;
    add_header Access-Control-Allow-Methods "*";
    add_header Access-Control-Allow-Headers "Authorization, Origin, Content-Type";
  }

[rconway]

This may also be solved by the approached described in the above reply - https://github.com/orgs/EOEPCA/discussions/109#discussioncomment-8997975 - since the cors annotation can be relied upon without need to reproduce the headers by hand.