Re: About Ruby2.5 runtime support proposal(in relation to #3725)

[Kei Sawada]

> > If you had time to write up generic instructions for creating a new
> > runtime, based on your experiences, it would help others add more. It has
> > been something we've been meaning to do since the PHP runtime.
> >
> > Also, if you get time, adding a simple OpenWhisk Ruby client library to
> the
> > default runtime would be really useful from a "developer" experience POV.
> > Just making it easy for developers to invoke functions & triggers from
> the
> > runtime would be 80% of the methods needed.
>

Yes if this PR goes well, I'm willing to do/consider both. Thanks for your
insight.


> diff --git a/ansible/files/runtimes.json b/ansible/files/runtimes.json
> index 44cb30f2..96a65001 100644
> --- a/ansible/files/runtimes.json
> +++ b/ansible/files/runtimes.json
> @@ -109,6 +109,17 @@
>  "name": "action-php-v7.1"
>  }
>  }
> +],
> +"ruby": [
> +{
> +"kind": "ruby:2.5",
> +"default": true,
> +"deprecated": false,
> +"image": {
> +"prefix": "remore",
> +"name": "openwhisk-runtime-ruby"
> +}
> +}
>  ]
>

Thank you for the better instruction. Definitely this looks nicer.

Best,
Kei

Re: New scheduling algorithm proposal.

[Dominic Kim]

Sorry.
Let me share Kafka benchmark results again.

| # of topics  |   Kafka TPS |
|50  |   34,488 |
|  100  |  34,502 |
|  200  |   31,781 |
|  500  |   30,324 |
| 1000  |  30,855 |

Best regards
Dominic


2018-06-07 2:04 GMT+09:00 Dominic Kim :

> Sorry for the late response Tyson.
>
> Let me first answer your second question.
> Vuser is just the number of threads to send the requests.
> Each Vusers randomly picked the namespace and send the request using REST
> API.
> So they are independent of the number of namespaces.
>
> And regarding performance degradation on the number of users, I think it
> works a little bit differently.
> Even though I have only 2 users(namespaces), if their homeInvoker is same,
> TPS become very less.
> So it is a matter of the number of actions whose homeInvoker are same
> though more the number of users than the number of containers can harm the
> performance.
> This is because controller should send those actions to the same invoker
> even though there are other idle invokers.
> In my proposal, controllers can schedule activation to any invokers so it
> does not happen.
>
>
> And regarding the issue about the sheer number of Kafka topics, let me
> share my idea.
>
> 1. Data size is not changed.
>
> If we have 1000 activation requests, they will be spread among invoker
> topics. Let's say we have 10 invokers, then ideally each topic will have
> 100 messages.
> In my proposal, if I have 10 actions, each topic will have 100 messages as
> well.
> Surely there will be more number of actions than the number of invokers,
> data will be spread to more topics, but data size is unchanged.
>
> 2. Data size depends on the number of active actions.
>
> For example, if we have one million actions, in turn, one million topics
> in Kafka.
> If only half of them are executed, then there will be data only for half
> of them.
> For rest half of topics, there will be no data and they won't affect the
> performance.
>
> 3. Things to concern.
>
> Let me describe what happens if there are more number of Kafka topics.
>
> Let's say there are 3 invokers with 5 activations each in the current
> implementation, then it would look like this.
>
> invoker0: 0 1 2 3 4 5 (5 messages) -> consumer0
> invoker1: 0 1 2 3 4 5 -> consumer1
> invoekr2: 0 1 2 3 4 5 -> consumer2
>
> Now If I have 15 actions with 15 topics in my proposal.
>
> action0: 0  -> consumer0
> action1: 0  -> consumer1
> action2: 0  -> consumer2
> action3: 0  -> consumer3
> .
> .
> .
> action14: 0  -> consumer14
>
> Kafka utilizes page cache to maximize the performance.
> Since the size of data is not changed, data kept in page cache is also not
> changed.
> But the number of parallel access to data is increased. I think it might
> be some overhead.
>
> That's the reason why I performed benchmark with multiple topics.
>
> # of topics
>
> Kafka TPS
>
> 50
>
> 34,488
>
> 100
>
> 34,502
>
> 200
>
> 31,781
>
> 500
>
> 30,324
>
> 1,000
>
> 30,855
>
> As you can see there are some overheads from increased parallel access to
> data.
> Here we can see about 4,000 TPS degraded as the number of topics increased.
>
> But we can still support 30K TPS with 1000 topics using 3 Kafka nodes.
> If we need more TPS we can just add more nodes.
> Since Kafka can horizontally scale-out, if we add 3 more servers, I expect
> we can get 60K TPS.
>
> Partitions in Kafka are evenly distributed among nodes in a cluster.
> Each nodes becomes a leader for each partition. If we have 100 partitions
> with 4 Kafka nodes, ideally each Kafka nodes will be a leader for 25
> partitions.
> Then consumers can directly read messages from different partition leaders.
> This is why Kafka can horizontally scale-out.
>
> Even though the number of topics is increased, if we add more Kafka nodes,
> the number of partitions which is managed by one Kafka node would be
> unchanged.
> So if we can support 30K TPS with 1000 topics using 3 nodes, then we can
> still get 60K TPS with 2000 topics using 6 nodes.
> Similarly, if we have enough Kafka nodes, the number of partitions in one
> Kafka nodes will be same though we have one million concurrent invocations.
>
> This is what I am thinking.
> If I miss anything, kindly let me know.
>
> Thanks
> Regards
> Dominic.
>
>
>
>
>
> 2018-05-26 13:22 GMT+09:00 Tyson Norris :
>
>> Hi Dominic -
>>
>> Thanks for the detailed presentation! It is helpful to go through to
>> understand your points - well done.
>>
>>
>> A couple of comments:
>>
>> - I'm not sure how unbounded topic (and partition) growth will be
>> handled, realistically. AFAIK, these are not free of resource consumption
>> at the client or.
>>
>> - In your test it looks like you have 990 vusers example (pdf page 121) -
>> are these using different namespaces? I ask because I think the current
>> impl isolates the container per namespace, so if you are limited to 180
>> containers, I can see how there will be container removal/restarts in the
>> case where the number of users greatly 

