openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Mitchell <>
Subject Re: OpenWhisk shell tool
Date Fri, 04 Aug 2017 15:59:46 GMT
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 input), or
reinvoke with new args, or add this action to a sequence now that you know
it works (append to myseq).

These are all plugins, so new ideas can appear as shell commands in a
matter of minutes.

On Aug 4, 2017 11:49, "Rodric Rabbah" <> wrote:

> This is a very useful discussion - thank you Rob for starting it. We both
> want and need this kind of feedback!
> One of the observations that you noted wrt to the shell is that it has "its
> own language". Indeed there is a language here, in the same way that the
> wsk CLI already offers a language for serverless programming using
> OpenWhisk. When the language of the CLI is limiting, what do we do as
> developers? I posit that we layer new languages on top --- my favorite
> example is "give me the last activation". At one point I polled for how
> many bash aliases the community has come up with for this feature! Recently
> the wsk CLI added `wsk activation get --last`. That's still too verbose and
> I continue to use my local alias for this command and I expect others will
> too. More concretely, it's too verbose when I'm developing, iterating, and
> debugging.
> In the same way, I've seen developers share bash scripts for automating
> other tasks that the current wsk CLI (or really any client) doesn't yet
> support. For example: deleting all assets in a namespace, or a package.
> These are features I expect will eventually end up in the wsk CLI. But the
> gate for rapidly experimenting with new aliases, plugins, features is too
> narrow today.
> The "openwhisk shell" is a way of normalizing the programming experience
> for serverless - it does subsume the CLI in that the wsk commands should
> work inside it, but also extends the capabilities to add more syntactic
> convenience and make a workflow more fluid - some of these may not be
> readily possible or practical in a terminal. One of the benefits that I've
> experienced directly is that it makes the iterative programming experience
> and development for serverless more agile and fluid.
> To me, this is independent of the question of scripting for deployment,
> continuous integration, and delivery and hence the context for my "old
> school" comment - the shell can export a bash script for you, or other
> artifacts like a serverless framework manifest, for managing a deployment
> (as examples).
>  -r

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message