Skip to content
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

Merged
merged 1 commit into from
Jul 25, 2019
Merged

Conversation

lblackstone
Copy link
Member

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, and
reverted the buggy await logic related to that apiVersion.

Fixes #611

@lblackstone lblackstone force-pushed the lblackstone/deployment-await-fix branch from d39e6fc to 7c6da3c Compare July 23, 2019 16:22
@hausdorff
Copy link
Contributor

Also we concluded that this partial revert breaks old versions of Deployment, right?

@lblackstone
Copy link
Member Author

Also we concluded that this partial revert breaks old versions of Deployment, right?

Right, as shown by the failing test. Instead of reverting, I'm working on fixing the workaround logic for the extensions/v1beta1 version.

@lblackstone lblackstone force-pushed the lblackstone/deployment-await-fix branch from 7c6da3c to 48a6953 Compare July 23, 2019 21:39
@lblackstone lblackstone force-pushed the lblackstone/deployment-await-fix branch 3 times, most recently from 69c3083 to 0c59e2d Compare July 24, 2019 21:04
pkg/await/apps_deployment.go Outdated Show resolved Hide resolved
pkg/await/apps_deployment.go Outdated Show resolved Hide resolved
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.
@lblackstone lblackstone force-pushed the lblackstone/deployment-await-fix branch from 0c59e2d to 35a0467 Compare July 25, 2019 20:28
Copy link
Contributor

@hausdorff hausdorff left a 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.

@hausdorff
Copy link
Contributor

Also note that this is not a fix for #611 any more. It is a fix for a related issue.

@lblackstone
Copy link
Member Author

@hausdorff Opened #656 to track the portion I'm not addressing here.

@lblackstone lblackstone merged commit 83dc10d into master Jul 25, 2019
@pulumi-bot pulumi-bot deleted the lblackstone/deployment-await-fix branch July 25, 2019 20:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

A failed Deployment update doesn't seem to fail
2 participants