Re: New scheduling algorithm proposal.

[Dominic Kim]

Sorry for the late response Tyson.

Let me first answer your second question.
Vuser is just the number of threads to send the requests.
Each Vusers randomly picked the namespace and send the request using REST
API.
So they are independent of the number of namespaces.

And regarding performance degradation on the number of users, I think it
works a little bit differently.
Even though I have only 2 users(namespaces), if their homeInvoker is same,
TPS become very less.
So it is a matter of the number of actions whose homeInvoker are same
though more the number of users than the number of containers can harm the
performance.
This is because controller should send those actions to the same invoker
even though there are other idle invokers.
In my proposal, controllers can schedule activation to any invokers so it
does not happen.


And regarding the issue about the sheer number of Kafka topics, let me
share my idea.

1. Data size is not changed.

If we have 1000 activation requests, they will be spread among invoker
topics. Let's say we have 10 invokers, then ideally each topic will have
100 messages.
In my proposal, if I have 10 actions, each topic will have 100 messages as
well.
Surely there will be more number of actions than the number of invokers,
data will be spread to more topics, but data size is unchanged.

2. Data size depends on the number of active actions.

For example, if we have one million actions, in turn, one million topics in
Kafka.
If only half of them are executed, then there will be data only for half of
them.
For rest half of topics, there will be no data and they won't affect the
performance.

3. Things to concern.

Let me describe what happens if there are more number of Kafka topics.

Let's say there are 3 invokers with 5 activations each in the current
implementation, then it would look like this.

invoker0: 0 1 2 3 4 5 (5 messages) -> consumer0
invoker1: 0 1 2 3 4 5 -> consumer1
invoekr2: 0 1 2 3 4 5 -> consumer2

Now If I have 15 actions with 15 topics in my proposal.

action0: 0  -> consumer0
action1: 0  -> consumer1
action2: 0  -> consumer2
action3: 0  -> consumer3
.
.
.
action14: 0  -> consumer14

Kafka utilizes page cache to maximize the performance.
Since the size of data is not changed, data kept in page cache is also not
changed.
But the number of parallel access to data is increased. I think it might be
some overhead.

That's the reason why I performed benchmark with multiple topics.

# of topics

Kafka TPS

50

34,488

100

34,502

200

31,781

500

30,324

1,000

30,855

