I can testify to the "race" conditions... you can look in wskdeploy to see what we had to do including adding default 3 retries for each client call. Triggers and Rules are the worst... there may be special logic there as well to try with waits imposed.
On 2020/03/25 01:20:54, 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 > > >> > > >> > > >