@dubeejw commented on Tue May 23 2017

$ wsk action create actionName hello.js --timeout 30303030300303030303003

invalid argument "30303030300303030303003" for --timeout: strconv.ParseInt: parsing "30303030300303030303003": value out of range

$ wsk action create actionName hello.js --timeout asdf

invalid argument "asdf" for --timeout: strconv.ParseInt: parsing "asdf": invalid syntax

@lzbj commented on Tue Jul 11 2017

@dubeejw , I think this kind of error is throw by cobra package, right? can we control it?

@dubeejw commented on Wed Jul 12 2017

I believe we can control the error message if we surround the strconv.ParseInt method calls in a try/catch, @lzbj. Will look to make sure.

@rabbah commented on Tue Feb 28 2017

wsk activation poll formats its output in a way that might be confusing:

Activation: hello (ce78012710e04ba79b3881d2575c7e0f)
[
    "2017-02-28T14:47:56.993327423Z stdout: hello world!",
    "2017-02-28T14:47:56.993327523Z stdout: hello again!",
]

why show the []?

Further it might be nice to add back the --strip option to remove the date/std[out,err] prefix.
Lastly in the summary, should show/color-code in the header if the activation was a success or not.

@rabbah commented on Fri Sep 29 2017

--strip is now available again.

@rabbah commented on Thu Aug 03 2017

Reported by @ptitzler.

The error status is properly reported if the first command name is invalid. However, if an invalid subcommand is specified the returned status code is zero instead of non-zero.

$ wsk pa
Error: unknown command "pa" for "wsk"
Did you mean this?
    package
    api
Run 'wsk --help' for usage.
unknown command "pa" for "wsk"
Did you mean this?
    package
    api
$ echo $?
1
$ wsk package xxx
work with packages
Usage:
  wsk package [command]
Available Commands:
  bind        bind parameters to a package
  create      create a new package
  update      update an existing package, or create a package if it does not exist
  get         get package
  delete      delete package
  list        list all packages
  refresh     refresh package bindings
Global Flags:
      --apihost HOST         whisk API HOST
      --apiversion VERSION   whisk API VERSION
  -u, --auth KEY             authorization KEY
      --cert string          client cert
  -d, --debug                debug level output
  -i, --insecure             bypass certificate checking
      --key string           client key
  -v, --verbose              verbose output
Use "wsk package [command] --help" for more information about a command.
$ echo $?
0

If you try to add an API to an action that isn't a web action, you get the following error.

error: API action '/_/parent' is not a web action. Issue 'wsk action update /_/parent --web true' to convert the action to a web action.
Run 'wsk --help' for usage.

Can we have a flag to make the api command automatically add the annotation if it is missing?

We need to discuss what the best plan is for setting up repos. Do we include go-whisk and go-whisk-cli in the same repo, or separate repos? @csantanapr, @mdeuser

Related to apache/openwhisk#2399

i can't grep 'foo$' in the output of wsk activaton list, because the lines end with a bunch of whitespace

e.g. i want to look for lines that end with my selected action name, because i might have both "foo" and "foo-rule", so i can't just grep for foo (yes, i can grep -v foo-rule, but this seems like an easy thing to fix in the CLI)

@sjfink commented on Mon Apr 17 2017

$ wsk property get --namespace
whisk namespace	      _

I propose wsk property get --namespace should always return the explicit name of the default namespace, and not _ or default.

@sroorda commented on Fri Sep 15 2017

Environment details:

• local deployment, vagrant, native ubuntu, Mac OS, Bluemix, ...
• version of docker, vagrant, ubuntu, ...
  Deployed to Bluemix api.ng.bluemix.net

It appears that if you invoke your Cloud Function via the CLI it will fail with
error: Unable to invoke action 'nestedDictionaryError': The connection failed, or timed out. (HTTP status code 200) if you include a key labeled response in your output.

Steps to reproduce the issue:

Create the following Cloud Function in python

def main(args):
    result = {'message': 'error result', 'response': {'key1': 'value1','key2': 'value2' }}

    if args and args['resultType'] and args['resultType'] == 'error':
        return {'message': 'error result', 'response': {'key1': 'value1','key2': 'value2' }}
    else:
        return {'message': 'error result', 'not_response': {'key1': 'value1', 'key2': 'value2'}}

Provide the expected results and outputs:

Provide the actual results and outputs:

Fails

wsk action invoke --result nestedDictionaryError --param resultType "error"
error: Unable to invoke action 'nestedDictionaryError': The connection failed, or timed out. (HTTP status code 200)
Run 'wsk --help' for usage.

Works

wsk action invoke --result nestedDictionaryError
{
    "message": "error result",
    "not_response": {
        "key1": "value1",
        "key2": "value2"
    }
}

Even if response is reserved we should get a better message than that.

