I understand what you are trying to do over here but I'm wondering if we need this level in the setting hierarchy.

I was thinking the config that is shipped with elastic-package would look something like this:

stack:
  images:
    "elastic-agent": "docker.elastic.co/beats/elastic-agent:7.13.0-SNAPSHOT"
    elasticsearch: "docker.elastic.co/elasticsearch/elasticsearch:7.13.0-SNAPSHOT"
    kibana: "docker.elastic.co/kibana/kibana:7.13.0-SNAPSHOT"

This would replace the DefaultStackVersion hardcoded version we have in the code today. Instead, the code would read the config and get the image names (including versions) from there.

Individual images could then be overridden by repo-level or local-level configurations that have the same structure (as mentioned in this comment).

The reason why I implement it like this is because we need a place to fixtures for various stack version. Use cases:

• elastic-agent in 7.13.0 doesn't work with latest snapshot - we need to use a stable image
• kibana in 8.0.0-SNAPSHOT is broken, we know about this, we need to set a specific version

I'm afraid we need a support matrix somewhere (per version stack), not sure where should we keep it. I'm happy to discuss it further!

EDIT:

Please consider also install tests against older versions: https://github.com/elastic/integrations/blob/master/.ci/Jenkinsfile#L89-L92

Okay, I see your point now, especially considering install tests again older versions.

I'm good with this structure but I'd keep the values in this file (the one supplied by elastic-package) clean — no specific SHAs, etc. IMO, overrides should be specified either at the repo level or the local development level, in similarly structured files as this one. elastic-package can discover these files by walking up the folder tree until it finds .elastic-package/config.yml and .elastic-package/config.dev.yml.

Nit: maybe we should remove the DefaultVersion const from the code and move it into this file, under the setting stack.default_version or similar? That way all information related to stack versions is in the same file and we only need to update this one file after every stack release.

Let me challenge it, I believe we're close to the final form.

It's a common use case to start the start wherever you want with: elastic-package stack up, which should pick up latest snapshots. If there is a problem with latest SNAPSHOTS, without fixtures in ~/.elastic-package/config.yml it will fail.

I think this is the only concern I have. It would be great if we can make elastic-package stack up working just anywhere.

Discussed this with @mtojek off-PR. We're on the same page now. Current model is good as-is. Reasons:

• It is the same amount of work for package authors to update elastic-package to get the override image IDs and then back to latest ones as it would be if we created a .elastic-package/config.yml in the integrations repo.
• Creating a .elastic-package/config.yml in the integrations repo would benefit developers who develop packages in that repo, but not other package developers using elastic-package.
• By providing the overrides via the elastic-package tool we also get an opportunity to get package developers to update their version of elastic-package from time to time.

Maybe put some commented out structure here so it's easy to know how to change it when we need to make overrides? Also maybe include a comment about informing package developers whenever overrides are defined or removed here?

Good idea, added!