Proposal
As mentioned in the docs, nomad plan...
...will return one of the following exit codes:
- 0: No allocations created or destroyed.
- 1: Allocations created or destroyed.
- 255: Error determining plan results.
I think it'd be good to offer either a different meaning to return codes or finer granularity adding a new rc status when there are changes even if they don't mean creating/destroying allocations. i.e.:
either:
0: No allocations created or destroyed.
1: Allocations created or destroyed.
2: Other pending changes that don't involve allocations' creation/destruction.
255: Error determining plan results.
or:
0: No pending changes detected.
1: Pending changes detected.
255: Error determining plan results.
The former would insure backwards compatibility, the later would be, I think, more useful and with low probability of bitting someone since the current rc meanings are basically unusable: as stated at #6589, current return codes in practice mean:
0: I'll do nothing. Well, maybe I'll do something after all, who knows.
1: I'll definitely do something.
Any other RC = An error. Except that there are other circumstances that will make fail the deploy, like lacking agents, or storage, or something like that, that may return a 0 -or maybe a 1?
Another approach might be adding a detailed-exitcode option to nomad plan, akin to what terraform does, for this use-case.
Use-cases
Anything script-based would benefit, especifically taking the decision of running a plan only when there are any kind of pending changes. As of now, current 3 declared return codes work effectively as just two:
- 0 or 1: you need to run
nomad apply even if there're no pending changes.
- any other: some kind of error.
Attempted Solutions
No one I can think of.
Proposal
As mentioned in the docs,
nomad plan...I think it'd be good to offer either a different meaning to return codes or finer granularity adding a new rc status when there are changes even if they don't mean creating/destroying allocations. i.e.:
either:
or:
The former would insure backwards compatibility, the later would be, I think, more useful and with low probability of bitting someone since the current rc meanings are basically unusable: as stated at #6589, current return codes in practice mean:
Another approach might be adding a detailed-exitcode option to
nomad plan, akin to what terraform does, for this use-case.Use-cases
Anything script-based would benefit, especifically taking the decision of running a plan only when there are any kind of pending changes. As of now, current 3 declared return codes work effectively as just two:
nomad applyeven if there're no pending changes.Attempted Solutions
No one I can think of.