💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

Not sure if I have this 100% right, so bear with me ;)

The relative-path is from the root.

If the client is configured to the manifest (which is host/version/manifest), the client would need knowledge about this relationship. So this would complicate if users put EMS behind a proxy like so:

reverseproxy.corp.org:5401/tiles/* -> tiles.maps.elastic.co/v7.6
reverseproxy.corp.org:5401/files/* -> vector.maps.elastic.co/v7.6

Unless we somehow bake this knowledge into Kibana/user-docs that the sub-path of the manifest is not the top-level (and imho, I think we actively want to avoid such a situation since this is the situation today to a certain extent).

We could update the EMS-client it needs a double config:

emsFileConfig:
     host: reverseproxy.org:5401/file
     version: v7.6

With the understanding on the back-end that EMS always needs to serve the manifest from <host>/<version>/manifest. Then the actual files have their relationship from <host>/<relative-url-from-manifest>.

Note that EMS diverges significantly from other geo-server products (e.g. ArcGIS Server, GeoServer, ...). Most of these platforms generate their manifests dynamically, based on user-config of the host. Mapbox-tile-spec are an example of this as well.

Another approach would be more along the lines of organizing resources hierarchically. (e.g. https://sampleserver6.arcgisonline.com/arcgis/rest/services/). The above is counter to how EMS was designed (no duplication of files for efficient content etc...).

Thoughts?

We could update the EMS-client it needs a double config:

emsFileConfig:
     host: reverseproxy.org:5401/file
     version: v7.6

ems-client already accepts a kbnVersion parameter that gets passed as a query parameter in requests for tiles and files. We could parse this parameter to get the matching EMS version. Although, this requires us to publish the next major and minor releases of EMS for development. However, these future EMS releases would be subject to change until stack release.

Another approach would be more along the lines of organizing resources hierarchically. (e.g. https://sampleserver6.arcgisonline.com/arcgis/rest/services/). The above is counter to how EMS was designed (no duplication of files for efficient content etc...).

I would prefer to keep the current convention to avoid duplicating vector files. Especially as we move to syncing EMS releases with the stack and also if we start to release higher resolution (much larger) datasets.

ems-client already accepts a kbnVersion parameter that gets passed as a query parameter in requests for tiles and files. We could parse this parameter to get the matching EMS version. Although, this requires us to publish the next major and minor releases of EMS for development. However, these future EMS releases would be subject to change until stack release.

One concern I have with this is handling breaking changes in future releases and functional tests downstream. For example, we might make a change to the v8.0 manifest while still in development that could require functional test changes in Kibana. The CI on the master branch and other PRs would fail until the functional test changes are fixed. We may be able to minimize the effect with parallel PRs, but I do not see how we could avoid it completely.

So perhaps it is better to hard-code the EMS version in the ems-client library instead and upgrade the ems-client dependency in Kibana after the API and client library are in sync.

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request