csantanapr opened a new issue #124: CLI should use filename as action name when 
one is not provided
URL: https://github.com/apache/incubator-openwhisk-cli/issues/124
 
 
   @dubeejw commented on [Wed Oct 18 
2017](https://github.com/apache/incubator-openwhisk/issues/2869)
   
   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]
   ```
   
   1.
   ```
   $ wsk action create someAction.js
   ok: created action someAction
   ```
   
   2.
   ```
   $ wsk action create someAction --kind nodejs:6
   ok: created action someAction
   ```
   
   3.
   ```
   $ wsk action create someAction.someExt --kind nodejs:6
   ok: created action someAction
   ```
   
   ---
   
   @dubeejw commented on [Wed Oct 18 
2017](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-337601897)
   
   @mdeuser, @drcariel, @jessealva, @csantanapr, thoughts on the above?
   
   ---
   
   @mdeuser commented on [Wed Oct 18 
2017](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-337607239)
   
   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](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-337610607)
   
   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](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-337950112)
   
   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](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-337964990)
   
   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](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-337996805)
   
   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](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-338005115)
   
   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](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-338011390)
   
   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](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-338015208)
   
   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](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-338025783)
   
   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](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-338025830)
   
   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](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-338032843)
   
   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](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-338034773)
   
   > 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.
   
   ```bash
   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](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-338101376)
   
   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](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-338253570)
   
   @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](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-338746639)
   
   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](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-338784689)
   
   Good discussion. Actually found a bug in the existing code when looking into 
action create (https://github.com/apache/incubator-openwhisk/pull/2887). 
   
   ---
   
   @dubeejw commented on [Mon Oct 23 
2017](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-338785713)
   
   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](https://github.com/apache/incubator-openwhisk/issues/2869#issuecomment-338799316)
   
   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
   ```
   
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

Reply via email to