openwhisk-cli
openwhisk-cli copied to clipboard
Export package parameters in the format needed for import
(I couldn't find an issue where this had already been discussed, I apologise if this is a duplicate or I'm creating noise)
My use case: copying parameters from one action to another
- when you add a database and refresh the package list, the parameters you want are on the wrong package and it's tedious to get them from one place to another
- when I wanted to test some changes to my openwhisk package without hurting what's already live, I wanted to copy the package - it's easy to redeploy but I needed the package parameters.
To get the parameters from a package, we do: wsk package get [packagename] parameters
which outputs something like:
ok: got package firstpackage, displaying field parameters
[
{
"key": "slackURL",
"value": "https://hooks.slack.com/blah/blah"
},
{
"key": "cloudantURL",
"value": "https://wibble-squeak-bluemix.cloudant.com"
},
{
"key": "dbname",
"value": "awesomedb"
}
]
To supply these parameters to another package (e.g. for testing, or allowing another team member to match my config) the format I want is:
{
"slackURL": "https://hooks.slack.com/services/blah/blah",
"cloudantURL": "https://wibble-squeak-bluemix.cloudant.com",
"dbname": "awesomedb"
}
With the above in a file called params.json
I can then to wsk package create mypackage -P params.json
.
Would it be desirable to offer this format (ideally without the extra verbose output as the first line as we have now) as an option? It's a small thing and I appreciate that patches are probably welcome, but is this a useful addition for anyone other than myself?
Related to https://github.com/openwhisk/openwhisk/issues/2062 for quiet mode requirement.
We have in the past considered changing the representation of parameters (and annotations) to a dictionary instead of the current array of key-value pairs. This on the one hand would also resolve this issue, but on the other is a breaking API change better left for "v2" perhaps.
A forward compatible switch in v1 would be nice so that the v1 users can migrate to the v2 format before going to v2? (Unless of course, v2 is imminent…)
Definitely not suggesting a breaking change, but an additional option for formatting this output. Especially if we would consider doing this for v2, then having it behind a switch to have people try it and offer feedback in the current version seems valuable. I'm just hesitating to create a patch if it won't be accepted.
This is a tooling issue. It's true we can make an API change but that's not what's being requested here. Going to close/transfer to the CLI repo.