Provide 'append_hash' for ConfigMaps and Secrets #196
Conversation
|
Hi @willthames. Thanks for your PR. I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with I understand the commands that are listed here. 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. |
555ef49 to
01adfed
Compare
|
@willthames, merged #197, can you rebase? |
01adfed to
1ab2154
Compare
|
@fabianvf rebased now |
|
hmm... I can see the benefit to adding the functionality that will allow the user to generate the hash, and then have them pass the new name into a get/create/delete/patch/replace call, but I'd prefer to keep the implementation of those main CRUD calls as generic as possible. How do you feel about taking out the changes to the dynamic client itself but leaving all the helpers + tests (and maybe adding a definition mutating function as well)? |
|
@fabianvf - I can quite understand those concerns, that all sounds reasonable to me, but I don't understand what you mean about adding a definition mutating function - what would that look like/do? |
|
@willthames, sorry, that was pretty unclear phrasing on my part. I meant a function that takes an object definition and returns an object definition with the hash appended to the name, like what you currently have inside the CRUD functions. |
1ab2154 to
7971854
Compare
7971854 to
8f95e2c
Compare
8f95e2c to
dc349a7
Compare
|
The problem with the name helper function is that you have to know beforehand whether the hash has already been added or not. It's easier to just update the name at that point to be name + hash rather than have a separate function. I think I'm fine with how this is now - let me know |
dc349a7 to
7da46cc
Compare
kubectl --append-hash adds a hash value to the name of a configmap or secret so that they can be used immutably. Using the same algorithms here, consumers of the dynamic client can generate the same hash that they can then append to a configmap or secret name.
7da46cc to
2153194
Compare
|
/cherrypick release-0.7 |
|
@fabianvf: new pull request created: #216 In response to this:
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. |
|
sweet I wasn't sure if we'd get the bot cherrypick stuff |
kubectl --append-hash adds a hash value to the name of a configmap or secret so that they can be used immutably. Using the same algorithms here, consumers of the dynamic client can generate the same hash that they can then append to a configmap or secret name.
kubectl --append-hash adds a hash value to the name of a configmap or secret so that they can be used immutably. Using the same algorithms here, consumers of the dynamic client can generate the same hash that they can then append to a configmap or secret name.
kubectl --append-hash adds a hash value to the name of a configmap
or secret so that they can be used immutably.
Using the same algorithms here, consumers of the dynamic client
can ask for a hash to be appended to a configmap or secret name.
To generate the hash requires the data, so
getanddeletehave been backwardly compatibly updated to accept parameters to
generate the hash