Re: devtools and make-quickstart

[Rodric Rabbah]

> I also like the standalone JAR. Should we consider adding to that the API
Management features made available through OW GW, or for that we should
keep the docker-compose route ?

I did get the API gateway to run (in the container) with standalone
openwhisk. I ran the ansible playbook (wskdev apigw) to get it up and
going. It doesn't work with sls (serverless framework because of the DNS
resolution issue I've posted about in the past) but will work with wsk.

-r

Re: devtools and make-quickstart

[Dascalita Dragos]

"...we should pin all the dependent images etc and make a release
available"
+1

I also like the standalone JAR. Should we consider adding to that the API
Management features made available through OW GW, or for that we should
keep the docker-compose route ?

On Fri, Jul 12, 2019 at 8:53 AM James Thomas  wrote:

> +1 on the first point. I've seen other issues in the past with the devtools
> project based on image versioning stuff.
>
> Given devtools is more for experimental and first-steps than production
> usage - switching to the standalone controller seems like a good idea.
>
> On Fri, 12 Jul 2019 at 16:15, Rodric Rabbah  wrote:
>
> > this issue was opened against devtools and raises an important point:
> > https://github.com/apache/incubator-openwhisk-devtools/issues/273
> >
> > "On a separate note, will these builds eventually be versioned or will
> they
> > continue to be tagged in a backwards incompatible way? I am trying to
> > create a build process that is deterministic and currently I am unable to
> > achieve this."
> >
> > Given that we're pointing developer to make quick start still as the way
> to
> > startup and some of the dependence in this build on docker latest (now
> > nightly), I think we should pin all the dependent images etc and make a
> > release available.
> >
> > An existential question is whether we should use the standalone
> controller
> > which is faster to startup and adapt our docs accordingly.
> >
> > Thoughts?
> >
> > -r
> >
>
>
> --
> Regards,
> James Thomas
>

Re: devtools and make-quickstart

[James Thomas]

+1 on the first point. I've seen other issues in the past with the devtools
project based on image versioning stuff.

Given devtools is more for experimental and first-steps than production
usage - switching to the standalone controller seems like a good idea.

On Fri, 12 Jul 2019 at 16:15, Rodric Rabbah  wrote:

> this issue was opened against devtools and raises an important point:
> https://github.com/apache/incubator-openwhisk-devtools/issues/273
>
> "On a separate note, will these builds eventually be versioned or will they
> continue to be tagged in a backwards incompatible way? I am trying to
> create a build process that is deterministic and currently I am unable to
> achieve this."
>
> Given that we're pointing developer to make quick start still as the way to
> startup and some of the dependence in this build on docker latest (now
> nightly), I think we should pin all the dependent images etc and make a
> release available.
>
> An existential question is whether we should use the standalone controller
> which is faster to startup and adapt our docs accordingly.
>
> Thoughts?
>
> -r
>


-- 
Regards,
James Thomas

devtools and make-quickstart

[Rodric Rabbah]

this issue was opened against devtools and raises an important point:
https://github.com/apache/incubator-openwhisk-devtools/issues/273

"On a separate note, will these builds eventually be versioned or will they
continue to be tagged in a backwards incompatible way? I am trying to
create a build process that is deterministic and currently I am unable to
achieve this."

Given that we're pointing developer to make quick start still as the way to
startup and some of the dependence in this build on docker latest (now
nightly), I think we should pin all the dependent images etc and make a
release available.

An existential question is whether we should use the standalone controller
which is faster to startup and adapt our docs accordingly.

Thoughts?

-r

