| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
I disagree with this change as would force a current user to always use this new flag when deleting entity.
One example of a more popular CLI is Kubernetes and it doesn’t require a flag to delete
https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#delete
Top level program calling CLI can do this check
You can extend/fork the code and create your own customized of the CLI (IBM already does with ibm wsk ...)
Sorry, something went wrong.
|
What about adding a—safe mode which will prevent delete without a confirmation? |
Sorry, something went wrong.
|
this appears to be a breaking change as it is currently implemented. if so, i'm not in favor of this change as implemented. one possible implementation is to use an env variable, say WSK_CLI_SAFE_MODE or WSK_CLI_ACTION_MGMT_SAFE_MODE or..., that when set will cause the cli to always prompt for confirmation of action deletes/updates. when env is not present, the current behavior remains. no need for additional command line flag. |
Sorry, something went wrong.
|
I like the suggestions. Could also store it in whisk properties. |
Sorry, something went wrong.
|
yep I like the using environment variable. |
Sorry, something went wrong.
|
@csantanapr , thanks for your reply. |
Sorry, something went wrong.
|
WSK_CLI_PROMPT_ON_CHANGE and/or WSK_CLI_PROMPT do not exist in the backend |
Sorry, something went wrong.
|
@mdeuser so you mean WSK_CLI_PROMPT_ON_CHANGE and/or WSK_CLI_PROMPT exists in wsk client side? |
Sorry, something went wrong.
|
A property saved in wskprops would address the environment issue since switching files will then configure the cli as desired. We have no precedent for an env file that changes the cli behavior outside of WSK_CONFIG_FILE so a stand-alone property to me for this behavior seems like the wrong direction. |
Sorry, something went wrong.
|
@rabbah ,already modified. The patch implement the protect feature at CLI layer. How about add the protect mechanism at the backed server layer also? But i am afraid that if added in backed server layer, may lead to client side do huge breakpoint. |
Sorry, something went wrong.
|
On the backend I think the model is finer grained entitlement than we have today, with unix style permissions. |
Sorry, something went wrong.
| apihostSet string | ||
| apiversionSet string | ||
| namespaceSet string | ||
| promptOnChangeSet string |
There was a problem hiding this comment.
can this be a boolean flag? i.e. the present of --confirm (typical practice in other clis use --force) indicates the desire to override the confirmation.
Sorry, something went wrong.
There was a problem hiding this comment.
Already modified
Sorry, something went wrong.
There was a problem hiding this comment.
This will also need unit tests (go unit tests preferably).
Sorry, something went wrong.
|
I think a prompt would be better than an additional flag. |
Sorry, something went wrong.
|
@rabbah , so we have no need to add the protect mechanism for backend layer, right? |
Sorry, something went wrong.
|
If by prompt you mean something interactive which requires input on the console then this will make it very inconvenient to actually update a namespace when it is so intended. |
Sorry, something went wrong.
As more and more production system uses openwhisk, Users will need some feature to protect their action to be deleted or updated by mistake.
|
@rabbah ,already added test cases. Regarding add protection feature to backend layer, i also think it these days. So one option is, add promptOnChange fileld to action, default value is false, If we add promptOnChange field to backend's action, so have no need to add promptOnChange to WSK's wskprops file. |
Sorry, something went wrong.
|
Please don't merge this patch |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
I writed a issue here: #371
As more and more production system uses openwhisk,
Users will need some feature to protect their action to be
deleted or updated by mistake.