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]: Wait to start container until initial file syncs complete #6113

Open
westrik opened this issue May 30, 2024 · 1 comment
Open

Comments

@westrik
Copy link

westrik commented May 30, 2024

Feature Request

Background / Motivation

We have configured our Garden local dev setup is run sleep 30 before starting our backend dev server. We do this to wait until the initial file syncs have completed and avoid errors caused by missing files.

This is not ideal because we need to hard-code a wait time greater than the worst-case initial sync time, so in most cases we are sleeping an unnecessarily long amount of time. This is also brittle because the initial sync time may increase as more files are added.

What should the user be able to do?

Users should be able to configure Garden to wait to run a container's startup command until the inital file sync(s) have completed.

Why do they want to do this? What problem does it solve?

Users may want a reliable way to avoid starting a container until all files it needs to run have been synced.

Suggested Implementation(s)

Perhaps a waitForInitialSync option could be added to a container spec, e.g.:

spec:
  containers:
    - command:
        - bash
        - dev-server.sh
      waitForInitialSync: true
      # ...

Or maybe a blockStartup option could be added to the sync config:

devMode:
  sync:
    - target: /src
      source: '.'
      mode: one-way-replica
      blockStartup: true
    # ...

How important is this feature for you/your team?

🌵 Not having this feature makes using Garden painful

@twelvemo
Copy link
Collaborator

This is a great feature request. I think a flag in the sync configuration would make more sense, since we can then implement this as well for helm and kubernetes Deploys.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants