Versions Compared

Old Version 1

changes.mady.by.user Matt Rutkowski

Saved on

compared with

New Version 2

changes.mady.by.user Matt Rutkowski

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Main/core OpenWhisk (Carlos//Markus/Tyson, etc.)
  • Scheduled topics
    • Matt Rutkowski & Priti Desai -> Website update
      • Matt thanks Priti for all the work she has done, esp. on Documenation page, creating a one-stop experience against 3 roles: Operator, Developer (many sub roles) and Contribs.
      • Matt demos on 3 browsers and multiple form factors
        • Goals: lossless data, min. info duplication, BUT provide a guided experience with the same presentation and gentle “hand off” to deeper resources. 
      • Chetan: Should not highlight Compose, it may have issues?
      • Matt: Priti investigated all options and chose most reliable, we have many options which one should we feature that works reliably on most platforms?
      • Priti: could not get Vagrant running on Mac... took very long to start
      • Ben: Katacoda is a good tool for developers to try stuff on...
      • Carlos: could not figure out to use free for open source
      • Matt: Would need to be accepted by Aache, and allow donation that apache can govern/admin.
      • Ben: RH has some agreement, will look into more
      • Dom: Is it supposed to have “provider” and “supporter” sections in community tab?
      • Matt: Dom, we have not done that yet as we have not had time to distinguish (by defn and consensus) what a Provider is yet
      • Matt: PR will dorp today, please comment, Priti and I will make time over next 2 weeks to address all comments/issues
    • Ben Browning/Markus Thömmes - Update on Knative
      • Ben:adds on-top of Kube
      • Ben: 3 comps. build, eventing and serving
      • Ben:“build” inspired by Triggers, Rules and Actions
      • Ben: ideas/conpets include: "serving", “spin up”, “scale” and “idle” images
      • Ben: general goal is to “make Kube a better place to run Serverless”
      • Ben: we should look at knative for our own Kube deployments/ingratiations
        • expect majority of innovation to take place in knative
      • Markus: working on a prototype for running on knative now
      • Markus: my design prop. from 2 weeks ago, have revision pending on prop. to better draw a picture how we could leverage the arch. changes to work on Knative
      • Rodric: have you thought about why "OW on knative" is better than on raw Kube?
      • Ben: reality today, prob. not…
        • cavaet, OW on Kube means diff things…. most perf. way today is to talk to Docker daemon, but that is not a great design and uses Kube’s mgmt. and scsaling efficiently
      • Ben: our Kube/Docker is differnet in Red Hat I cannot talk dieectlyl to the daemon… we need to unify under one way to access/run on kube, this could be the way forward
      • Ben; goal this is a “future play”, would not increase perf. today..
      • Markus: assume we might get some innovation from knative in future
      • Markus:
        • Perf. of Serverless platform & abstractions a Serverless platform gives you are the 2 major considerationsPerf: knative, is built around deploying images and containers, whereas in OW we deploy source code…. this allow us to use stem cell/pre-warm containers which is not yet supported in knative.
          • goes for other similar offerings (work at container granularity)
      • Markus: this “warm” notion is not generally avail. apart from OW
      • Rodric: containers per Function… is not granular, there is still a “why” question that knative does not solve, in large multi-tenant env.  the mgmt. needs to considered as inefficient
      • Rodric: my early analysis, OW is what knative wants to be… as we drive concepts thru knative (expected)
        • is there a way the OW comm. and project is recognized for that???
        • How do we publicize the OW contributions and relationship?
      • Ben: No idea on recognition,
        • 1:1 mappings of ideas rule:subsc., feed:feed other concepts really map well…
        • knative is a set “building blocks”, OW is the whole package
      • Ben: have been prototyping, how we align a runtime that can use OW or run on knative
      • Daisy: has closed integrations Istio, Prometheus, Kibana, logging etc.
        • knative has better monitoring and traffic mgmt.
        • regardless OW needs to improve our dashboards, and user mgmt.
      • Rodric: good point, OpenFaaS has similar integrations…
        • we left “large chunk” for Providers to do themselves
        • should have “out of box” help for operators
      • Ben: not sure ow OW can advantage knative without being “all in” on knative…
        • we cannot adv. knative as we exist today
      • Markus: where do we draw lines (or abstraction layers)
        • personally believe we can have an execution layer and user layer on-top o
        • e.g., our OW API can be one layer (switch out to knative, mesos, other)
        • my proposal revision (working on) will show these ideas…
      • Dave: agree w/ Marks
        • but as we focus on Kube, as comm. moves to knative, we have to look at Scala (and control plane) to leverage knative (
        • Docker compose stuff will need replacement as well
      • Ben: in add. to Markus, what if OW APIs and tools became the std. for depl. and interacting with Knative…
        • what would that mean as OW for future project?
        • API/tooling/packages (all that talk to controller)…
          • spin these off?
      • Rodric: we did it right, these things should happen
      • Carlos: knative naming is its own, we tried to influence, but not much luck, but OW idioms exist; should protect OW mindshare around this...
    • Rodric Rabbah -> CVE/Security update (up to 5 minutes)
      • Rodric: (shares screen):
        • reported to “private” in June with example of exploit (PureSec); followed Apache guidance/process
        • CVE issued 2 weeks ago (will walk thru mitigation)
        • Vulnerability was in user space
          • Fx that does not apply basic security eng. is vulnerable
        • Medium blogpost example shown and article posted as well (linked in Slack)
        • Shows example:
          • could do many things like fetch code, hijack parms, etc.
        • Carlos: would like to update blog with “replace an executable” where “exec” can be replaced entirely
        • Rodric: just wanted to emph. security should be considered
        • Thanks Rob Allen for fixing PHP runtime
        • Rodric: fixed all runtimes to block /init exploit (re0init fixed in skeleton), added std. test suite to test runtimes for vulnerabilities (for runtimes)
          • named: “basic action runner tests” (for runtimes)
        • Rodric: all curated runtimes now run this test suite
        • Rodric: noted that using these tests we found that the PHP runtime had a vulnerability with large payloads and fixed 
        • Carlos: background processes can be an issue as well
        • 2 CVEs issued (due to 2 different repos.
          • even though there has not been an official Apache release, but opened CVEs as well since project is mature and has known users/consumers
          • Should build/run latest Docker images and runtimes
          • IBM Cloud Functions for example rolled out these fixes
  • Release process: (Matt/Vincent)
    • Justin: please VOTE on Vincents email thread for CLI release
  • Mesos/Compose/Splunk update: (Dragos/Tyson)
    • No Update
  • OpenShift update: (Brendan/Ben)
    • Brendan: not much to update
      • bunch of work at Red Hat over last 8-10 months 
      • we have scripts to deploy on OpenShift working with Dave Grove to eliminate “custom” images (Docker) for all deployments/builds
      • Have initial code drops, working on getting workin on these non-custom images
      • Over time we want to align with other repos like Kube to have shared images we can all build from
      • Ben: main goal, move OS customizations out, working on permissions/openings now
        • Kube/OS sharing is first order goal
      • Carlos: are these image mods for invoker/controller?
      • Ben: mods, to most images incl. invoker controller, providers, couch, etc.
      • Brendan: need to figure out permissions
      • Carlos: would like to discuss more on this later
      • Ben: figure out remaining delta and remove over time
  • Kubernetes:  (Dave Grove/Daisy)
    • Dave:
      • Split into 2 helm charts, 1 for core, 1 for providers (org'ed as subcharts) 
      • PR from Daisy
      • Flex. to install providers on diff cluster if they like
      • Helm charts on Kube engine also a new contrib.
      • Community jumped-in and fixed env, vars. positive notes
      • Docker files, optimizations, got rid of lots of “custom” Docker images
      • suggest we push up into core project, a base/core iamge that has everything needed for ANsible istnalls already naked into base image
  • API Gateway (Matt Hamann/Dragos)
    • No update
  • Catalog/Packages/Samples (anyone)
    • No update
  • Tooling/Utilities (Carlos (CLI), Priti/Matt (wskdeploy))

...