implicit initContainer, added by jkube-volume-permission enricher, could brake deployment about jkube HOT 9 CLOSED

@vantonov1 Do you think this is related to #1179 ?

from jkube.

Yes, it is related. But #1179 was closed with "you could switch it off, if you know."
Problem is - no one knows :).
So, people get problems in production again and again. It is good functionality, but please, switch it off by default.

from jkube.

To disable the enricher you should configure the plugin as:

<plugin>
    <groupId>org.eclipse.jkube</groupId>
    <artifactId>kubernetes-maven-plugin</artifactId>
    <version>1.14.0</version>
    <configuration>
        <enricher>
            <excludes>
                <exclude>jkube-volume-permission</exclude>
            </excludes>
        </enricher>
    </configuration>
</plugin>

The other option would be to switch the permission enricher base image to something else that has the chmod command tool available and which is not subject to pull rate-limits.

from jkube.

@manusa : I think @vantonov1 is requesting to remove this enricher from the default profile as it can cause issues in production.

from jkube.

Yes, exactly. You could disable the enricher. AFTER you have failed release )

from jkube.

AFTER you have failed release

Could you please elaborate on this point?

from jkube.

I have dozens of services and decided to mount a volume to all. Everything was good on stage, but deployed to production we get couple of pod in ImagePullBackOff state - just because busybox could not be downloaded (rate limit, yes)

from jkube.

As a workaround for this very specific problem, we could consider using something different than busybox as the image for the volume-permission enricher init container that is not rate-limited by Docker.

from jkube.

I believe that this can be closed by #2570

from jkube.