You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reverting between different versions of a job, with identical job spec, is a no-op. This mostly isn't a big deal, except that the state after job revert is probably not as expected.
Reproduction steps
(Job file below)
$ nomad job run -var id=a repro.nomad # create v0
$ nomad job run -var id=b repro.nomad # create v1
$ nomad job run -var id=a repro.nomad # create v2, spec identical to v0
$ nomad job status example
...
Allocations
ID Node ID Task Group Version Desired Status Created Modified
74185fab 4298f96a cache 2 run running 22s ago 11s ago
01ec7537 4298f96a cache 1 stop complete 1m10s ago 21s ago
b452ec74 4298f96a cache 0 stop complete 1m32s ago 1m10s ago
$ http localhost:4646/v1/job/example/versions | jq '.Versions[0]'> v0
$ http localhost:4646/v1/job/example/versions | jq '.Versions[2]'> v2
$ sdiff -s v2 v0 # these have identical spec"Version": 0, |"Version": 2,
"SubmitTime": 1617915598452144000, |"SubmitTime": 1617915668471469000,
"ModifyIndex": 17, |"ModifyIndex": 38,
"JobModifyIndex": 9 |"JobModifyIndex": 30
$ nomad job inspect example | jq '.Job.Version'# should be on v2
2
###### REPRO
$ nomad job revert example 0
==> Monitoring evaluation "077283c4"
Evaluation triggered by job "example"
Evaluation within deployment: "e7e2e902"
Evaluation status changed: "pending" ->"complete"
==> Evaluation "077283c4" finished with status "complete"
$ nomad eval status -json 0772 | jq '.JobModifyIndex'# should target v0, but it doesn't
30
$ nomad job inspect example | jq '.Job.Version, .Job.JobModifyIndex'# current job version is still v2
2
30
$ nomad job status example # allocs were not updated either
...
Allocations
ID Node ID Task Group Version Desired Status Created Modified
74185fab 4298f96a cache 2 run running 4m29s ago 4m18s ago
01ec7537 4298f96a cache 1 stop complete 5m17s ago 4m28s ago
b452ec74 4298f96a cache 0 stop complete 5m39s ago 5m17s ago
$ nomad alloc status -json 7418 | jq '.Job.Version'
2
$ nomad job deployments example # no new deployment
ID Job ID Job Version Status Description
8318c580 example 2 successful Deployment completed successfully
9ee4c16a example 1 successful Deployment completed successfully
9d7182e6 example 0 successful Deployment completed successfully
Expected Result
I think a reasonable expectation would be that after calling job revert example N, the eval would be targeting job version N and the resulting status would be that the job would be on version N.
Aside from that, it seems that the state of the system is consistent. The evaluation returned by job revert even indicates the resulting version (2).
This adds a Revert two-step button to the JobVersions component for
not-current versions, which redirects to the overview on success. It
checks the job version before and after reversion to mitigate the edge
case where reverting to an otherwise-identical version has no effect, as
discussed in #10337.
It uses existing facilities for handling other errors and disabling the
button when permissions are lacking.
Nomad version
Nomad v1.0.4 (9294f35f9aa8dbb4acb6e85fa88e3e2534a3e41a
Issue
Reverting between different versions of a job, with identical job spec, is a no-op. This mostly isn't a big deal, except that the state after
job revert
is probably not as expected.Reproduction steps
(Job file below)
Expected Result
I think a reasonable expectation would be that after calling
job revert example N
, the eval would be targeting job versionN
and the resulting status would be that the job would be on versionN
.Aside from that, it seems that the state of the system is consistent. The evaluation returned by
job revert
even indicates the resulting version (2
).Job file (if appropriate)
The text was updated successfully, but these errors were encountered: