search

juju / amulet

Testing harness and tools for Juju Charms
Other
17 stars 33 forks source link

Allow subordinates with no relations to pass wait_for_status #104

Closed johnsca closed 9 years ago

johnsca commented 9 years ago

To preserve existing behavior, subordinates that have no relations (and thus can never possibly have a public-address or idle agent) should not block wait_for_status. However, we do still want to block if a subordinate has been added & related, but has not yet attached to the appropriate units (usually due to a long-running hook blocking the subordinate install hook).

marcoceppi commented 9 years ago

This is logic that has always annoyed me, and it's mainly because of the way deployer does things in stages which was because of openstack charms trying to manage complexity back when they were in bash.

History.

That said, this is a very elegant patch, I'll wait for travis to sign off on it, but it LGTM :boat:

johnsca commented 9 years ago

We're also testing against the cassandra and big data bundles which were what hit either end of this issue (the cassandra test deploys an unrelated subordinate, and the big data bundles have subordinates blocked on long-running hooks).

marcoceppi commented 9 years ago

Right, but we have to code around this case because deployer and juju-gui will deploy services first, then after services are successful, initate relations, which existed because years ago when deployer was written it was written to make deployment of Open Stack environments easier, but a lot of those older charms had race conditions which meant you would have to do it in stages. As a result, we have the current workflow where deployer would of deploy services and wait for agent-state started before doing relations. This made sense in the days of juju 0.6 and juju 1.0 but we've come so far from then that it doesn't' make much sense anymore.

It was primarily anecdotal for anyone wondering why a subordinate would be deployed but not related