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. Regards, Rob... > On 4 Aug 2017, at 13:59, Markus Thömmes <[email protected]> wrote: > > 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 > > <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 > > <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 >> <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 >> <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! >> -- Development thoughts at http://akrabat.com Daily Jotter for macOS at http://dailyjotter.com
