-
Notifications
You must be signed in to change notification settings - Fork 117
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
Fix Deployment await logic #646
Conversation
d39e6fc
to
7c6da3c
Compare
Also we concluded that this partial revert breaks old versions of |
Right, as shown by the failing test. Instead of reverting, I'm working on fixing the workaround logic for the |
7c6da3c
to
48a6953
Compare
69c3083
to
0c59e2d
Compare
The Deployment await logic was incorrectly checking for the `extensions/v1beta1` apiVersion, which was causing the await logic to erroneously pass for change triggered rollouts, even if the Deployment was invalid. The fix required two changes: 1) For some reason, the resource client was defaulting to the `extensions/v1beta1` apiVersion, even though recent versions were available on the cluster. Updated the client to prefer newer apiVersions. 2) Updated await logic for the old apiVersion to use the input object rather than a received watch Event. Regardless of the apiVersion of the received watch Event, the relevant status field will be missing if the Deployment was created with the `extensions/v1beta1` API.
0c59e2d
to
35a0467
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is smoke tested we should ship this as is and come back to the extensions/v1beta1
.
Also note that this is not a fix for #611 any more. It is a fix for a related issue. |
@hausdorff Opened #656 to track the portion I'm not addressing here. |
The Deployment await logic had a bug for the old
extensions/v1beta1
apiVersion which was causing the await logic to erroneously pass for
change triggered rollouts, even if the Deployment was invalid.
For some reason, the resource client was defaulting to
the old apiVersion, even though recent versions were available on the
cluster. Updated the client to ignore
extensions/v1beta1
, andreverted the buggy await logic related to that apiVersion.
Fixes #611