These instructions assume you are using Minishift 1.0.1 or newer as your OpenShift installation.
You'll also need a wsk
binary in your $PATH
to interact with
OpenWhisk after it's deployed. Download the latest version for your OS
from https://github.com/apache/incubator-openwhisk-cli/releases/
First, start minishift and fix a networking bug in current releases:
minishift start
minishift ssh -- sudo ip link set docker0 promisc on
eval $(minishift oc-env)
Then, deploy OpenWhisk:
oc new-project openwhisk
oc create -f https://raw.githubusercontent.com/projectodd/incubator-openwhisk-deploy-kube/simplify-deployment-openshift/configure/openwhisk_openshift.yml
watch "oc get all"
Make sure all pods enter the Running state before moving on. If not, something is broken and start troubleshooting by looking in the logs of the failing pods.
The install-openwhisk-catalog-xxxxx
and
preload-openwhisk-runtimes-xxxxx
pods should transition from Running
to Completed as they finish installing the default OpenWhisk catalog
of packages and pulling the default OpenWhisk runtime container
images.
Then, wait until the controller recognizes the invoker as healthy:
oc logs -f $(oc get pods | grep controller | awk '{print $1}') | grep "invoker status changed"
You're looking for a message like invoker status changed to invoker0: Healthy
. Once you see that message, OpenWhisk is running and you need
to configure the client authentication to your controller:
export AUTH_SECRET=$(oc get configmap openwhisk-config -o yaml | grep 'AUTH_WHISK_SYSTEM=' | awk -F '=' '{print $2}')
export API_HOST=http://$(oc get route/controller --template={{.spec.host}})
wsk property set --auth $AUTH_SECRET --apihost $API_HOST
Finally, you're ready to test actions:
wsk list
wsk action invoke /whisk.system/utils/echo -p message hello -b
Now you can follow along with the OpenWhisk docs on creating actions.
Thanks for the feedback! You should be able to deploy this to any project / namespace you'd like, but I didn't want to imply that a specific namespace of
openwhisk
was required. And, you're right about looking at jobs instead of pods is a more reliable way and I'll think about a better way to know when the invoker is actually up.Good to know it worked!