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

[PumpkinSeed]

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.

[nicks]

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:

• start as a tilt extension
• watch uiresource for changes, sort of like we do in this shell script - https://github.com/tilt-dev/tilt-extensions/blob/b2193c9554e48234b3de6441587fbea32556ed34/cancel/cancel_btn_controller.sh#L18
• every time uiresource changes, write all the enabled resources to a file
• on first load, call config.set_enabled_resources() with the contents of the file

does that make sense?

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

[PumpkinSeed]

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.

[PumpkinSeed]

I have worked on the extension by using the tilt get uiresource, I could get notified about the changes and I could get the details of a resource. I have 30% of the code already done. I will finalize and send it over here to see whether you have any feedback on that. @nicks

[PumpkinSeed]

I made a small progress in this. I found out the EngineState's field, the TiltfileStates which keeps the state of the resources. Since it is usually running on kubernetes we can save it into a config map.

I also found out HandleUIResourceUpsertAction is where I would invoke a function which updates that config map.

So let's say we can have a flag like --persist-state (I can imagine a better name), and if it is passed to the up command, it will use that config map to read the state of the resources and keep updating it.

@nicks Let me know what you think.

[andycmaj]

hello there @PumpkinSeed! I'd be willing to help implement/test this... do you have a fork you are willing to share with the WIP?

[PumpkinSeed]

Hey @andycmaj, I didn't go over the discovery phase and since than I didn't have a priority over it. That is challenging, because the Tilt mostly communicate over the kubernetes client, so it doesn't really have a state. If you can figure out something, I can help.

[andycmaj]

makes sense @PumpkinSeed thanks for the info. i'll research more when i have time :)