Execute OpenWhisk action via Ignite and Firecracker VM (pr #4556)

[Chetan Mehrotra]

Hi Team,

Seeing the recent Weave Ignite announcement [1] I tried to implement a
quick prototype for integrating it with OpenWhisk [2].

So far the results are good and OpenWhisk can create and launch
ignite/firecracker based vm for action invocation. Currently the cold
startup times have few issues due to late binding of node service
within the vm. Also the logs part does not work. However apart from
that other aspects work ok.

It is a promising technology and we can possibly explore it more for
integrating it with OpenWhisk to provide more secure execution
environment.

Chetan Mehrotra
[1] https://www.weave.works/blog/fire-up-your-vms-with-weave-ignite
[2] https://github.com/apache/incubator-openwhisk/pull/4556

[slack-digest] [2019-07-11] #general

[OpenWhisk Team Slack]

2019-07-11 07:45:37 UTC - Adam Varsano: Hi all,

I start developing my business via openwhisk.
I deployed the openwhisk on rancher via helm chart: 


The issue is that every few days/weeks something fall like zoo keeper pod.
Then it doesn't come back to life, it goes into crash loop.

I'm not feeling it is stable enough via kubernetes for production.
Any ideas?
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562831137308500

2019-07-11 07:48:39 UTC - Dominic Kim: Since I am not working for IBM, I have 
no much idea but,
AFAIK, IBM Cloud function has been operated on Kubernetes for server years.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562831319309800

2019-07-11 07:50:36 UTC - Roberto Santiago: @Adam Varsano I have had the same 
issue as well.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562831436310100

2019-07-11 07:55:06 UTC - chetanm: Can you open an issue for  that and if 
possible add relevant log files. That may provide some clue
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562831706312000

2019-07-11 07:55:43 UTC - Roberto Santiago: It seems like zookeeper pod can get 
evicted.  When it comes back kafka is not able to find it.  Then as a result 
the controller starts throwing errors.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562831743312600

2019-07-11 07:57:13 UTC - chetanm: So far kube chart did not had pod disruption 
budgets. That may cause zookeeper quorum to break. Pod disruption budge support 
was added recently which may help to some extent
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562831833313800

2019-07-11 08:38:08 UTC - Sven Lange-Last: if you observe problems like pod 
eviction, check your kube resources with `kubectl -n your_ns describe 
pod ...`. you can do the same for your higher level resources like 
statefulsets, replicasets, etc.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562834288315500

2019-07-11 08:38:26 UTC - Sven Lange-Last: pods are usually only evicted if 
something went wrong with your worker node.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562834306315900

2019-07-11 08:38:39 UTC - Sven Lange-Last: maybe you are running too many 
components on a single worker node?
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562834319316300

2019-07-11 08:39:41 UTC - Sven Lange-Last: ibm cloud functions runs on ibm 
cloud kubernetes cluster. i can confirm that kube is stable enough to run 
openwhisk in production.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562834381317100

2019-07-11 08:40:11 UTC - Sven Lange-Last: but i have to admit that we are not 
using  but use a 
homegrown deployment.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562834411317600

2019-07-11 08:41:49 UTC - Roberto Santiago: @Sven Lange-Last I've thought about 
putting together my own as well.  Would you be open to sharing some details 
about your deployment (and the thinking that went into how you are doing your 
deployment)?
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562834509318600

2019-07-11 08:42:44 UTC - Sven Lange-Last: i you have specific questions, i may 
be able to share some details.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562834564319200

2019-07-11 08:44:45 UTC - Roberto Santiago: The two areas I have recurrently 
had issues with is kafka-zookeeper (similar to @Adam Varsano) and couchdb.  
What are you doing around deployment with those two pieces?
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562834685320500

2019-07-11 08:45:41 UTC - Sven Lange-Last: we are using ibm cloudant db service 
instead of running our own db.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562834741321400

2019-07-11 08:45:57 UTC - Adam Varsano: So what is the best practice for deploy 
openwhisk with the most stable way?
Can you explain more about your homegrown deployment?
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562834757321800

2019-07-11 08:47:30 UTC - Sven Lange-Last: regarding zookeeper / kafka. we made 
sure that these run on their own (large) worker nodes and have enough cpu / 
disk resources. these two have persistent volume claims to make sure they 
cannot loose their data.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562834850322900

2019-07-11 08:48:38 UTC - Sven Lange-Last: and for prod envs, it’s better to 
set up zookeeper / kafka in an ha setup with replication.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562834918323800

2019-07-11 08:49:02 UTC - Adam Varsano: So we should ignore the helm chart? 
deploy it manually?
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562834942324200

2019-07-11 08:50:36 UTC - Sven Lange-Last: to be honest: i don’t know the helm 
charts in detail. it’s better to discuss with @Dave Grove. but running on 

[slack-digest] [2019-07-11] #random

[OpenWhisk Team Slack]

2019-07-11 01:52:12 UTC - Rodric Rabbah: 

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

2019-07-11 04:54:04 UTC - chetanm: This is pretty powerful! Bringing similar 
model  like `docker run` for vms. And its fast
 When you run your OCI image using ignite run, Firecracker will boot a new 
VM in c.125 milliseconds (!) for you
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1562820844026200

2019-07-11 05:01:31 UTC - Dominic Kim: Yes.

One of its specs guarantees 125 ms to create thousands of micro VMs.
Since it could be a good alternative for Docker performance issue, it would be 
great to keep eyes on this.

This project aims to integrate firecracker with containerd.
https://openwhisk-team.slack.com/archives/C3UDXSFA6/p1562821291028300