reconnect to existing services
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 10.1k
- Forks
- 413
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 6
Description
When people are using a remote cluster, a pattern we've seen is that they don't WANT to restart all the services from scratch. They want Tilt to check if the server is already there, and if possible, try to reconcile with what they had locally.
In other cases, they'd be fine with Tilt reconnecting to a stale version of a service, and updating that service to the fresh version in the background (rather than blocking other builds on it).
We've had trouble making progress on it because the product experience is deeply tied to the technical implementation, and there's a couple different ways you can solve it, between:
- More robust caching of image builds - https://github.com/tilt-dev/tilt/issues/3690
- A "live connect" feature that checks if the binary can be made consistent with the local workspace with live-update sync alone
- A way to deliberately use a pre-built image when available
- A way to share images across teams (https://github.com/tilt-dev/tilt/issues/3629)
- Changing the ergonomics about updating on the first tilt up, so that Tilt will only do the initial build if you confirm that that you want to replace the existing one.
I think the sheer number of options here speaks to how painful it is for app devs to start Tilt once you have more than a handful of services, and different ways that people are willing to sacrifice correctness to speed it up.
Filing this issue just to collect thoughts and feedback on this and what the right trade-offs are here between possible solutions
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files, tests, or entry points are identified. Start by reviewing the referenced caching and image-sharing issues, then compare the listed reconnect, live-connect, pre-built-image, and first-run update options; done would require a decided product direction and defined implementation scope.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes
- Domain
- infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100