| 2013-04-11 10:01:49 |
William Reade |
description |
`juju status` output has drifted away from compatibility with python. dditions are not a problem, but changes are; while some changes are unavoidable (eg, we have no independent concept of an error specific to a unit/relation pair any more) we should have a documented and overwhelmingly compelling explanation for every change we make.
For example, machine id type has changed, and should not have. |
`juju status` output has drifted away from compatibility with python. dditions are not a problem, but changes are; while some changes are unavoidable (eg, we have no independent concept of an error specific to a unit/relation pair any more) we should have a documented and overwhelmingly compelling explanation for every change we make.
Of these changes, of which I am aware:
* machine id type has changed to string across the board, to allow for consistent JSON and YAML output.
* unit now has a singular "error" status, and reports what hook failed in the info, rather than having install-error, start-error etc statuses. (hmm; gratuitous?)
* machine instance-state needs to be faked, because the provider capability is not present
* unit relation membership is not exposed, so we might need to fake it by cloning service relation membership (or expose the necessary info from state... shouldn't be too hard)
* machine agent-state values are changing to be consistent with unit agent-states |
|
| 2013-04-11 10:02:21 |
William Reade |
description |
`juju status` output has drifted away from compatibility with python. dditions are not a problem, but changes are; while some changes are unavoidable (eg, we have no independent concept of an error specific to a unit/relation pair any more) we should have a documented and overwhelmingly compelling explanation for every change we make.
Of these changes, of which I am aware:
* machine id type has changed to string across the board, to allow for consistent JSON and YAML output.
* unit now has a singular "error" status, and reports what hook failed in the info, rather than having install-error, start-error etc statuses. (hmm; gratuitous?)
* machine instance-state needs to be faked, because the provider capability is not present
* unit relation membership is not exposed, so we might need to fake it by cloning service relation membership (or expose the necessary info from state... shouldn't be too hard)
* machine agent-state values are changing to be consistent with unit agent-states |
`juju status` output has drifted away from compatibility with python. dditions are not a problem, but changes are; while some changes are unavoidable (eg, we have no independent concept of an error specific to a unit/relation pair any more) we should have a documented and overwhelmingly compelling explanation for every change we make.
Of these changes, of which I am aware:
* machine id type has changed to string across the board, to allow for consistent JSON and YAML output.
* unit now has a singular "error" status, and reports what hook failed in the info, rather than having install-error, start-error etc statuses. (hmm; gratuitous?)
* machine instance-state needs to be faked, because the provider capability is not present
* unit relation membership is not exposed, so we might need to fake it by cloning service relation membership (or expose the necessary info from state... shouldn't be too hard)
* machine agent-state values are changing to be consistent with unit agent-states
Anything not in the above list should be discussed and/or fixed. |
|