As you can see there are some overheads from increased parallel access to
data.
Here we can see about 4,000 TPS degraded as the number of topics increased.

But we can still support 30K TPS with 1000 topics using 3 Kafka nodes.
If we need more TPS we can just add more nodes.
Since Kafka can horizontally scale-out, if we add 3 more servers, I expect
we can get 60K TPS.

Partitions in Kafka are evenly distributed among nodes in a cluster.
Each nodes becomes a leader for each partition. If we have 100 partitions
with 4 Kafka nodes, ideally each Kafka nodes will be a leader for 25
partitions.
Then consumers can directly read messages from different partition leaders.
This is why Kafka can horizontally scale-out.

Even though the number of topics is increased, if we add more Kafka nodes,
the number of partitions which is managed by one Kafka node would be
unchanged.
So if we can support 30K TPS with 1000 topics using 3 nodes, then we can
still get 60K TPS with 2000 topics using 6 nodes.
Similarly, if we have enough Kafka nodes, the number of partitions in one
Kafka nodes will be same though we have one million concurrent invocations.

This is what I am thinking.
If I miss anything, kindly let me know.

Thanks
Regards
Dominic.





2018-05-26 13:22 GMT+09:00 Tyson Norris :

> Hi Dominic -
>
> Thanks for the detailed presentation! It is helpful to go through to
> understand your points - well done.
>
>
> A couple of comments:
>
> - I'm not sure how unbounded topic (and partition) growth will be handled,
> realistically. AFAIK, these are not free of resource consumption at the
> client or.
>
> - In your test it looks like you have 990 vusers example (pdf page 121) -
> are these using different namespaces? I ask because I think the current
> impl isolates the container per namespace, so if you are limited to 180
> containers, I can see how there will be container removal/restarts in the
> case where the number of users greatly outnumbers the number of containers
> - I'm not sure if the test behaves this way, or your "New implementation"
> behaves similar? (does a container get reused for many different
> namespaces?)
>
>
> I'm interested to know if there are any kafka experts here that can
> provide more comments on the topics/partition handling question? I will
> also ask for some additional feedback from other colleagues.
>
>
> I will gather some more comments to share, but wanted to start off with
> these. Will 

