Notes:

  • Ben Browning is moderating today
  • last meeting was 2018-08-01
  • Attendees:
    • Ben, James, Markus, Matt, Tyson, afield, Martin, rtripath, Justin, Daisy, mamishra, Priti, tzuchiao, Dave Grove, Vincent, Dan, Carlos, Erez, Andy

Introductions of new attendees

  • No one volunteered to intro. themselves


Open comments on status/updates in a few areas:

  • Main/core OpenWhisk (Carlos//Markus/Tyson, etc.)
  • Recent topics (perhaps another update is in order)?
    • Matt Rutkowski & Priti Desai -> Website update
      • Matt shows updaed website
      • thanks all for Issues/Comments/PRs
      • Priti and I are prioritizing and fixing
      • added project map
    • Ben Browning/Markus Thömmes - Update on Knative
      • Ben shares internal work/protoype running OW on knative
        • Got triggers, rules, actions working
        • Working on Java actions next..
      • Shares video in chat:
      • Goal: inform on how we adv. knative from OW
      • Markus: on dev list, my proposal had discussion,
        • single-concurrency mode specifically,
        • Markus working in knative to fix issues frlom an OW point of view, so some of the comments” knative is not good for” is changing over time (even recent comments may not be true)
      • Ben: this is a long term effort, trying to make sure we identify things we need to “get into” knative over the long term
    • Arch. Proposal (Markus):
      • user-facing part (abstractions are included, progr. model, sequences, etc.)
      • extract all concerns related to execution of functions
      • used this to draw a picture of the execution layer that could work the same on raw VMs, kube, mesos, open shift, anything
        • Shares diagram from or CWiki
      • Goal: seamlessly swap out “execution systems”
      • will allow us to adapt to knative easier if we choose to implement
      • Discussion on the dev list is going into lots of details..
      • is there an agreement on parts of this proposals arch. as I am not able to perceive if this large proposal is getting general adoptance?
      • e.g., expose interfaces as first step?
      • Dave G.: that makes sense, Apache should kick off a vote on smaller parts like the routing layer (on unique threads)
      • Dave G: I started a logging vote thread yesterday
      • Markus: most proposal discussions are around routing layer, no one questioned the ctrl->user container 
      • So perhaps not as contentious
  • Release process: (Vincent) / Roadmap (Ben)
    • Ben: comm., priority is still to get a 0.9.0 complete release
    • Ben: is priority to drive to 1.0, a 2.0? for new arch.?
    • Markus: another goal is to drive a roadmap discussion.
    • Ben: all user os apache is an operator…
    • Carlos: maybe user swagger is enough?
    • Matt: i see lots of users as operators, like Navir 
    • Vincent: there is still lots of refactoring in terms of naming for 1.0..
    • Vincent: we have 13 modules that we nee to eventually release as a group.  OW and Apache has not been responsive to VOTEs
    • ALL: please push through votes, bug mentors
    • Ben: on dev list we will make sure to pay attention to votes
    • Carlos: once we graduate, we do not have to do the 2nd vote, we need to get there...
  • Mesos/Compose/Splunk update: (Dragos/Tyson)
    • Rahul (rtipath): (Adobe) work for Adobe team, have some ideas around a testing framework to compliment Scala.
    • Ben: saw some discussion on the dev list, centered around overlap with existing test suite… is there a plan to switch to behavior-driven test or use it for new tests
    • Ben: is this replacement or augment existing?
    • Rahul: compliments today, not proposing to port/move to karate
    • Rahul: we just want to improve test coverage for use cases, but we want easy on-boarding (not a Scala person) and test scenarios which is easier in karate.
    • Rahul: try it and evaluate later to see if it has value
    • Rahul: perhaps extend to UI automation support/testing, but again today is just a compliment
    • Matt: optional?
    • Rahul: today optional
    • Dave G: what is maturity of Karate? community? licensing? should we invest in this?
    • Mamishra: we can do a demo, and the benefits
    • Dave: will Karate be supported in 3 years? 
    • Rahul: MIT project, started 2 years ago and based on Cucumber, comm. is growing. This fw. is planned to replace other major frameworks.
    • Carlos: you mentioned gatling tests in mailing lists? we have some already for performance tests. Does karate use gatling?
    • Rahul: example: some smoke test, we divided test into diff. testing types, plug-in can utilize gatling fw. similar to what we use in scala, but instead use a “feature file’.
    • Rahul: Scala Gatling -> Karate “feature file” can use same baseline
    • Carlos: no strong opinions, but Scala contribs. wanted tests in scala for backend, do not want them to learn new framework, perhaps if it is limited to other user/ui tests?
    • Carlos: do not want to support every fw. that comes along, can scala devs. need to learn X number of fws? That added learning curve could be imposing
    • Ben: agrees as a Scala dev. do not want to learn a new DSL
    • Ben: do you have a Travis job?
    • Rahul: can add gradle, int. with Jenkins and supported later as a travis job.
    • Markus: also, have same sentiment of other guys, would it be possible to provide a PR that is complimentary, but not duplicating exiting tests? so we can better see a simple user workflow test to evaluate?
    • Markus: PR today is too large, hard to digest
    • Rahul: yes we can reduce the PR
    • Ben: agree, PR is too large, need to understand the fw. around simpler set of tests to see how we adapt it.
    • Ben: the test runners use Java, do we have to use java? can we use scala?
    • Carlos: we removed java tests a long time ago. Does karate support IntelliJ or other debug tools?
    • Tyson: good approach is to provide a reduced PR. Imagine that these tests would come in the same way the system tests are run… that they are integration tests.  Inside system tests we already have variants today e.g., wrappers around APIs,
    • Tyson: what is long-term situation to extend system tests in the future?  In adobe we have a team trying to add more tests, to exercise more parts of the system.  How does anyone extend those tests?  Karate could make this consumable from not being a hardcore OW dev. but as an OW operator
    • Dave: there is value to make OW more easier to adapt as operators (blackbox testing orgs.)
    • Dan: goal is not to replace scala test (was not intent), the first PR was to show how easy it was to replace a scala test with Karate, but perhaps that caused confusion, we simply wanted to show Karate provided an simple ext. mechanism
    • Ben: let’s try for a simpler unit test on PR to better evaluate.  

      • Also, please enumerate the savings (size, diff., etc.) on dev list
    • Carlos: what is separation (again versioning) for testing purposes?
  • OpenShift update: (Brendan/Ben)
    • No update
  • Kubernetes:  (Dave Grove/Daisy)
    • No update
  • API Gateway (Matt Hamann/Dragos)
    • No update
  • Catalog/Packages/Samples (anyone)
    • No update
  • Tooling/Utilities (Carlos (CLI), Priti/Matt (wskdeploy))


Confirm moderator for next call

  • Tyson will volunteer, for Aug 29th meeting
  • adjourn 11:00 AM US Central
  • No labels