Yeah that’s ok to do it in both clients, is better than current state +1 - Carlos Santana @csantanapr
> On Mar 24, 2020, at 9:21 PM, Nick Mitchell <moose...@gmail.com> wrote: > > i think the core problem is that there are several layers of collections, > but no bulk and no cursored operations against these collections: "all > actions", "actions in package"... retries and careful coding can work > around these. so it might be sufficient just do it "twice" (in the > openwhisk client npm, and in the go CLI). our code is open source. it's > still not 100% correct. we still get travis failures 1/100 times or so. > >> On Tue, Mar 24, 2020 at 9:09 PM Carlos Santana <csantan...@gmail.com> wrote: >> >> Hi Nick this is very useful even outside demos, I remember having a bash >> alias that it was 95% correct to delete all. >> >> Your proposing the heavy lifting is implemented on the server side >> controller API and the client/api just do a single http request “delete >> all” ? >> >> - Carlos Santana >> @csantanapr >> >>>> On Mar 24, 2020, at 7:16 PM, Nick Mitchell <moose...@gmail.com> wrote: >>> >>> we implemented this in https://github.com/kui-shell/oui >>> >>> some lessons learned. it's possible, but tricky, due to the loose >> semantics >>> of openwhisk delete-after-delete ordering, plus some bits of potential >> race >>> conditions with with list windowing. things may have improved since we >>> first implemented this, so keep that in mind: >>> >>> 1) if you have an action in a package; then you have to delete the >> actions >>> in the package before you can delete the package; but... if you issue the >>> package delete after the last action delete API call has returned, there >>> (at least used to be) a short window where the package delete would >> fail. i >>> think this depends upon the quorum configuration of your backend >> database. >>> so you may need to have retries here. >>> >>> 2) if you have more than 200 (or whatever the LIMIT config is of your >>> server) actions (c.f. packages, etc.), then you will need to manage the >>> windowing yourself. since the openwhisk API has no strong sense of >> cursors >>> (or does it now?), you have to be careful to fetch all windows before >>> initiating any deletes in any of the windows... >>> >>> there may be more issues, but this one was non-trivial to get right. >> after >>> doing all the work, "delete all" struck me as the kind of thing that >> should >>> be supported by the API directly. >>> >>> @starpit >>> >>>> On Tue, Mar 24, 2020 at 5:23 PM Will Plusnick <pwplu...@us.ibm.com> >> wrote: >>>> >>>> Hello all! >>>> >>>> I've frequently found myself having to clear a namespace after working >>>> on a demo or when experimenting. I'll have a number of artifacts left >>>> in a namespace that I don't want to preserve. Right now, unless I used >>>> wskdeploy for deployment, I'm stuck manually deleting all of the >>>> actions, rules, etc. I want to propose adding a command to the >>>> namespace subcommand in the cli for deleting all the artifacts in a >>>> namespace. >>>> >>>> I envision the syntax for the command going something like: >>>> >>>> $ wsk namespace delete all >>>> This command will delete all entities in the namespace <namespace>: >>>> <list of entities> >>>> Are you sure you want to proceed? Type '<namespace name>' to proceed: >>>> <user typed namespace name> >>>> action: >>>> <entity 1> is deleted >>>> <entity 2> is deleted >>>> .. >>>> trigger: >>>> <entity 3> is deleted >>>> <entity 4> is deleted >>>> .. >>>> etc >>>> >>>> The user would then be prompted whether they really want to delete all >>>> of the entities in the namespace. They would need to type in a "danger >>>> phrase" such as the name of the namespace to avoid accidentally running >>>> the command. This is similar to deleting a github repo. If anything >>>> but the "danger phrase" is received then the operation is aborted. >>>> >>>> This is a feature I would find personally useful, and would like to >>>> add it to the cli. Does the community at large feel this is a useful >>>> feature? >>>> >>>> Thanks, >>>> Will >>>> >>>> >>