Additional information you deem important:

• issue happens only occasionally or under certain circumstances
• changes you did or observed in the environment

@cfjedimaster commented on Mon Oct 23 2017

It would be nice if there was a quick way to get stats about an action. So something like:

wsk stats ACTIONNAME

Which would report a very brief summary:

ACTIONNAME has had X invocations in 24h. Average duration is 219ms. Error rate is 2%

Obviously Bluemix's online reporting can show some of this and you can build your own tools to report similar values, but I'm thinking that the CLI could provide a quick summary of your action and that could be pretty useful.

@dubeejw commented on Wed Mar 22 2017

CLI code is hard to read as the externalized string package being used requires a map of keys and values. This process should be abstracted to make the code more readable.

@dubeejw commented on Wed Mar 22 2017

@csantanapr, @mdeuser, this is technical debt, and should be fixed ASAP.

@csantanapr commented on Thu Mar 23 2017

Looking forward to a PR :)

@rabbah commented on Thu Mar 23 2017

As part of doing this, consider: adding quiet mode which omits "ok:" and "error:" lines so that raw Json responses are more amenable to post processing.

@markusthoemmes commented on Thu Mar 23 2017

Alternatively: --json or --raw to explicitly make the output machine-readable?

@dubeejw commented on Thu Mar 23 2017

@markusthoemmes, @rabbah, a flag like --raw would be accomplished through this issue: apache/openwhisk#2064.

@akrabat commented on Wed Apr 12 2017

A quiet mode would be handy for property get too. That way I wouldn't need to do this:

wsk property get --cliversion | rev | cut -f1 | rev

@rabbah commented on Sun Jun 11 2017

> WSK_CONFIG_FILE= wsk property get --all
error: The API host is not valid: An API host must be provided.
Run 'wsk --help' for usage.

If I'm trying to get all the properties, I think the CLI should just show what is set and what isn't.

Trying to override this:

> WSK_CONFIG_FILE= wsk property get --all --apihost xxx
whisk auth		
whisk API host		
whisk API version	v1
whisk namespace		_
whisk CLI version	2017-06-09T21:18:47+00:00
whisk API build		Unknown
whisk API build number	Unknown
error: Unable to obtain API build information: Get openwhisk.ng.bluemix.net/v1: unsupported protocol scheme ""

Seems to show there's a baked in reference to bluemix somewhere: https://github.com/apache/incubator-openwhisk/blob/master/tools/cli/go-whisk/whisk/client.go#L36 which should not be present, and looks like a bug since the default does not seem to hold if that was intended.

@rabbah commented on Tue May 16 2017

create a trigger with a feed

> wsk trigger create t --feed cloudant/changes 
ok: invoked /_/cloudant/changes with id xyz
{
    "activationId": "xyz",
    "response": {
        "result": {},
        "status": "success",
        "success": true
    },...
}
ok: created trigger myCloudantTrigger

then delete it:

> wsk trigger delete t
ok: invoked /.../changes with id xyz
{
    "activationId": "xyz",
    "response": {
        "result": {},
        "status": "success",
        "success": true
    }, ...
}
ok: deleted trigger t

is it intentional to show the feed action activation?

@mdeuser commented on Thu May 18 2017

@dubeejw - was this the desired behavior? this additional output comes from invoking the action invoke cli command method under the covers. calling the lower level action invoke method would avoid displaying the action invocation output.

@cfjedimaster commented on Fri Dec 23 2016

There is no available command to wsk that returns the version of the CLI installed.

@rabbah commented on Fri Dec 23 2016

Try: wsk property get -h

@cfjedimaster commented on Fri Dec 23 2016

Confirmed this works: wsk property get --cliversion

However, this should be exposed on the top level help screen. It is a pretty common feature (imo) should be made more evident.

@rabbah commented on Thu Jan 05 2017

Sure wsk --version makes sense as an alias.

@dubeejw commented on Wed Jan 11 2017

Looks like there is two different converstations going on here. One about the wsk CLI and the other about wskdeploy.

@rabbah commented on Wed Jan 11 2017

This issue should address wsk not wsk deploy.

@lzbj commented on Mon Jan 16 2017

@rabbah, is this one we need fix or not?

@rabbah commented on Mon Jan 16 2017

We should add wsk --version and it would be great to also add an auto update feature as well or at least notify the user there is a newer version.

@markusthoemmes commented on Mon Jan 16 2017

We'll need to improve our build processes to not create a new CLI version if no code has changes, as the CLI is currently versioned by date and you don't want to notify users everytime a new OpenWhisk is deployed.

@rabbah commented on Mon Jan 16 2017

Agree - the date was more intended to show the build date, not the actual version. We could adopt semantic versioning and do it manually to get going.

@lzbj commented on Mon Jan 16 2017

manually you mean we pass in build number as arguments everytime we updated code?

