Re: API Gateway routing on Mac

> Lastly the invite bot for your slack channel seems to not be sending > out invites. Thanks for alerting us. I checked this out and it is working from what I can see. I can send you a direct invite if you like.

Re: API Gateway routing on Mac

Hi Tom. I’ve used quick start on Mac with api gateway successfully in the past. I’ll see if I can reproduce your issue. -r > On Nov 18, 2019, at 11:26 AM, Tom Barber wrote: > > Just to expand on my deployment question, I appreciate make > quick-start isn't production ready. I'm just curious

Re: OpenWhisk as a single docker image?

ed those evolutions. So I guess it should not be hard to > >> package it as a docker image. > >>> > >>>To be able to say to people: execute "docker run -p 8080:8080 > >> openwhisk/standalone" and enjoy... > >>> > >>>

adding 'updated' field to the API response

Thanks Seonghyun Oh for PR https://github.com/apache/openwhisk/pull/4646 from September which adds the 'updated' field to the API response for whisk assets. I have reviewed the PR and approved it, and pending CI passing, intend to merge it. -r

Re: ContainerPool buffering changes

Hi Tyson. I’ll have a look. -r > On Nov 12, 2019, at 2:00 PM, Tyson Norris wrote: > > Seeking someone to review this PR – I’ve been load testing it this week with > good success. > https://github.com/apache/openwhisk/pull/4593 > > We can discuss at the call tomorrow if nobody reviews it

Re: Providing a namespace field when action is initialized

tion_name (__OW_ACTION_NAME) > > And some environments can not be moved to it. > > not possible > - (x) activaiton_id (__OW_ACTIVATION_ID) > - (x) deadline (__OW_DEADLINE) > > > 2019년 11월 5일 (화) 오후 2:24, Rodric Rabbah 님이 작성: > >> The namespace is currently prov

Re: Providing a namespace field when action is initialized

The namespace is currently provided on /run as part of the environment context. I think the entire context should be moved to /init. This would also address your use case. Wdyt. -r > On Nov 5, 2019, at 12:04 AM, Seong Hyun Oh wrote: > > Hi, whiskers. > I want to discuss adding a new field

Remove legacy view code from subjects index.

I opened PR 4638 [1] a little over a month ago to remove legacy subject indexing in the auth database (which predates a bijective mapping from namespaces to keys). This PR introduces a new subjects view (v2) and removes the old view. Operators can still use the old view because the view is now

Re: Action health checks

as a longer term point to consider, i think the current model of "best effort at most once" was the wrong design point - if we embraced failure and just retried (at least once), then failure at this level would lead to retries which is reasonable. if we added a third health route or introduced a

bump to scala 2.12.10

This PR form 10 days ago bump the scala version to 2.12.10 (from 2.12.9). If you have concerns about this change please have a look or it will be merged in 48hrs by silent assent. https://github.com/apache/openwhisk/pull/4694 -r

Re: Make the formula to calculate the action time limit more configurable

Makes sense to me also. Docker images are also not capped and always pulled on demand. Have you considered an alternate and more efficient management strategy that shifts the pulls to create time perhaps? -r On Fri, Oct 18, 2019 at 10:01 AM Steffen Rost wrote: > Recently, we observed a

[Call for Topics] Tech Interchange Call - Wednesday 10/16/19

Hello OpenWhisk community. I am hosting the Tech Interchange Call on Wednesday October 16th at 10am Eastern (other times listed below). Call on Zoom: https://zoom.us/my/asfopenwhisk Arrive early before the Pizza and Cookies are all gone. There is also a prize for volunteering to host the next

Re: [VOTE] Release Apache OpenWhisk Runtime Go (v1.14.0, rc1)

+1 Approve the release Release verification checklist for reference: [x] Download links are valid. [x] Checksums and PGP signatures are valid. [x] Source code artifacts have correct names matching the current release. [x] LICENSE and NOTICE files are correct for each OpenWhisk

Re: [DISCUSS] release openwhisk-runtime-go 1.14.0

