HYPERFLEET-796 - docs: Design proposal consolidating the e2e and infr…#148
HYPERFLEET-796 - docs: Design proposal consolidating the e2e and infr…#148ma-hill wants to merge 3 commits into
Conversation
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Central YAML (base), Organization UI (inherited) Review profile: ASSERTIVE Plan: Enterprise Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
ciaranRoche
left a comment
ciaranRoche
left a comment
There was a problem hiding this comment.
Really nice work on this, my main concern is introducing another location here. Given we only really have 2 consumers infra and e2e. I worry if its potentially overkill, when we could just leverage the infra repo to deploy e2e infra 🤔
| ``` | ||
|
|
||
| **Impact**: | ||
| - ✅ `helmfile diff` shows drift between desired and actual state (bash has no equivalent) |
There was a problem hiding this comment.
As our deployments are essentially ep[hemeral per run, how often do you think we would actually use helmfile diff?
There was a problem hiding this comment.
Probably not much. I guess I've just been using it for setting this up.
| ``` | ||
|
|
||
| **Benefits**: | ||
| - ✅ True single source of truth - helmfile lives in one canonical location |
There was a problem hiding this comment.
Given we have only two real consumers, infra and e2e, having this single source of truth in a third location might be overkill. We tried something similar in the past with https://github.com/openshift-hyperfleet/hyperfleet-chart but ended up moving to infra to reduce cost and duplication.
Might be worth looking how infra charts can own this canonical location. WDYT?
There was a problem hiding this comment.
Yeah that makes sense... I didn't have the history on that. So that's good to know. So you are more on board with having everything in infra, and all setup comes from there?
There was a problem hiding this comment.
So should we just continue to clone the infra repo and go from there? But we should be able to pass in new e2e configs?
2 participants
Summary
Adds a comprehensive design proposal for consolidating duplicated component installation logic between hyperfleet-infra and hyperfleet-e2e repositories. Currently, both repos maintain separate deployment codebases (1940 lines of bash scripts in E2E, ~824 lines of Makefile in infra) that deploy the same HyperFleet stack, leading to configuration drift and maintenance overhead. This proposal recommends adopting a unified Helmfile approach with a config-passing pattern where the helmfile repository contains only deployment logic, while each consuming repo owns and passes its own adapter and sentinel configurations via Makefile parameters.
Notes
This design proposal addresses HYPERFLEET-796 and builds on findings from the HYPERFLEET-1007 spike. The spike originally recommended a Makefile-only approach, but this proposal recommends Helmfile based on its declarative benefits, drift detection capabilities (helmfile diff), and cleaner separation between deployment logic (helmfile) and configuration data (each repo's configs).
The key innovation is the config-passing pattern: the helmfile repository contains only deployment logic with no hardcoded paths or repo-specific configurations. Each consuming repo (hyperfleet-infra, hyperfleet-e2e, future staging/perf repos) owns its own adapter and sentinel configs and passes them to helmfile via Makefile parameters. This makes the helmfile truly portable and eliminates the need to PR to the helmfile repo when adding test-specific adapters.
Jira Issue
HYPERFLEET-796