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

Wait for multiple services #2

Closed
andrewshawcare opened this issue Mar 7, 2016 · 10 comments

Comments

Projects
None yet
5 participants
@andrewshawcare
Copy link

commented Mar 7, 2016

It would be ideal if multiple services (i.e. multiple host:port combinations) could be declared such that the command is executed only after all dependent services are available.

@vishnubob

This comment has been minimized.

Copy link
Owner

commented Mar 7, 2016

I feel like this is better solved by either a top level script that orchestrates the logic of such a situation or chaining multiple wait-for-it commands together.

@andrewshawcare

This comment has been minimized.

Copy link
Author

commented Mar 7, 2016

Yeah, I did that but that approach is potentially misleading.

For example:

./wait-for-it.sh service-a:1234 -- ./wait-for-it.sh service-b:1234 -- docker-entrypoint.sh

Logically, is service-b dependent on service-a? In my case it isn't (so they shouldn't be chained). In my view, it would be clearer to have:

./wait-for-it.sh service-a:1234 service-b:1234 -- docker-entrypoint.sh

Structurally, there should be two options:

container -> {service-a, service-b} // set denotes mutually-exclusive dependencies
container -> [service-a, service-b] // list denotes dependency order

A chain provides a list mechanism and multiple host:port arguments provides a set mechanism.

@vishnubob

This comment has been minimized.

Copy link
Owner

commented Mar 7, 2016

A high-level script is your best option to solving this particular use case, as it allows you the flexibility you need in testing and interpreting the various states that arise in your specific scenario. wait-for-it is intentionally designed to keep-it-simple, leaving the use-case you describe as an exercise for the reader. Feel free to fork and tailor to your needs.

@jlordiales

This comment has been minimized.

Copy link

commented May 25, 2016

@vishnubob did you get to implement your use case? I was looking to do exactly the same

@vishnubob

This comment has been minimized.

Copy link
Owner

commented May 25, 2016

@jlordiales: i think you meant to ask @andrewshawcare, since he originally posted the issue.

@jlordiales

This comment has been minimized.

Copy link

commented May 26, 2016

Yes @vishnubob, sorry it was late :)

@jlordiales

This comment has been minimized.

Copy link

commented May 28, 2016

@andrewshawcare FWIW I implemented this on https://github.com/jlordiales/wait-for-it/blob/master/wait-for-it.sh (for my use case at least). You can specify multiple host:port pairs and the whole thing will fail as soon as the first host times out

@Forever-Young

This comment has been minimized.

Copy link

commented Sep 29, 2016

Didn't see this issue, also implemented this: Forever-Young@f9aa0c1

@frastel

This comment has been minimized.

Copy link

commented Mar 8, 2017

Could this issue be closed as "won't fix" so it is clear that this high-level functionality shouldn't be integrated in this project?
As vishnubob already mentioned it makes totally sense to keep this script as simple as possible and to not patch this script for this reason.

@Forever-Young

This comment has been minimized.

Copy link

commented Mar 9, 2017

I guess it's enough to have some receipts just in the issue comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.