Have you applied to dockerhub to exempt the openwhisk org from their
new-ish rate limiting? Travis tests (or any tests on a shared
infrastructure) will begin to routinely fail because of this:
>
> docker: toomanyrequests: You have reached your pull rate limit. You may
> increase the limit by
h
> 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:
worse. i don't know whether this is an openwhisk bug or a linux bug or an
electron bug, but something breaks if electron+linux makes too many
connections to openwhisk.
On Mon, Jun 24, 2019 at 8:31 AM Nick Mitchell wrote:
> it's been working well for our CI/CD tests. standalone openwhisk, combi
a minimal REST
> > api to add user in standalone case
> >
> > Chetan Mehrotra
> > [1]
> https://github.com/chetanmeh/incubator-openwhisk/blob/openwhisk-standalone/core/standalone/README.md#adding-custom-namespaces
> >
> > On Fri, Jun 21, 2019 at 5:36 PM Nick M
nwhisk-standalone-1.0.0-SNAPSHOT.jar
> >>
> >> You can use the default guest and whisk.system credentials to interact
> >> with it. I am in the process of writing a readme for various options
> >> exposed. Hope to get it done by Monday
> >>
> >> Ch
thanks chetan for doing this!
could you provide some example startup sequences, e.g. with sample configs?
i'm willing to try this out for our CI/CD pipeline -- i'm sick of 1)
waiting 5-7 minutes for openwhisk to start up; and b) fighting ansible
versus xenial :)
@starpit
On Fri, Jun 21, 2019 at
this is great james, thanks for the awesome writeup. last year, i tried a
somewhat similar experiment with using openwhisk as a proxy to kubectl and
helm. it worked! but ended up not being viable due to cold starts. i either
needed to use a docker action to host the go binaries, or download them
>
> 1100+ Kafka brokers, over 31,000 topics
am i reading this right, as this seems like an unhealthy ratio. a new
broker for every 30 topics? so i must be misinterpreting the numbers...
On Wed, Nov 28, 2018 at 10:18 PM Dominic Kim wrote:
> Dear Rodric.
>
> We`ve just started benchmarking of
from a usability perspective, there is something quite attractive about
having ready access to logs (and activation records generally)... while
developing. i think most of the woes we encounter with logs come from high
volume actions (either exercised in prod, or during a high volume test)?
i
> --
> > Michele Sciabarra
> > openwh...@sciabarra.com
> >
> > - Original message -
> > From: Nick Mitchell
> > To: dev@openwhisk.apache.org
> > Subject: Re: MiniWhisk: what you think?
> > Date: Wed, 25 Jul 2018 14:35:37 -0400
> >
> > the shell
the shell indeed has a `local` plugin that does most of this, though it
does not support the `go build` part; but it does take care of pulling the
base images, injecting code, and routes invokes to and from the container.
for nodejs, we can also optionally hand the local invocation off to the
yes please! https://github.com/apache/incubator-openwhisk/issues/335
On Mon, Jul 9, 2018 at 12:57 PM, Rodric Rabbah wrote:
> currently if you query the API host (GET /openwhisk) you get a response
> which includes the deployment manifest and action invocation limits. I've
> added in this PR [1]
for nodejs at least: the cost of a few requires of common packages can
easily get you up to the 150-200ms range (e.g. request is a big hitter; and
this is all on top of the cost of starting a container!). perhaps, for
nodejs at least, there are only a few options, ultimately: user pays more
for
ion - that
> it's not used that heavily.
>
> -r
>
> On Thu, Apr 19, 2018 at 11:51 AM, Nick Mitchell <moose...@gmail.com>
> wrote:
>
> > this seems like a breaking API change. e.g. in nodejs `===` checks would
> > break.
> >
> > On Thu, Apr 19,
i've wanted, for a while now, the ability to encapsulate remote requests,
whether to other actions or to remote services, behind a Composer-like
linguistic facade.
so that, to sequence a call to any REST API, i would like to have, e.g.
composer.sequence('myOwnAction', composer.request({ url: '
e invoked from a shell in a REPL style, thanks -
> is this possible with the current downloads?
>
> I appreciate the value of the UI (looks great btw!) - its just not clear
> how to do the 'scripted execution’ parts?
> Thanks
> Tyson
>
> > On Aug 4, 2017, at 11:22 AM, Nick
get behind, as long
> as things that are not purely session-based are added to the CLI as well
> (like auth flavored commands).
>
> Thanks for starting this tool, I think its useful and look forward to
> watching it progress!
>
> Tyson
>
>
>
>
> > On Aug 4,
With the shell, one would issue `last`. Or `last foo`. With a REPL, we have
the luxury of a flexible command structure that can be tailored to the task
at hand.
And, once you are looking at that activation, you can drill down (eg to
tree view of the sequence), or reinvoke (we can remember the
On Fri, Aug 4, 2017 at 10:32 AM, Raymond Camden <raymondcam...@gmail.com>
wrote:
> On Fri, Aug 4, 2017 at 9:25 AM, Nick Mitchell <moose...@gmail.com> wrote:
> >> It looks like it the shell has its own language, Is it documented? I'm
> >> concerned that we're i
Thanks rob for the great questions!
> This new shell thing seems to be its own app. How accessible is it for
> people who can't use a mouse and need to drive it via keyboard only?
>
>
it can be used entirely without a mouse. for example, to open and close the
sidecar, use the Escape key. history
/nickm_wskng_
demos/public/index.html
nick mitchell
@starpit
hi dragos,
an approach we took, in this regard, was the "router action" pattern.
facebook (similarly for slack) is configured to communicate with the router
action, which will discriminate challenge invocations from normal event
flow invocations.
in the case of facebook (and slack, more
maybe a bit of caution is needed in the use of "no-ops"? amongst the first
things i did with my serverless apps is get jenkins health checks going!
you may not have a server, but you have assets that can, and so will fail.
perhaps the implication of "no-ops" is that skill set needed for
won't this only be of benefit for invocations that are mostly sleepy? e.g.
I/O-bound? because if an action uses CPU flat-out, then there is no
throughput win to be had (by increasing the parallelism of CPU-bound
processes), given the small CPU sliver that each container gets -- unless
there is a
i would place this pretty high up on the list of requirements for
supporting serverless web apps (e.g. without it, secure cookies and local
storage are not possible).
yes, we could require a separate reverse proxy front-end, but for a couple
of lines of static nginx config, this seems like a
i like that this gives me a stable/predictable route, so that i don't have
to keep around a registry of endpoints in my deployment scripts -- as i
would if the routes were exposed with a random-ish hash in them.
and i like the idea of a simple way of supporting client applications that
doesn't
26 matches
Mail list logo
