openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Allen <>
Subject Re: Today - Join us for the OpenWhisk “Tech. Interchange” (bi-weekly) Zoom Meeting
Date Fri, 04 Aug 2017 13:13:48 GMT
Thanks Marcus,

I'm sorry I couldn't make it this time.

I'm definitely +1 on a regular status update email. At least until we get releases, it'd be
quite nice if it could include a list of PRs that have been merged since the last update email.



> On 4 Aug 2017, at 13:59, Markus Thömmes <> wrote:
> Heyho,
> sorry for taking so long. Here's the video of the call:
> And the summary:
> Attendees:
> 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
> Features:
> Namespace specific throttles
> Topics:
> 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 iteratively.
> 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 “official”?
> 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
> 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 pull-requests.
> 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:
>> ---
>> Agenda:
>> 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!

Development thoughts at
Daily Jotter for macOS at

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