provider/maas: StopInstances may fail if nodes are removed out of band
Bug #1319016 reported by
Andrew Wilkins
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
juju-core |
Fix Released
|
Low
|
Michael Foord |
Bug Description
The MAAS "release" operation will fail if any of the specified nodes are unknown. We should either parse the error and retry with the known IDs (ignoring unknown; we call release on StopInstances), or request an option in MAAS to ignore unknown IDs.
Changed in juju-core: | |
status: | Triaged → Fix Committed |
Changed in juju-core: | |
milestone: | none → 1.22 |
Changed in juju-core: | |
assignee: | nobody → Michael Foord (mfoord) |
Changed in juju-core: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Some more info that may be relevant here.
<bigjools> folks, when juju destroys an environment, does it keep issuing commands to destroy individual machines if it later notices that one is not in the state it expected (ie getting destroyed)? This might be provider-specific, in which case I'm talking about maas. pad.lv/ 1319016 /bugs.launchpad .net/maas/ +bug/1381619 /launchpad. net/bugs/ 1381619>
<bigjools> axw: you worked on the maas provider recently :) --^
<axw> bigjools: I'll check what it does
* xwwt has quit (Ping timeout: 260 seconds)
<bigjools> cheers
<axw> I think it issues a single release call
<axw> bigjools: http://
<axw> it does a single release API call
<axw> bigjools: why do you ask?
<bigjools> axw: because https:/
<mup> Bug #1381619: Failed to destroy-environment when node is in commissioning or new state <cloud-installer> <oil> <juju-core:Triaged> <MAAS:Triaged> <https:/
<bigjools> axw: ignore the bug title, look at what greg posted
<bigjools> I'll need to explain some background perhaps:
<bigjools> we added some more states. It used to go from ALLOCATED straight to READY as soon as an API call was issued to release the node, however now it goes via a RELEASING state
<bigjools> but because this broke some API users, we folded RELEASING into ALLOCATED so that API users never see it
<bigjools> I wondered if juju was issuing a release call, and still seeing ALLOCATED when in reality it's RELEASING, so juju issues another release?