[DISCUSS] graduation from the incubator

[David P Grove]

I'd like to kick off a discussion to assess the project's readiness for
graduation from the incubator.

Per Rodric's recent stats [1], the community has developed nicely in terms
of code contribution.

We've released a number of software components following the Apache release
process.  We are in the midst of making our first "uber-release" across all
of our sub-components (expect at least 2 voting threads next week).

Overall I think the community is active.  Communication on the project
slack is frequent (avg of >160 messages a day) and is now digested daily to
the dev list. (See [2] for stats).

There are a couple procedural tasks we still need to complete, foremost
being the formal transfer of the OpenWhisk trademarks from IBM to the ASF.
But I think we can assume that these tasks will be completed and start
considering graduation in parallel.

Please share your thoughts,

--dave

[1]
https://lists.apache.org/thread.html/b2217c61caad5c7a0369699d06d44e5cf688d3cba982e354a45b8c78@%3Cdev.openwhisk.apache.org%3E
[2]
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103091999

Re: Welcome Krzysztof Sobkowiak as an additional incubation mentor!

[Sobkowiak Krzysztof]

Hi

Thanks for the warm welcome :)  I'm glad to be part of your community 
and I'll do my best to help you on the way to be TLP


Best regards

Krzysztof


On 14.03.2019 15:05, Matt Rutkowski wrote:

Welcome Krzysztof!

Appreciate the great support from all our mentors as we indeed complete
the last stretch towards graduation!

Warm regards,
Matt Rutkowski




From:   Bertrand Delacretaz 
To: OpenWhisk Dev 
Cc: ksobkow...@apache.org
Date:   03/14/2019 07:44 AM
Subject:Welcome Krzysztof Sobkowiak as an additional incubation
mentor!



Hi OpenWhisk community,

I'm pleased to announce that, after a general call for more incubation
mentors (I was the only one for a bit), Krzysztof Sobkowiak
(ksobkowiak) has agreed to help.

With Matt Sicker and myself that makes three mentors, which should be
plenty for the final charge towards graduating this project!

Thank you Krzysztof - and welcome.

-Bertrand







--
Krzysztof Sobkowiak

JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Apache Incubator PMC Member (https://incubator.apache.org/)
Senior Solution Architect @ Capgemini SSC 
(http://www.capgeminisoftware.pl/)

Re: OpenWhisk Apps on Knative

[Carlos Santana]

Matt Priti I see the PR got merged/closed with no discussion

Here is my initial feedback:

I wasted like 30 minutes looking for the hello.js openwhisk action and how
this was used to build final docker image to be use in knative.

Never found it, after reading every file I think I finally realize that the
openwhisk code is suppose to be a k8s environment variable in the
build.yaml

I never expected this and I think is not a good solution, just editing a
file to get the code in the yaml, encodings, handling package zip actions,
and the limit of env variables when is too large

I think the build template should take an existing openwhisk app directory,
it can be a git repo and directory path (root as default) and look for a
wskdeploy manifest or a serveless framework manifest.

copy that to a knative build workspace and then using the manifest take the
action code and generate one or more docker images, that could then be
refer in a knative service yaml

Looking forward to the openwhisk community meeting that you said you were
going to present more details and demo, before I provide more feedback

-- Carlos





On Fri, Mar 15, 2019 at 8:06 AM James Thomas  wrote:

> My 2 cents (from a personal perspective - these views are my own and not my
> employers yada yada)...
>
> Despite the marketing hype, (at the moment) knative isn't a serverless
> platform like openwhisk.
>
> It's a Containers-as-a-Service platform (which scales from zero) than a
> Functions-as-a-Service platform. It exposes lots of low-level plumbing to
> the user, (scaling behaviour, k8s YAML, images), which is all hidden in a
> serverless platform.
>
> I think the description on their Github organisation makes more sense...
>
> "Kubernetes-based platform to build, deploy, and manage modern serverless
> workloads".
>
> Building primitives into k8s to make running serverless workloads easier
> make sense. It doesn't necessary mean that developers will use these
> primitives directly.
>
> All the current open-source faas platforms (openwhisk, openfaas, kubeless,
> fission, fn project..) have had to implement the same custom runtime
> primitives on top of lower-level infrastructure services. Those services
> (roughly) map to the knative projects (build, serving, events) being
> proposed.
>
> If you follow Simon Wardley's work, you'll recognise this as a known
> process as these components shifting from custom-built/product-rental to
> commodity/utility on the technology evolution lifecycle.
>
> https://www.youtube.com/watch?v=NnFeIt-uaEc
>
> In theory, Apache OpenWhisk adopting those knative primitives means we can
> focus on higher-order systems and new innovations in the serverless space,
> whilst leaving the lower-level plumbing to the downstream project.
>
> Kelsey Hightower has regularly stated both k8s and knative are tools for
> building platforms, not the platforms developers use.
>
> https://twitter.com/kelseyhightower/status/1104041461836787712
>
> https://twitter.com/kelseyhightower/status/1099710178545434625
>
> There are lots of questions about knative that make things more
> challenging….
>
>-
>
>Will knative stay as lower-level k8s primitives to run serverless
>workloads or move "up the stack" and starts to provide developer tools
> or
>frameworks for serverless apps? The former leaves a gap for openwhisk,
> the
>later less so much (in openwhisk's current incarnation).
>-
>
>What is the governance model for knative? It is not in a foundation at
>the moment and currently (mostly) controlled by Google. Re-basing
> solely on
>knative comes with more of a risk until this is cleared up.
>-
>
>Knative is still extremely immature, it's at like v0.4. The projects
>under the knative organisation, their APIs and goals might change
>substantially over the next 12-24 months.
>
>
>
> On Thu, 14 Mar 2019 at 01:45, Carlos Santana  wrote:
>
> > I echo Dave’s words
> >
> > To add:
> >
> > OpenWhisk was born before Kubernetes was mainstream
> >
> > OpenWhisk took advantage at that time of Docker CLI and Docker Engine
> > avoiding to re-invent the wheel.
> >
> > OpenWhisk was build and deploy using bash and ant at one point, then
> > gradle, ansible, compose and later Helm
> >
> > Kubernetes has become mainstream and there are things that OpenWhisk do
> > and is concerned today that could be delegated to Kubernetes or
> Kubernetes
> > ecosystem tools and patterns such as Istio, CRD, Controllers, Operators,
> > etc...
> >
> > Like Dave said OpenWhisk can still provide a a better developer
> experience
> > to people that just want to build serverless applications and don’t have
> > any interest on how the low level infrastructure, installation,
> deployment,
> > or scaling layers work.
> >
> > Maybe it means additions to v1, maybe it takes a re-imagination as a v2,
> > maybe it takes building on top of Knative, maybe takes integrating
> trigger
> > providers in the form of native CRDs and Operators, 

Re: [DISCUSS] release openwhisk CLI

[Carlos Santana]

+1 Yay!!

On Fri, Mar 15, 2019 at 9:31 AM Dave Grove  wrote:

>
>
> On 2019/02/21 17:29:40, Rodric Rabbah  wrote:
> > I have reviewed the the CLI related repos listed below and think we
> should
> > delay release of the CLI until the following PRs/issues are addressed.
>
> The pending PRs have all been merged and I believe we are finally ready to
> go ahead with creating the release artifacts and starting the formal
> release voting process.
>
> I've created a draft CHANGELOG for the wsk-cli in [1].  This was done
> via a quick scan of the git logs from the 3 repositories to try to pull out
> the big ticket items.  Please comment on the PR if there are additional
> items you want to add.  I'll hold the PR open for 24 hours to give time for
> comments.
>
> --dave
>
> [1] https://github.com/apache/incubator-openwhisk-cli/pull/425
>


-- 
Carlos Santana

Re: override main on activation?

[Carlos Santana]

I'm guessing you already tried passing the name of the function as
parameter and got "is not a function" :-)

function man(param) { param["main"](param) }

At least for me I consider best practice to users to avoid packaging into a
single file/zip multiple functions

I think OpenWhisk gave a good architecture constraint to adhere to the
single responsibility rule

In OpenWhisk terms an action should have one function, which with web
action gives you a single endpoint url
This avoids for the most part a large monolith hybrid function where you
stuck a bunch of other functions into a single action package/deployment.

I like using a single action for a single purpose, and not sneak other
functions, because if I have to path it or quick fix, I know the change to
the action code/zip only affects the function with the bug and not the
other functions I snuck :-)

Creating multiple actions and endpoints should be cheap and easy.

With that said, I realize when I create applications with OpenWhisk and
create multiple actions, the multiple zips (because I like packaged actions
!) there is a lot of duplication
This duplications come from my own utility common code across the actions,
and a bunch of npm packages that I use across the actions.

But I would like a better UX to void burning so many bandwidth sending the
same bytes of common code as an user, as a vendor/provider I would not like
to pay for the duplicate storage I give users for free Yay!

Pigging back on what James said about using S3/COS, and also something that
we have discuss in the past in Slack with folks like Michael Marth from
Adobe.

It would be awesome if I can have some tooling that allows me to deploy to
S3/COS and then tell OpenWhisk about it.

For example (here are the mechanics, not necessary how it get's expose to
end user:

Deploy an object to S3 with my common utils code maybe is a tgz
/mybucket/app1-common-v1.tgz
Deploy an object to S3 with my npm packages maybe is a tgz using the
command "npm pack" /mybucket/app1-dependencies-v1.tgz

This two artifacts I don't have to deploy them from my laptop for a while
as they don't change that much,

Now I can deploy my actions to S3
/mybucket/app1-action-task1-single-source-v1.js
/mybucket/app1-action-niam-multifilesource-v1.tgz

An an user maybe I never see S3, maybe I just see the wsk CLI, or wsk
deploy and a manifest, maybe this tools or provider takes care for me to
deploy and manage the S3, or if I want to go raw I deploy to S3
like:
wsk action update package app1 --layer mybucket/app1-common-v1.tgz --dep
bucket/app1-dependencies-v1.tgz
wsk action update action app1/task1 app1-action-task1-single-source-v1.js
wsk action update action app1/func21
app1-action-niam-multifilesource-v1.tgz --kind nodejs:10

Just wanted to give my POV that we don't throw the baby with the bathwater,
also that incremental improvements are fine as long they are not hack
shortcuts in other direction.

Not saying this is shortcut for this the case, but just in case the counter
argument is:
"This awesome and nice but it would take a lot of work, can we do this
short term solutions for now because we already do things today that brake
the single responsibility principle anyway"

my two cents.

PS: Don't going to block a PR that adds this .json@, going
to assume is also applicable to .http and .html?

-- Carlos











On Fri, Mar 15, 2019 at 6:58 AM James Thomas  wrote:

> This is an interesting idea. Lambda has a nice feature of being able to
> create functions from an S3 file containing the source zip, which means you
> don't have to upload the same code for each different function. Not having
> something can make deployments unnecessarily long on OpenWhisk when you
> have a large app with dozens of functions and large action packages.
>
> If this was available - I wonder if there's a way to define an "action
> clone" which is like a sym-link to another action with a different "main"
> parameter (defined at create time)? It would allow us to upload the action
> package once and then create sym-links for all the other actions. This
> would dramatically speed up deployments and reduce the amount of code
> needed to store in the backend.
>
>
>
>
> On Fri, 15 Mar 2019 at 07:45, Michele Sciabarra 
> wrote:
>
> > I like the idea. In particular, it would be very helpful in implementing
> > an idea I had some time ago: deployment of Jupyter Notebooks as actions!
> > (Here I refer to Python based notebooks mostly)
> >
> > Normally you have some code in it that you develop (and test)
> > interactively, but the problem is: what is the entry point? Of course, it
> > would be a "main" action defined in it but it would be limiting.
> >
> > In this way, I could pass the entire notebook to the initialization of
> the
> > action and then invoke the various functions defined in it.
> >
> > --
> >   Michele Sciabarra
> >   mich...@sciabarra.com
> >
> > - Original message -
> > From: Rodric Rabbah 
> > To: 

Re: [DISCUSS] release openwhisk CLI

[Dave Grove]

On 2019/02/21 17:29:40, Rodric Rabbah  wrote: 
> I have reviewed the the CLI related repos listed below and think we should
> delay release of the CLI until the following PRs/issues are addressed. 

The pending PRs have all been merged and I believe we are finally ready to go 
ahead with creating the release artifacts and starting the formal release 
voting process.

I've created a draft CHANGELOG for the wsk-cli in [1].  This was done via a 
quick scan of the git logs from the 3 repositories to try to pull out the big 
ticket items.  Please comment on the PR if there are additional items you want 
to add.  I'll hold the PR open for 24 hours to give time for comments.

--dave

[1] https://github.com/apache/incubator-openwhisk-cli/pull/425

Re: OpenWhisk Apps on Knative

[James Thomas]

My 2 cents (from a personal perspective - these views are my own and not my
employers yada yada)...

Despite the marketing hype, (at the moment) knative isn't a serverless
platform like openwhisk.

It's a Containers-as-a-Service platform (which scales from zero) than a
Functions-as-a-Service platform. It exposes lots of low-level plumbing to
the user, (scaling behaviour, k8s YAML, images), which is all hidden in a
serverless platform.

I think the description on their Github organisation makes more sense...

"Kubernetes-based platform to build, deploy, and manage modern serverless
workloads".

Building primitives into k8s to make running serverless workloads easier
make sense. It doesn't necessary mean that developers will use these
primitives directly.

All the current open-source faas platforms (openwhisk, openfaas, kubeless,
fission, fn project..) have had to implement the same custom runtime
primitives on top of lower-level infrastructure services. Those services
(roughly) map to the knative projects (build, serving, events) being
proposed.

If you follow Simon Wardley's work, you'll recognise this as a known
process as these components shifting from custom-built/product-rental to
commodity/utility on the technology evolution lifecycle.

https://www.youtube.com/watch?v=NnFeIt-uaEc

In theory, Apache OpenWhisk adopting those knative primitives means we can
focus on higher-order systems and new innovations in the serverless space,
whilst leaving the lower-level plumbing to the downstream project.

Kelsey Hightower has regularly stated both k8s and knative are tools for
building platforms, not the platforms developers use.

https://twitter.com/kelseyhightower/status/1104041461836787712

https://twitter.com/kelseyhightower/status/1099710178545434625

There are lots of questions about knative that make things more
challenging….

   -

   Will knative stay as lower-level k8s primitives to run serverless
   workloads or move "up the stack" and starts to provide developer tools or
   frameworks for serverless apps? The former leaves a gap for openwhisk, the
   later less so much (in openwhisk's current incarnation).
   -

   What is the governance model for knative? It is not in a foundation at
   the moment and currently (mostly) controlled by Google. Re-basing solely on
   knative comes with more of a risk until this is cleared up.
   -

   Knative is still extremely immature, it's at like v0.4. The projects
   under the knative organisation, their APIs and goals might change
   substantially over the next 12-24 months.



On Thu, 14 Mar 2019 at 01:45, Carlos Santana  wrote:

> I echo Dave’s words
>
> To add:
>
> OpenWhisk was born before Kubernetes was mainstream
>
> OpenWhisk took advantage at that time of Docker CLI and Docker Engine
> avoiding to re-invent the wheel.
>
> OpenWhisk was build and deploy using bash and ant at one point, then
> gradle, ansible, compose and later Helm
>
> Kubernetes has become mainstream and there are things that OpenWhisk do
> and is concerned today that could be delegated to Kubernetes or Kubernetes
> ecosystem tools and patterns such as Istio, CRD, Controllers, Operators,
> etc...
>
> Like Dave said OpenWhisk can still provide a a better developer experience
> to people that just want to build serverless applications and don’t have
> any interest on how the low level infrastructure, installation, deployment,
> or scaling layers work.
>
> Maybe it means additions to v1, maybe it takes a re-imagination as a v2,
> maybe it takes building on top of Knative, maybe takes integrating trigger
> providers in the form of native CRDs and Operators, or maybe fusing parts
> of both projects
>
> Like Dave said is up to the community and not a single person or single
> company
>
> - Carlos Santana
> @csantanapr
>
> > On Mar 13, 2019, at 9:17 PM, David P Grove  wrote:
> >
> >
> > "Michele Sciabarra"  wrote on 03/13/2019 04:08:15
> > PM:=
> >>
> >> So, is the focus of the project shifting on Knative? Dropping the
> >> current invoker and controller, keeping the runtimes and run them
> >> with Knative?
> >>
> >
> > My 2 cents as an individual is that there is quite a bit of value in
> being
> > able to program against the OpenWhisk programming model and its runtimes
> in
> > a more Kubernetes-centric world.
> >
> > I think it is still an open question what the best underlying runtime
> > system for that programming model is (and even if there is a single best
> > runtime system that spans all the possible scenarios in terms of scale,
> > multi-tenancy, etc.). As a system researcher, one of the best ways I know
> > to explore that question is to be able to run the exact same
> > program/workload on multiple runtime systems under different scenarios
> and
> > measure what happens.
> >
> > Our current runtime system probably does need to evolve to better exploit
> > Mesos/Kubernetes (eg Tyson's recent PR).  Kubernetes itself is likely to
> > evolve to better support FaaS-style workloads so we 

Re: override main on activation?

[James Thomas]

This is an interesting idea. Lambda has a nice feature of being able to
create functions from an S3 file containing the source zip, which means you
don't have to upload the same code for each different function. Not having
something can make deployments unnecessarily long on OpenWhisk when you
have a large app with dozens of functions and large action packages.

If this was available - I wonder if there's a way to define an "action
clone" which is like a sym-link to another action with a different "main"
parameter (defined at create time)? It would allow us to upload the action
package once and then create sym-links for all the other actions. This
would dramatically speed up deployments and reduce the amount of code
needed to store in the backend.




On Fri, 15 Mar 2019 at 07:45, Michele Sciabarra 
wrote:

> I like the idea. In particular, it would be very helpful in implementing
> an idea I had some time ago: deployment of Jupyter Notebooks as actions!
> (Here I refer to Python based notebooks mostly)
>
> Normally you have some code in it that you develop (and test)
> interactively, but the problem is: what is the entry point? Of course, it
> would be a "main" action defined in it but it would be limiting.
>
> In this way, I could pass the entire notebook to the initialization of the
> action and then invoke the various functions defined in it.
>
> --
>   Michele Sciabarra
>   mich...@sciabarra.com
>
> - Original message -
> From: Rodric Rabbah 
> To: dev@openwhisk.apache.org
> Subject: override main on activation?
> Date: Friday, March 15, 2019 5:58 AM
>
> When one creates an action today, they can specify the main entry point at
> creation time. For example:
>
>   wsk action create myfn f.js --main foo
>
> This allows a single file with multiple functions to be used as different
> actions.
>
> But this is wasteful - one has to create multiple actions this way and
> we're paying the cost in the backend by replicating the code (in the
> database, and multiple code fetches).
>
> What if the main was specified on invoke instead? For example, take a web
> action from this file hello.js
>
>   function niam(args) { return { 'greetings': 'Hello from a
> non-standard entrypoint.' } }  function main(args) { return {
> 'greetings': 'Hello from a standard entrypoint.' } }
>
> We could allow main to be set on the action activation.
>
> > curl -k https://guest.localhost/default/hello.json
> {
>   "greetings": "Hello from a standard entrypoint."
> }
>
> And now with an override to "main", using @ as the new entry
> point.
>
> > curl -k https://guest.localhost/default/hello.json@niam
> {
>   "greetings": "Hello from a non-standard entrypoint."
> }
>
> I created an issue to discuss the idea [1].
>
> I'm thinking primarily to restrict this to web actions initially, although
> there are some extensions that are also reasonable to consider
> subsequently:
>
>1. we could also make it work for POST invoke, namely wsk action invoke
>--main.
>2. we can extend it to sequences so that you can create a sequence from
>fn@main1, fn@main2
>3. we can further extend it to conductor continuations
>
> [1] https://github.com/apache/incubator-openwhisk/issues/4349
>


-- 
Regards,
James Thomas

Re: Pluggable Trigger Feed Event Provider

[James Thomas]

I've now opened an infrastructure ticket to move the pluggable event
provider back into Apache OpenWhisk.
https://issues.apache.org/jira/browse/INFRA-18011

Once this is done and the repo is ready, I'll work on migrating the S3
plugin back upstream too.

On Sat, 9 Feb 2019 at 16:29, Rodric Rabbah  wrote:

> This is awesome. Thanks James for sharing it.
>
> -r
>
> > On Feb 8, 2019, at 12:11 PM, James Thomas  wrote:
> >
> > Hello Whiskers.
> >
> > On Wednesday's Community Call, I presented my work on building a
> "pluggable
> > trigger feed event provider". The background for this experiment was
> > needing to build another trigger feed event source without having to
> > replicate all the boilerplate needed for trigger management.
> >
> > Here is the presentation from the call:
> >
> https://speakerdeck.com/jthomas/apache-openwhisk-pluggable-event-providers
> > Video recording of the call is available on the OpenWhisk YouTube
> channel:
> > https://www.youtube.com/watch?v=krm7X5YpGy0
> >
> > Feedback on the call was very positive so I've pushed the code to an
> > external Github repo allowing others to have a look at how it works.
> >
> > This is the repo for the "generic event feed provider". The README
> contains
> > all the instructions on how to create a plugin and run the provider with
> a
> > pluggable event source.
> >
> > https://github.com/jthomas/openwhisk-pluggable-event-provider
> >
> > Here's an example event plugin I built for an S3-compatible object store.
> > It polls a bucket endpoints and compares file etags, stored in Redis, to
> > determine any file changes. Triggers are fired with file events.
> >
> > https://github.com/jthomas/openwhisk-s3-trigger-feed
> >
> > As discussed on the call, my next steps were
> >
> >   -
> >
> >   Make the code public for the community to evaluate. (DONE ✅)
> >   -
> >
> >   Write a few more plugin providers (RabbitMQ, MQTT) to test it further.
> >   -
> >
> >   Contribute the code back to Apache to become an official component of
> >   the project.
> >
> > All feedback welcome!
> > --
> > Regards,
> > James Thomas
>


-- 
Regards,
James Thomas

Re: override main on activation?

[Michele Sciabarra]

I like the idea. In particular, it would be very helpful in implementing an 
idea I had some time ago: deployment of Jupyter Notebooks as actions! (Here I 
refer to Python based notebooks mostly)

Normally you have some code in it that you develop (and test) interactively, 
but the problem is: what is the entry point? Of course, it would be a "main" 
action defined in it but it would be limiting.

In this way, I could pass the entire notebook to the initialization of the 
action and then invoke the various functions defined in it.

-- 
  Michele Sciabarra
  mich...@sciabarra.com

- Original message -
From: Rodric Rabbah 
To: dev@openwhisk.apache.org
Subject: override main on activation?
Date: Friday, March 15, 2019 5:58 AM

When one creates an action today, they can specify the main entry point at
creation time. For example:

  wsk action create myfn f.js --main foo

This allows a single file with multiple functions to be used as different
actions.

But this is wasteful - one has to create multiple actions this way and
we're paying the cost in the backend by replicating the code (in the
database, and multiple code fetches).

What if the main was specified on invoke instead? For example, take a web
action from this file hello.js

  function niam(args) { return { 'greetings': 'Hello from a
non-standard entrypoint.' } }  function main(args) { return {
'greetings': 'Hello from a standard entrypoint.' } }

We could allow main to be set on the action activation.

> curl -k https://guest.localhost/default/hello.json
{
  "greetings": "Hello from a standard entrypoint."
}

And now with an override to "main", using @ as the new entry
point.

> curl -k https://guest.localhost/default/hello.json@niam
{
  "greetings": "Hello from a non-standard entrypoint."
}

I created an issue to discuss the idea [1].

I'm thinking primarily to restrict this to web actions initially, although
there are some extensions that are also reasonable to consider subsequently:

   1. we could also make it work for POST invoke, namely wsk action invoke
   --main.
   2. we can extend it to sequences so that you can create a sequence from
   fn@main1, fn@main2
   3. we can further extend it to conductor continuations

[1] https://github.com/apache/incubator-openwhisk/issues/4349

[slack-digest] [2019-03-14] #random

[OpenWhisk Team Slack]

2019-03-14 03:00:14 UTC - Jin Choi: @Rodric Rabbah I am running Openwhisk 
system on my servers and here's one question for you.
For Openwhisk deployment using ansible can we make it BLUE-GREEN deployment?
Ansible playbooks in `${OPENWHISK_HOME}/ansible` doesn't seem so.
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552532414119600

2019-03-14 03:01:12 UTC - Rodric Rabbah:  I think you’re right there isn’t a 
playbook for it. 

https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552532472120700

2019-03-14 03:01:36 UTC - Jin Choi: How does IBM deploy Openwhisk without 
downtime?
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552532496121400

2019-03-14 03:02:37 UTC - Rodric Rabbah: blue green is a good bet :)
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552532557121800

2019-03-14 03:04:02 UTC - Jin Choi: Once we migrate Openwhisk onto k8s, it will 
do the whole magic for us, right?
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552532642124100

2019-03-14 03:04:46 UTC - Jin Choi: While we are here stuck with ansible for 
the time being... I was wondering if I could provide zero downtime deployment 
experience for my customers.
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552532686125200

2019-03-14 03:05:34 UTC - Rodric Rabbah: you can deploy an outer router 
(another nginx) and switch the active cluster by reloading the config file 
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552532734126300

2019-03-14 03:06:09 UTC - Jin Choi: Is that how it's done in IBM?
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552532769126800

2019-03-14 03:06:29 UTC - Jin Choi: One charming solution, BTW
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552532789127100

2019-03-14 03:08:46 UTC - Jin Choi: In that case I need 2 seperate clusters of 
Openwhisk, and those two need to share the same one-and-only couchdb cluster. 
Am I getting it right?
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552532926128700

2019-03-14 03:09:08 UTC - Rodric Rabbah: our earliest solutions did just that - 
I can’t say what ibm does today 
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552532948129200

2019-03-14 03:09:36 UTC - Jin Choi: You mean, it's credential, right?
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552532976130300

2019-03-14 03:09:51 UTC - Rodric Rabbah: I think couch could be shared - you 
can replicate fully the rest as one option 
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552532991131000

2019-03-14 03:20:40 UTC - Jin Choi: With the suggested solution by @Rodric 
Rabbah I am worried if I could switch the Openwhisk clusters safely. It is the 
key making sure every actions that were being invoked on the BLUE cluster are 
all served and done. Otherwise some action invocation requests would return 
generated activation IDs and the result might disappear.  Only then I could 
switch the outer router from BLUE to GREEN.
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552533640138400

2019-03-14 03:20:46 UTC - Jin Choi: What do you think?
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552533646138600

2019-03-14 03:22:39 UTC - Rodric Rabbah: If you use the outer router as the api 
host then once you switch the active cluster the rest of activations in the now 
inactive cluster will just drain 
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552533759139600

2019-03-14 04:49:41 UTC - Carlos Santana: We use a shared Cloudant SaaS, we use 
Cloudflare Internet Services SaaS outer router to toggle the blue green, 0 
downtime 
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552538981141300

2019-03-14 04:55:29 UTC - Dominic Kim: @Jin Choi FYI, We(Naver) are deploying 
OpenWhisk without downtime(Not blue-green) in this way:
1. Remove a controller from the nginx
2. Wait until controller does not handle any activations(with API implemented 
to fetch the number of ongoing activations)
3. Deploy the controller
4. Readd the controller to nginx.
thankyou : Jin Choi
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552539329144100

2019-03-14 04:55:43 UTC - Dominic Kim: Similar logic is applied to invokers as 
well.
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552539343144500

2019-03-14 05:00:59 UTC - Jin Choi: @Dominic Kim Do you use the ansible 
playbooks in `OPENWHISK_HOME/ansible` as it is for the deploying strategy you 
are saying?
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552539659146600

2019-03-14 05:01:23 UTC - Dominic Kim: Yes
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552539683146800

2019-03-14 05:08:37 UTC - Jin Choi: And you don't modify this file, 
`OPENWHISK_HOME/ansible/environments/prod/hosts`, during the deployment?
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1552540117150200

2019-03-14 05:08:58 UTC - Dominic Kim: It depends.

[slack-digest] [2019-03-14] #general

[OpenWhisk Team Slack]

2019-03-14 02:55:39 UTC - Rodric Rabbah: That suggests your controller didn’t 
come back cleanly. Checked the logs? In /tmp/wsklogs
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552532139263500?thread_ts=1552532139.263500=C3TPCAQG1

2019-03-14 03:01:46 UTC - Xue Shuai: @chetanm Thanks for your reply, I fond the 
same info in  the log file at wsklogs. It seems that the metric have been 
enabled, but I still can't got data via grafana web port, Is there any 
suggestion :slightly_smiling_face:
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552532506263600?thread_ts=1552481145.258900=C3TPCAQG1

2019-03-14 08:23:36 UTC - Lars Andersson: I can't find any documentation of the 
breaking change with api keys that was introduced with PR #4284. Can someone 
point me to where I can find information on the new annotation and how that 
changes commands with wsk cli?
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552551816265600?thread_ts=1552551816.265600=C3TPCAQG1

2019-03-14 09:01:01 UTC - chetanm: Its documented here 

https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552554061265700?thread_ts=1552551816.265600=C3TPCAQG1

2019-03-14 09:01:20 UTC - chetanm: So just pass one more annotation as part of 
wsk cli
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552554080265900?thread_ts=1552551816.265600=C3TPCAQG1

2019-03-14 09:02:06 UTC - chetanm: Not played much with graphite. Would check. 
Most likely data is there just need to be surfaced in Grafan by authoring a 
dashboard
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552554126266100?thread_ts=1552481145.258900=C3TPCAQG1

2019-03-14 09:05:02 UTC - chetanm: I can see the metrics in 

https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552554302266300?thread_ts=1552481145.258900=C3TPCAQG1

2019-03-14 09:05:23 UTC - chetanm: 
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552554323266500?thread_ts=1552481145.258900=C3TPCAQG1

2019-03-14 09:20:39 UTC - Lars Andersson: Thanks. Never checked that document 
:face_with_monocle:
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552555239266900?thread_ts=1552551816.265600=C3TPCAQG1

2019-03-14 11:15:17 UTC - Barry: How does the invoker get the IP addresses of 
the action containers(wsk0_*) ? I intercept the docker commands that executed 
by invoker, but it seems that the command of "docker inspect..." has never been 
executed. I can see only "docker ps/run/pause/unpause/rm" commands executed.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552562117268900

2019-03-14 11:21:17 UTC - Dominic Kim: @Barry IP address is acquired by this 

 while creating a container.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552562477269600

2019-03-14 11:25:06 UTC - Barry: @Dominic Kim Then it will execute this code ? 

https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552562706270200

2019-03-14 11:25:27 UTC - Dominic Kim: I think so.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552562727270400

2019-03-14 11:26:03 UTC - Barry: It seems the docker inspect command will be 
executed then.  Seq("inspect", "--format", 
s"{{.NetworkSettings.Networks.${network}.IPAddress}}", id.asString)
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552562763270900

2019-03-14 11:26:31 UTC - Barry: But I didn't see the inspect command executed 
in my log file
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552562791271500

2019-03-14 11:27:13 UTC - Dominic Kim: How do you capture the docker command 
execution?
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552562833271800

2019-03-14 11:27:39 UTC - Barry: === docker run -d --cpu-shares 256 
--memory 256m --memory-swap 256m --network openwhisk_default -e 
__OW_API_HOST= --name wsk0_6_whisksystem_getApi --cap
=== docker pause 
4a7a5046fb1c0d0f8ef71eb1c444be54cc1e969ccac20dc4b02bf9e3b0f634d5
=== docker unpause 
216d9c5a2d22009610693ae050932638f1c0eae724c29f228b89aa7ed89cae84
=== docker run -d --cpu-shares 256 --memory 256m --memory-swap 256m 
--network openwhisk_default -e __OW_API_HOST= --name 
wsk0_7_whisksystem_deleteApi --
=== docker rm -f 
216d9c5a2d22009610693ae050932638f1c0eae724c29f228b89aa7ed89cae84
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552562859272000

2019-03-14 11:28:45 UTC - Dominic Kim: Are using logging to capture the docker 
command?

fun contributor stats

[Rodric Rabbah]

The project has a total of 217 unique contributors across 32 repositories,
and 145 of these are contributors to the "openwhisk" repo.

There are (across all the repos):

- 19 contributors with at least 100 commits
- 7 contributors with at least 50 commits (and fewer than 100 commits)
- 34 contributors with at least 10 commits ...
- 25 contributors with at least 5 commits
- 17 contributors with at least 4 commits
- 28 contributors with at least 2 commits
- 87 contributors with 1 commit

-r