I suggested in the call yesterday to remove the “loop” in the name. Is that too much to include in this release? On Thu, Oct 3, 2019 at 9:43 AM Michele Sciabarra wrote: > Please note that currently all the runtimes build the proxy directly from > the sources of the master on github. > > I did

Re: [VOTE] Release Apache OpenWhisk Command-line Interface (CLI), OpenWhisk Client Go, OpenWhisk Wskdeploy (v1.0.0, rc1)

+1 for all three. I checked with rcverify and manual checklist. -r On Tue, Sep 17, 2019 at 9:26 AM David P Grove wrote: > > > Hi, > > This is a call to vote on releasing version 1.0.0 release candidate rc1 of > the following 3 project modules with artifacts built from the Git > repositories

Re: acceptable file types in 'tests' portion of source releases?

For the main repo, the sources from which the zips are made should also be in the repo. We can create a build.sh script to generate the zipped artifacts for the tests (and avoid changing the tests). I can do that if there are no takers. Maybe create a similar issue for the main repo with help

Re: Dangers of renaming and removing runtime kinds

I don't think there is actually a distinction between the two paths in deserialize(). The try path throws the exception inside docReader.read() whereas in the catch, the exception is deferred to the actual type check that occurs on lines 64-67. The exceptions should arguably be the same - I

testing activation polling on/off

When invoking an action, the controller waits on a promise of the result to complete in one of two ways: active ack (response from the invoker) or from the activations database. The latter is protected by a deployment flag and may not be enabled. However our tests did not test for both cases: with

Re: [DISCUSS}: release "cli group" of projects

+1 for for 1.0 On Fri, Sep 13, 2019 at 10:23 AM David P Grove wrote: > > > I'd like to make a release of the 3 "cli group" projects: > openwhisk-client-go, openwhisk-wskdeploy, openwhisk-cli. > > The main motivation is to pick up the fix for a bug [1] in wskdeploy, which > causes the `wsk

PRs ready to merge

There are at least 4 PRs ready to merge and now have the ready label. https://github.com/apache/openwhisk/pulls?q=is%3Aopen+is%3Apr+label%3Aready I know Chetan was generating github digest messages briefly (that was really useful I thought, thanks for the initiative!) and I'd be happy to add a

optionally skip kafka/zookeeper pulls

This PR from Bill Zong removes the explicit zookeeper pull task and uses the 'pull' attribute on 'docker_container' instead. See https://github.com/apache/openwhisk/pull/4619. I will merge this by the end of the week unless there's an objection. -r

bug in active ack protocol

I opened an issue for a bug in the invoker https://github.com/apache/openwhisk/issues/4614. There are 5 calls to send a "ack" from an invoker - 4 of them are Completion messages and only 1 is an active ack with the activation result. Two of the calls from InvokerReactive only send a Completion

Re: Allow decision about action result inclusion in logs on a per call basis

e activation json is > not > suppressed in the error case (success=false) and printed out to the > action > log so that the user can find more information in the action log about > the > error. But we do not want the 'result' field content be part in the > action > log if an activatio

factoring out the name of the subjects view

Hello. At some point in the past, we factored out the couch view names for actions and activations but not subjects. The subjects view name is hard coded in the code and not versioned. This makes it difficult to change that view. The view name should be factored into the db config object. I

Re: Add namespace field to activation log

Thanks Jiang - I reviewed the change and it looks good to me. I also don't think it affects compatibility. -r On Thu, Sep 5, 2019 at 9:50 PM 蒋鹏程 wrote: > Dear all: > ​ > While I was using DockerToActivationFileLogStore ​to store acitavation > logs to a separate file and use logstash to

Re: Allow decision about action result inclusion in logs on a per call basis

es not > contain sensible information. It is very helpful information for the > customer to correct the action. So we do not want to suppress this > information. > > > > From: James Thomas > To: dev@openwhisk.apache.org > Date: 03/09/2019 15:24 > Subje

Re: Can we adjust the time for the community call

Thanks Dominic for bringing this up. +1 from me. What about alternating times (every two weeks) so other time zones aren't always so late in the day? -r On Wed, Sep 4, 2019 at 11:27 PM Dominic Kim wrote: > Dear community members. > > I wonder whether we can set up our Tech. Int. meeting 1-hour

