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

Document that some specific properties may not be removed when using kubectl apply #82525

Open
stephen-dexda opened this issue Sep 10, 2019 · 6 comments

Comments

@stephen-dexda
Copy link

commented Sep 10, 2019

Per #72519, serviceAccountName (and serviceAccount) are not removed when they are deleted from a resource spec. which is then passed to kubectl apply.

I hit this exact bug, and there is nothing in the docs at https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#kubectl-apply to warn about the existence of special cases like that.

If there is no obvious fix that would address non-removal of special cases, then this caveat should be mentioned.

@stephen-dexda

This comment has been minimized.

Copy link
Author

commented Sep 10, 2019

@kubernetes/sig-cli-bugs
@kubernetes/sig-auth-bugs

@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2019

@stephen-dexda: Reiterating the mentions to trigger a notification:
@kubernetes/sig-cli-bugs, @kubernetes/sig-auth-bugs

In response to this:

@kubernetes/sig-cli-bugs
@kubernetes/sig-auth-bugs

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@liggitt

This comment has been minimized.

Copy link
Member

commented Sep 11, 2019

/remove-sig auth
/remove-kind bug
/kind documentation

Defaulted fields cannot be unset without getting re-defaulted.

Fields that are represented in multiple places in the same object (like Pod spec.serviceAccount and spec.serviceAccountName) must both be updated or explicitly unset.

This is not specific to apply, but is reasonable to mention in documentation.

@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2019

@liggitt: Those labels are not set on the issue: sig/auth, kind/bug

In response to this:

/remove-sig auth
/remove-kind bug
/kind documentation

Defaulted fields cannot be unset without getting re-defaulted.

Fields that are represented in multiple places in the same object must both be updated or explicitly unset.

This is not specific to apply, but is reasonable to mention in documentation.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2019

@liggitt: Those labels are not set on the issue: sig/auth, kind/bug

In response to this:

/remove-sig auth
/remove-kind bug
/kind documentation

Defaulted fields cannot be unset without getting re-defaulted.

Fields that are represented in multiple places in the same object (like Pod spec.serviceAccount and spec.serviceAccountName) must both be updated or explicitly unset.

This is not specific to apply, but is reasonable to mention in documentation.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@stephen-dexda

This comment has been minimized.

Copy link
Author

commented Sep 11, 2019

Fields that are represented in multiple places in the same object (like Pod spec.serviceAccount and spec.serviceAccountName) must both be updated or explicitly unset.

I'd consider this behaviourally a bug, since the user can't know this without digging into the history/provenance of every property, and further because the state of the resource passed to apply currently depends on the previous state of the resource. A user would reasonably expect that the result of apply would be the same whether the resource was being created or updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.