Heyho,
sorry for taking so long. Here's the video of the call:
https://www.youtube.com/watch?v=-sXiZlPnX98&t=29s
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:
https://openwhisk.ng.bluemix.net/api/v1/web/nickm_wskng_demos/public/index.html
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 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 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:
https://lists.apache.org/thread.html/04f4094784678abb5105d9b4f3bccc527e042b925d6b1e80e3273b62@%3Cdev.openwhisk.apache.org%3E
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 <[email protected]>:
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: https://ibm.zoom.us/j/357640980
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:
https://ibm.zoom.us/zoomconference?m=nMjjJbNvSpqZbEIUB0b66gqJcuvQFZDO
---
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!
