Nest raster, vector and stac services into apiServices.

[pantierra]

This PR proposes encapsulating the external services—stac, raster, and vector—within an externalServices structure. This enhancement enables subcharts to extend these services, facilitating the injection of additional external services, such as an application frontend.

Involved in this PR @ciaransweet and @emmanuelmathot during our pod week.

[pantierra]

I will have to look into the failing tests, first.

[pantierra]

Just came back to this, as I wanted to add another service. I fixed the tests. It is ready for review. Thanks for looking into it.

[ividito]

Nit: externalServices -> eoAPIServices

Is there any way to use externalServices as a list of services to iterate over, but still keep the per-service values at the top level? It would be great to maintain some backwards compatibility, but I'm not sure how much control helm's templating gives us over that.

[pantierra]

This approach should work fine as well. We could define in values.yaml:

apiServices:
  - raster
  - stac
  - vector

and then just check for them in the charts with:

{{- if has $serviceName $.Values.apiServices }}

If I recall correctly, when @ciaransweet and I discussed this a few months ago, we considered this structure but preferred nesting them under externalServices—or better yet, as you suggest, something like eoAPIServices. I'm fine with either. Which do we prefer? Any arguments for or against each option?

[pantierra]

I hope this works for you. I renamed externalServices to apiServices because it's shorter than eoAPIServices, and the latter seems to break the camel case convention with the uppercase "API."

[ividito]

If I recall correctly, when @ciaransweet and I discussed this a few months ago, we considered this structure but preferred nesting them under externalServices—or better yet, as you suggest, something like eoAPIServices. I'm fine with either. Which do we prefer? Any arguments for or against each option?

I would prefer to keep existing values.yml files valid for a little while longer, which leads me away from the nested values. That being said, I don't want to hold things up. It might also be possible to get the same backwards compatibility using a helper function (although that might add more complexity than it's worth).

[pantierra]

Indeed this change needs more evaluation and proper documentation and maybe even assistance to roll it out. Thus i suggest we do a twp-step approach:

• Step 1: The approach with the list, but no nesting. I created a PR for that: Introduce a list to avoid hardcoding of api service names. #180 This will not introduce any breaking changes.
• Step 2: Potentially nest these services and make sure that configuration change is smooth for everyone.

[batpad]

This enhancement enables subcharts to extend these services, facilitating the injection of additional external services, such as an application frontend.

Nothing to block the PR, but just curious: as someone slightly fuzzy with how subcharts work but having encountered similar issues, would you have a link to an example of how this would work with a subchart extending to add a custom frontend, for eg? Linking to some existing subchart docs to demonstrate the idea should be fine - I just wanted to understand a bit clearly how the nesting helps here for the subchart use-case. Thanks!

[pantierra]

Good point about adding documentation. We don’t have an example yet, but polder would be a good first use case.

The main idea is that a deployment using eoapi-k8s as a dependency can easily integrate additional services—such as another services API or frontend—via the values.yaml, regardless of whether they are defined as variables (#161) or nested configurations (this PR). These services will then be picked up by templates/service/services.yaml (and others) and deployed within the same context, utilizing the existing ingress.

[pantierra]

We merged step 1 into main (#180). Now, I’ve merged it back into this branch to focus solely on the nesting aspect.

[pantierra]

Closing in favour of the much better approach here: #211