-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
patch_namespaced_secret does not delete keys when passing them via string_data #2262
Comments
/assign We should have some example on patch types (JSON, JSONMERGE, STRATEGIC). Let me find some examples |
@roycaihw thank you for responding. Please note that I think I understand how to remove a key from a secret by patching it. In my code example above, let's look at the last line. This deletes the key
Where this does not delete it, but I would expect it to be deleted:
|
@roycaihw Any updates? |
Sorry for the delay and thanks for the clarification! @mpw96 #2262 (comment) I suspect this may be a server-side issue. As I've seen multiple upstream issue discussing the different behavior between data and string_data:
The behavior in kubernetes/kubernetes#123843 seems to be similar to your use case, and it was suggested that server-side apply may help in this case. It's supported in the dynamic client: python/kubernetes/base/dynamic/client.py Line 152 in 4da83df
|
What happened (please include outputs or screenshots):
I want to remove a key from a secret. So I'm creating the patch data with a
None
value for this key. This key is not deleted (secret is unchanged).What you expected to happen:
The key is deleted.
How to reproduce it (as minimally and precisely as possible):
Create a secret
my-secret
in some namespacempw
. It should contain a keytest
with some value.Then run this program:
Anything else we need to know?:
Note that I'm passing the
secret_data
to the parameter string_data. When I passing it to data, the key is deleted as expected.Environment:
kubectl version
): Server Version: v1.29.3python --version
): Python 3.11.9pip list | grep kubernetes
): kubernetes 30.1.0The text was updated successfully, but these errors were encountered: