FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Add confirm mechanism when delete or update action by ningyougang · Pull Request #372 · apache/openwhisk-cli · GitHub

Add confirm mechanism when delete or update action - #372

Open
ningyougang wants to merge 1 commit into
apache:masterfrom
ningyougang:add-confirm-when-delete-update-action
Open

Add confirm mechanism when delete or update action#372
ningyougang wants to merge 1 commit into
apache:masterfrom
ningyougang:add-confirm-when-delete-update-action

Conversation

ningyougang commented Sep 20, 2018
edited
Loading

Copy link
Copy Markdown
Contributor

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.

ningyougang force-pushed the add-confirm-when-delete-update-action branch from ba7141a to 62cab2f Compare September 20, 2018 08:34

csantanapr left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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 ...)

rabbah commented Sep 20, 2018

Copy link
Copy Markdown
Member

What about adding a—safe mode which will prevent delete without a confirmation?

mdeuser commented Sep 20, 2018
edited
Loading

Copy link
Copy Markdown
Contributor

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.

rabbah commented Sep 20, 2018

Copy link
Copy Markdown
Member

I like the suggestions. Could also store it in whisk properties.

csantanapr commented Sep 20, 2018
edited
Loading

Copy link
Copy Markdown
Member

yep I like the using environment variable.
But I'm not in love with the wording SAFE.
How about something along WSK_CLI_PROMPT_ON_CHANGE or WSK_CLI_PROMPT=true|false (default) to false.
Also this PR only touches on actions.
I think it should be done for all changes (ie. wsk update | delete) I guess the user wants to be prompted if by mistake it updates or deletes a rule.

ningyougang commented Sep 21, 2018
edited
Loading

Copy link
Copy Markdown
Contributor Author

@csantanapr , thanks for your reply.
if used WSK_CLI_PROMPT_ON_CHANGE or WSK_CLI_PROMPT=true|false
Does this env WSK_CLI_PROMPT_ON_CHANGE existed in openwhisk server side, exactly controller side(not in wsk client side)?

mdeuser commented Sep 21, 2018

Copy link
Copy Markdown
Contributor

WSK_CLI_PROMPT_ON_CHANGE and/or WSK_CLI_PROMPT do not exist in the backend

ningyougang commented Sep 25, 2018
edited
Loading

Copy link
Copy Markdown
Contributor Author

@mdeuser
Regarding WSK_CLI_PROMPT_ON_CHANGE and/or WSK_CLI_PROMPT do not exist in the backend

so you mean WSK_CLI_PROMPT_ON_CHANGE and/or WSK_CLI_PROMPT exists in wsk client side?
if exist in wsk client side, for wsk client users, they may not know above environment env.
How to notify wsk client users to know above environment env?

ningyougang force-pushed the add-confirm-when-delete-update-action branch from 62cab2f to 8294483 Compare September 25, 2018 10:01

rabbah commented Sep 25, 2018

Copy link
Copy Markdown
Member

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.

ningyougang force-pushed the add-confirm-when-delete-update-action branch from 8294483 to 247866e Compare September 26, 2018 05:51

ningyougang commented Sep 26, 2018
edited
Loading

Copy link
Copy Markdown
Contributor Author

@rabbah ,already modified.

The patch implement the protect feature at CLI layer.

How about add the protect mechanism at the backed server layer also?
because users may deploy their action using API (not wsk CLI)

But i am afraid that if added in backed server layer, may lead to client side do huge breakpoint.
How do you think?

rabbah commented Sep 26, 2018

Copy link
Copy Markdown
Member

On the backend I think the model is finer grained entitlement than we have today, with unix style permissions.

Comment thread commands/flags.go Outdated
apihostSet string
apiversionSet string
namespaceSet string
promptOnChangeSet string

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Already modified

rabbah left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

This will also need unit tests (go unit tests preferably).

dubee commented Sep 26, 2018

Copy link
Copy Markdown
Member

I think a prompt would be better than an additional flag.

Copy link
Copy Markdown
Contributor Author

@rabbah , so we have no need to add the protect mechanism for backend layer, right?

ningyougang force-pushed the add-confirm-when-delete-update-action branch 4 times, most recently from f6017df to b63643e Compare September 27, 2018 07:51

rabbah commented Sep 27, 2018

Copy link
Copy Markdown
Member

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.

ningyougang force-pushed the add-confirm-when-delete-update-action branch 3 times, most recently from 7a1a4c5 to d84129f Compare September 27, 2018 10:17
As more and more production system uses openwhisk,
Users will need some feature to protect their action to be
deleted or updated by mistake.
ningyougang force-pushed the add-confirm-when-delete-update-action branch from d84129f to 33b6054 Compare September 27, 2018 10:18

ningyougang commented Sep 28, 2018
edited
Loading

Copy link
Copy Markdown
Contributor Author

@rabbah ,already added test cases.

Regarding add protection feature to backend layer, i also think it these days.
First, we should consider the original created action,
if we add protection feature in backend layer ,we should promise have no influences to the original created action.

So one option is, add promptOnChange fileld to action, default value is false,
When create action, we can assign the promptOnChange to true.
if that, when call delete action API, should add force request parameter to delete it.

If we add promptOnChange field to backend's action, so have no need to add promptOnChange to WSK's wskprops file.
How do you think?

Copy link
Copy Markdown
Contributor Author

Please don't merge this patch
May be we can solve this problem in backend layer:
apache/openwhisk#4058

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants


Back | FazBrowse Home | New Git URL