-
Notifications
You must be signed in to change notification settings - Fork 524
Support stateless for multi container scaling and deployment #1831
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
Comments
Copying a response from Discord, in case others are also interested: This will be difficult since not everything is serializable so can’t be stateless. These are running programs that inherently have state. Even if we made marimo stateless, your code may not be (e.g threads, db connections, etc) I think a better request would be a load balancer that can manage multiple instances. Based on what you know about marimo, if you have suggestions on how marimo might one day support stateless execution, we're open to hearing them. |
@akshayka one model you can follow is how Airflow serializes it's objects. It would be useful for deployed programs as programs are built to be stateless. https://airflow.apache.org/docs/apache-airflow/stable/authoring-and-scheduling/serializers.html |
Thanks for the link. We'll likely look into this one day (perhaps we could patch |
@akshayka any idea if there has been any prioritization for this because i'd really like to use this. It would be nice to have a redis cache of some sort |
Just testing my understanding, would something like edit: Updated link to persistent_cache |
@dmadisetti I think that would work if there was redis integration and the global session shared in redis some how through persistant_cache maybe? |
I think adding redis integration to I think a stateful_vars = load_stateful_from_redis()
my_state, my_ui_element, my_shared_object_with_varying_state = create_stateful_objs_from_dump(stateful_vars) # e.g.
f""" Just a simple dashboard showing
{my_ui_element}
which is the same for every session
""" with persistent_cache("result_ideally_loaded_from_redis", type="redis") as cache_attempt:
do_app_level_computations(my_shared_object_with_varying_state) if not cache_attempt.hit:
dump_stateful_obj(my_shared_object_with_varying_state)
dump_ui_state(my_state, my_ui_element) But open to other api suggestions, and how a more native solution could smooth this over |
i think a persistant session is necessary as the our system doesn't support sticky sessions which means that the session needs to persist remotely as the api calls with reach out via a round robin load balancer which could hit different machines. |
Oh I see, so down to the request level it needs to be session agnostic. Have you considered just using the containers to create / serve a WASM page? Getting dynamic information from unsupported libraries would then be as easy as a refresh, and it would still be interactive within WASM. Alternatively, you could also serve Maybe true stateless execution is possible? There's a lot of web-socket and miscellaneous requests- but I feel like WASM could get you most of the way there, and maybe an expanded Islands (server side initial run) could get you further: https://docs.marimo.io/guides/exporting/?h=islands#islands-in-action |
Description
I have a custom kubernetes deployment that requires stateless applications which has been a standard for a long time.
Suggested solution
I'd like to be able to deploy the app and any state necessary be offloaded to redis or refactoring to support stateless applications which have been a standard for a long time i.e. 12 factor apps
Alternative
Our internal kubernetes system doesn't support sticky sessions.
Additional context
error received:
The text was updated successfully, but these errors were encountered: