-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't manualy fail deployment from buggy versions of nomad #4286
Comments
After some investigations we found a solution for this. We create fake jobs with same names as in buggy deployments, then we can fail them and clear with GC |
This PR cancels deployments that are active but do not have a job associated with them. This is a broken invariant that causes issues in the deployment watcher since it will not track them. Thus they are objects that can't be operated on or cleaned up. Fixes #4286
@tantra35 PR I just put up should clean them when upgrading to newer versions of Nomad. Don't want to add an endpoint since this isn't a case that should ever happen since it arouse from a bug that has since been fixed. |
I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues. |
Nomad version
Nomad v0.8.3 (c85483d)
Issue
We have some deployments which remained from old times of nomad v0.6.0 development and it bugs. So now we decide to fail this deployments because we periodically see in out server logs follow:
All this deployments shows as they running for example for deployment
354218d0-1f40-aa7d-6f9a-841a01e4d453
short notation354218d0
Since
S3apiCache
job doesn't actually exist we try to manually fail this deployment, and got the same error that we see in nomad server logsBecause this deployments stays after buggy versions of nomad I does;t think that this is a bug, but looks strange that nomad doesn't cleanup from not existent jobs, and doen't allow do manual cleanup
The text was updated successfully, but these errors were encountered: