Skip to content

Installer simplification adr 2.0#1618

Open
scottmbaker wants to merge 7 commits intomainfrom
installer-simplification-adr
Open

Installer simplification adr 2.0#1618
scottmbaker wants to merge 7 commits intomainfrom
installer-simplification-adr

Conversation

@scottmbaker
Copy link
Copy Markdown
Contributor

Description

Adds a new ADR for installer simplification tasks for 2026.1

Checklist:

  • I agree to use the APACHE-2.0 license for my code changes
  • I have not introduced any 3rd party dependency changes
  • I have performed a self-review of my code

@scottmbaker scottmbaker force-pushed the installer-simplification-adr branch from f82140d to 03bcb86 Compare March 17, 2026 23:47

### Goal #1: Eliminate Installer Sprawl

Reduce the number of distinct installer implementations from four (AWS, OnPrem old, OnPrem new, Coder)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

recommend not to use Onprem old and Onprem new. Maybe legacy and current is better suited.

Enable EMF deployment without requiring ArgoCD as a continuous reconciliation component, while
preserving the ability for customers to add ArgoCD for GitOps workflows if desired.

### Goal #3: Support "Bring Your Own Kubernetes"
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we reorder these based on priority, as removing Argo is likely 4th in priority out of the current list?

## Success Criteria

- Single installer pattern documented and functional across all deployment scenarios
- AWS, legacy OnPrem, and Coder installers deprecated (can be maintained externally if needed)
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps be explicit that "users or community can elect to maintain these in a fork or branch as needed" so that it doesn't imply that Intel is committed to maintaining these.

In production scenarios, the customer is responsible for DNS configuration and will usually
use their existing infrastructure.

An example dnsmasq configuration shall be provided in the deployment guide.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will we also preserve the existing generate_fqdn, or perhaps enhance it with more output options? Though the current text output is easy enough for someone to transorm into needed formats for their DNS service.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants