package bind should support updating a binding

[alexkli]

Problem

Currently, wsk package bind can only create bindings, but not update them. Because it always sets overwrite=false.

Proposal

Would be nice to have either

• new update command such as wsk package bind-update
• always have wsk package bind set ovewrite=true

Motivation

Updating a package binding in one go is a useful feature to do e.g. "stack flips" with openwhisk, switching to a new code version deployed in a different package.

Details

I haven't found another way to update a package with wsk. Updating the binding works with the openwhisk HTTP API when setting overwrite=true:

https://openwhisk-service.com/api/v1/namespaces/<ns>/packages/<pkg>?overwrite=true

Example curl to update that <package> binds to <target-package:

curl -H "Authorization: Basic <auth>" -H "Content-Type: application/json" \
    -d '{"binding":{"namespace":"<target-namespace>","name":"<target-package>"}}' \
    https://<apihost>/api/v1/namespaces/<namespace>/packages/<package>?overwrite=true

[alexkli]

For others who might have the same need in the meantime, here is a little bash script named wsk-package-bind that does an update/overwrite:

#!/bin/bash

if [ $# -lt 2 ]; then
    echo "Usage: `basename $0` <pkg> <target>"
    echo
    echo "Creates or updates a package binding (symlink)."
    exit 1
fi

package="$1"
target="$2"

apihost=$(wsk property get -o raw --apihost)
auth=$(wsk property get -o raw --auth | base64)
namespace=$(wsk property get -o raw --namespace)

curl -X PUT -H "Authorization: Basic $auth=" \
    -H "Content-Type: application/json" \
    -d "{\"binding\":{\"namespace\":\"$namespace\",\"name\":\"$target\"}}" \
    "$apihost/api/v1/namespaces/$namespace/packages/$package?overwrite=true"

[jiangpengcheng]

this is a great idea, how about adding a boolean flag like overwrite to wsk package bind?

it would be great if you have time to create a PR for this, if not, I can do it later

[purplecabbage]

I think this is can be closed

[alexkli]

Haven't tested it since then but seems very much like #474 addressed this.