Excerpts from Gustavo Niemeyer's message of Tue Sep 13 18:35:28 UTC 2011:
> For instance, the fact you want to wait for bootstrapping is generally a
> side-effect of the lack of compound commands (stacks).
>
At some point we have to let go of the idea that everybody can write
effective asynchronous scripts. It may not be at the "wait for bootstrap"
level, but users need to be able to write straight forward, blocking
scripts, or they'll do evil things like polling with sub-second timeouts.
Even with a stack, I can see wanting
deploy-stack --wait-for-relations
Which means wait for all relations in the stack to be up before returning.
This would allow somebody's continuous deployment system to *know* that
the new stack at least did everything *it* expected to do already. If
you make them poll *all* of the services, you're not really helping them
with automation. More than likely they'll just pick the one they perceive
as being "last" and poll that.. possibly racing with other services and
then having a less reliable experience when some new formula slows down
that process.
Its a wishlist item, we can live without it. We can workaround it by
doing what I did, polling status, but seems kind of silly to have that
as an external script when it would be *super* easy inside ensemble.
Excerpts from Gustavo Niemeyer's message of Tue Sep 13 18:35:28 UTC 2011:
> For instance, the fact you want to wait for bootstrapping is generally a
> side-effect of the lack of compound commands (stacks).
>
At some point we have to let go of the idea that everybody can write
effective asynchronous scripts. It may not be at the "wait for bootstrap"
level, but users need to be able to write straight forward, blocking
scripts, or they'll do evil things like polling with sub-second timeouts.
Even with a stack, I can see wanting
deploy-stack --wait- for-relations
Which means wait for all relations in the stack to be up before returning.
This would allow somebody's continuous deployment system to *know* that
the new stack at least did everything *it* expected to do already. If
you make them poll *all* of the services, you're not really helping them
with automation. More than likely they'll just pick the one they perceive
as being "last" and poll that.. possibly racing with other services and
then having a less reliable experience when some new formula slows down
that process.
Its a wishlist item, we can live without it. We can workaround it by
doing what I did, polling status, but seems kind of silly to have that
as an external script when it would be *super* easy inside ensemble.