Re: Allow decision about action result inclusion in logs on a per call basis

> Action results may contain sensible data that should not be logged. I interpret this to mean: not stored in the activation record. If this is what you mean, why not make this a feature controlled per action using an annotation and let the user decide: ok to save the result, not ok to save the

Re: removing "projections" on web actions

> Assuming no one wants to bother with a feature flag for a deprecated feature, let's set a concrete date on which the PR will be merged. My suggestion is December 1, 2019. That gives ample time for downstream operators to do their deprecation process. I don't want to bother with a feature

Re: removing "projections" on web actions

> Though projections on “.http” got removed two years ago, we confusingly saw A LOT calls of the form ".http/foo/bar”. Research showed that those customers are accessing the “foo/bar” section of the path via the "message.__ow_path" property in their action code to be used as additional parameters.

Re: [VOTE] Release Apache OpenWhisk API Gateway (v0.11.0, rc1)

[x] +1 Approve the release Release verification checklist performed manually: [x] Download links are valid. [x] Checksums and PGP signatures are valid. [x] Source code artifacts have correct names matching the current release. [x] LICENSE and NOTICE files are correct for each OpenWhisk

removing "projections" on web actions

This PR https://github.com/apache/openwhisk/pull/4592 removes the documentation for projecting results of actions via the web invoke path. This was previously discussed https://github.com/apache/openwhisk/issues/4352 and there is a pending PR to also remove the functionality but I thought

Re: Passing TransactionId as part of action invocation

