Attendees: Matt, Jeremias, Rob, James Thomas, Christian, Markus, Eric, Jason, Angela, Martin, Carlos, Sandeep, Belinda, Tyson, Vadim, Duy, Nick, Vincent, Dragos, Mark D., Himvanth, Duy,  
Notes:
  • Jeremias moderating
  • Agenda posted to “dev” list, short agenda, only 2 topics
Introductions of attendees
  • Belinda, (+Dave and Admin) in conference room in Austin (IBM)
    • currently working on new features, blueprints work around wskdeploy, submitted to email list a week or so ago on wskdeploy package
Open comments on status 
  • Main/core OpenWhisk
    • Carlos: repos. for runtimes are “gone” from main repo., folders still there, it should have been seamless, left there for now in case people have existing scripts.
    • Dragos discussed renaming/reorganizing repo. including not calling it “core”
    • Hoping people will see an increase in build times, as images are not being built again and again
    • Swift still has issues building (quite large dependencies)
    • Carlos: Travis pulling failing on DockerHub is hanging… need to investigate
    • someone in Slack is having same trouble locally…
    • Carlos: im not seeing the issue because i have local images on laptop.. will try a clean build and see if it happens still
    • Jeremias: is build now pulling from Travis (runtime images) and not building anymore.
    • Carlos: its a gradle dist Docker task but pulls now
    • Jeremias: any other notable changes?
    • Carlos: dynamic assignment using Redis or not??? is that clear now for the Invokers
    • Jeremias: Dave grove not in call today, but there is info in PR
    • Carlos: did it get merged? Redis not required?
    • Jeremias; was merged, but not the default, you have to enable it
    • Markus: lat wed. meeting, the design of it … it is merged, but is optional but can be triggered via env. variables
    • Jeremias: in “core” openwhisk my team is working on robustness, making sure (old) artifacts not being left 
      • related to removing “broken” containers
      • also working on controller improvements
    • Jeremias: LogStore SPI work starting as well with Tyson, Markus and Christian. Tyson touch points work ery well and should fit many implementations.  Now looking for other impls.
      • Markus: good summary, new reading of log file not changing behavior now, but should help us support streaming logs; PR open on that
    • Jeremias: Trigger mgmt. operations is another topic
    • James: I posted to dev list on Friday, are feed providers and their state updates (as feeds are being used more) sufficient?
      • James: can we update max triggers for example?
      • James: is there an y work being done to better manage (add new caps.) to current feed providers (e.g., Alarm ,Kafka)? 
      • James: have a more formal “spec” or markdown that describes the operations.  Better docs needed. 
      • Good to see event support as being made as good as possible, usability improved, please post open more requirements on this work to the dev list
    • Carlos: we now have a good collection of feature requests in the feed provider area.  Need to have a good balance between user experience and still able to scale effectively.
      • I have a slide deck that shows the lifecycle which we need to perhaps make part of markdown as current is deficient
      • at one point, we had a template feed provider repo, does simple hellow world, could be NodeJS etc. but would be good to use that to document and teach people how to make feeds better.
    • Jeremias: we have the time today if you have the slide.
    • Carlos: shares his slide “OpenWhisk Feed Mgmt.” and described the current create/delete/pause/unpause lifecycle we have today
      • would like to add a more actions … will open PR
      • “feed” annotation is NOT documented (part of the magic) we need to document this.
      • READ is a proposed new feed action, get status of the trigger and configuration
      • Jeremias: status will be updated by the feed provider? 
      • Carlos: ayes, and saved to the database
      • UPDATE: similar process to READ, allows us to not create/delate a trigger, but actually update an existing trigger…
      • REVOKE: not a common scenario, often needed when auth keys need to be revoked… its still being discussed.  Issue still be be resolved if person loses their old key.  The key update would have to make sure it is updated for all instances.
      • Jeremias: can we PAUSE/UNPAUSE the actual “firing”?  
      • Carlos: its in the spec., but still not come up on mailing lists, others are based on user feedback
      • Carlos; work ongoing under PRs on Kafka, Alarm, CouchDB, GO Client to support these new lifecycle operations
        • future work?  Save copy of config., save status if trigger, save payload?
      • Matt: looking at having JSON schema and/or Swagger in Whisk Deploy to describe Inputs and outputs, would we do this in annotations?
      • Carlos: On the Alarm trigger, feature request from users include more “controls” to adjust triggers
        • startDate, stopDate, fire only once at specific time/date, allow a more granular interval (cron does not support this, hour/minute is not granular enough) along with start/stop date (Jason is working on)
      • Proposal is to use RFC 2822 for date/time format (https://www.ietf.org/rfc/rfc2822.txt)
    • James: this is good work on Alarms, this week I am writing a blog post around Alarms and would be good feature to describe to user.
    • Rob: RFC 2822 does not include GMT… can someone verify that, your proposal may not work if we cannot resolve to UTC time
    • Carlos: will look into...
    • James: the rate addition is a good one, how do we better socialize this?
    • Carlos: Issue/PR and mailing list discussion.  Want people to comment on issue
    • James: create an issue for each ? as an epic issue…   PRs too late to provide feedback
    • Jeremias: Martin wants to show a demo on Log forwarder for Metrics support using Kamon module
    • Martin: shows slide of exiting flow/design
      • We found out that the sheer amount of metrics output put high load on invoker and controller
      • good idea to get metrics out of current logging mechanism and write them directly to a metric backend
      • Introduced the Kamon library that can write metrics directly to statsd (http://kamon.io/documentation/get-started/)
      • metrics now out of our logging/log file (separate path)
      • Shows Grafana dashboard with new statsd output of metrics
      • Dragos: this is great, no logging to logs…
        • if we have 2 controllers can we differentiate the performance impacts still?
      • Martin: yes the name of controller (ID) is logged so you can separate the data.
      • Vadim: amount of logs actually  directly impact Controller performance, 
      • Vadim: want to (goal) to only log errors and critical information (and analyze each log line to make sure we leverage metrics to offload).
        • Need to increase # of concurrent requests per invoker, still be able to identify broken invokers, errors
      • Martin: PR is still in progress, you can play with this for now
    • Jeremias: we need to make sure we have a dev list discussion, on how we leverage this and make sure people have a chance to comment on PR.  Loglines (analysis) needs comments from community on which are important/not
    • Martin: it is important to get opinions on this as it is tricky deciding which are important
    • Jeremias: need ability to dynamically increase/decrease log level (to debug perhaps), think about operational perspective
Confirm moderator for next call (i.e., Wed. Nov 8th)
  • James volunteers. 
  • No labels