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 auth
ash
> 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,
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 t
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 openwh
we can look into support 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 2
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 on
>
> 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 th
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 real
> --
> > 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
chro
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 idl
it's not used that heavily.
>
> -r
>
> On Thu, Apr 19, 2018 at 11:51 AM, Nick Mitchell
> wrote:
>
> > this seems like a breaking API change. e.g. in nodejs `===` checks would
> > break.
> >
> > On Thu, Apr 19, 2018 at 11:37 AM, Rodric Rabbah
> wrote:
this seems like a breaking API change. e.g. in nodejs `===` checks would
break.
On Thu, Apr 19, 2018 at 11:37 AM, Rodric Rabbah wrote:
> Should we also rename “code”?
>
> I don’t see the value in using code: 0 and changing the schema should be
> fine and better in the long run.
>
> -r
>
> > On A
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: '
ht
be 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,
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, 2017, at 8:59
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 inpu
On Fri, Aug 4, 2017 at 10:32 AM, Raymond Camden
wrote:
> On Fri, Aug 4, 2017 at 9:25 AM, Nick Mitchell wrote:
> >> It looks like it the shell has its own language, Is it documented? I'm
> >> concerned that we're inventing a whole new language off the cuff...
>
oh, i should've answered the last question better. let's try again:
I'm a bit confused as to the status of this tool. There was mention of a
> vague hope to OpenSource it, but it didn't sound very concrete or important
> to the speaker. Is it proprietary to IBM? Will it work with other
> installat
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
ng.bluemix.net/api/v1/web/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 recently,
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 serve
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 co
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 prett
i like the proposed solution. i think this is an important problem to
address, from usability perspective. as an example: recently, a client
application started to experience bimodal performance: either very fast, or
30.x seconds. the logs gave no indication as to what was going on, and so a
bit of
andom-ish hashes today? you mean the api gw integration?
> If so, I agree that is sub-optimal and should be addressed there as well.
>
>
>
>
> From: Nick Mitchell
> To: dev@openwhisk.apache.org
> Date: 01/13/2017 12:21 AM
> Subject:Re: Allow actions to be 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 req
31 matches
Mail list logo