> Here are a few more examples of "meta" information, other than transaction > id. > - QoS (e.g., to affect scheduling) > - URL of specific log channel (e.g., to consolidate logs across a chain of > invocations) > - Flow ID (e.g., for tracing) > - Debug flag (e.g., to enable step-into

Re: Passing TransactionId as part of action invocation

ables exposing the transactionId to env. It >> does not make any attempt to store the transactionId currently. Once we >> decide how such data should be stored then I can open PR for the same >> >> Chetan Mehrotra >> >> >>> On Mon, Aug 19, 2019 at 8:47 AM Rodr

Re: Passing TransactionId as part of action invocation

uot;meta" sub document > 2. OR Change annotations to flat map while storing but transform that to > array based structure while returning to client > > Chetan Mehrotra > > >> On Mon, Aug 19, 2019 at 7:15 AM Rodric Rabbah wrote: >> >> >>> However ch

Re: Passing TransactionId as part of action invocation

> However changing them now would cause compatibility > issue with various tooling out there which may be interpreting the > annotation per current design That’s true. Time for api/v2... 

Re: Passing TransactionId as part of action invocation

;value": { >"concurrency": 200, > "logs": 10, >"memory": 256, >"timeout": 6 >} >} >], >"cause": &quo

Re: Passing TransactionId as part of action invocation

(e.g., from CouchDB / > Redis), but again, at the cost of a higher code change. > > Regards, > -- Erez > > > > > > > From: Rodric Rabbah > To: dev@openwhisk.apache.org > Cc: tyson.nor...@gmail.com > Date: 17/08/2019 03:36 > Sub

init parameters

Is anyone up for reviewing this PR https://github.com/apache/openwhisk/pull/4559 which adds the ability to separate parameters into init time vs run time? It’s been open for a while with no feedback. Previously discussed here [1] and implemented accordingly. -r [1]

Re: Passing TransactionId as part of action invocation

uest-Id >> header (using the existing transaction id/X-Request-Id), the parent is not >> needed? i.e. there may be 2 parts to this effort: >> - expose the transaction id to runtime container >> - propagate the transaction id in requests initiated from runtime >> contain

Re: Passing TransactionId as part of action invocation

In general yes but I think generally do you need the transaction id or the parent id for an activation? This issue is relevant - https://github.com/apache/openwhisk/issues/3083. I also recall in the early days of the composer, we wanted a way to query parent/child activations but this requires

Re: OpenWhisk swag at ApacheCon?

Thanks Matt for the heads up. The wiki says "The following list of projects have at least one presentation on the schedule or will have some of their community present and would like some stickers available at the Apache booth;" I don't think if we have any openwhisk presentations at the

Re: Video + Notes posted from today's OW Tech. Interchange meeting on 2019-08-07

wskdebug is very cool! will be trying it out. and congrats Michele for the book. thanks Neeraj for volunteering to host the next call! -r On Wed, Aug 7, 2019 at 12:41 PM Matt Rutkowski wrote: > Thanks Chetan for hosting! > > A very full and informative call including: > - wskdebug tool demo

Re: housecleaning of openwhisk git repos

Arching makes the repo read only and indicates it is no longer maintained. https://help.github.com/en/articles/archiving-a-github-repository -r > On Aug 5, 2019, at 5:15 PM, Priti Desai wrote: > > > >> On 2019/08/05 16:51:33, James Thomas wrote: >> Looking over the list, here's a few

Re: Publishing a pre-release version of Standalone OpenWhisk

It would certainly help in getting others to try it. Since the nightly builds are not releases and must not be labeled as releases I think the issue you’re alluding to is not the same. -r > On Aug 1, 2019, at 4:57 AM, Chetan Mehrotra wrote: > > Would it be useful to publish a pre-release

Re: Try out the api gateway support in standalone server (#4571)

Hi Chetan, this is fantastic... I followed your instructions here as is even though I noticed the gw PR was merged already and in theory I should be able to drop the image override. the system came up cleanly, and as relayed on Slack, I think it would be useful to hoist the messages that gw is

Re: Video+notes posted from today's tech. int. call

Thanks Matt for the notes. Sorry I couldn’t make it today. I’ll go through the repo list from Dave and Chetan for my suggested list of repos to retire. I’ll do that tomorrow. -r > On Jul 24, 2019, at 1:13 PM, Matt Rutkowski wrote: > > First post-grad. meeting! > > video:

Re: add reason parameter for wskadmin tool

Thanks Steffen for adding this feature. I agree it's useful. Could you add a test for the change? In terms of divergence between wskadmin and wskadmin-next, I propose that we separately deprecate wskadmin and all new features are added to wskadmin-next. -r On Wed, Jul 24, 2019 at 6:28 AM

Re: stricter scancode: now rejecting minified license headers

not too loose. # Exclude from incubator-openwhisk # Jenkins/test generated reports # Test data. # Generated binary artifacts tests/build/reports tests/dat/actions docs/images bin On Wed, Jul 24, 2019 at 11:25 AM Rodric Rabbah wrote: > We've got a gap somewhere. > > https://g

Re: stricter scancode: now rejecting minified license headers

We've got a gap somewhere. https://github.com/apache/incubator-openwhisk/blob/master/tests/dat/actions/argsPrint.js and several other js files in the tests use the short license. -r On Wed, Jul 24, 2019 at 11:04 AM David P Grove wrote: > > > I just merged [1] which enforces the stricter

Re: A direction to take in a new component, "the scheduler"

We should put together a roadmap that shows the evolution and all presents a coherent view of all the moving parts. -r > On Jul 18, 2019, at 8:52 AM, Markus Thömmes wrote: > > Hi, > > this sounds a lot like the "OpenWhisk 2.0" discussion we had in an older > thread where I proposed an

Re: A direction to take in a new component, "the scheduler"

> It must not break any existing downstream system as well as the upstream > pipelines. So all implementations should be disabled by default along with > proper > switches. Agreed. There is a feature flag class that Chetan introduced when I introduced a breaking change (sorry) a few months

Re: exporting activation arguments to the environment

I opened issue https://github.com/apache/incubator-openwhisk/issues/4558 and corresponding PR https://github.com/apache/incubator-openwhisk/pull/4559 . Additional feedback and critique welcomed. -r

Re: exporting activation arguments to the environment

I implemented both, the "convention" and the parameters designated as init through the API. The latter wasn't much more over the former and is backward compatible. This can be introduced incrementally into the main repo/REST API, then the runtimes (I added it to Node but not the others), and

Welcome new PPMC members

It is my pleasure to share that the OpenWhisk PPMC voted to invite Rob Allen and Michele Sciabarra as new PPMC members based on their ongoing and valuable contributions to the project. They have both accepted the invitation. Rob and Michele were already project committers. Please join me in

Re: Updating our contributions guide

ere to help ensure the contributions are made along the same rules > as the ALv2. > >> On Tue, 9 Jul 2019 at 03:06, Rodric Rabbah wrote: >> >> It was pointed out that our contributing guide sets a higher bar than other >> Apache projects by requiring an ICLA. >>

Re: devtools and make-quickstart

> 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

devtools and make-quickstart

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

devtools update for mighty docker tag

Hi This PR https://github.com/apache/incubator-openwhisk-devtools/pull/270 I think fixes the docker compose quick start since the docker tags change. Can I get help with a review/merge? I tested make quickstart for myself. We are getting several people reporting the failures. -r

Re: rationale for wskdeploy Docker image

I think we don’t need it but defer to those who worked on it. I’d like to also ask at the risk of broadening the original question: - should we fold the repository into the cli? - or is there a good reason to keep it as a separate deploy tool independent of the cli? -r > On Jul 3, 2019,

Updating our contributions guide

It was pointed out that our contributing guide sets a higher bar than other Apache projects by requiring an ICLA. Looking at some of the other successful Apache projects they do a better job explaining how to contribute, and all the ways someone can be contributor, and how to open a PR,

Re: Fine-grained permission

Thanks Dominic for bringing up this feature. I know PR 4058 has been sitting for a while. Does it make sense to accept it (I will review it again it’s been a while since I posted my comments last) before going on to do more of the permissions work? We should capture the dev list discussion in

API gateway Invalid URI "undefined/tenants"

Several openwhisk users recently have hit a bug using serverless framework (sls) and openwhisk to deploy a function/api. I've hit the same bug when using the standalone controller + api gateway. The symptom is failure to create an API and this error: Failed to deploy API Gateway route due to

Re: Re: OpenWhisk invoker overloads - "Rescheduling Run message"

> Instead of resending the message to the pool immediately, it just waits in the runbuffer, and the runbuffer is processed in reaction to any potential change in resources: NeedWork, ContainerRemoved, etc. This may add delay to any buffered message(s), but seems to avoid the catastrophic crash in

Re: api gateway with standalone controller

olvers.conf" and hence the DNS > resolution doesn't work ? > > [1] - > > https://github.com/apache/incubator-openwhisk-apigateway/blob/master/init.sh#L58-L59 > > On Wed, Jun 26, 2019 at 5:28 PM Rodric Rabbah wrote: > > > I tried to use the api gateway with the standalo

Re: Adding Github app (Depend-a-bot) to Client JS SDK repo?

Hey James, I don't know the answer but can offer this anecdotal evidence. I attempted to add github app, and requested access for our apache repo over a week ago and nothing has happened in terms of approval. So I suspect without INFRA's help, the request falls on the floor. -r On Mon, Jul 1,

Re: [VOTE] Release Apache OpenWhisk Catalog (v0.10.0-incubating, rc1)

+1 [x] Download links are valid. [x] Checksums and PGP signatures are valid. [x] DISCLAIMER is included. [x] Source code artifacts have correct names matching the current release. [x] LICENSE and NOTICE files are correct for each OpenWhisk repository. [x] All files have license

log stripping for standalone controller

I opened this PR https://github.com/apache/incubator-openwhisk-cli/pull/444 to allow activation log stripping to work with the standalone controller. The notable change is the regex for recognizing the timestamp and stream identifier. The PR also turns on unit cli test which weren't previously

Re: [DISCUSS] - prepare to release OpenWhisk catalog

> We can either (a) wait out a release cycle of clientgo/cli/wskdeploy to get a > fixed cli or (b) leave the bash installers in for this release and cleanup > after the next cli release. I would do it later then. -r

Re: exporting activation arguments to the environment

Thanks for the added feedback - keep it coming! Tyson is right in that we shouldn't let implementation concerns affect a proper design and sacrifcie the experience. So in line with his concerns, is there a desire to facilitate environment variables at all (user specified values, not

Re: exporting activation arguments to the environment

completely separate, but worth noting: logging (and env vars) in the > face of concurrency > > On 6/26/19, 5:29 PM, "Rodric Rabbah" wrote: > > > There are some accumulating issues around init and run. > > Which issues are these? > > -r > > >

Re: exporting activation arguments to the environment

> There are some accumulating issues around init and run. Which issues are these? -r

api gateway with standalone controller

I tried to use the api gateway with the standalone controller and ran into a few issues which I'll document in the relevant docs soon. I'm now hitting an issue where the api gateway cannot resolve the host for routing a request. I opened

Re: exporting activation arguments to the environment

By the way, an existential question is whether we should facilitate environment variables at all for actions (a user can still do whatever they like). To Rob's point about separating parameters, this could be achieved through environment variables, or context object (to tie the two dev threads

Re: exporting activation arguments to the environment

env > vars, but my point is that this doesn't seem at all like an explicit > choice. I think an explicit choice would be more like adding a '-e' flag > that specifically does "set these environment variables", instead of > overloading the '-p' flag with a convention based on the na

Re: exporting activation arguments to the environment

, and always visible to run, regardless of what client > sends as execution parameters. > > Thanks > Tyson > > > On 6/25/19, 3:32 PM, "Rodric Rabbah" wrote: > > Context and Knative I view as orthogonal. > > That is, for the context object, it is an

Re: Notes & Video posted from today's Tech Int. call

James Thomas hosted today. Thank you James. And thanks Matt for the notes and agreeing to moderate the next one. I thought we agreed to skip July 10 so the next one is July 24. I can volunteer for the one after that (August) if no one else volunteers. I will miss the next call. -r > On Jun

Re: [ACTION REQUIRED] Nominations for PMC Chair for TLP graduation resolution

Dave and I conferred and we've agreed he's in a better position today to chair the PMC. I'm happy to be in a able to learn from him in the inaugural year, assuming a successful petition to graduate. -r On Tue, Jun 25, 2019 at 5:04 PM Matt Rutkowski wrote: > > This PMC Chair nominations thread

context object to action

In an earlier email discussion [1] Tyson noted the previously discussed idea of using a context object per activation in lieu of environment variables which are currently exported by the system/runtime per activation. This was previously discussed in [2] and is necessary to separate

Re: exporting activation arguments to the environment

functions. > In the case where we init code into an already running container, it is > useful to have the init process separate from run, since otherwise each > runtime will need to track its own init state and queue requests during init > etc. If I'm not getting the whole pictur

Re: Openwhisk in a standalone runnable jar (#4516)

I tried this out - it is awesome... and fast! -r On Mon, Jun 24, 2019 at 6:08 AM Chetan Mehrotra wrote: > Hi Team, > > At this stage the OpenWhisk Standalone jar works fine. So would like > to get it tried out in real world and for that need some volunteers! > > You can follow the steps at >

exporting activation arguments to the environment

In the current activation model, an action's arguments are always provided to the action on "run", not "init". Should we consider partitioning the argument list into two sets, the first is exported as environment variables at "init" time, and the second become the action's argument at "run" time?

Re: Re: Backpressure for slow activation storage in Invoker

> Can we handle these in same way as user events? Maybe exactly like user events, as in use a single service to process both topics. good call - the user events already contains much of the activation record (if not all modulo the logs)? -r

oauth token verification in the controller

I'm curious if anyone has thought about or implemented an oauth based authentication mechanism in the controller. I've thought about replacing the subject authentication with oauth and think it would not be a lot of work to do although it does have some wider implications. -r

Re: Backpressure for slow activation storage in Invoker

Overflowing to Kafka (option b) is better. Actually I would dump all the activations there and have a separate process to drain that Kafka topic to the datastore or logstore. There is another approach of routing the logs directly to a logstore without going through the invoker at all. IBM may

Re: openwhisk distributions via dockerhub

>> 3. Once we have addressed (1) and (2), we should consider opening a legal >> discuss thread to see if we can continue to use /u/openwhisk (with clear >> branding that /u/openwhisk is an official distribution channel from the >> Apache OpenWhisk (P)PMC) or if we must migrate to

Re: openwhisk distributions via dockerhub

If we’re going to fix up all the builds we might as well use Apache/ on dockerhub or whatever we decide the location should be so we’re not doing this chore twice. I don’t know how we get access to the Apache org and if that’s tedious to manage vs an org we already own and manage. -r > On

Re: [ACTION REQUIRED] Nominations for PMC Chair for TLP graduation resolution

A one year rotation makes sense to me. I’d like to nominate Dave Grove for consideration. Dave is engaged on the general list, and I’ve consulted him many times on the Apache Way and for pointers to Apache docs. He’s also lead several releases and followed up on issues noted during voting to

Re: [ACTION REQUIRED] Nominations for PMC Chair for TLP graduation resolution

He should lead the project in the right direction at the same time, he > should always be nice and not arrogant. > > And I know who's exactly right for the position. > > I want to recommend Rodric Rabbah. > > If someone should be the Char, I think he is the one. > > Best reg

Re: status of openwhisk components releases

On Sun, Jun 16, 2019 at 12:56 PM Matt Sicker wrote: > How well documented is release management here? Or how well automated would > be an interesting question too. > > On Fri, Jun 14, 2019 at 14:27, Rodric Rabbah wrote: > > > Per this issue > > https://github.com/apache/

Re: [ACTION REQUIRED] Nominations for PMC Chair for TLP graduation resolution

This link http://www.apache.org/dev/pmc.html#chair is helpful to understand the duties of the PMC chair. -r

Re: Accept NodeJs syntax quirks

Hey Martin - the refactoring was not intended to be semantic changing. Thanks for reporting the bug. I prefer to not accept #4514 and instead address this by restoring the behavior as noted in #136. I did add a test in the latter inspired by the code that broke in the former. -r On Tue, Jun 18,

Re: Openwhisk in a standalone runnable jar (#4516)

That's very cool! +1. -r On Tue, Jun 18, 2019 at 9:22 AM Chetan Mehrotra wrote: > Hi Team, > > Recently based on some feedback by end users I felt a need for a > simpler way to test out OpenWhisk for end users. Towards that end > there is a new PR #4516 which enables launching OpenWhisk as a

Re: [DISCUSS] - prepare to release OpenWhisk catalog

If the weather package is functional and can run with newer node kinds then I’d favor keeping it. I’d favor removing the combinators as we have composer now and we didn’t document them properly (my fault). I would consider removing the bash installers since they’re redundant with the wsk

status of openwhisk components releases

Per this issue https://github.com/apache/incubator-openwhisk-release/issues/241 we are almost ready to cut a new release of the openwhisk repo. The last release of the main repo was 0.9 and I wonder if we should cut the new release at 1.0. Thoughts? We need to create a release candidate for the

refactoring nodejs runtime

I opened a PR to refactor and apply javascript-isms to our node.js runtime https://github.com/apache/incubator-openwhisk-runtime-nodejs/pull/133. There are no semantic changes intended only code hygiene applied. -r

Re: managing our project trademarks

> For example, the official project plugins follow a naming scheme of maven-foo-plugin, while third party plugins follow a naming scheme of foo-maven-plugin. Similar to the distinction between “Apache Maven Foo Plugin” versus “Foo Plugin for Apache Maven”. This is useful - are you suggesting we

managing our project trademarks

The discussion about our graduation on the general list [1] led to a question relating to how we manage the project trademarks. Specifically, our project website does not provide any guidance we can point to when needed. We have previously discussed the use of the OpenWhisk name in a prior

Re: our source releases do not include tests

I’m not sure why we don’t include tests. I do remember this mentioned in the past I’ll see if I can find the discussion on the dev list. -r > On Jun 10, 2019, at 6:08 PM, David P Grove wrote: > > > > I was trying to understand Justin's comment [1] that the NOTICE file for > apigateway

[VOTE] [RESULT] Apache OpenWhisk graduation to Top Level Project

Voting is now closed. Thanks to everyone who has participated. The vote has passed. We received 19 votes for "+1 Apache OpenWhisk should graduate." and no other votes. Voting +1 were all three project mentors (Matt Sicker, Bertrand Delacretaz, Krzysztof Sobkowiak) and David Breitgand, Tyson

<    1   2   3   4   5   6   7   >