Re: Asynchronous communications (was: Please review our project's draft...)

[David P Grove]

Bertrand Delacretaz  wrote on 06/06/2018 11:06:01
AM:
>
> On Wed, Jun 6, 2018 at 4:42 PM, David P Grove  wrote:
> > ...As Rodric said, properly organized channels and the use of threads
help
> > quite a bit...
>
> Do you have a few Slack URLs of good examples of that?
>
> I'll look at them quickly, before they disappear ;-)
>
> -Bertrand
>

I think Slack is measurably better than a mailing list for some kinds of
interactions:
1. User support.  Quick interaction, back & forth QA, ability to
directly embed pictures, URLS, etc. For example,
https://openwhisk-team.slack.com/archives/C7DJNS37W/p152497924770

2. Brainstorming discussions (distributed water cooler).  For
example,
https://openwhisk-team.slack.com/archives/C4J3R7JFL/p1526486614000581

3. Group debugging & problem fixing (the link in Rodric's email)
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1527870544000195

I don't think Slack is as good at going really deep into the details (turns
into "walls of text" that are intimidating to catch up with when you come
to them later).  GitHub issues or email is still better here I think.

--dave

Re: Asynchronous communications (was: Please review our project's draft...)

[Rob Allen]

> On 6 Jun 2018, at 15:30, Rodric Rabbah  wrote:
> 
> Re slack... good discipline on our part does make it easier to catch up
> even after hundreds of messages are posted. We do try to organize
> discussions using slack threads so that it is easier to follow a particular
> topic. This doesn't always happen and as I noted, requires good habits.
> 

I'm one of those who is particularly poor at threads as they are a 
significantly more effort to create and read than just talking in channel when 
you're a keyboard-centric user. Sorry.

It may be worth having some sort of document noting how to use the OpenWhisk 
Slack if there are practices that make it better.

Rob

Re: Asynchronous communications (was: Please review our project's draft...)

[Rodric Rabbah]

Chetan suggested looking into Slack workspace export - It looks like we can
export all the messages this way (since 1/20/2017 for public channels). A
simple UI to polish the JSON and make it easier to read and search would be
helpful.

Here's an example of a recent thread of discussion:
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1527870544000195 for
fixing an issue with docker compose deployment.

-r

On Wed, Jun 6, 2018 at 11:06 AM, Bertrand Delacretaz  wrote:

> On Wed, Jun 6, 2018 at 4:42 PM, David P Grove  wrote:
> > ...As Rodric said, properly organized channels and the use of threads
> help
> > quite a bit...
>
> Do you have a few Slack URLs of good examples of that?
>
> I'll look at them quickly, before they disappear ;-)
>
> -Bertrand
>

Re: Asynchronous communications (was: Please review our project's draft...)

[Bertrand Delacretaz]

On Wed, Jun 6, 2018 at 4:42 PM, David P Grove  wrote:
> ...As Rodric said, properly organized channels and the use of threads help
> quite a bit...

Do you have a few Slack URLs of good examples of that?

I'll look at them quickly, before they disappear ;-)

-Bertrand

Re: Tech Interchange meeting tomorrow

[David P Grove]

Apologies for missing the interchange today; unavoidable personal conflict.

A quick update on the openwhisk-deploy-kube sub-project.

1. Main focus in the last two weeks has been the Helm-based
deployment.  This is looking really solid.  I'm working on a PR now to
reorganize the documentation to make Helm the recommend way of deploying to
Kubernetes.  It should be submitted for review later today.

2. I think we should consider adding openwhisk-deploy-kube to the set
of release repositories.  Dev list discussion of pros/cons and what needs
to be done to make this possible?

--dave

Re: Asynchronous communications (was: Please review our project's draft...)

[Rodric Rabbah]

Re slack... good discipline on our part does make it easier to catch up
even after hundreds of messages are posted. We do try to organize
discussions using slack threads so that it is easier to follow a particular
topic. This doesn't always happen and as I noted, requires good habits.

We have also applied the practice in slack where there is a discussion
worth recording for posterity to open an issue, send an email to the dev
list, and make sure it's not only recorded in slack.

We do have a channel just for PRs on slack, and while we have several
channels, we mainly use the general channel for all discussions. I think
this was worked well to keep all topics widely visible but that is only my
opinion of course.

Weekly summaries if they can be automated could be a nice way of catching
up. Perhaps an opportunity to use OpenWhisk itself to generate the digests,
perhaps summarizing the PR activities and commits to start.

-r

Re: Asynchronous communications (was: Please review our project's draft...)

[Bertrand Delacretaz]

Hi,

On Wed, Jun 6, 2018 at 4:05 PM, David P Grove  wrote:
> ...Professionally, I'm on several Slack teams that are paid (unlimited
> history) and I personally find it _much_ easier to catch up with and
> understand multiple weeks of technical conversation in a properly focused
> Slack channel than multiple weeks of email chains sent to a single dev
> list

I'm genuinely interested in how that can work - if you have examples
I'm all ears.

> ...I'd suggest that perhaps the ASF should be considering how to adapt and
> support this style of communication in a way that meets its broader
> objectives for project organization...

My goal with "fixing" this with OpenWhisk is indeed to see how the ASF
can adapt efficiently.

> ...Things like
> Slack are not going to go away...

Of course, but if it's the project's main channel it needs to support
efficient asynchronous collaboration. As mentioned, I'm willing to be
educated on how that works.

-Bertrand

Re: Please review our project's draft Apache Incubator June board report

[Bertrand Delacretaz]

On Wed, Jun 6, 2018 at 4:04 PM, Carlos Santana  wrote:
> ...I think the company is referring to that to my understanding is that the
> project to graduate should have at least 3 companies sponsoring the
> project...

It's not exactly that. To graduate, a project must have "sufficient
diversity" so that it's not overly dependent on a single entity which
might lose interest and cause the project to stop.

That diversity is generally defined by having PMC members affiliated
with at least 3 different entities, which do not have to be companies
- people from two companies along with a few independents is fine.

What's most important is for all things to happen in the open, "if it
didn't happen on the dev list it didn't happen" so that anyone can
participate in decisions. My other thread about asynchronous
communications is related - it must be easy to collaborate with the
project even if one isn't working 100% on it.

-Bertrand

Re: Asynchronous communications (was: Please review our project's draft...)

[David P Grove]

Bertrand Delacretaz  wrote on 06/06/2018 09:32:09
AM:

> > ...Would it be worth adding the growth of the
> > Slack community? We're ~800 members and it is really active
>
> With my incubation mentor hat on: enthusiasm for the the project is
> fantastic news, but Apache projects should do their business on
> asynchronous channels, and I don't consider Slack to be one (*)
>
> OpenWhisk is not the only ASF project to be working in this mode and
> finding a way to reconcile this with the ASF's asynchronous
> communications principles might be a good example for other projects.
>
> Barring "move everything to the dev list" which wouldn't be popular,
> do people have suggestions on how to improve this? Weekly news that
> point to important places (PRs etc.) where things are happening so
> people can catch up? Guidelines on how to use the various channels?
> Something else?
>
> I understand this is not a big problem now if many OpenWhisk
> committers are working full-time on the project, but as it evolves I
> suppose the number of full-time contributors will go down. And the
> Apache model requires providing full support to part-time folks as
> well, so this needs to be improved.
>
> -Bertrand
>
> (*) because it's impossible to catch up there if you come back from a
> week-long absence, for example
>

I think the main problem is the limitations of using a "free" slack team,
so there is very limited history.

Professionally, I'm on several Slack teams that are paid (unlimited
history) and I personally find it _much_ easier to catch up with and
understand multiple weeks of technical conversation in a properly focused
Slack channel than multiple weeks of email chains sent to a single dev
list.

I'd suggest that perhaps the ASF should be considering how to adapt and
support this style of communication in a way that meets its broader
objectives for project organization.  For example, arrange for paid Slack
teams for its projects that would not have history limitations. Things like
Slack are not going to go away.

regards,

--dave

Re: Please review our project's draft Apache Incubator June board report

[Carlos Santana]

I think the company is referring to that to my understanding is that the
project to graduate should have at least 3 companies sponsoring the
project, which typically in practice sponsoring means that they are behind
the project in case 1 company drops, there are at least 2 to continue the
project.

In practice the company will have a set of people really involved int the
project and these people would be part of IPPMC and committers.

Is there is a better way to articulate the distinction between the normal
Apache way that at the end of the day is individuals are the contributors
and maintainers of the projects, vs. maybe a graduation criteria (initial
stages of project) I'm good with to make it explicit and more clear.

-- Carlos

On Wed, Jun 6, 2018 at 9:34 AM Bertrand Delacretaz 
wrote:

> On Tue, Jun 5, 2018 at 7:51 PM, Matt Rutkowski 
> wrote:
> ...
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=85475755
> ...
>
> Thanks for this! Great report as usual.
>
> Could "Increase additional company and individual Contributors to
> maintain all project repos" be changed to just "increase
> contributions" or something similar?
>
> It's individuals who contribute to ASF projects, not companies.
>
> -Bertrand (nitpicking, with my incubation mentor hat on - but that's
> an important nuance)
>

Re: Please review our project's draft Apache Incubator June board report

[Bertrand Delacretaz]

On Tue, Jun 5, 2018 at 7:51 PM, Matt Rutkowski  wrote:
...
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=85475755 ...

Thanks for this! Great report as usual.

Could "Increase additional company and individual Contributors to
maintain all project repos" be changed to just "increase
contributions" or something similar?

It's individuals who contribute to ASF projects, not companies.

-Bertrand (nitpicking, with my incubation mentor hat on - but that's
an important nuance)

Asynchronous communications (was: Please review our project's draft...)

[Bertrand Delacretaz]

Someone wrote:

> ...Would it be worth adding the growth of the
> Slack community? We're ~800 members and it is really active

With my incubation mentor hat on: enthusiasm for the the project is
fantastic news, but Apache projects should do their business on
asynchronous channels, and I don't consider Slack to be one (*)

OpenWhisk is not the only ASF project to be working in this mode and
finding a way to reconcile this with the ASF's asynchronous
communications principles might be a good example for other projects.

Barring "move everything to the dev list" which wouldn't be popular,
do people have suggestions on how to improve this? Weekly news that
point to important places (PRs etc.) where things are happening so
people can catch up? Guidelines on how to use the various channels?
Something else?

I understand this is not a big problem now if many OpenWhisk
committers are working full-time on the project, but as it evolves I
suppose the number of full-time contributors will go down. And the
Apache model requires providing full support to part-time folks as
well, so this needs to be improved.

-Bertrand

(*) because it's impossible to catch up there if you come back from a
week-long absence, for example

Re: Please review our project's draft Apache Incubator June board report

[Bertrand Delacretaz]

Hi,

On Tue, Jun 5, 2018 at 10:28 PM, Matt Rutkowski  wrote:
> ...We recently had a public (and private threads) around "models" for
> donation at Apache which went no where...

IIUC you mean donating resources for automated testing?

The ASF now has a Targeted Sponsors [1] program meant specifically for that.

If you think that's not useful, or if there are obstacles, I'm happy
to help figure out how to fix that. Ideally here or on private lists
if really required.

-Bertrand

[1] http://www.apache.org/foundation/thanks.html

Re: Please review our project's draft Apache Incubator June board report

[Carlos Santana]

Matt,

Thanks for spending time doing the report, I can't express more gratitude
about this.

On one of the board meetings, someone mentioned that "OpenWhisk" report is
one of the best incubator reports they have seen in years. Kudos !!
I don't know how you come up with so excellent detail report of the things
we have done

I updated the report with the following, other than adding is lgtm

-  For blocker for graduation, I remove the kubernetes/mesos statement,
this should not be related to graduation (Tyson pointed out in a comment)
- Added trademark handoff to graduation blockers
- Added what James Thomas suggested on Slack activity
- check box for "initial setup" (Rob pointed out in a comment)

-cs


On Wed, Jun 6, 2018 at 6:19 AM James Thomas  wrote:

> LGTM - nice work Matt.
>
> On the "Community" section? Would it be worth adding the growth of the
> Slack community? We're ~800 members and it is really active.
>
> On 5 June 2018 at 18:51, Matt Rutkowski  wrote:
>
> > Whiskers,
> >
> > I have drafted our project board report for this quarter (June); I plan
> to
> > post it tomorrow to the board's Wiki; please review and comment here or
> on
> > our CWiki:
> >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=85475755
> >
> > Thanks,
> > Matt
> >
> > PS message me if you need CWiki access
> >
>
>
>
> --
> Regards,
> James Thomas
>

Re: Tech Interchange meeting tomorrow

[Dominic Kim]

Dear Tyson.
Sorry for the late response, I thought I am already supposed to share it at
this meeting.
I am in.

Let me continue to share my scheduling proposal.

Thanks
Regards
Dominic.


2018-06-06 17:41 GMT+09:00 Rodric Rabbah :

> Thanks Sandeep - id like to see; we need a plan for resolving the long
> outstanding pr so getting to see the status, features, and your thoughts
> will be essential.
>
> Tyson, I hope we can put this toward the top of the agenda, along with the
> release discussion.
>
> -r
>
> > On Jun 6, 2018, at 4:37 AM, sandy...@gmail.com 
> wrote:
> >
> > Hi Tyson,
> >
> > If time permits I can demo OpenWhisk tracing support based on my PR.
> >
> > thanks,
> > Sandeep
> >
> >> On 2018/06/05 16:08:23, Tyson Norris 
> wrote:
> >> Hi All -
> >> Reminder: the biweekly call is tomorrow 10 am GMT-5:00 (US Central
> Time), please send any agenda items to the list or myself.
> >> Google cal link below with call details.
> >>
> >> Dominic - do you want to continue your presentation from 2 weeks ago?
> >>
> >> Current agenda to also include:
> >> * Priti Desai -  to discuss enhancements to wskdeploy
> >> * Vincent - to discuss Apache (source) release progress with focus on
> JDK considerations.
> >>
> >> Thanks
> >> Tyson
> >>
> >>
> >> https://calendar.google.com/calendar/r/eventedit/copy/
> M3RmZG04YW12cXVib2xwYzFycmEzYmFicGNfMjAxODA1MjNUMTUwMDAwWiBh
> cGFjaGVvcGVud2hpc2tAbQ/dHlzb25ub3JyaXNAZ21haWwuY29t?scp=ALL=
> AKUaPmYgpqvJrIPapxAhgpPqCtZr3uZXPgEH0o4LhuRu2k3JFiZjkq4BxBHG
> sLWVpl8P0Sy6jYLel9AYjRmJ3OizyEB21gEcHA%3D%3D=true=xml<
> https://calendar.google.com/calendar/r/eventedit/copy/
> M3RmZG04YW12cXVib2xwYzFycmEzYmFicGNfMjAxODA1MjNUMTUwMDAwWiBh
> cGFjaGVvcGVud2hpc2tAbQ/dHlzb25ub3JyaXNAZ21haWwuY29t?scp=ALL=
> AKUaPmYgpqvJrIPapxAhgpPqCtZr3uZXPgEH0o4LhuRu2k3JFiZjkq4BxBHG
> sLWVpl8P0Sy6jYLel9AYjRmJ3OizyEB21gEcHA===true=xml>
> >>
>

Re: About Ruby2.5 runtime support proposal(in relation to #3725)

[James Thomas]

This looks excellent - I've seen lots of people asking about Ruby support
before!

If you had time to write up generic instructions for creating a new
runtime, based on your experiences, it would help others add more. It has
been something we've been meaning to do since the PHP runtime.

Also, if you get time, adding a simple OpenWhisk Ruby client library to the
default runtime would be really useful from a "developer" experience POV.
Just making it easy for developers to invoke functions & triggers from the
runtime would be 80% of the methods needed.

Thanks for the contribution - looking forward to promoting this!


On 6 June 2018 at 10:39, Kei Sawada  wrote:

> Hi,
>
> This email is follow-up from #3725 which proposes Ruby2.5 runtime addition.
> https://github.com/apache/incubator-openwhisk/pull/3725
>
> > (perhaps including a small example on how to try it)
> Here is a quick introduction on how to use and test this runtime. Excuse me
> in advance for a little bit awkward installation step, I guess there would
> be better way to do this with fewer steps.
>
> ```
> # 1. Setting up both openwhisk and openwhisk-runtime-ruby
> git clone https://github.com/remore/incubator-openwhisk.git
> cd incubator-openwhisk
> git checkout origin/add-ruby-as-a-kind
> cd tools/vagrant
> ./hello  # fail here because pulling image from openwhisk/action-ruby-v2.5
> is not possible yet
> vagrant ssh
> git clone https://github.com/remore/openwhisk-runtime-ruby.git
> cd openwhisk-runtime-ruby/core/ruby2.5Action/
> docker build -t action-ruby-v2.5 -t whisk/action-ruby-v2.5
> openwhisk/action-ruby-v2.5 .
> exit  # go back to the host machine
> vagrant provision  # resume installation
>
> # 2. Creating a ruby action
> vagrant ssh
> cd openwhisk-runtime-ruby
> echo -e "def main(param)\n  {result: param}\nend" > my_action.rb
> wsk action update myAction my_action.rb --docker whisk/action-ruby-v2.5
> ./gradlew core:ruby2.5Action:distDocker
>
> # 3. Try it out
> wsk action invoke myAction --result -p message hello
>
> # 4. Test it
> cd ../openwhisk && ./gradlew install && cd ../openwhisk-runtime-ruby
> ./gradlew :tests:test --tests *actionContainers.
> Ruby25ActionContainerTests*
> ```
>
> Best,
> Kei
>



-- 
Regards,
James Thomas

Re: Please review our project's draft Apache Incubator June board report

[James Thomas]

LGTM - nice work Matt.

On the "Community" section? Would it be worth adding the growth of the
Slack community? We're ~800 members and it is really active.

On 5 June 2018 at 18:51, Matt Rutkowski  wrote:

> Whiskers,
>
> I have drafted our project board report for this quarter (June); I plan to
> post it tomorrow to the board's Wiki; please review and comment here or on
> our CWiki:
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=85475755
>
> Thanks,
> Matt
>
> PS message me if you need CWiki access
>



-- 
Regards,
James Thomas

About Ruby2.5 runtime support proposal(in relation to #3725)

[Kei Sawada]

Hi,

This email is follow-up from #3725 which proposes Ruby2.5 runtime addition.
https://github.com/apache/incubator-openwhisk/pull/3725

> (perhaps including a small example on how to try it)
Here is a quick introduction on how to use and test this runtime. Excuse me
in advance for a little bit awkward installation step, I guess there would
be better way to do this with fewer steps.

```
# 1. Setting up both openwhisk and openwhisk-runtime-ruby
git clone https://github.com/remore/incubator-openwhisk.git
cd incubator-openwhisk
git checkout origin/add-ruby-as-a-kind
cd tools/vagrant
./hello  # fail here because pulling image from openwhisk/action-ruby-v2.5
is not possible yet
vagrant ssh
git clone https://github.com/remore/openwhisk-runtime-ruby.git
cd openwhisk-runtime-ruby/core/ruby2.5Action/
docker build -t action-ruby-v2.5 -t whisk/action-ruby-v2.5
openwhisk/action-ruby-v2.5 .
exit  # go back to the host machine
vagrant provision  # resume installation

# 2. Creating a ruby action
vagrant ssh
cd openwhisk-runtime-ruby
echo -e "def main(param)\n  {result: param}\nend" > my_action.rb
wsk action update myAction my_action.rb --docker whisk/action-ruby-v2.5
./gradlew core:ruby2.5Action:distDocker

# 3. Try it out
wsk action invoke myAction --result -p message hello

# 4. Test it
cd ../openwhisk && ./gradlew install && cd ../openwhisk-runtime-ruby
./gradlew :tests:test --tests *actionContainers.Ruby25ActionContainerTests*
```

Best,
Kei

Re: Tech Interchange meeting tomorrow

[Rodric Rabbah]

Thanks Sandeep - id like to see; we need a plan for resolving the long 
outstanding pr so getting to see the status, features, and your thoughts will 
be essential. 

Tyson, I hope we can put this toward the top of the agenda, along with the 
release discussion.

-r

> On Jun 6, 2018, at 4:37 AM, sandy...@gmail.com  wrote:
> 
> Hi Tyson,
> 
> If time permits I can demo OpenWhisk tracing support based on my PR.
> 
> thanks,
> Sandeep
> 
>> On 2018/06/05 16:08:23, Tyson Norris  wrote: 
>> Hi All -
>> Reminder: the biweekly call is tomorrow 10 am GMT-5:00 (US Central Time), 
>> please send any agenda items to the list or myself.
>> Google cal link below with call details.
>> 
>> Dominic - do you want to continue your presentation from 2 weeks ago?
>> 
>> Current agenda to also include:
>> * Priti Desai -  to discuss enhancements to wskdeploy
>> * Vincent - to discuss Apache (source) release progress with focus on JDK 
>> considerations.
>> 
>> Thanks
>> Tyson
>> 
>> 
>> https://calendar.google.com/calendar/r/eventedit/copy/M3RmZG04YW12cXVib2xwYzFycmEzYmFicGNfMjAxODA1MjNUMTUwMDAwWiBhcGFjaGVvcGVud2hpc2tAbQ/dHlzb25ub3JyaXNAZ21haWwuY29t?scp=ALL=AKUaPmYgpqvJrIPapxAhgpPqCtZr3uZXPgEH0o4LhuRu2k3JFiZjkq4BxBHGsLWVpl8P0Sy6jYLel9AYjRmJ3OizyEB21gEcHA%3D%3D=true=xml
>> 

Re: Tech Interchange meeting tomorrow

[sandy801]

Hi Tyson,

If time permits I can demo OpenWhisk tracing support based on my PR.

thanks,
Sandeep

On 2018/06/05 16:08:23, Tyson Norris  wrote: 
> Hi All -
> Reminder: the biweekly call is tomorrow 10 am GMT-5:00 (US Central Time), 
> please send any agenda items to the list or myself.
> Google cal link below with call details.
> 
> Dominic - do you want to continue your presentation from 2 weeks ago?
> 
> Current agenda to also include:
> * Priti Desai -  to discuss enhancements to wskdeploy
> * Vincent - to discuss Apache (source) release progress with focus on JDK 
> considerations.
> 
> Thanks
> Tyson
> 
> 
> https://calendar.google.com/calendar/r/eventedit/copy/M3RmZG04YW12cXVib2xwYzFycmEzYmFicGNfMjAxODA1MjNUMTUwMDAwWiBhcGFjaGVvcGVud2hpc2tAbQ/dHlzb25ub3JyaXNAZ21haWwuY29t?scp=ALL=AKUaPmYgpqvJrIPapxAhgpPqCtZr3uZXPgEH0o4LhuRu2k3JFiZjkq4BxBHGsLWVpl8P0Sy6jYLel9AYjRmJ3OizyEB21gEcHA%3D%3D=true=xml
>