Race where recently destroyed service is not redeployed causing tracebacks
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
juju-deployer |
Confirmed
|
Low
|
Unassigned |
Bug Description
I regular see this failure running an Amulet test suite locally, where a service is is repeatedly setup and torn down. It seems that if I destroy a service and run juju-deployer again too quickly to redeploy it, then juju-deployer will think the recently destroyed service is still there and neglect to deploy it. I have also seen similar tracebacks where juju-deployer thought the old units were still there, which would cause it to fail when it attempted to create the relations. The most odd thing to me is that I'm waiting until the service is no longer listed in 'juju status' before continuing, so either that is broken or juju-deployer is receiving data from the API that is more out of date than juju-status. Or perhaps this is a change in Juju 1.24, where status is no longer listing services in their death throws but juju-deployer is not filtering them out in the same way.
2015-08-27 00:57:16 Starting deployment of charm-testing-
2015-08-27 00:57:18 Deploying services...
2015-08-27 00:57:19 Deploying service postgresql using /tmp/charmjgoqt
2015-08-27 00:58:44 Adding 1 more units to client
Traceback (most recent call last):
File "/usr/bin/
load_
File "/usr/lib/
run()
File "/usr/lib/
importer.
File "/usr/lib/
self.
File "/usr/lib/
self.
File "/usr/lib/
return self.client.
File "/usr/lib/
"NumUnits": num_units}})
File "/usr/lib/
raise EnvError(result)
jujuclient.
{ u'Error': u'service "client" not found',
u'ErrorCode': u'not found',
u'RequestId': 1,
u'Response': { }}
>
ERROR
Changed in juju-deployer: | |
status: | New → Confirmed |
importance: | Undecided → Low |
I get the same issue if I I wait for 'juju-deployer -f service' to return an error code for each service before continuing. I get this a lot with the local provider, but the traceback in the description is from a joyent deploy.