Skip to content

docs(design): improve orchestrator deployment experience #290

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

charlesmcchan
Copy link
Member

Description

This proposal aims to significantly improve the deployment experience of EMF across multiple environments (AWS, Azure, and on-prem).
The new installer will prioritize user experience by offering a streamlined, zero-touch installation process after configuration,
along with clear error handling and actionable feedback.
It will also increase cloud portability through clear infrastructure abstraction and support for Azure.
Finally, by replacing monolithic shell scripts with modular Go components and adding test coverage, we will enable faster iteration and more frequent releases.

Any Newly Introduced Dependencies

N/A

How Has This Been Tested?

N/A

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

@charlesmcchan charlesmcchan added the Proposal Identify a PR as a design proposal to be reviewed. label May 8, 2025
@charlesmcchan charlesmcchan changed the title docs: Design Proposal: Orchestrator Deployment Experience Improvement docs (design): Orchestrator Deployment Experience Improvement May 8, 2025
@charlesmcchan charlesmcchan changed the title docs (design): Orchestrator Deployment Experience Improvement docs(design): improve orchestrator deployment experience May 8, 2025
- Every module should be **toggled independently** and have minimal external dependency.
- Installer should support **orchestrator CLI integration** (e.g. `cli deploy aws`) and parallel execution of non-dependent tasks.
- On-prem installation will not require a separate admin machine.
- Be compatible with upcoming Azure implementation and ongoing replacement of kind with on-prem in Coder
Copy link
Contributor

Choose a reason for hiding this comment

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

:(. Uff I was hoping for kind

Copy link
Member Author

Choose a reason for hiding this comment

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

There are several benefits of focusing on the same deployment method that customers use.

We acknowledge that on-prem infra is not as lightweight as it can be, and we are committed to proposing and implementing a weight-loss program.


### Out of scope

- Optimizing total deployment time, as current durations are acceptable.
Copy link
Contributor

Choose a reason for hiding this comment

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

I belileve we have to discuss if there is any optimization possible here

@ajaythakurintel ajaythakurintel modified the milestone: 3.1 May 8, 2025
Copy link
Contributor

@pierventre pierventre left a comment

Choose a reason for hiding this comment

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

very nice. Looking forward on how we can potentially optimize ttdeploy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Proposal Identify a PR as a design proposal to be reviewed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants