Skip to content
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

[Feature request] Save the resources status between up/down cycles #6469

Open
PumpkinSeed opened this issue Nov 14, 2024 · 2 comments
Open
Labels
enhancement New feature or request

Comments

@PumpkinSeed
Copy link

Describe the Feature You Want

We have a decent amount of services across a few Tiltfiles of our multiple systems. Each time I change between systems I have to individually disable resources what I don't want to run in that particular system. That would be nice to somehow persist that information. First I thought --output-snapshot-on-exit will do that for me, but I tried it and resources came up again.

Current Behavior

If I disable a resource, that will came back after "Down and Up" again.

Why Do You Want This?

That would make it lot easier to change between systems.

Additional context
I tried to write an extension for this by using the config.clear_enabled_resources() and config.set_enabled_resources(...), but I couldn't get information about the status of the services. If there would be a config.get_resources(), maybe I can get it periodically and save the state into a file.

If I just missed something can you direct me to the right direction how should I add this behavior? Otherwise that would be nice to add a flag for that just like how the --output-snapshot-on-exit works. If you point me to the direction I can work on it once we have an established plan for the implementation.

@PumpkinSeed PumpkinSeed added the enhancement New feature or request label Nov 14, 2024
@nicks
Copy link
Member

nicks commented Nov 19, 2024

we did a bunch of user research and prototyping on behavior like this when we first implemented 'disabled resources'. we never found a solution we really liked. But we're totally supportive of people taking a crack at it.

there's basically 4 common patterns that are worth mentioning:

  • batch jobs (like tilt ci) where you only want to use the state from the command-line
  • event-driven systems: you have a base Tiltfile that runs kafka, and a few dozen services that consume events. By default, all the consumers are disabled. You manually enable the ones you want to do development on.
  • "distributed monolith" systems: you have a base Tiltfile that runs, like, 20 microservices. By default, all the services are enabled in "prod" mode that runs the latest version. You use enable/disable to disable the "prod" version and enable the "dev" version (which builds the image locally).
  • statically defined groups of services, similar to how Compose Profiles works (https://docs.docker.com/compose/how-tos/profiles/)

all of that said: if you wanted to try implementing this, I'd probably do it like this:

does that make sense?

(open to making it a native feature, just thinking thru the best way to start prototyping something)

@PumpkinSeed
Copy link
Author

Thanks @nicks, I'm on holiday but as soon as I get back to my computer I will read it carefully and write a plan.

start as a tilt extension

That was my first thought, but I couldn't get notification about the UI change. I didn't know about this shell script, I will check it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants