-
Notifications
You must be signed in to change notification settings - Fork 352
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
Usage of binary data in ConfigMaps #1946
Comments
I think the main reason was that configmap were supposed to hold configurations whereas to add arbitrary binary data there is a Maybe we should improve |
I've made some test in order to enhance |
* Any binary data will be using BinaryData ConfiMap instead of Data. We let the cluster to encode/decode the resource * Any text resource will be still using the Data (plain) ConfigMap * The `compression` feature can be run both on binary and text resources, providing a base64 encoded file. * Added unit test to check all the possible scenarios Close apache#1946, close apache#1881
* Added integration test for apache#1946
With apache#1946 we are no longer needing a special `compress-binary` flag
Include rawContent and contentType for resources Ref apache#1946
* Any binary data will be using BinaryData ConfiMap instead of Data. We let the cluster to encode/decode the resource * Any text resource will be still using the Data (plain) ConfigMap * The `compression` feature can be run both on binary and text resources, providing a base64 encoded file. * Added unit test to check all the possible scenarios Close apache#1946, close apache#1881
* Added integration test for apache#1946
With apache#1946 we are no longer needing a special `compress-binary` flag
Include rawContent and contentType for resources Ref apache#1946
* Any binary data will be using BinaryData ConfiMap instead of Data. We let the cluster to encode/decode the resource * Any text resource will be still using the Data (plain) ConfigMap * The `compression` feature can be run both on binary and text resources, providing a base64 encoded file. * Added unit test to check all the possible scenarios Close #1946, close #1881
* Added integration test for #1946
With #1946 we are no longer needing a special `compress-binary` flag
Include rawContent and contentType for resources Ref #1946
As a follow up of #1881 I am wondering if there is any reason why we are not using binary
ConfigMap
s. I was thinking to find some way and generate a binaryConfigMap
s when we detect any resource that is binary (and default to text if not). That would simplify the usage of a binary resource directly fromIntegration
s as we delegate kube cluster to mount a volume with the binary content.The text was updated successfully, but these errors were encountered: