You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by GitBox <gi...@apache.org> on 2021/01/06 13:26:24 UTC
[GitHub] [camel-k] lancerdima opened a new issue #1881: Corrupted binaries attached as resource
lancerdima opened a new issue #1881:
URL: https://github.com/apache/camel-k/issues/1881
Using #1750 as a reference.
### Problem
I am attaching binary resource (with `--resource`) to the integration and expecting it to appear in the container as a resource.
Original file size: 6733 bytes (binary, zip archive in its essence).
Executing command: `kamel run --dev --resource account.adm Integration.java`.
Result: reviewing pod, I see that the attached resource file size is 12255, thus corrupted, integration is unusable.
Attempts adding `--compression=true` flag (ar per #1750 suggestion) yields raw base64 text file in attached pod resource, that is unusable as a) it is base64, not binary, b) there is an extra compression applied on top of the file.
Using `kamel version` -> 1.3.
Also wondering, whether there is currently a way to attach resource to camel, directly from self-created configMap?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] squakez commented on issue #1881: Corrupted binaries attached as resource
Posted by GitBox <gi...@apache.org>.
squakez commented on issue #1881:
URL: https://github.com/apache/camel-k/issues/1881#issuecomment-766862259
The problem I see is that we mount a volume with file contents from `ConfigMap`s created from `Integration Resource`s. These are base64 encoded if they are binary or compressed. The problem we have with this approach is that we always require the application to take care of decoding prior using the binary content.
A possible workaround I found is to use directly binary `ConfigMap`s in order to let the kube cluster to take care of encoding/decoding by asking the user to create a specific one before the integration. However there seems to be some issue there too (see https://github.com/apache/camel-k-runtime/issues/593)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] nicolaferraro commented on issue #1881: Corrupted binaries attached as resource
Posted by GitBox <gi...@apache.org>.
nicolaferraro commented on issue #1881:
URL: https://github.com/apache/camel-k/issues/1881#issuecomment-756684961
Thanks for reporting, this behavior is strange.
Sure, there's a way to work this issue around and use data from manually created secrets/configmaps.
You need to link the integration to the secret using:
```
kamel run it.yaml --secret mysecret
```
If the secret has a property named `key`, then you can use the following property placeholder to reference it:
```
{{secret:mysecret/key}}
```
Full documentation: https://camel.apache.org/camel-k/latest/configuration/configmap-secret.html#_reference_a_secret_in_properties
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] nicolaferraro commented on issue #1881: Corrupted binaries attached as resource
Posted by GitBox <gi...@apache.org>.
nicolaferraro commented on issue #1881:
URL: https://github.com/apache/camel-k/issues/1881#issuecomment-756684961
Thanks for reporting, this behavior is strange.
Sure, there's a way to work this issue around and use data from manually created secrets/configmaps.
You need to link the integration to the secret using:
```
kamel run it.yaml --secret mysecret
```
If the secret has a property named `key`, then you can use the following property placeholder to reference it:
```
{{secret:mysecret/key}}
```
Full documentation: https://camel.apache.org/camel-k/latest/configuration/configmap-secret.html#_reference_a_secret_in_properties
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] lburgazzoli commented on issue #1881: Corrupted binaries attached as resource
Posted by GitBox <gi...@apache.org>.
lburgazzoli commented on issue #1881:
URL: https://github.com/apache/camel-k/issues/1881#issuecomment-765316130
eventually the information about the content should be added to the resource struct so it gets decoded only if it is needed (i.e. the application logic is already aware of the base64 encoding thus, decoding it could be an issue)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] squakez commented on issue #1881: Corrupted binaries attached as resource
Posted by GitBox <gi...@apache.org>.
squakez commented on issue #1881:
URL: https://github.com/apache/camel-k/issues/1881#issuecomment-766862259
The problem I see is that we mount a volume with file contents from `ConfigMap`s created from `Integration Resource`s. These are base64 encoded if they are binary or compressed. The problem we have with this approach is that we always require the application to take care of decoding prior using the binary content.
A possible workaround I found is to use directly binary `ConfigMap`s in order to let the kube cluster to take care of encoding/decoding by asking the user to create a specific one before the integration. However there seems to be some issue there too (see https://github.com/apache/camel-k-runtime/issues/593)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] squakez commented on issue #1881: Corrupted binaries attached as resource
Posted by GitBox <gi...@apache.org>.
squakez commented on issue #1881:
URL: https://github.com/apache/camel-k/issues/1881#issuecomment-765306800
So, the problem seems that the `Resource`s and `Source`s are correctly base64 encoded in order to be able to include binary contents in `ConfigMap`s. The `Source`s are later base64 decoded by the runtime, whilst the `Resource`s are left encoded. Since `Resource`s are meant to be consumed by the application the way they originally are I am going to include the base64 decode before writing the files on the container. I think that should solve the issue.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] squakez commented on issue #1881: Corrupted binaries attached as resource
Posted by GitBox <gi...@apache.org>.
squakez commented on issue #1881:
URL: https://github.com/apache/camel-k/issues/1881#issuecomment-764486356
I am having a look at this.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] squakez commented on issue #1881: Corrupted binaries attached as resource
Posted by GitBox <gi...@apache.org>.
squakez commented on issue #1881:
URL: https://github.com/apache/camel-k/issues/1881#issuecomment-764486356
I am having a look at this.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] astefanutti closed issue #1881: Corrupted binaries attached as resource
Posted by GitBox <gi...@apache.org>.
astefanutti closed issue #1881:
URL: https://github.com/apache/camel-k/issues/1881
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org