Corrupted binaries attached as resource

[lancerdima]

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?

[nicolaferraro]

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

[squakez]

I am having a look at this.

[squakez]

So, the problem seems that the Resources and Sources are correctly base64 encoded in order to be able to include binary contents in ConfigMaps. The Sources are later base64 decoded by the runtime, whilst the Resources are left encoded. Since Resources 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.

[lburgazzoli]

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)

[squakez]

The problem I see is that we mount a volume with file contents from ConfigMaps created from Integration Resources. 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 ConfigMaps 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 apache/camel-k-runtime#593)