openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Thömmes <>
Subject Re: Today - Join us for the OpenWhisk “Tech. Interchange” (bi-weekly) Zoom Meeting
Date Fri, 04 Aug 2017 11:59:20 GMT

sorry for taking so long. Here's the video of the call:

And the summary:
Markus Thömmes (moderator)
Michael Behrendt
Dan Lavine
Lionel Villard
Nick Mitchell
Lorna Mitchell
Carlos Santana
Vadim Raskin
Mark Deuser
Dragos Dascilate
Michael Marth
Tyson Norris
Lloyd Roseblade (Swift IBM)
Dror Gensler (Startup company related to Serverless)

What’s new:
Markus: Proposal: Weekly/Monthly digest of what has happened
Dan: Kube
A couple of blockers still
More configuration in docker images themselves —> environment variables
Don’t rely on ansible
Markus: Main repository
Deprecation of old containerpool —> new pool is default
Old codebase to be removed soon —> end confusion
Namespace specific throttles

Nick: OpenWhisk Shell
See what it is and can do here:

Lorna: Nice for demos, but not sure how it fits in a scriptable environment. Should we create
a separate tool vs. improving our wsk CLI?
Nick: This will be open-sourced very soon.
Rodric: Whatever you do in Whisk Shell you can export a script with raw CLI commands, you
can use this in CI then.
Nick: Goal of the shell: Take the meaningful atomic tasks and make those shorter and easier
to use. We could make the REPL executable outside of the GUI to enable scripting in the Whisk
Shell syntax: simple syntactically, quickly writable, no low-level script.
We should embody common tasks into the REPL.
Lorna: My reservations are around how useful it is for people who need to deploy in a scriptable
way, who don’t want to learn a new shell or write javascript. I love it and it looks nice.
Rodric: There’s such a big tooling gap in serverless. This is just one more tool in that
space. It could find adoption for people who want an overview of how things execute and develop
Nick: We need a way to quickly extend the command set. API change relatively slowly. How do
we add support for project level support, debuggers, schema inference? We need a platform
for that.

Michael Marth: Performance tests
Michael: Should we move Markus’ performance repository to the apache repos and make them
Michael: It is great we can discuss performance issues and we need common tests we can everywhere
and talk about the same things.
Markus: No problem, we could just move the repository and I agree: We need a common testbase
to quickly determine performance benefits and regressions.
Markus: Where do we run them continuously? Apache Jenkins? Automatically run them on pull-requests.
We should do it incrementally. As a quick step: Run the tests on a set of machines, specify
them and put a stake in the ground on performance numbers.
Current tests are very simple, everything is warm, no cold-containers for instance. Can we
have more sophisticated configurations?
Rodric: What are the benchmarks we should have? Raw latency, raw throughput, latency under
different scenarios. We need to specify a set of those benchmarks and not just talk about
infrastructure and frameworks to implement them. We saw a couple of devs trying to benchmark
their environments. A nice thing would have been a standardized way to setup and run the benchmarks
with good documentation.
We should figure out how we get infrastructure out of Apache.
Michael: I reached out to INFRA and I never got a proper reply. Shouldn’t stop us to move
the scripts though.
Rodric: Can our mentors help here?
Michael: I asked Felix and pinged the mentors in the thread we had. No reply.
Markus: I wanted to at least a specified run on some of our hardware so people can compare.
We should agree on a common framework though. I looked into Gatlin it has pros and cons.
Tyson: We looked at Locust, which also has its drawbacks.
Gatlin is a scala-based load-testing tool, a DSL around something like JMeter. You can code
quite sophisticated scenarios with it. It can produce great load, but the reporting is terrible.
Locust is opposite, scriptability is more limited, reporting is much better. It is able to
be running distributedly, while Gatling will only run on a single node.
Gatling is a reasonable compromise. We haven’t found an obvious choice though.
Dragos: I worked with Tsung, written in Erlang. Nice performance. Quite difficult to cluster.
I find Locust to be my first choice because it runs distributed.
Markus: Nice, I’ll look into Locust as well. I found Gatling reporting good though, at least
the report generated in the end. I care mostly about reporting containing everything we need,
like latency changing over time.
Tyson: Gatling is better in time-based views. Locust also only gives you a summary aggregate.
Dragos: We can even do a screen-sharing session to teach the community.
Rodric: One outcome is, we can move the repository to Apache. Everything else we’ll do with
Tyson: It might even be useful to have different frameworks doing different work.
Rodric: Right, we should standardize on the things to measure and how to measure. The framework
doesn’t matter.
Markus: Makes sense, this could even converge over time. Will move the repo to Apache org.
Dev-list and/or pull-requests should be used to discuss new benchmarks.

Tyson: Authentication
Tyson: Authentication discussion in Slack: Provide a different way to extend the authentication
that the CLI uses. I think it’s different changes like the cert authentication PR that is
pending. We need changes to the CLI (different authentication headers). Could be different
parameters like wsk —bearer-auth.  Server side needs pluggability in the authentication
mechanism. Shouldn’t check for all possible auth mechanisms but an explicit configuration.

We could implement a wsk login command which automatically sets up your CLI properties. For
example, it could do an OAuth dance.
Rodric: I tried capturing the thoughts in the dev-list:
Markus: You could imagine the CLI figuring out in conjunction with the backend which method
to use. The general approach though doesn’t change. I think it’s fairly easy to do. Challenges
will be: How you integrate with the subjects db for example.
Rodric: Nick Mitchell did a prototype for this, where you can login through OAuth with Github
and Google. It already handles the subjects database. Could be a good starting point. We need
to keep in mind backward compatibility.
Nick: Yeah, I did this like 8 months ago so it’s quite stale. You needed a CLI change and
on the backend where you handle the subject database updates. It’s not quite complete though.
It’s a PoC though.
Markus: Any next steps or just agreeing: This is doable?
Tyson: Yeah I think we agree it’s doable. Somebody should look into Nick’s branch and
that could be a good source of inspiration. If one starts to work on it, we should advertise
on the dev-list to not duplicate work.

Next moderator: Tyson Norris

Thanks everyone for joining and thanks Tyson for volunteering to moderate next time.

See you around!

Am 02. August 2017 um 13:20 schrieb Markus Thömmes <>:

Hi there,

It's biweekly meeting time again. Matt won't be able to join so we'll need to use another
zoom meeting (thanks Michael Behrendt for helping out)

Time: Wed., August 2nd, 11am US EDT, 8am US PDT, 5pm CEST 

Join from PC, Mac, Linux, iOS or Android:

Or iPhone one-tap (US Toll): +14086380968,,357640980# or +16465588656,,357640980#

Or Telephone:
Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
Meeting ID: 357 640 980
International numbers available:


1. Introduction/New faces on the call?
2. What's new? Short status updates depending on who's joining the call.
3. Topics:
  3.1: Nick Mitchell - OpenWhisk Shell
  3.2: Markus Thömmes - Invoker Reactive: What's the fuzz and how does it work?
  3.3: Anything else you are interested in!
4. Confirm moderator for the next call

Note: This is not a fixed agenda. If we have consensus on items we want to discuss, we can
adjust the agenda ad-hoc

Hope to see you there!

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