Fix Helm binding errors

[yoshi-1224]

This PR aims to fix all the helm binding related issues.

Shifting from alpine docker image (fixes #358)

The Dockerfile in this PR is changed to FROM python:3.7-slim-stretch. This was chosen because it is one of the smaller debian images which have python 3.7 installed by default (the custom image is named as kapitan-debian below).

$ docker image ls
REPOSITORY           TAG                 IMAGE ID            CREATED             SIZE
kapitan-debian       latest              728041763c54        2 hours ago         1.04GB
deepmind/kapitan     latest              0670fbc69cde        4 days ago          860MB
python               3.7-alpine          39fb80313465        7 days ago          98.7MB
python               3.7-slim-stretch    7f8ea8958a02        7 days ago          155MB

I think the image size difference is not so bad (~ 160MB) given that musl-libc is going to be smaller than glibc to start with.

So far the image is working just fine (tested with the examples folder, plus helm binding works as well). Got decryption failed error when using --reveal option but I also get that using deepmind/kapitan image so I may just be doing it wrongly.

If this is acceptable, we can move on to change the base image of Dockerfile.ci as well.

Supporting subcharts

The binding should now correctly work with charts with subcharts

• fix Compilation fail with multiple ISTIO charts: fatal: morestack on g0 #362

[ademariag]

I think we should also fix Dockerfile.ci

[uberspot]

LGTM! I'd just add the same changes to Dockerfile.ci as well so that everything is on the same page.
But it can also be done in another PR too, up to you. 👍

[yoshi-1224]

@uberspot
Should we change the name of the helm binding shared object according to which platform this is targeted, just as we did for kapitan binary? In my understanding @ramaro wants the so distributed for each of Linux and Mac. I'm working on cross compile for OSX now, which hopefully takes us somewhere

[uberspot]

@uberspot
Should we change the name of the helm binding shared object according to which platform this is targeted, just as we did for kapitan binary? In my understanding @ramaro wants the so distributed for each of Linux and Mac. I'm working on cross compile for OSX now, which hopefully takes us somewhere

Sure, go for it!
Just don't forget to update the docs too if there's any mention of the .so there too. :)

[ademariag]

Is there an update on this?

[yoshi-1224]

Hi @ademariag
Sorry I'd been busy and couldn't really get on this task until now.

@uberspot
Could you please have a look at the new the docker CI image and confirm whether everything that was there on the previous alpine version is available as before?

[taharah]

Everything else looks good to me thus far.

[yoshi-1224]

@uberspot
what would be the most convenient way to build and distribute helm binding for Mac in addition to the existing Linux binding? Is cross-compiling on Travis the way, or do you think there might be an easier path (e.g. is it possible to build natively on OSX machine on Travis from which we can copy the built shared object file onto our Debian one)?

[ademariag]

May I suggest that we look at the helm binding in mac in another PR? I feel this one if getting more than it came for. This way we can unlock testing on the current state.

[yoshi-1224]

@ademariag
I totally agree. That way @taharah can get started on the multistage Docker image(s) too. @uberspot Let me work on OSX binding in another PR. I'm going to make this one ready for review.

[uberspot]

LGTM!

[uberspot]

@uberspot
what would be the most convenient way to build and distribute helm binding for Mac in addition to the existing Linux binding? Is cross-compiling on Travis the way, or do you think there might be an easier path (e.g. is it possible to build natively on OSX machine on Travis from which we can copy the built shared object file onto our Debian one)?

About this btw, https://docs.travis-ci.com/user/multi-os/ https://docs.travis-ci.com/user/reference/osx/ these two docs would cover how to run a specific test to build the OSX bindings in a different env too.

Merging this MR for now, and let's keep the OSX work in a separate PR. :)
Nice work!