openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodric Rabbah <>
Subject Re: [discuss]Add protect feature to avoid update or delete actions by mistake
Date Fri, 25 Jan 2019 03:36:07 GMT
I posted a comment on the issue but for the benefit of the dev list: I
think the implementation points to a more general permission set on an
action. In the noted PR, it is strictly a "write" permission for the
namespace (like a group in UNIX terminology), and one can image an execute
permission as well next (disables an action from executing for a
namespace). I'm not sure if a read permision makes sense here since its per
namespace still.

So my thoughts is whether to factor the permission more generally to allow
for generalization later... or leave it as is and change it later to add
execute permission - does that even make sense (to "pause" an action from


On Tue, Jan 22, 2019 at 9:57 PM 甯尤刚 <> wrote:

> As more and more production system uses openwhisk,
> It seems we need some feature to protect their service safe from mistake.
> ​
> for example, when users create action use like below(add annotation
> "lock":true)
> curl -X PUT -H "Content-type: application/json" --user
> 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP
> -d
> '{"namespace":"guest","name":"hello","annotations":[{"key":"lock","value":true}],"exec":{"kind":"nodejs:default","code":"//
> Licensed to the Apache Software Foundation (ASF) under one or more
> contributor\r\n// license agreements; and to You under the Apache License,
> Version 2.0.\r\n\r\n/**\r\n * Hello, world.\r\n */\r\nfunction main() {\r\n
> return {\"payload\":\"Hello world\"};\r\n}\r\n"}}'
> ''
> The lock field will be added in couchdb's annotation, like below
> "annotations": [ { "key": "exec", "value": "nodejs:6" }, { "key": "lock",
> "value": true }
> So this action can't be deleted/updated until the protection is updated to
> false
> ​
> This is the patch:
> ​
> If this patch is merged into upstream, the wsk side will do some changes,
> add unlock feature to wsk to enable update or delete operation, for example
> ​
> wsk action update hello --unlock
> So we can discuss there, is it necessary to add this feature? or any other
> suggestions.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message