OpenWhisk Docker Image for Edge component.

[ghost]

I have seen that there were a bunch of OpenWhisk Docker images for all of the components which is pretty cool. It would be nice to also have an image for Nginx that has all of the extra pieces already baked into it like the CLI and SDKs. This we we would not have to build them and upload them as part of the deployment process.

[rabbah]

@csantanapr is this done?

[csantanapr]

not sure how to go about this one.
Do we create the edge docker image instead of using a mount volume we add the files to the image, what about the configuration do we pass this info as environment variables to replace the template on start of the container?

[ghost]

@csantanapr the "Edge" image will need to mount in the certs and nginx.conf file since those are environment specific. the "Edge" Docker Image should just need to comprise of the public Nginx image plus any of the CLI/SDKs prebuilt into it.

This means that the current Ansible scripts should more or lest just work as they are. Minus the need to already have the cli prebuilt and build the BlackBox tarball.

Then When deploying Kubernetes, you can take a look at this README for how configuring those same values would go.

[dgrove-oss]

The only barrier to using a vanilla docker image for nginx now is this stanza in nginx.conf:

        location /cli/go/download {
            autoindex on;
            root /etc/nginx;
        }

I can see four ways to deal with this:

1. Redirect the generic /cli/go/download to the incubator-openwhisk-cli release page. (Ok if this route is intended for interactive human consumption. Not so nice if we're scripting against it).
2. Have stanzas for the CLI for each platform that we support that redirects the download to the right release tar ball (not nice if people are used to exploring the available downloads).
3. Do both 1 and 2.
4. Decide that we really want to do auto-indexing and so commit to always needing to copy in the CLI binaries to /etc/nginx/cli/download/os/arch/cli.zip.

If we need to take path 4, I think I can do it with an InitContainer in Kubernetetes so we could use a vanilla nginx image + a custom image to do the download of the CLI to the right place in the running containers file system.

@rabbah @csantanapr opinions on what this should look like when we are done?

[csantanapr]

I like option 3
I have being thinking on updating and having additional option on no longer copying the CLI and instead doing redirect

We already cleaned up this way the swift sdk and the docker/blackbox sdk

[dgrove-oss]

ok. I'll plan on submitting a PR for 3 on Monday unless Rodric weighs in with a different opinion.

[csantanapr]

Hi @dgrove-oss
Today we have in ansible two modes local and remote
The variable is openwhisk_cli.installation_mode
https://github.com/apache/incubator-openwhisk/blob/master/ansible/group_vars/all#L310-L317
Today the default is "remote" this pulls down the cli, copy the files, and mounts the volume.

One way to do it is to introduce a 3rd option for openwhisk_cli.installation_mode, local, remote and remote_redirect
WDYT?

[dgrove-oss]

I'm wondering if we need anything other than remote_redirect (just like the SDKs are now). If the core project supports multiple modes, then people might still be depending on having the CLI installed into the nginx image, so I probably have to support the same set of options in the kube variant.

[rabbah]

These routes may be overridden in a custom deployment. So for the defaults I think we should point to the official download sites and defer to private deployments to support alternate packaging.

[csantanapr]

I would say going forward we only support redirect mode, and do it for kube like that.
And say that having the CLI installed into the nginx is deprecated eventually remove.

[csantanapr]

Custom deployment have their choice on how they want to distribute the CLI, it's open based on their use case.

[dgrove-oss]

Sounds good to me. I'll do a PR to change nginx.conf to have the redirects