@dubeejw commented on Tue Jan 17 2017

A new CLI is not created if the code has not been changed as long as there is already a Docker container of the built CLI in the cache.

@lzbj commented on Thu Jan 19 2017

Ok, got it.

It would be nice if it just made the package for you when you run the action create or update command.

Thanks 👍

(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?

for example

        {
            "ImportPath": "github.com/apache/incubator-openwhisk-client-go/whisk",
            "Rev": "f26793c94fd6883867eaa98ed8249024128cbcc6"
        },
        {
            "ImportPath": "github.com/apache/incubator-openwhisk-client-go/wski18n",
            "Rev": "f26793c94fd6883867eaa98ed8249024128cbcc6"
        }

OpenWhisk CLI project needs to have its integration tests running against OpenWhisk. The current CLI tests are running inside openwhisk and they are written in scala. As a separate project, we need to have the tests written in Go, and establish the test environment in Travis.

Travis CI supports Go project only under Linux so far. It deserves more investigations for Go project under mac and windows.

@cfjedimaster commented on Mon May 22 2017

I filed a bug report on "wsk activation poll -h" not making it clear that it can match by name as well, but I want to expand on the feature in general. It feels like the name matching isn't very robust. It's also possible I'm not doing this right, but this is where better docs would help.

I've got an action called makeresult that lives in the serverless_superman package. The only way I can see to poll for it is to poll JUST for 'makeresult'. If I try /serverless_superman/makeresult, it will not match. If I've got 10 packages with makeresult in it, then I'll get a lot of noise back.

If I need to also provide a namespace, than I'd consider that a bug as well. It would work, but the CLI should just default to my namespace anyway. (And again, it should be documented.)

Also, there seems to be no way to get everything called within one package. (Again, unless I'm running it wrong.)

@rabbah commented on Mon May 22 2017

confirmed bug - you can name an action in the default package but not an action in a named package.

it may be possible to support polling on all actions in a package as part of the same fix.

@dubeejw commented on Thu Jun 22 2017

I had a PR open to update the activation poll usage, but was informed that activation IDs may not apply to rules and triggers in the future. I can update the usage to just mention actions though. See: apache/openwhisk#2398.

@dubeejw commented on Thu Jun 22 2017

Linked the PR to the proper issue.

For example, wsk action list will display 30 actions by default. I should be able to save a non-default value for the limit in wskprops allowing wsk action list to read the stored non-default limit from properties.

Possible usage:
$ wsk property set --actionlistlimit 50

$ wsk action list
actions
action1
...
action50

@csantanapr commented on Thu Apr 27 2017

The WSK CLI would need to be adjust , today by default the support export admin cfg file, and import the same admin cfg, it's not a swagger file for consumers.

The WSK CLI would need to be updated with a flag to indicate that the desire output is for consumers of the API (ie wsk api get --consumer > consumer_client_swagger.json)

The file will be ready to be use as it will have the full basePath and host client can use to call the APIs.
The full basePath and host (i.e. 172.17.0.1:9001) that a consumer API consumer would use say with curl will be constructed from the managedUrl value we get back from API Gateway management interface.

@dubeejw commented on Wed Oct 18 2017

When creating an action, we should assume the action name will match the filename if an action name is not provided. (1) For instance, if a filename of someAction.js is specified without an action name, we would create the action named someAction. (2) In the case were only one argument is passed without a file extension and a kind is specified, we can assume that the argument is a filename. (3) The same holds true if a file extension is passed that does not map to a runtime, but a kind is specified.

The action create usage would be changed to the following:

Usage:
  wsk action create [ACTION_NAME] ACTION [flags]

$ wsk action create someAction.js
ok: created action someAction

$ wsk action create someAction --kind nodejs:6
ok: created action someAction

$ wsk action create someAction.someExt --kind nodejs:6
ok: created action someAction

@dubeejw commented on Wed Oct 18 2017

@mdeuser, @drcariel, @jessealva, @csantanapr, thoughts on the above?

@mdeuser commented on Wed Oct 18 2017

What happens in the case of wsk action create myaction, where myaction is a file? i guess this should fail since the runtime is not known.

Same changes for wsk action update, which can also be used to create an action ?

@dubeejw commented on Wed Oct 18 2017

In that case, we would have to fail if a kind is not specified and an extension that does not map to a valid runtime is not provided.

Same changes would apply for the update command.

@drcariel commented on Thu Oct 19 2017

in scenario 2, the CLI would need to complete the file extension based on the kind flag in order to find the correct local file, right?

Im a bit confused by the 3rd scenario, would the extension need to match the kind? what happens if they do not match?

@dubeejw commented on Thu Oct 19 2017

Scenario 2 and 3 are essentially the same. If a kind is not specified, we try to figure out the kind by checking the file extension. If a kind is not specified we need to error if the extension is not present or unknown. When a kind is specified we will always use that and forego checking the file extension. We currently do this today, and it would be applied to the scenarios above.

@mrutkows commented on Thu Oct 19 2017

IMO, the CLI should be careful in not inferring too much from too little in CRUD operations... and if assumptions or inferences are made, the user needs to be informed/warned of this additional behaviors.

Entity naming and Namespacing is becoming more and more important with Compositions so making these assumptions could cause unintended consequences for user/customers composing solutions with hundreds of actions.

"Hard to misuse":
https://swaggerhub.com/blog/api-design/api-design-best-practices/

@drcariel commented on Thu Oct 19 2017

I agree with @mrutkows , I think it's important to inform the user that these assumptions are being made in real time.

@rabbah commented on Thu Oct 19 2017

Less magic FTW and clarity. What's the point of saving the user from .js or .py it's not that many more characters and potentially confusing. Maybe I missed the rationale here.

@dubeejw commented on Thu Oct 19 2017

No API changes here. This is a usability issue to allow the user to type less information when creating/update an action. Ie, not having to provide an action name. The CLI will continue to work as it does today when creating/updating actions even with the changes mentioned above.

@dubeejw commented on Thu Oct 19 2017

To be more clear, here are some more examples.

Say the user wants to create an action that has the same name as his or her filename. Instead of the user having to type duplicate information, we only need the filename to be provided. Ex:

$ wsk action create myActionName.js
ok: created action myActionName

The CLI would still work as it does today allowing a filename and an action name if the user wants the action name to differ from the filename:

$ wsk action create myAction myActionName.js
ok: created action myAction

@rabbah commented on Thu Oct 19 2017

I get that it's client only - I'm just not sure I like the automatic inference here. Note that the CLI change is actually going to change behavior (1 is an error today, and will work after these changes).

@drcariel commented on Thu Oct 19 2017

I can see the value in the 1st use case. Maybe the scope should be limited to this?

2 is where I see more user complications
( For example: different files with the same name but different extensions etc..)

3 still doesn't make sense to me, but I am not sure how it works in it's current state TBH.

@rabbah commented on Thu Oct 19 2017

I can see the value in the 1st use case. Maybe the scope should be limited to this?

yeah maybe... but also feel that if you're doing anything serious you're going to use a deployment framework like wskdeploy or you're writing your own scripts. I could be convinced to buy into 1.

wsk action create foo.zip --kind nodejs:6

do you want that to work? I think that's maybe a use of 3.

@dubeejw commented on Fri Oct 20 2017

Scenario two and three are just to keep in sync with the same type functionality that currently works with --kind. Currently the filename extension is disregarded if a kind is specified.

I think zip files would fall under the third scenario.

@drcariel, good point above same filenames with different extensions.

For me at least, I find that I create a lot of different actions to test the backend manually. Having to type an action name all the time just seems redundant when I name the file appropriately.

@mrutkows commented on Fri Oct 20 2017

@dubeejw @rabbah as long as the CLI (API) provide the "clean contract" to the users... I agree with Rodric that the CLI should provide plain/straightforward functionality with known (contracted) results and higher-order tooling should provide the interaction/fuzzy logic.

If the CLI is performing logic based upon some inference of user intent, then that provides less assurance to tooling built on top. I would rather have success/fail from the CLI with clear return codes and not have any other extended logic where possible.

@jessealva commented on Mon Oct 23 2017

Just caught up. I think I agree with @rabbah and @mrutkows . Although the changes seem small and should not cause problems, the fact that the cli is really mostly an entry point for higher order usages it makes sense that its more reliable in its usage than providing shortcuts.

In the end, i rarely ever type things over and over, even when outside of higher level tooling I'll use the up arrow or command history to rerun the command, so don't ever need to type the command out once. Not entirely sure why we really need this.

@dubeejw commented on Mon Oct 23 2017

Good discussion. Actually found a bug in the existing code when looking into action create (apache/openwhisk#2887).

@dubeejw commented on Mon Oct 23 2017

I have started implementing the suggestions here for my own personal usage as it makes things easier for me.

@dubeejw commented on Mon Oct 23 2017

Looks like we currently allow actions to be created with only the action name when creating docker actions.

Ex:

$ wsk -i action create dockerContainer --docker bogusihxfy6q5ssatqazy

There readme should information on how to run tests

@mdeuser commented on Mon Aug 14 2017

Environment details:

• Bluemix

Steps to reproduce the issue:

1. Create an action (normal action or web action) that returns a promise that's resolved with a JSON object

function main(args) {
   return new Promise((resolve, reject) => {
       resolve({"response":{"SomeField":1}});
   });
}

2. Invoke the action via CLI using the -b and -r options
3. Compare results to invoking action with just the -b option

Provide the expected results and outputs:

Exit code of 0 and output:

{
  "response": {
    "SomeField": 1
  }
}

Provide the actual results and outputs:

Exit code of -56 and output:

error: Unable to invoke action 'YOUR-ACTION': The connection failed, or timed out. (HTTP status code 200)
Run 'wsk --help' for usage.

@cfjedimaster commented on Mon Aug 14 2017

To add a bit more context, it seems to revolve around the name of the key and the value. When I change "response" to anything else, it works. If I change the value to a simple string, it works. If I change the value to an array, it works. As soon as I use: "reponse":{ ...} it fails via the CLI. The code runs 100% fine though. In my original code, I was using Twitter's API to send out a tweet and it ran fine, it's just the error in the CLI.

@rabbah commented on Mon Aug 14 2017

I'll guess this has to do with the cli searching for "response" which is also part of the schema for an activation.

@GabrielNicolasAvellaneda commented on Tue Sep 26 2017

developer@ubuntu:~/openwhisk$ cat ~/.wskprops 
# Bellow is an empty line and then we set the namespace

NAMESPACE=my-namespace # This is an inline comment

# This API host is for the dev environment
APIHOST=http://dev.openwhisk.local:10001

developer@ubuntu:~/openwhisk$ bin/wsk property set --apihost http://test.openwhisk.local:10001
ok: whisk API host set to http://test.openwhisk.local:10001

developer@ubuntu:~/openwhisk$ cat ~/.wskprops 
APIHOST=http://test.openwhisk.local:10001
NAMESPACE=my-namespace # This is an inline comment

@rabbah If this makes sense please assign this to me. Thanks!

@GabrielNicolasAvellaneda commented on Tue Sep 26 2017

@rabbah Is it safe to do changes in this project instead of the incubator-openwhisk-cli repository? Are you syncing repos?

@rabbah commented on Tue Sep 26 2017

go for it - indeed they're kept in sync until the cord is cut.

Other tools based on the same Cobra CLI framework have autocompletion support. This might make wsk CLI more user friendly.

spf13/cobra#69
https://kubernetes.io/docs/tasks/tools/install-kubectl/#enabling-shell-autocompletion

After the code here keeps updated with the latest Go CLI, we should make sure the Go CLI can be built into binaries either locally or by docker container.

@dubeejw commented on Wed Mar 22 2017

The error type in the CLI should be refactored as a linked list. This will eliminate the need to manually concatenate error messages whenever an error occurs.

@dubeejw commented on Wed Mar 22 2017

@csantanapr, @mdeuser, this is technical debt, and should be fixed ASAP.

@mdeuser commented on Thu Mar 23 2017

@dubeejw - is there a particular failure that you are seeing?

@markusthoemmes commented on Wed Feb 08 2017

When uploading a large zip file (and we support up to 48 Megabyte) I get no indication of the progress of my upload. It would be a nice feature to have to show progress like wget.

Under mac, linux and other major operating systems, openwhisk cli needs to be installed by software management tools, like homebrew, apt-get, gem, etc.

@l2fprod commented on Wed Nov 16 2016

Just like I can pass the JSON body of a request on the command line with cURL, I'd like to be able to pass the parameters the same way with the OpenWhisk CLI

curl -H "Content-Type: application/json" -X POST -d '{"username":"xyz","password":"xyz"}' http://localhost:3000/api/login

as example:

wsk action invoke --body '{"key1": "value1", "object1": { "object1Prop": "anotherValue" }}'

@mbehrendt commented on Wed Nov 16 2016

good point.

should we even allow piping it in, sth like echo <json> | wsk action invoke myAction ?

@dubeejw commented on Wed Nov 16 2016

You can put the JSON in a file, and pass that filename to the -P flag.

@l2fprod commented on Wed Nov 16 2016

true but here I don't want to have to create a temp file.

Travis should be modify to use ansible cli local mode with location where the binary was just compiled

@uwefassnacht commented on Tue Apr 25 2017

How do I know which version of the CLI I have installed? And whether it's the latest & greatest one? How do I know when to update (re-install) the CLI?

It would be good to provide a -v flag (similar to the cloud foundry CLI) that outputs the version. I realize that -vis already taken (verbose option).

At the very least, the CLI "splash screen" (displayed when using wsk without any options) should display a version number.

It's also not clear from the CLI repo at https://openwhisk.ng.bluemix.net/cli/go/download what the current version is and whether it's time to update.

@sjfink commented on Tue Apr 25 2017

wsk property get --cliversion

probably duplicate of apache/openwhisk#1492

@rabbah commented on Tue Apr 25 2017

@houshengbo @pritidesai as part of making the JSON object available advertising the CLIs versions, it would be nice to address the comment above: the link to a binary should carry version information.

Of course, we don't have a proper version yet or release tag (#1880).
@csantanapr I think we need one epic to track all the related CLI issues for versioning, the download page, etc.

@eweiter commented on Tue Apr 25 2017

It would also be nice if we could try to expose this info through the CLI page on the download button or near it.

@dubeejw commented on Tue Apr 25 2017

@eweiter, @houshengbo, we should be able to expose the CLI version to the UI via the content.json file.

@rabbah commented on Fri Apr 07 2017

wsk action create a --docker a
wsk action create b --docker b
wsk action create s a,b --sequence
wsk action update s --sequence

The CLI accepts the update with no artifact present and constructs the following incorrect request to post to the API:

{{"namespace":"_","name":"s","exec":{"kind":"sequence","components":["/_/"]}}

The controller will reject this because the component has an invalid action name.

requirement failed: The fully qualified name of the entity must contain at least the namespace and the name of the entity.

@dubeejw commented on Fri Jul 14 2017

@rabbah, is this issue still valid? Here's the output I get with the current CLI:

$ wsk action create a --docker a
ok: created action a
$ wsk action create b --docker b
ok: created action b
$ wsk action create s a,b --sequence
ok: created action s
$ wsk action update s --sequence
error: Invalid argument(s). An action name and code artifact are required.
Run 'wsk --help' for usage.

@rabbah commented on Fri Jul 14 2017

that's better.

this never worked for openwhisk and should be removed.

I have multiple spaces under my organization name. I expected that I would be able to easily switch between spaces via the cli. However, running wsk namespace list will only show the namespace I am currently logged into. The issue is that I have to login to openwhisk via web browser to see my list of space names.

Is there a design reason why I cannot list all of the spaces from the CLI? Or is this a bug?

@rabbah commented on Thu Nov 10 2016

I've experience several instances where a schema change in the controller must be reflected in the CLI to properly render the expected output on the command line because the current CLI implementation encodes the types too strictly and unnecessarily - in every case I've encountered so far where I've made a schema change to add or remove a field, the CLI would have been just fine if it treated the response from the controller opaquely.

We should refactor the API respond handling in the CLI so that it uses more generic JSON object interface rather than strict types that just get in the way.

I've also found several instances where the CLI is not in sync with the controller (Evidenced by several defects I've opened for these in recent days) and the CLI injects properties that should not exist (and hence confusing).

@ioana-blue commented on Thu Nov 10 2016

I was bit by this as well and it's not fun. In fact, if I hadn't checked with RR, I would have wasted a lot of time on chasing a "bug" in my code, while it was really a schema change for activations which is not reflected in the cli.

@starpit commented on Tue Dec 20 2016

It would be handy to have @file support, analogous to that in curl. For example:

wsk action invoke myAction -p input @filename

In which the CLI would JSON.stringify the contents of the file. In addition, it would be nice if the command line could specify the encoding of the file. For example, if the file is encoded UTF-16, the CLI needs to know this, so that it can stringify the file properly. For now, perhaps it could iconv the file to UTF-8 and stringify it. Suggestion for UTF-16:

wsk action invoke myAction -p input @utf16:filename

@dubeejw commented on Tue Dec 20 2016

JSON file input support exists in the CLI currently. The encoding support does not, however.

-P, --param-file FILE, FILE containing parameter values in JSON format

@starpit commented on Tue Dec 20 2016

hi @dubeejw thanks for the response. we need something more than that. think of the case of an XML document as input to an action invocation. the XML document needs to be stringified (after all, it has double quotes!) before it can be passed as input to an openwhisk action.

yes, i could script this externally, but i think it'd be nice to just have this support directly in the CLI.

it gets even more messy when considering non-ascii encodings.

@starpit commented on Tue Dec 20 2016

here is how i ended up invoking my action with a utf-16 xml document as input:

% echo "{\"xmlInput\": "`iconv --unicode-subst=formatstring -f utf-16 -t us-ascii < sample.xml | node conv.js`"}" > in.json
% wsk action invoke cogdigity/export2json --param-file in.json

notice the use of: 1) iconv, and 2) a nodejs program to help with stringifying (i could've used sed or awk here, i just gave up trying to figure out the escaping of escaping of escaping... nonsense)

@rabbah commented on Tue Dec 20 2016

the param file also requires one to modify the file to nest the payload into a json property - i does not quite satisfy the feature requested here even if you set aside the encoding.

@jthomas commented on Thu Dec 22 2016

It would be nice to also be able to pipe content as input.

cat file.json | wsk action invoke my_action

@rabbah commented on Wed Apr 05 2017

The cli refers to error messages not by a short tag but a string that is the error message. The translation file then repeats the same message again. Why is it done this way instead of a short descriptive name for the error? So that only the transalation (actual error msg) needs to be fixed, once.

@dubeejw commented on Mon Apr 10 2017

Related to apache/openwhisk#2063.

@rabbah commented on Thu Apr 13 2017

@dubeejw should this be done more expeditiously so as not to perpetuate this further especially with more CLI work picking up?

@RSulzmann FYI.

@rabbah commented on Thu Apr 13 2017

Also @dubeejw should we combine 2113 and 2063?

@lzbj commented on Tue Jul 11 2017

@rabbah , do you mean this kind of replication
https://github.com/apache/incubator-openwhisk/blob/master/tools/cli/go-whisk-cli/commands/action.go#L596

we can perhaps use pointer instead of string copying to make it more faster.

@rabbah commented on Tue Jul 11 2017

I mean the replication in the error messages themselves like this:

errMsg := wski18n.T(
    "Unable to create action '{{.name}}': {{.err}}",

Search for the string:

    "Unable to create action '{{.name}}': {{.err}}"

You will see it's repeated so making a change to any error message requires fixing all the refeerences. These should be via indirection, a pointer as you suggest.

@rabbah commented on Tue Jul 11 2017

Here are the three copies as one example https://github.com/apache/incubator-openwhisk/search?utf8=%E2%9C%93&q=++++%22Unable+to+create+action+%27%7B%7B.name%7D%7D%27%3A+%7B%7B.err%7D%7D%22&type=

@lzbj commented on Wed Jul 12 2017

thanks for your clarification, I submitted one pr apache/openwhisk#2475, please help review if you available, thanks.

@lzbj commented on Mon Jul 17 2017

apache/openwhisk#2502

@drcariel commented on Wed Jul 19 2017

@mdeuser This is the issue we discussed, wondering if there are any tips or preferred styles for updating the String references?

@mdeuser commented on Wed Jul 19 2017

I looked at another CLI project written in Go, and all of the resource strings followed the convention currently used by this CLI. @drcariel - Can you scrounge around a bit more for other globalized Go projects to get a sense of the resource key best practice.

@drcariel commented on Thu Jul 20 2017

I have seen the same after doing a bit of investigation. Do you think that is the standard?

It still seems more efficient, in respect to ease of maintenance, to shorten the reference names, but I leave the final decision to you @mdeuser

@rabbah commented on Sun Jul 23 2017

It still seems more efficient, in respect to ease of maintenance, to shorten the reference names

+1

@drcariel commented on Tue Jul 25 2017

Just discussed with my old team.

Their initial decision to externalize the reference names as the actual strings was due to the misunderstanding that that was a requirement for translation to work properly. A new team has since taken over that project and made the decision to use shortened names.

I was given this as a reference for bluemix CLI guidelines:
https://github.com/IBM-Bluemix/bluemix-cli-sdk/blob/master/docs/plugin_developer_guide.md#6-globalization

and while their example shows the id and translation as the same, it's important to note that this is their single example, not a hard requirement. If we take a look at the actual 3rd party translation library documentation (https://github.com/nicksnyder/go-i18n#workflow) you see another style of shortened reference names.

Knowing what freedoms we have now, I think we absolutely should shorten these references with our own style or an existing one, especially as an open-sourced project.

@mdeuser commented on Tue Jul 25 2017

@drcariel - thanks for digging into the current best practices. I agree we can move away from having the resource key match the actual text.

Modify the build files so that go cli is able to build in this new repo.
Update the README.md accordingly.

Action, trigger and rule names must be unique within a namespace and package. It could be confusing to a developer that you cannot create an action with a name, if a trigger or rule already exists with them identifier.

Here's the error message that gets returned if you try to do this....

error: Unable to create action 'hello': Resource by this name exists but is not in this collection. (code 5000008)
Run 'wsk --help' for usage.

It would be helpful if the CLI could return the resource details ("Trigger with name ... already exists") to help users understand this issue.

Alternatively, a more helpful error message ("Actions, rules and triggers share the same namespace, check for those resources with that name.").

@dubeejw commented on Wed Mar 22 2017

As values returned from Whisk backend can get out of sync with the CLI, the HTTP body of a response should be returned to each command. This way the HTTP body can be directly printed. This allows fields to be added/removed from the backend responses without the CLI needing to be updated unless the modified fields are critical to the functionality of the CLI.

@dubeejw commented on Wed Mar 22 2017

@csantanapr, @mdeuser, this is technical debt, and should be fixed ASAP.

@dubeejw commented on Thu Mar 23 2017

All of the commands currently receive the HTTP response from each request, but the response body is not accessible as the connection has already been closed.

Support flags to wsk activation list/poll that allow for filtering based on the status of the activation. For example, all ongoing activations or activations that returned an error.

@alexkli commented on Thu Oct 05 2017

It would be useful to support reading a parameter json file from stdin for various piping scenarios, using the convention of "-" as filename:

cat some.json | envsubst | wsk action invoke my-action -P -

In this example we can leverage envsubst to replace some environment variables in the file. Without being able to read from stdin, one has to push the content into a temporary file, invoke and then delete the temp file again.

From looking at the go cli code, it seems readFile() in util.go could be adapted to leverage ioutil.ReadAll(os.Stdin) in case filename == "-". One probably has to check if that is ok for all other readFile() usages, or if that should be a special option reserved for -P --param-file only.

@alexkli commented on Tue Oct 10 2017

Provided pull request #2848.

Please have a look, thanks!

@mdeuser commented on Tue Oct 17 2017

See https://github.com/apache/incubator-openwhisk-cli/blob/master/commands/api.go#L916

Instead of hardcoding the protocol to https use the protocol configured in the apihost

@jsanda commented on Fri Oct 27 2017

I submitted PR 2909 for this.

If you don't specify the --kind on every command, then the CLI will reset back to the default:

$ wsk action list
actions
/19FT_dev/ping                                                         private swift:3

$ wsk action update ping ping.swift --kind swift:3.1.1
ok: updated action ping

$ wsk action list
actions
/19FT_dev/ping                                                         private swift:3.1.1

$ wsk action update ping ping.swift
ok: updated action ping

$ wsk action list
actions
/19FT_dev/ping                                                         private swift:3

I expect that once I've set a kind, then that action will always stay on that kind.

@sdague commented on Thu Nov 16 2017

When you set an action using the wsk action update command, and specify both --kind and --docker, the --docker portion is silently ignored. Instead at least a warning should be provided to the users to ensure that they get something consistent.

This tripped me up when moving from a --kind python:3 to --docker as I didn't remember to delete the --kind from my script, then my image wasn't used, the base python3action was used instead.

@csantanapr commented on Thu Nov 16 2017

@jessealva take a look when you have a chance.

I am trying to create some action by passing some annotation along the way.

 wsk -v  action create  create-cat create-cat.js --web true -a mykey  "true"
REQUEST:
[PUT]	https://openwhisk.ng.bluemix.net/api/v1/namespaces/_/actions/create-cat?overwrite=false
Req Headers
{
  "Authorization": [
    "Basic REDACTED"
  ],
  "Content-Type": [
    "application/json"
  ]
}
Req Body
{{"namespace":"_","name":"create-cat","exec":{"kind":"nodejs:default","code":"function main(params) {\n\n  return new Promise(function(resolve, reject) {\n\n    if (!params.id) {\n      reject({\n        'error': 'id parameter not set.'\n      });\n    } else {\n      resolve({\n        id: params.id,\n        name: 'Tahoma',\n        color: 'Tabby'\n      });\n    }\n\n  });\n\n}\n"},"annotations":[{"key":"mykey","value":true},{"key":"web-export","value":true},{"key":"raw-http","value":false},{"key":"final","value":true}]}
}
RESPONSE:Got response with code 200
Resp Headers
{
  "Access-Control-Allow-Headers": [
    "Authorization, Content-Type"
  ],
  "Access-Control-Allow-Origin": [
    "*"
  ],
  "Connection": [
    "Keep-Alive"
  ],
  "Content-Type": [
    "application/json; charset=UTF-8"
  ],
  "Date": [
    "Tue, 11 Jul 2017 07:02:50 GMT"
  ],
  "Server": [
    "nginx/1.11.13"
  ],
  "Set-Cookie": [
    "DPJSESSIONID=PBC5YS:1376290542; Path=/; Domain=.whisk.ng.bluemix.net"
  ],
  "X-Backside-Transport": [
    "OK OK"
  ],
  "X-Global-Transaction-Id": [
    "1584633913"
  ]
}
Response body size is 850 bytes
Response body received:
{
  "name": "create-cat",
  "publish": false,
  "annotations": [{
    "key": "web-export",
    "value": true
  }, {
    "key": "raw-http",
    "value": false
  }, {
    "key": "final",
    "value": true
  }, {
    "key": "mykey",
    "value": true
  }, {
    "key": "exec",
    "value": "nodejs:6"
  }],
  "version": "0.0.1",
  "exec": {
    "kind": "nodejs:6",
    "code": "function main(params) {\n\n  return new Promise(function(resolve, reject) {\n\n    if (!params.id) {\n      reject({\n        'error': 'id parameter not set.'\n      });\n    } else {\n      resolve({\n        id: params.id,\n        name: 'Tahoma',\n        color: 'Tabby'\n      });\n    }\n\n  });\n\n}\n",
    "binary": false
  },
  "parameters": [],
  "limits": {
    "timeout": 60000,
    "memory": 256,
    "logs": 10
  },
  "namespace": "[email protected]_ashish"
}
ok: created action create-cat

It always show the boolean true and not "true" even when that is what was passed in the CMD