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

Reply via email to