ability to wait for a condition

[ryane]

In https://github.com/asteris-llc/converge-elk/blob/master/elk.hcl#L46, I am abusing task.query to wait for a service to become healthy. Should this be a native capability of converge?

It it could behave similarly to task.query (or possibly healthcheck) but with a built-in retry loop and timeout. Perhaps something like:

task.probe "elasticsearch-health" {
   check = "[[ $(curl -s 'http://localhost:9200/_cluster/health' 2>/dev/null | jq -r .status) == \"green\" ]]"
   initialDelay = "1s"
   interval = "1s"
   timeout = "10s"
}

[rebeccaskinner]

Timeout is supported in task and task.query, I could see possibly
adding a retry count or something in the future.

On Tue, Sep 13, 2016 at 10:00 AM, Ryan Eschinger [email protected]
wrote:

In https://github.com/asteris-llc/converge-elk/blob/master/elk.hcl#L46, I
am abusing task.query to wait for a service to become healthy. Should
this be a native capability of converge?

It it could behave similarly to task.query (or possibly healthcheck) but
with a built-in retry loop and timeout. Perhaps something like:

task.probe "elasticsearch-health" {
check = "[[ $(curl -s 'http://localhost:9200/_cluster/health' 2>/dev/null | jq -r .status) == "green" ]]"
initialDelay = "1s"
interval = "1s"
timeout = "10s"
}

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#238, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMbq6gD16W8RQowT63Nh8eJiWRViMM1ks5qprqEgaJpZM4J7xqZ
.

Rebecca Skinner
Sr. Software Developer
Asteris, LLC

[sehqlr]

Ryan and I were having a chat about this, and it brought up this question: is there a way to integrate the functionality from smlr into this?

[BrianHicks]

Just piping in: please use the concepts from smlr, but not the code. I wrote it in a day in Germany and was very jet-lagged. It may be useful, but it's also awful.

[ryane]

Just thinking aloud - perhaps we start with something like wait.query that would be similar to the task.probe example above. That would be the escape hatch so that you can roll your own wait conditions using existing tools. In the future, we could build higher-level waits like wait.port, wait.url, wait.docker.healthcheck, wait.host, etc.

[BrianHicks]

We probably should begin with that and wait.port. Unless there's a really easy way to check if a port is open and in use by some program? (lsof could do it but I'm not sure how portable that invocation would be)

[ryane]

you could also use nc but of course you would have to ensure it is installed first. but, yeah, wait.port seems pretty fundamental

[BrianHicks]

It's kind of like having to write a curl command to download a file every time. It's "good enough" but eventually you want #250