Re: Blog about APISIX-OpenWhisk Plugin
Hi Yilin Welcome to the OpenWhisk community this is great news, let us know me know if you want help reviewing. +1 - Carlos Santana @csantanapr > On Nov 20, 2021, at 1:10 AM, Rodric Rabbah wrote: > > hi Yilin - that's great. One of us can help with this when you're ready and > I'm happy to review it ahead of time. > > -r > >> On Tue, Nov 16, 2021 at 4:24 AM Yilin Zeng wrote: >> >> Hi Community, >> >> >> I am Yilin, from the Apache APISIX community. APISIX is a Cloud-native API >> gateway, and it is also a project of the Apache Software Foundation. You >> can get more details from Apache APISIX’s GitHub Repository[1]. >> >> >> We are developing a plugin[2] for Apache APISIX to integrate with Apache >> OpenWhisk. I think the plugin is very meaningful for developers and the >> community. In addition, it will help Apache APISIX and Apache OpenWhisk >> publicize and let more developers and companies know about them. >> >> >> The OpenWhisk plugin (in developing process) should be ready by the end of >> November. Can we arrange to write a blog, and post it on OpenWhisk ’s >> Medium page[3] later this month? >> >> >> I am looking forward to your reply. >> >> >> Sincerely, >> >> Yilin Zeng >> >> >> [1] https://github.com/apache/apisix >> >> [2] https://github.com/apache/apisix/pull/5518 >> >> [3] https://medium.com/openwhisk/about >> >>
Re: Cannot join slack
I think Nick did a POC with Github oauth at one point if I remember. So it's possible to plug in your own implementations. - Carlos Santana @csantanapr > On Apr 11, 2021, at 10:28 AM, Rodric Rabbah wrote: > > Hi Courtney - I'm sorry you're having trouble with the slack auto signup. I > opened a defect to investigate [1]. > > It is possible to implement external authentication. My understanding is > that IBM Cloud Function for example implemented an integration with their > IAM (someone from IBM would be better speak to this). > > There are two parts to this: authentication and use management, and > entitlement. Can you share more details about which identity provider you > are interested in using? > > This would certainly be an area we'd also welcome contributions if that's > something you're interested in. > > [1] https://github.com/apache/openwhisk-website/issues/477 > >> On Sat, Apr 10, 2021 at 7:03 AM Courtney Robinson >> wrote: >> >> I've been trying to join slack now for over a week but was unable to. >> Finally thought I'd investigate and found the issue is the inviter fn is >> using an old version of node >> https://openwhisk.apache.org/slack.html >> [image: Screenshot 2021-04-10 at 10.59.00.png] >> [image: Screenshot 2021-04-10 at 10.58.34.png] >> >> What I've been wanting to ask about is how to integrate an external >> authentication and authorisation provider? >> I can see from the codebase that there are a number of Spi impls but also >> found >> https://github.com/apache/openwhisk/pull/1914 >> https://github.com/apache/openwhisk/issues/1152 >> which suggests the this isn't supported. >> >> Regards, >> Courtney Robinson >> Founder and CEO, Hypi >> Tel: ++44 208 123 2413 (GMT+0) <https://hypi.io> >> >> <https://hypi.io> >> https://hypi.io >>
Re: [DISCUSS] update release of npm client
+1 - Carlos Santana @csantanapr > On Apr 8, 2021, at 10:57 PM, Rodric Rabbah wrote: > > The OpenWhisk Node.js client has two fixes [1, 2] and some doc updates [3] > which I'd like to roll into a new release and update the npm client. There > are currently no new open pull requests. If there are no objections in the > next couple of days, I will move ahead with a release candidate next week. > > -r > > [1] > https://github.com/apache/openwhisk-client-js/commit/5b313c1ab8d96f1437f477e03fa1cb14e2f6eb03 > [2] > https://github.com/apache/openwhisk-client-js/commit/d366830246241810e5c8b332669b2876e704104f > [3] > https://github.com/apache/openwhisk-client-js/commit/10fb2ad8044f06a25bdeed06f8754b36e571a254
Re: Free Travis-CI will go away for open source projects
Thanks for bringing it Martin Our current usage of Travis for OpenWhisk we use the ASF foundation account, and Infra pays some amount $ to able to support so many builds by many Apache projects. With that said I think the amount paid today might not cover all the builds I have used GitHub actions and I would +1 for OpenWhisk to move away from Travis Github Actions are event driven you can have one action in one repo trigger another one in another repo we can leverage this If you are going to get started don’t reinvent the wheel there are many actions available in the open market place, things like reviewdog And avoid code duplication you can have the action definitions for OpenWhisk specifics in a central repo and reference them from the other repos —Carlos On Fri, Nov 20, 2020 at 10:15 AM Martin Henke wrote: > Hi, > > free Travis usage will be ending for open source projects end of the year. > > See: > https://mailchi.mp/3d439eeb1098/travis-ciorg-is-moving-to-travis-cicom > https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing > > Open source projects will migrated to trial accounts in travis-ci.com > with some free budget. > > > For those of you who have been building on public repositories (on > travis-ci.com, with no paid subscription), we will upgrade you to our > trial (free) >plan with a 10K credit allotment (which allows around 1000 > minutes in a Linux environment). > > It looks like our OW projects have to find other alternatives like GitHub > Actions. > > Kind regards, > Martin -- Carlos Santana
Re: golang versions / end of life
Michele You mean the new gomod support? That would be RAD ! - Carlos Santana @csantanapr > On Jul 25, 2020, at 5:16 AM, Michele Sciabarra wrote: > > I can do it... I also can update the runtime to add module support. > > -- > Michele Sciabarra > mich...@sciabarra.com > > - Original message - > From: Dominic Kim > To: dev@openwhisk.apache.org > Subject: Re: golang versions / end of life > Date: Friday, July 24, 2020 3:08 AM > > Thank you for your efforts. > Regarding upgrading the go version, I would work on it. > > -dom > > > 2020년 7월 23일 (목) 오후 10:19, David P Grove 님이 작성: > >> >> >> Currently our openwhisk-runtime-go supports golang 1.11 and golang 1.12. >> Unfortunately, go is now on version 1.14 and has a 2 version EOL policy >> [1]. So golang 1.11 and 1.12 are out of support and no longer receiving >> vulnerability fixes. >> >> A few weeks back, I had proposed doing a runtime release wave [2] to pick >> up security fixes. But I think we really should refresh our runtime-go >> versions before we do that (as the go version flows through as the >> actionloop runtime for many of the other runtimes). >> >> Does anyone have the time to look at updating runtime-go to go 1.14? I'd >> be tempted to skip golang 1.13 unless there was a reason to include it. >> >> --dave >> >> [1] https://endoflife.date/go >> >> [2] >> >> https://lists.apache.org/thread.html/r208d84ea92debcedb80c30895c53397db12989286a787f037e0a5add%40%3Cdev.openwhisk.apache.org%3E >> >>
Re: golang versions / end of life
+1 Ok to skip 1.13 - Carlos Santana @csantanapr > On Jul 23, 2020, at 9:09 PM, Dominic Kim wrote: > > Thank you for your efforts. > Regarding upgrading the go version, I would work on it. > > -dom > > > 2020년 7월 23일 (목) 오후 10:19, David P Grove 님이 작성: > >> >> >> Currently our openwhisk-runtime-go supports golang 1.11 and golang 1.12. >> Unfortunately, go is now on version 1.14 and has a 2 version EOL policy >> [1]. So golang 1.11 and 1.12 are out of support and no longer receiving >> vulnerability fixes. >> >> A few weeks back, I had proposed doing a runtime release wave [2] to pick >> up security fixes. But I think we really should refresh our runtime-go >> versions before we do that (as the go version flows through as the >> actionloop runtime for many of the other runtimes). >> >> Does anyone have the time to look at updating runtime-go to go 1.14? I'd >> be tempted to skip golang 1.13 unless there was a reason to include it. >> >> --dave >> >> [1] https://endoflife.date/go >> >> [2] >> >> https://lists.apache.org/thread.html/r208d84ea92debcedb80c30895c53397db12989286a787f037e0a5add%40%3Cdev.openwhisk.apache.org%3E >> >>
Re: What you think of trying to compile OpenWhisk with GraalVM?
I think it’s a great idea to compare the performance/efficiencies gains - Carlos Santana @csantanapr > On Jul 22, 2020, at 4:21 AM, Michele Sciabarra wrote: > > Hi guys what you think of trying to compile OpenWhisk with GraalVM? > > I have read around we should gain a 35% improvement. > > I am especially interested in using it for the standalone openwhisk. > > -- > Michele Sciabarra > mich...@sciabarra.com
Re: project maintenance
Should we open a ticket with infra to enable a stale Github app/bot? That will automate the closing of old issues and PRs and reduce toil - Carlos Santana @csantanapr > On Jul 3, 2020, at 10:04 AM, Rodric Rabbah wrote: > > Hello OpenWhisk community. > > A heads up that I plan to go through the open issues in a number of repos > over the weekend. I apologize in advance for upcoming github chatter. > > -r
Github settings via .asf.yaml
I just stumble into this wiki page [1] from another mailing list. It looks like infra implemented a self service to configure the github repo now, we used to do this via ticket and instructions It looks like it also has the feature to build the website and push to asf-site branch in case the jenkins job start giving problems again. PS: Notice how they are using YAML, someone might be a yaml software engineer like me with so much Kubernetes yaml lately :-) [1] https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories - Carlos Santana @csantanapr
Re: Discuss how to set environment variables in Java11 and more...
-1 on separate process, affects performance
- Carlos Santana
@csantanapr
> On Mar 29, 2020, at 5:17 AM, Michele Sciabarra wrote:
>
> The subprocess is intialized with environment variables. That works.
>
> The problem is that after the process is launched, it starts the "action
> loop" of reading a line for each action activation, that includes some values
> that are always different and are passed as environment variables.
>
> Launching a process for each requests is what the older "docker support" was
> doing. And no, it is horribly inefficient even for fast C programs. And for
> java, that also has a long startup time, would be terrible.
>
> --
> Michele Sciabarra
> mich...@sciabarra.com
>
> - Original message -
> From: Matt Sicker
> To: dev@openwhisk.apache.org
> Subject: Re: Discuss how to set environment variables in Java11 and more...
> Date: Saturday, March 28, 2020 5:36 PM
>
> I think Java broke up environment variables and system properties to allow
> for a more fine grained permission model of who is allowed to edit them and
> read them, hence the overly locked down API for it.
>
> Would it be feasible to launch a sub process with the environment variables
> initialized? Or would that be too much overhead for this use case?
>
>> On Sat, Mar 28, 2020 at 09:31 Rodric Rabbah wrote:
>>
>> We should not change this for java8. For Java 11 since it’s new, it would
>> be ok to make the change but only for the activation context. Since init
>> time env vars can still be set by the proxy.
>>
>> Another approach since something will change for 11: introduce the context
>> object for java methods that want these variables (alternate signature)
>> which matches aws lambda.
>>
>> -r
>>
>>> On Mar 28, 2020, at 7:34 AM, Carlos Santana
>> wrote:
>>>
>>> Would this be for a new kind “java:11” not affecting existing java
>> kinds?
>>>
>>> Then will affect only someone migrating a java action from using java:8
>> or java:8a to use java:11? then it would be a good time to also clean up
>> how it access this variables/properties if for any chance is using them in
>> existing kind.
>>>
>>> there is no java sdk in openwhisk like the one from node.js
>>>
>>> Can’t think what other areas of openwhisk or use cases this will affect.
>>>
>>> - Carlos Santana
>>> @csantanapr
>>>
>>>> On Mar 28, 2020, at 7:13 AM, Michele Sciabarra
>> wrote:
>>>>
>>>> Community,
>>>>
>>>> Let's make a long story short:
>>>>
>>>> In the openwhisk runtime for java, when you activate an action, you
>> have to pass some informatins. Most notably those:
>>>>
>>>> ---
>>>> {
>>>> "namespace": String,
>>>> "action_name": String,
>>>> "api_host": String,
>>>> "api_key": String,
>>>> "activation_id": String,
>>>> "transaction_id": String,
>>>> "deadline": Number
>>>> }
>>>> ---
>>>>
>>>> Now, the common way in all the programming languages is to set
>> environement variables:
>>>>
>>>> so action_name is passed as __OW_ACTION_NAME and so on.
>>>>
>>>> This is easy in every programming language except java. In Java "you
>> should not change environment variables". Because the concept of
>> environemnt variables is actually to use "system properties". Generally all
>> the environment variables are used to set system properties, read only.
>>>>
>>>> In che java8 runtime however the environment variables has been set.
>> Following this stack overlflow "horrible and unacceptable' (my opinion)
>> hack
>>>>
>>>>
>> https://stackoverflow.com/questions/318239/how-do-i-set-environment-variables-from-java
>>>>
>>>> Note this "vomit causing" (still my opinion) thing:
>>>>
>>>> Field field = cl.getDeclaredField("m");
>>>> field.setAccessible(true);
>>>>
>>>> Yep, you hack an in-memory undocumented hash map marked read only with
>> reflection to say "no, I want to write in it anyway" and then proceed your
>> surgery.
>>>>
>>>> I very very very very unwillingly applied this hack in the actionloop
>> runtime for java 8 for the sake of keeping compatibility and pass all the
>> existing tests.
>>>>
>>>> For java 11 however, this hack also requires you mark the runtime as
>> using "unsafe code"
>>>>
>>>> I thing this thing now it is a bit ... too much. So we should instead
>> change the way we pass the values and use system properties instead.
>>>>
>>>> Yes, user code for Java11 need to be changed. No more
>> System.getenv(...) but System.getProperties.
>>>>
>>>> Your thoughts?
>>>>
>>>>
>>>> --
>>>> Michele Sciabarra
>>>> mich...@sciabarra.com
>>
> --
> Matt Sicker
Re: Discuss how to set environment variables in Java11 and more...
Would this be for a new kind “java:11” not affecting existing java kinds?
Then will affect only someone migrating a java action from using java:8 or
java:8a to use java:11? then it would be a good time to also clean up how it
access this variables/properties if for any chance is using them in existing
kind.
there is no java sdk in openwhisk like the one from node.js
Can’t think what other areas of openwhisk or use cases this will affect.
- Carlos Santana
@csantanapr
> On Mar 28, 2020, at 7:13 AM, Michele Sciabarra wrote:
>
> Community,
>
> Let's make a long story short:
>
> In the openwhisk runtime for java, when you activate an action, you have to
> pass some informatins. Most notably those:
>
> ---
> {
> "namespace": String,
> "action_name": String,
> "api_host": String,
> "api_key": String,
> "activation_id": String,
> "transaction_id": String,
> "deadline": Number
> }
> ---
>
> Now, the common way in all the programming languages is to set environement
> variables:
>
> so action_name is passed as __OW_ACTION_NAME and so on.
>
> This is easy in every programming language except java. In Java "you should
> not change environment variables". Because the concept of environemnt
> variables is actually to use "system properties". Generally all the
> environment variables are used to set system properties, read only.
>
> In che java8 runtime however the environment variables has been set.
> Following this stack overlflow "horrible and unacceptable' (my opinion) hack
>
> https://stackoverflow.com/questions/318239/how-do-i-set-environment-variables-from-java
>
> Note this "vomit causing" (still my opinion) thing:
>
>Field field = cl.getDeclaredField("m");
>field.setAccessible(true);
>
> Yep, you hack an in-memory undocumented hash map marked read only with
> reflection to say "no, I want to write in it anyway" and then proceed your
> surgery.
>
> I very very very very unwillingly applied this hack in the actionloop runtime
> for java 8 for the sake of keeping compatibility and pass all the existing
> tests.
>
> For java 11 however, this hack also requires you mark the runtime as using
> "unsafe code"
>
> I thing this thing now it is a bit ... too much. So we should instead change
> the way we pass the values and use system properties instead.
>
> Yes, user code for Java11 need to be changed. No more System.getenv(...) but
> System.getProperties.
>
> Your thoughts?
>
>
> --
> Michele Sciabarra
> mich...@sciabarra.com
Re: [wskcli] Delete all entities in a namespace
Yeah that’s ok to do it in both clients, is better than current state +1 - Carlos Santana @csantanapr > On Mar 24, 2020, at 9:21 PM, Nick Mitchell wrote: > > i think the core problem is that there are several layers of collections, > but no bulk and no cursored operations against these collections: "all > actions", "actions in package"... retries and careful coding can work > around these. so it might be sufficient just do it "twice" (in the > openwhisk client npm, and in the go CLI). our code is open source. it's > still not 100% correct. we still get travis failures 1/100 times or so. > >> On Tue, Mar 24, 2020 at 9:09 PM Carlos Santana wrote: >> >> Hi Nick this is very useful even outside demos, I remember having a bash >> alias that it was 95% correct to delete all. >> >> Your proposing the heavy lifting is implemented on the server side >> controller API and the client/api just do a single http request “delete >> all” ? >> >> - Carlos Santana >> @csantanapr >> >>>> On Mar 24, 2020, at 7:16 PM, Nick Mitchell wrote: >>> >>> we implemented this in https://github.com/kui-shell/oui >>> >>> some lessons learned. it's possible, but tricky, due to the loose >> semantics >>> of openwhisk delete-after-delete ordering, plus some bits of potential >> race >>> conditions with with list windowing. things may have improved since we >>> first implemented this, so keep that in mind: >>> >>> 1) if you have an action in a package; then you have to delete the >> actions >>> in the package before you can delete the package; but... if you issue the >>> package delete after the last action delete API call has returned, there >>> (at least used to be) a short window where the package delete would >> fail. i >>> think this depends upon the quorum configuration of your backend >> database. >>> so you may need to have retries here. >>> >>> 2) if you have more than 200 (or whatever the LIMIT config is of your >>> server) actions (c.f. packages, etc.), then you will need to manage the >>> windowing yourself. since the openwhisk API has no strong sense of >> cursors >>> (or does it now?), you have to be careful to fetch all windows before >>> initiating any deletes in any of the windows... >>> >>> there may be more issues, but this one was non-trivial to get right. >> after >>> doing all the work, "delete all" struck me as the kind of thing that >> should >>> be supported by the API directly. >>> >>> @starpit >>> >>>> On Tue, Mar 24, 2020 at 5:23 PM Will Plusnick >> wrote: >>>> >>>> Hello all! >>>> >>>> I've frequently found myself having to clear a namespace after working >>>> on a demo or when experimenting. I'll have a number of artifacts left >>>> in a namespace that I don't want to preserve. Right now, unless I used >>>> wskdeploy for deployment, I'm stuck manually deleting all of the >>>> actions, rules, etc. I want to propose adding a command to the >>>> namespace subcommand in the cli for deleting all the artifacts in a >>>> namespace. >>>> >>>> I envision the syntax for the command going something like: >>>> >>>> $ wsk namespace delete all >>>> This command will delete all entities in the namespace : >>>> >>>> Are you sure you want to proceed? Type '' to proceed: >>>> >>>> action: >>>> is deleted >>>> is deleted >>>> .. >>>> trigger: >>>> is deleted >>>> is deleted >>>> .. >>>> etc >>>> >>>> The user would then be prompted whether they really want to delete all >>>> of the entities in the namespace. They would need to type in a "danger >>>> phrase" such as the name of the namespace to avoid accidentally running >>>> the command. This is similar to deleting a github repo. If anything >>>> but the "danger phrase" is received then the operation is aborted. >>>> >>>> This is a feature I would find personally useful, and would like to >>>> add it to the cli. Does the community at large feel this is a useful >>>> feature? >>>> >>>> Thanks, >>>> Will >>>> >>>> >>
Re: [wskcli] Delete all entities in a namespace
Hi Nick this is very useful even outside demos, I remember having a bash alias that it was 95% correct to delete all. Your proposing the heavy lifting is implemented on the server side controller API and the client/api just do a single http request “delete all” ? - Carlos Santana @csantanapr > On Mar 24, 2020, at 7:16 PM, Nick Mitchell wrote: > > we implemented this in https://github.com/kui-shell/oui > > some lessons learned. it's possible, but tricky, due to the loose semantics > of openwhisk delete-after-delete ordering, plus some bits of potential race > conditions with with list windowing. things may have improved since we > first implemented this, so keep that in mind: > > 1) if you have an action in a package; then you have to delete the actions > in the package before you can delete the package; but... if you issue the > package delete after the last action delete API call has returned, there > (at least used to be) a short window where the package delete would fail. i > think this depends upon the quorum configuration of your backend database. > so you may need to have retries here. > > 2) if you have more than 200 (or whatever the LIMIT config is of your > server) actions (c.f. packages, etc.), then you will need to manage the > windowing yourself. since the openwhisk API has no strong sense of cursors > (or does it now?), you have to be careful to fetch all windows before > initiating any deletes in any of the windows... > > there may be more issues, but this one was non-trivial to get right. after > doing all the work, "delete all" struck me as the kind of thing that should > be supported by the API directly. > > @starpit > >> On Tue, Mar 24, 2020 at 5:23 PM Will Plusnick wrote: >> >> Hello all! >> >> I've frequently found myself having to clear a namespace after working >> on a demo or when experimenting. I'll have a number of artifacts left >> in a namespace that I don't want to preserve. Right now, unless I used >> wskdeploy for deployment, I'm stuck manually deleting all of the >> actions, rules, etc. I want to propose adding a command to the >> namespace subcommand in the cli for deleting all the artifacts in a >> namespace. >> >> I envision the syntax for the command going something like: >> >> $ wsk namespace delete all >> This command will delete all entities in the namespace : >> >> Are you sure you want to proceed? Type '' to proceed: >> >> action: >> is deleted >> is deleted >> .. >> trigger: >> is deleted >> is deleted >> .. >> etc >> >> The user would then be prompted whether they really want to delete all >> of the entities in the namespace. They would need to type in a "danger >> phrase" such as the name of the namespace to avoid accidentally running >> the command. This is similar to deleting a github repo. If anything >> but the "danger phrase" is received then the operation is aborted. >> >> This is a feature I would find personally useful, and would like to >> add it to the cli. Does the community at large feel this is a useful >> feature? >> >> Thanks, >> Will >> >>
Re: [VOTE] Release Apache OpenWhisk wskdebug (v1.2.0, rc1)
alidating sha512... passed > verifying asc... passed (signed-by: Dave Grove ) > verifying notice... passed > verifying absence of DISCLAIMER.txt passed > verifying license... passed > verifying sources have proper headers... passed > scanning for executable files... passed > scanning for unexpected file types... passed > scanning for archives... passed > scanning for packages... passed > scanning package.json for version match... passed > scanning package-lock.json for version match... passed > -- Carlos Santana
Re: [wskdebug] github actions
We currently use Travis for OpenWhisk npm js lib [1] but also I’m cool if you want to use github actions is all just about maintainance We have scripts to test and also to publish to npm js registry We currently use codecov [2] check out the npm scripts [1] https://github.com/apache/openwhisk-client-js/blob/master/.travis.yml [2] https://github.com/apache/openwhisk-client-js/blob/master/package.json#L17 - Carlos Santana @csantanapr > On Mar 4, 2020, at 8:44 PM, Alexander Klimetschek > wrote: > > Ok, cool. Nodejs 13 (or "latest" if available) is missing yet here [1]. > > We should also remove the .circleci folder. > > And would be great to add codecov support [2] [3]. I hope that service is > allowed. It could happen after the first release though. It needs an account > config + secret/token configured somewhere in travis I assume. > > [1] > https://github.com/apache/openwhisk-wskdebug/blob/master/.travis.yml#L19-L22 > [2] https://codecov.io > [3] > https://github.com/alexkli/openwhisk-wskdebug/blob/2c2edd384835d6ecede8dc891f505bbca2944cd8/.github/workflows/nodejs.yml#L21-L23 > > Cheers, > Alex > > From: David P Grove > Sent: Wednesday, March 4, 2020 13:40 > To: dev@openwhisk.apache.org > Subject: RE: [wskdebug] github actions > > Alexander Klimetschek wrote on 03/04/2020 > 03:36:40 PM: >> >> I expect it would take considerable time to get Travis to work here >> and I would like to get back to making changes and fixes to >> wskdebug, which is currently blocked without a CI. > > Travis is configured and running tests on all PRs plus a daily run on > master via cron. > > --dave
Re: wskdebug: npm module name?
My two cents: Publishing to npm would be a community thing as a convenience not an official distribution guaranteeing the bytes for a third party service (ie npmjs.org) No need to vote on the npmjs.org published, vote should already happened for the source code and the tgz source code published. Just setup some scripting that publishes the already voted tgz source to npmjs.org server. - Carlos Santana @csantanapr > On Feb 28, 2020, at 11:43 AM, David P Grove wrote: > > > > Alexander Klimetschek wrote on 02/28/2020 > 01:44:51 AM: >> >>> We own both the @openwhisk and @apache-openwhisk organizations, so >>> we could choose to use either as a scope for this new package. >> >> I did not see any @openwhisk or @apache-openwhisk scopes on npm (no >> results for e.g. [1]). Which are you referring to? > > We have not published a package to either one of these scopes, but the > organizations already exist and are owned by the PMC's "openwhisk-bot" > functional id. The existence of the org claims the scope. > > We should be able to publish a package to either one of those scopes at any > time without additional setup (after we go through the usual voting process > to actually have content to put there). > > --dave
Re: [VOTE] Accept wskdebug contribution from Adobe
+1 To accept wskdebug into Apache OpenWhisk project. Thanks to the Adobe team for the contribution. Thanks David for handling the handover. - Carlos Santana @csantanapr > On Feb 20, 2020, at 6:37 AM, David P Grove wrote: > > > > This is a call to vote to accept the donation of the wskdebug code base > from Adobe as discussed in [1]. This majority vote will remain open for at > least 72 hours. > > The IP clearance form [2] has been filed and I will initiate an IPMC IP > clearance vote shortly (in parallel with this vote). (Note that there > appears to be a lag in rebuilding the html version of the clearance at [2]; > consult the .xml file in svn [3] if you want to see the latest) > > If the vote is successful, we will create a new git repo, > openwhisk-wskdebug, to contain the donated code to allow the OpenWhisk > community to continue its development. > > --dave > > [1] > https://lists.apache.org/thread.html/3cb01abdf0a6a0f2d577d08ed687ab0c06918b7ce958a27b0654b145%40%3Cdev.openwhisk.apache.org%3E > [2] https://incubator.apache.org/ip-clearance/openwhisk-wskdebug.html > [3] > https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/openwhisk-wskdebug.xml
Re: Preview of a OpenWhisk IDE & Debugger... and an help request
About ngrok I have being using inlets as an alternative to ngrok and the license is MIT which is good one. https://github.com/inlets/inlets - Carlos Santana @csantanapr > On Feb 14, 2020, at 10:33 AM, Michele Sciabarra wrote: > > Yes I have a big advantage, in the fact I control the proxy. > I read your documentation and from what I see it works in a very similar way: > you "decorate" the action with your own action, while I am actually working > at the proxy level. But for the rest the concept is similar: create a tunnel > to reach the action, whenever it is. > > I started to dissect the code, and I noticed you use ngrok for creating a > tunnel. I am trying to understand what it is exactly, but is this? > https://ngrok.com/ > > What is the license state? It looks like to be proprietary code coupled with > a proprietary service that happens to have a free (as a beer) but not open > source version. Is it correct? Is it appropriate/acceptable for an apache > project? > > -- > Michele Sciabarra > mich...@sciabarra.com > > > > - Original message - > From: Alexander Klimetschek > To: "mich...@sciabarra.com" , > "dev@openwhisk.apache.org" > Subject: Re: Preview of a OpenWhisk IDE & Debugger... and an help request > Date: Wednesday, February 12, 2020 2:06 AM > >> : Standalone OpenWhisk running in a docker container, because the debugger >> (and the IDE) runs in another docker container. > > I guess this isn't really a scenario that wskdebug is built for, because in > this case you have full control over what happens in that local openwhisk and > debug ports of action containers can be visible in your host. IIUC this might > be what you are doing already - not sure I fully grasped that however. > > wskdebug is generally meant for debugging when you are using a remote > Openwhisk (say IBM Cloud or Adobe I/O Runtime) and you have no other choice. > Many/most action developers will not themselves be able to spin up a local > openwhisk, and sometimes you really need to debug in the real environment, > not a local copy. > > But ignoring that, I wonder what exactly is failing when you run wskdebug > inside a container? In theory it should be feasible. Might be something that > can be fixed. > > Cheers, > Alex > > > *From:* Michele Sciabarra > *Sent:* Tuesday, February 4, 2020 08:18 > *To:* dev@openwhisk.apache.org > *Subject:* Re: Preview of a OpenWhisk IDE & Debugger... and an help request > > The main reason because I tried my own approach instead of using wskdebug, > that I tried, is because I was unable to make it work from within a docker > container. > > My setup is: Standalone OpenWhisk running in a docker container, because the > debugger (and the IDE) runs in another docker container. > > I need this setup because I want to provide a very simple installation, a > wskide command that will setup the development environment. If I run the > debugger from the standalone openwhisk works. But I have problems to add also > the IDE that requires also node. So the prerequisites to run the whole thing > would be a java of a given version, a node of the right version and docker. > > So I decided to go for a full dockerized solution. I have a launcher, written > in go, that starts standalone openwhisk running in a docker container, and > another container with the debugger and the editor (theia). In this setup, > wskdebug does not work. It tries to do something with docker and does not > work. I was unable to understand what is wrong, I tried to read the code but > I do not follow it. > > For this reason I simply put an action in debug mode (using the runtime) and > then I connected from the ide. It is more straightforward. There are still > some issues to sync. But everything is open for discussion, I am more than > happy if I can re-use wskdebug. > > -- > Michele Sciabarra > mich...@sciabarra.com > > - Original message - > From: Alexander Klimetschek > To: "dev@openwhisk.apache.org" > Subject: Re: Preview of a OpenWhisk IDE & Debugger... and an help request > Date: Tuesday, February 04, 2020 5:02 PM > > Hi Michele, > > please note that wskdebug [1] is a debugger for any kind. Nodejs has the best > out of the box support since that’s what we are exclusively using right now. > Other languages can already be supported using the right command line > arguments (ports, docker command etc), which is how Java worked. Given this > new __OW_DEBUG_PORT env variable, it can be set with wskdebug using > —dockerArgs. Contributions are welcome to make this more automatic b
Re: [VOTE] Release Apache OpenWhisk Client Js (v3.21.1, rc1)
-client-js-3.21.1-sources.tar.gz > > SHA512: openwhisk-client-js-3.21.1-sources.tar.gz: > > 89E62001 CA784F23 2CA52140 ADC2E68F AC145656 EF5C1E0F 52803660 49D98F3B > 10F18BC1 > > B9763B72 1DD49CDC 10045B42 3A2DF152 CC252CC4 67E0FC44 12A95A53 > > validating sha512... passed > > verifying asc... passed (signed-by: Rodric Rabbah ) > > verifying notice... passed > > verifying absence of DISCLAIMER.txt passed > > verifying license... passed > > verifying sources have proper headers... passed > > scanning for executable files... passed > > scanning for unexpected file types... passed > > scanning for archives... passed > > scanning for packages... passed > > scanning package.json for version match... passed > > scanning package-lock.json for version match... passed > > > > On 2020/02/07 17:22:04, Rodric Rabbah wrote: > > > Hi, > > > > > > This is a call to vote on releasing version 3.21.1 release candidate > rc1 of > > > the following project module with artifacts built from the Git > repositories > > > and commit IDs listed below. This is a very small update to the just > passed > > > vote to release v3.21.0 rc2. It corrects the version number in > package.json > > > and package-lock.json. > > > > > > * OpenWhisk Client Js: faa7f69f09a93564e0f91abb4556aa0ea1434c10 > > > > > > > https://github.com/apache/openwhisk-client-js/commits/faa7f69f09a93564e0f91abb4556aa0ea1434c10 > > > > > > > https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-client-js-3.21.1-sources.tar.gz > > > > > > > https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-client-js-3.21.1-sources.tar.gz.asc > > > > > > > https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-client-js-3.21.1-sources.tar.gz.sha512 > > > > > > This release is comprised of source code distribution only. > > > > > > You can use this UNIX script to download the release and verify the > > > checklist below: > > > > https://gitbox.apache.org/repos/asf?p=openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=177e177 > > > > > > Usage: > > > curl -s " > > > > https://gitbox.apache.org/repos/asf?p=openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=177e177 > " > > > -o rcverify.sh > > > chmod +x rcverify.sh > > > rcverify.sh openwhisk-client-js 'OpenWhisk Client Js' 3.21.1 rc1 > > > > > > Please vote to approve this release: > > > > > > [ ] +1 Approve the release > > > [ ] 0 Don't care > > > [ ] -1 Don't release, because ... > > > > > > Release verification checklist for reference: > > > [ ] Download links are valid. > > > [ ] Checksums and PGP signatures are valid. > > > [ ] Source code artifacts have correct names matching the current > release. > > > [ ] LICENSE and NOTICE files are correct for each OpenWhisk > repository. > > > [ ] All files have license headers as specified by OpenWhisk project > > > policy [1]. > > > [ ] No compiled archives bundled in source archive. > > > > > > This majority vote is open until at least 3 passing votes are recorded > > > since there were no objections to releasing 3.21.0 and this is only a > > > trivial change. > > > > > > [1] > > > > https://github.com/apache/openwhisk-release/blob/master/docs/license_compliance.md > > > > -- Carlos Santana
Re: Preview of a OpenWhisk IDE & Debugger... and an help request
Very cool feature and demo Michele +1 - Carlos Santana @csantanapr > On Jan 31, 2020, at 8:38 AM, Michele Sciabarra wrote: > > Hello Whiskers, > > I am working on an integrated IDE & Debugger for OpenWhisk using the > ActionLoop runtime, the standalone OpenWhisk and Eclipse Theia. This would be > complementary to the existing wskdebug for Javascript and Java, as this works > now for Typescript and I plan to add to other actionloop based runtimes. > > You can see a demo here: https://www.youtube.com/watch?v=FhtGsm4Vnu4 > > I am using the standalone Openwhisk and Eclipse Theia, the in-browser > vscode-like editor that can be deployed as a docker container. > > The mechanic is simple: when I deploy an action I pass an additional > environment variable __OW_DEBUG_PORT > The runtime when it sees this environment variable starts under a debugger. > I can then ask to the runtime the parameters to connect to the debugger and I > use this to connect to the debugger, as you can see in the demo. > > I adapted the upcoming typescript runtime to do this, but I plan to do > similar changes also for other action loop based runtimes, like go and > python. Also I am using a Makefile to start the environment but I am working > on a standalone openwhisk-ide launcher. Unless we add the feature “ide" to > the wsk cli 🙂, if you like the idea... > > I have a couple of problems to solve and I am asking for help. The first > problem is that I need to invoke an action twice as the first time the > debugger does not attach. I guess it is because the image is paused. So I > wonder if it is possible to enable an option that does not pause the > container while running using the standalone openwhisk. And the second > problem is that sometimes I get more than one instance of an action. This > happens when I redeploy. I wonder if it is possible to force the Lean > Balancer to use only one instance of an action. > > All of this of course are options only for development purposes but I think > in this way OpenWhisk would be the ONLY serverless to include also an IDE > with debugger ready to go. No more “serverless actions are hard to debug”. > > -- > Michele Sciabarra > mich...@sciabarra.com
Re: OpenWhisk project goodies
Rodric thanks for doing this +100 Also thanks to the recent committers for accepting the challenge of growing and helping the community. Happy Holidays to all Whiskers ! - Carlos Santana @csantanapr > On Dec 21, 2019, at 9:48 AM, Markus Thömmes wrote: > > Thanks for taking this on you Rodric. For new contributors it can really > make all the difference to be welcomed into a community like this. Kudos to > you! > > Happy holidays! > >> Am Mi., 18. Dez. 2019 um 17:16 Uhr schrieb Rodric Rabbah : >> >> As a project and community we have a lot to celebrate this year and be >> thankful for. I'm thankful for all the new contributors and contributions, >> for the community's recognition of new committers, and for all the work >> that went into the project graduation. >> >> On Slack yesterday I asked if new community members who haven't received >> any project swag would like some goodies (a coffee or tea mug, t-shirt or >> hoodie, stickers...) and ended up sending out a bunch of gifts. It's a >> small token of appreciation for our community. >> >> This message is to reach out to other community members not on slack who'd >> like one of these goodies. Email me directly or message me on slack. You'll >> find items https://www.redbubble.com/ (search for our project name to see >> what's available and if you only get one result, click it and scroll down >> to see more). >> >> Happy holidays and my best wishes to everyone! >> >> -r >>
Re: sorry for the github notification flood
Thanks Rodric I got them all this morning :-) Thanks for the holiday cleaning 🧹 - Carlos Santana @csantanapr > On Dec 18, 2019, at 11:59 AM, Chetan Mehrotra > wrote: > > Thanks Rodric for this long overdue cleanup!!. > > Having a set of valid and non stale issues would be helpful > > >> On Wed, Dec 18, 2019, 9:35 PM Rodric Rabbah wrote: >> >> if you subscribe to github notifications for our project, i'm sorry. >> i should have sent a warning that I was going to go through a lot of our >> our open issues and close ones that are fixed, stale, or won't fix. >> >> good news is that i'm done for now and reduced the issue count by 150 or so >> (largely because we've addressed the substance but were not very good about >> closing). >> >> bad news now that i started, i might keep going to address the remaining >> 300 issues. >> >> -r >>
Re: Road to Scala 2.13
Woot +1 - Carlos Santana @csantanapr > On Nov 21, 2019, at 5:58 AM, David P Grove wrote: > > > > > "Markus Thömmes" wrote on 11/21/2019 02:03:30 > AM: >>> >>> One thing to be careful of is that many downstream repos (runtime, >>> providers) depend on the test suite from the core repo. We had a > couple >>> rounds of breakage in the last few months where a test suite change got > a >>> clean core travis run, but still broke all the downstream repos leading > to >>> some hasty fixing and/or reverting. >>> >> >> I hear you! Is there a good way to verify stuff works across all >> repositories or will I have to manually go through all of them and check > if >> my changes have any impact? >> >> > > Not going to be perfect, but I think all of the breakages we had would have > been caught by building even one downstream repo against the modified core > since the test suite is used more or less the same way in all the runtime > repos. > > --dave
Re: OpenWhisk as a single docker image?
Yes that’s fine to be “alongside” with the release, but I would not want to wait months for another release just get a minor update to the jar I would prefer in addition to have a nightly jar built and easy to get. - Carlos Santana @csantanapr > On Nov 13, 2019, at 9:09 AM, Bertrand Delacretaz > wrote: > > On Wed, Nov 13, 2019 at 3:02 PM Carlos Santana wrote: >> ...The jar can’t and should not be distributed as part of an Apache >> release... > > It won't be an Apache Release but it's fine to distribute that jar as > a "compiled package" [1] alongside its released source code. > > -Bertrand > > [1] http://www.apache.org/legal/release-policy.html
Re: OpenWhisk as a single docker image?
+1 The jar can be build and made available as a nightly/dev artifact for quick development and testing purposes for convenience. Then provide the one liner command to get up and running, assuming jre and docker is present :-) The jar can’t and should not be distributed as part of an Apache release. - Carlos Santana @csantanapr > On Nov 13, 2019, at 8:55 AM, Michele Sciabarra wrote: > > I did some experimentations with the docker in docker and ultimately I am > convinced it is actually better just to use the jar. I would then suggest to > distribute at least the precompiled jar instead of requiring to compile by > himself. > > -- > Michele Sciabarra > mich...@sciabarra.com > > - Original message - > From: Chetan Mehrotra > To: dev@openwhisk.apache.org > Subject: Re: OpenWhisk as a single docker image? > Date: Wednesday, November 13, 2019 6:00 AM > > Running standalone logic within a Docker would be tricky as there is quite > a bit of logic involved to use the right IP for inter docker communications > specially in Kafka and Api Gateway part. > > Hence currently we expect that to use standalone the user has at minimum > JDK + Docker on the host > > Chetan Mehrotra > > >> On Tue, Nov 12, 2019 at 10:58 PM Matt Sicker wrote: >> >> Docker in Docker has some slight security improvements depending on >> your use case, too, compared to just mounting your docker socket into >> the running container. >> >>> On Sat, 9 Nov 2019 at 10:30, Tyson Norris >>> wrote: >>> >>> I suspect that due to Docker-in-Docker scenario, it will be easier to >> use java+jar (+local docker) instead of running the jar in a container. >>> >>> Today you can start the jar with only java , but you will need a >> bunch of parameters (probably different per OS?) to run it in a container, >> I think. >>> Local docker client is switched per OS here >> https://github.com/apache/openwhisk/blob/231e739373ef681c44b5647a6956d5838a87db2e/core/invoker/src/main/scala/org/apache/openwhisk/core/containerpool/docker/StandaloneDockerContainerFactory.scala#L37 >>> I guess this wouldn't apply if running in a container, but it arguably >> makes running the jar simpler than running the container IMHO. >>> I also suspect you won't get the behavior of launching playground ui to >> browser either, which I would miss. >>> >>> Tyson >>> >>> On 11/9/19, 5:38 AM, "Michele Sciabarra" wrote: >>> >>>Wow. I missed 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... >>> >>>If it is possible I can volounteer to write the dockerfile do that... >>> >>>I have a question: does it use the local docker? Where is the >> invoker? >>> >>> >>>-- >>> Michele Sciabarra >>> mich...@sciabarra.com >>> >>>- Original message - >>>From: Rodric Rabbah >>>To: dev@openwhisk.apache.org >>>Subject: Re: OpenWhisk as a single docker image? >>>Date: Saturday, November 09, 2019 2:31 PM >>> >>>Do you mean the standalone controller? >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fopenwhisk%2Fblob%2Fmaster%2Fcore%2Fstandalone%2FREADME.md&data=02%7C01%7Ctnorris%40adobe.com%7Cfc313c39337a44a5882a08d7651a0cbc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637089034867332217&sdata=OCnWo8R5OfbKLaSQCEeI%2B7pqz0ewp%2BYQGBK2msMoMtc%3D&reserved=0 >>> >>>-r >>> >>>> On Nov 9, 2019, at 8:18 AM, Michele Sciabarra < >> mich...@sciabarra.com> wrote: >>>> >>>> Hello all, >>>> >>>> I remember the discussion about the openwhisk as a single >> executable that includes also Kafka. So I wonder: is it now possible to run >> (for development purposes of course) OpenWhisk as single docker image if we >> add also couchdb to that one? Because I have an use case where even a >> docker-compose can be inconvenient... >>>> >>>> -- >>>> Michele Sciabarra >>>> mich...@sciabarra.com >>> >>> >> >> >> -- >> Matt Sicker >>
Re: Playground UI for openwhisk
I think this is great complement a single jar with an UI If someone wants to create a “brew install apache/openwhisk” 😉 $ openwhisk Brings up PG UI - Carlos Santana @csantanapr > On Oct 14, 2019, at 1:25 AM, Chetan Mehrotra > wrote: > > Thanks Rodric and Nimbella for contributing the Playground UI to > OpenWhisk. This would greatly improve the first user experience trying > out OpenWhisk by providing them a good ui to play around with > OpenWhisk without installing the `wsk` cli and learning it > > For those who want to try this feature now > > $ wget > https://github.com/chetanmeh/incubator-openwhisk/releases/download/0.14/openwhisk-standalone.jar > $ java -jar openwhisk-standalone.jar --pg > > As the Playground provides much simpler experience for the first time > user (even does not need `wsk` cli installed) I was thinking to launch > Playground UI as a default behavior > > By default when a user run `java -jar openwhisk-standalone.jar` it > would also install the actions needed for Playground use and also > launch the browser loading the Playground UI automatically with > following conditions > > 1. Launch PG by default > >1. If launch is done from console. Such that test when launching > the standalone does not trigger PG flow (should be possible to do by > checking for TTY support in Console) >2. If system is configured with `MemoryArtifactStore` or used > `--couchdb` option. Idea here being to not automatically install the > action if user was connecting to some other long term db. Note that > this would need to be later fixed for also preventing default > bootstrapping user if standalone is started referring to some existing > db managed outside of Standalone lifecycle > > 2. If user passes `--no-pg` then Playground would not be launched > > 3. If user explicitly passes `--pg` then Playground would be launched > > > Chetan Mehrotra > [1] > https://github.com/chetanmeh/incubator-openwhisk/releases/download/v0.14/openwhisk-standalone.jar > > Chetan Mehrotra > > >> On Sat, Oct 12, 2019 at 4:08 AM David P Grove wrote: >> >> >> >> Rodric Rabbah wrote on 10/11/2019 05:08:09 PM: >>> >>> With Chetan's contributions around the standalone controller, he and I >>> recently chatted about adding a simple UI to complement all the other >>> features now available out of the box. >>> >>> At Nimbella, we had developed a playground interface for quickly >> authoring >>> functions (and sharing code) and we'd like to contribute this to the >> Apache >>> project. >>> >>> I have opened a PR [1] to seed this implementation and have coordinated >>> with Chetan so that it can be used with the standalone controller. You >> can >>> try it out at [2] if you haven't already seen in and I will show it at >> the >>> upcoming tech exchange on Wednesday. >>> >>> Feedback as usual is welcomes and appreciated. I have not considered >> adding >>> this to the rest of the deployments but could explore that. In particular >> a >>> previous commit added a "/ui" route to the nginx routing in the open >> source >>> configuration and we could use that for this purpose. >>> >> >> This is cool! >> >> Looking forward to the demo at the next tech exchange. >> >> --dave
Re: acceptable file types in 'tests' portion of source releases?
Even if want to we should not include in the release tgz anything that is not simple source code files (ie jar,zip,binaryexec) The released tgz can contain files and scripts (also files) that could generate those artifacts (jar, zip, binaryexec) This is my understanding As a receiver of the released tgz to use in a comercial product I would not trust those type of files (jar, zip, binaryexec), but I would be ok to run some commands using the content of the tgz to generate the test features artifacts (jar,zip, binaryexec) that allow me to run the tests. - Carlos Santana @csantanapr > On Sep 15, 2019, at 6:09 PM, David P Grove wrote: > > > > In the current round of releases, we've stopped excluding the tests subdir > from the source releases. In general, I think this is the right thing to > do because if someone is actually going to build an OpenWhisk component > from a source release, they really should be able to test what they built. > > However, some of our repos include "binary" files of various flavors to use > as test input. Clearly, we can extend rcverify.sh to accept a wider range > of file types in the "tests" tree, but do we want to allow everything or > just a restricted set of file types? > > Appended is the list for wskdeploy. It runs the spectrum of zips > containing source files, jar files, and full-out executables (golang). > > --dave > > scanning for unexpected file types... failed > (/var/folders/8c/zvj0nsxx2rgc_km8nvf8k0c0gn/T/tmp.RHoEu36n/openwhisk-wskdeploy-1.0.0/tests/src/integration/helloworld/actions/hello.zip: > application/zip; charset=binary > /var/folders/8c/zvj0nsxx2rgc_km8nvf8k0c0gn/T/tmp.RHoEu36n/openwhisk-wskdeploy-1.0.0/tests/src/integration/helloworld/actions/hello.jar: > application/java-archive; charset=binary > /var/folders/8c/zvj0nsxx2rgc_km8nvf8k0c0gn/T/tmp.RHoEu36n/openwhisk-wskdeploy-1.0.0/tests/src/integration/docker/actions/go/exec: > application/x-executable; charset=binary > /var/folders/8c/zvj0nsxx2rgc_km8nvf8k0c0gn/T/tmp.RHoEu36n/openwhisk-wskdeploy-1.0.0/tests/src/integration/docker/actions/exec.zip: > application/zip; charset=binary > /var/folders/8c/zvj0nsxx2rgc_km8nvf8k0c0gn/T/tmp.RHoEu36n/openwhisk-wskdeploy-1.0.0/tests/src/integration/validate-packages-in-manifest/actions/hello.jar: > application/java-archive; charset=binary > /var/folders/8c/zvj0nsxx2rgc_km8nvf8k0c0gn/T/tmp.RHoEu36n/openwhisk-wskdeploy-1.0.0/tests/src/integration/jaraction/src/hello.jar: > application/java-archive; charset=binary > /var/folders/8c/zvj0nsxx2rgc_km8nvf8k0c0gn/T/tmp.RHoEu36n/openwhisk-wskdeploy-1.0.0/tests/src/integration/runtimetests/src/helloworld/helloworld.zip: > application/zip; charset=binary > /var/folders/8c/zvj0nsxx2rgc_km8nvf8k0c0gn/T/tmp.RHoEu36n/openwhisk-wskdeploy-1.0.0/tests/src/integration/runtimetests/src/helloDotNet.src.zip: > application/zip; charset=binary > /var/folders/8c/zvj0nsxx2rgc_km8nvf8k0c0gn/T/tmp.RHoEu36n/openwhisk-wskdeploy-1.0.0/tests/src/integration/runtimetests/src/hello.jar: > application/java-archive; charset=binary > /var/folders/8c/zvj0nsxx2rgc_km8nvf8k0c0gn/T/tmp.RHoEu36n/openwhisk-wskdeploy-1.0.0/tests/src/integration/runtimetests/src/helloDotNet.zip: > application/zip; charset=binary) > scanning for archives ... failed > (/var/folders/8c/zvj0nsxx2rgc_km8nvf8k0c0gn/T/tmp.RHoEu36n/openwhisk-wskdeploy-1.0.0/tests/src/integration/helloworld/actions/hello.jar > /var/folders/8c/zvj0nsxx2rgc_km8nvf8k0c0gn/T/tmp.RHoEu36n/openwhisk-wskdeploy-1.0.0/tests/src/integration/validate-packages-in-manifest/actions/hello.jar > /var/folders/8c/zvj0nsxx2rgc_km8nvf8k0c0gn/T/tmp.RHoEu36n/openwhisk-wskdeploy-1.0.0/tests/src/integration/jaraction/src/hello.jar > /var/folders/8c/zvj0nsxx2rgc_km8nvf8k0c0gn/T/tmp.RHoEu36n/openwhisk-wskdeploy-1.0.0/tests/src/integration/runtimetests/src/hello.jar)
Re: [DISCUSS}: release "cli group" of projects
+1 and version 1.0 - Carlos Santana @csantanapr > On Sep 13, 2019, at 10:46 AM, Rodric Rabbah wrote: > > +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 project` subcommand to crash in some common usage scenarios >> in the 0.10.0 release. >> >> It looks to me like the current master branch is stable with no pending PRs >> that need to be merged. If I missed something, please comment on this >> thread. >> >> One item for discussion is whether we should number this release as 0.11.0 >> or go ahead and call it 1.0.0. To me it seems like the cli api is fairly >> stable, so going to a 1.x.y numbering seems plausible. But I don't work on >> the cli tools, so I might be overlooking a reason to stay with a 0.x >> number. >> >> thanks, >> >> --dave >> >> [1] https://github.com/apache/openwhisk-wskdeploy/issues/1050 >>
Re: removing "projections" on web actions
I was never a fan of projections, very clever trick but the idea that an the path to an endpoint was controlling a filter for the http response gives me the heebie-jeebies :-) On the other side feels like a form of graphQL From experience don’t do the feature flag, and don’t try to implement in another way. If you want to invest effort instead show an example/lib of using whisk actions as front workers for graphQL might be more useful similar to Cloudflare [1] when talking about projections and filtering responses. I like the idea of a cut off date. Do a /remind in Slack or a Whisk alarm trigger :-) [1] https://developers.cloudflare.com/workers/templates/boilerplates/graphql/ - Carlos Santana @csantanapr On Aug 30, 2019, at 9:53 AM, Rodric Rabbah wrote: >> 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 flag. I think the feature as > implemented is unwieldy and kudos to those that did get it to work. Fine > with me to defer it's already been open 4 months. > > That said, I have thought that we could provide projection capabilities but > using X- headers (an argument for keeping some of the code around). I am > not sure/convinced this feature in general though is useful. > > -r
Re: Execute OpenWhisk action via Ignite and Firecracker VM (pr #4556)
Great work Chetan This must be a new record how fast to get a POC integrated in a few days after ignite being announced -- Carlos On Fri, Jul 12, 2019 at 9:46 AM Chetan Mehrotra wrote: > 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 > -- Carlos Santana
Re: Adding Github app (Depend-a-bot) to Client JS SDK repo?
The Github repos are managed by INFRA they are the only ones with admin. You need to open a JIRA ticket for the request. - Carlos Santana @csantanapr > On Jul 1, 2019, at 8:00 AM, Rodric Rabbah wrote: > > 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, 2019 at 9:50 AM James Thomas wrote: >> >> Hello Whiskers. >> >> If I want to add a Github app to one of our repos - do I just need to open >> a JIRA ticket with Infra? Does anyone know if there are any rules about >> what apps are allowed? >> >> I'm continuing work[1] on updating the project dependencies for the Client >> JS SDK, which had not been updated for a long time. I want to make sure >> this doesn't happen again and add a Github app to send PRs each time a >> major dependency upgrade is available using Depend-a-bot: >> https://github.com/marketplace/dependabot-preview >> >> Does anyone have any issues with this? >> >> [1] - https://github.com/apache/incubator-openwhisk-client-js/pull/180 >> -- >> Regards, >> James Thomas >>
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 headers as specified by OpenWhisk project policy [1]. [x] No compiled archives bundled in source archive. On Sun, Jun 30, 2019 at 6:20 PM Rodric Rabbah wrote: > +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 headers as specified by OpenWhisk project > policy [1]. > [x] No compiled archives bundled in source archive. > > On Sun, Jun 30, 2019 at 3:34 PM David P Grove wrote: > > > > > > > Hi, > > > > This is a call to vote on releasing version 0.10.0-incubating release > > candidate rc1 of the following project module with artifacts built from > the > > Git repositories and commit IDs listed below. > > > > * OpenWhisk Catalog: cb8d5c73 > > https://github.com/apache/incubator-openwhisk-catalog/commits/cb8d5c73 > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-catalog-0.10.0-incubating-sources.tar.gz > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-catalog-0.10.0-incubating-sources.tar.gz.asc > > > > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-catalog-0.10.0-incubating-sources.tar.gz.sha512 > > > > This release is comprised of source code distribution only. > > > > You can use this UNIX script to download the release and verify the > > checklist below: > > > > > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD > > > > Usage: > > curl -s " > > > > > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD > > " -o rcverify.sh > > chmod +x rcverify.sh > > rcverify.sh openwhisk-catalog 'OpenWhisk Catalog' 0.10.0-incubating rc1 > > > > Please vote to approve this release: > > > > [ ] +1 Approve the release > > [ ] 0 Don't care > > [ ] -1 Don't release, because ... > > > > Release verification checklist for reference: > > [ ] Download links are valid. > > [ ] Checksums and PGP signatures are valid. > > [ ] DISCLAIMER is included. > > [ ] Source code artifacts have correct names matching the current > > release. > > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. > > [ ] All files have license headers as specified by OpenWhisk project > > policy [1]. > > [ ] No compiled archives bundled in source archive. > > > > This majority vote is open for at least 72 hours. > > > > > > [1] > > > > > https://github.com/apache/incubator-openwhisk-release/blob/master/docs/license_compliance.md > > > -- Carlos Santana
Re: Cleaning up old images on Docker Hub, help confirming candidates
loud.docker.com/u/openwhisk/repository/docker/openwhisk/action-swift-v4 > (1 year+) > > > - > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/swift3action > (2+ years ago) > > > - > > > > > > Early dev/test images? > > > - > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/couchdb-snapshot > (2+ years ago) > > > - > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/couchdb-catalog > (2+ years ago) > > > > > > - > > > > > > Also, found these old Docker SDK samples/demos? which would love to > know where the source code exists for the actual code to see if we want to > use as our own examples and automate builds for (perhaps as part of the > SDK). > > > > > > Note: > > > * they referenced bluemix home page… REMOVED > > > * with the quote "This image demonstrates OpenWhisk's support for > executing arbitrary code in a safe manner. Bring your own docker image.”. > > > * Single tag “latest” (single push) > > > > > > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/javaaction > (2+ years ago) > > > * No description > > > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/thumbnail > (3+ years ago) > > > * A example docker image that creates a polaroid-style thumbnail from > a given image URL. > > > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/asciiart > (3+ years ago) > > > * A example docker image that creates a polaroid-style thumbnail from > a given image URL. > > > > https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/spellcheck > (3+ years ago) > > > * A example docker image that includes a spell client that interfaces > with aspell. (sic) > > > > > > Please comment if these can/should be deleted or if not please let us > know why and how we proceed to make current. > > > > > > Thanks, > > > Matt > > > > > > -- Carlos Santana
Re: exporting activation arguments to the environment
I understand that this is orthogonal on what Rodric is proposing but for the topic of environment variables Reserved 2 annotations to be private like “__OW_CONFIGS” and “__OW_SECRETS” No schema change This variables would be dictionaries/jsonobjects The information will end up as environment variables at runtime. Then provide an user experience thru UI or CLI to set both Example of CLI: wsk action update myaction myaction.js -c LOGLEVEV DEBUG -s PASSWORD supersecret Both LOGLEVEL and PASSWORD will be set as environment variables The idea to brake them into two sets give the opportunity to the operator and the management platform to treat secrets a bit different if desired. - Carlos Santana @csantanapr > On Jun 27, 2019, at 6:00 AM, Dominic Kim wrote: > > I am inclined to be more explicit. > Whenever users forget about the difference between uppercase and lowercase > parameters, the feature may not work as they expected. > So I am inclined to Tyson's opinion to explicitly add another flag such as > "-e". > > If it could be overhead to change the schema, how about relying on > annotation? > I think it makes sense to set environment variables at action creation time. > We can introduce a new annotation to set environment variables, or apply > some rules against the existing flag "-a" as Rabbah suggested. > > Best regards > Dominic > > > > > > > 2019년 6월 27일 (목) 오전 8:52, Rodric Rabbah 님이 작성: > >> The use of env vars wouldn't be an issue with intra-container concurrency >> if they're immutable, right? The more specific issue that arises today >> which I think is your primary concern, are the __OW_ system provided >> environment variables which mutate with each invocation of main. Is that >> right? >> >> If so, then I think there are only two issues: >> 1. do we introduce a context object (did you see my other dev list mail?) >> 2. logging >> >> i really think my issue is orthogonal to these concerns - it's a >> convenience feature for the developer. An action can already export >> environment variables today from main. >> >> -r >> >> On Wed, Jun 26, 2019 at 8:44 PM Tyson Norris >> wrote: >> >>> Sorry, what I meant was: accumulating issues around the "main" function, >>> which are: >>> - context >>> - use of env vars >>> - your issue: separating user provided params from developer-provided >>> params >>> - 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: Cleaning up old images on Docker Hub, help confirming candidates
I think the images being actively used by Travis or jenkins testing should remain in the current repository their current usage should be as nightly builds only intended for dev and build integrating testing. I think having the tag latest is not a big deal as it’s a default tag when pulling containers, but I’m not going to oppose if someone wants to change it to something like “dev” or like I had at one point “master” which then Rodric changes to “latest” :-) As for the convenient binaries of the release, I think these images should be build out of Apache jenkins server using the source code that is already released on the “dist” directory from Apache distribution server these images should not be in the current “openwhisk” docker namespace they should be pushed to the Apache “docker.io/apache/incubator-openwhisk-*:version” [1] We also need to check what are the ASF Infra requirements to host an image under the Apache namespace like the requirement to secure the image by signing the image or just have the digest/taghash documented for verification. [1] https://hub.docker.com/u/apache - Carlos Santana @csantanapr > On Jun 26, 2019, at 4:00 AM, Rodric Rabbah wrote: > > For the demos, the asciiart image might be from Nick M but I think we can > extract the source into a repo from just the docker image. The spell checker > I may have the source for. It’s a bash script which was covered in a blog > post. > > Do you want to save the sources? We can make them demos under the docker > runtime repo, if so. > > For ballerina I would leave it. 1.0 is slated for release soon and I’ll pick > that up and update the runtime image. > > -r > >> On Jun 25, 2019, at 3:40 PM, Matt Rutkowski wrote: >> >> Just made a pass through all images under the "openwhisk" moniker on Docker >> Hub: >> https://hub.docker.com/u/openwhisk/ >> >> assuring all have valid (short) descriptions and long descriptions that >> clearly describe each belonging to our Apache project proper (adapting 2 >> examples from other Apache projects, thanks Rodric). In addition, we BOLDly >> indicate these are convenience binaries and point back to the our Apache >> repos. in github where they are generated from as build artifacts. >> >> Along the way, I found the following images that I believe should be >> deprecated (i.e., deleted from Docker Hub) along with my notes as to when >> they stopped being used/generated and last build date: >> >> -- >> - >> https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/action-ballerina-v0.975 >> (5 months, current version action-ballerina-v0.990.2), same major version, >> not sure who is maintaining >> >> --- >> replaced by ow-utils: >> >> - >> https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/ansible-runner >> (7 months, replaced bu ow-utils image >> >> - >> https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/script-runner >> (7 months, replaced bu ow-utils image) >> * deprecated by this PR: >> https://github.com/apache/incubator-openwhisk/pull/4158 >> >> >> >> Kube related: >> >> - >> https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-whisk-ansible-runner >> (10 months, replaced by ansible-runner) >> >> - >> https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-whisk-script-runner >> (10 months, replaced by script-runner) >> >> - >> https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-kafkapkginstaller >> (1 year+) >> - >> https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-routemgmt >> - >> https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-openwhisk-catalog >> * deprecated by these PRs >> * https://github.com/apache/incubator-openwhisk-deploy-kube/pull/239 >> (Kubernetes YAML removed) >> * https://github.com/apache/incubator-openwhisk-deploy-kube/pull/249 >> (Dockerfile removed) >> >> - >> https://cloud.docker.com/u/openwhisk/repository/docker/openwhisk/kube-couchdb >> * deprecated by these PRs >> * https://github.com/apache/incubator-openwhisk-deploy-kube/pull/239 >> (Kubernetes YAML removed) >> * https://github.com/apache/incubator-openwhisk-deploy-kube/pull/261 >> (uses ow-utils and initdb.sh script to run ansible playbooks in main OW) >> >> https://cloud.docker.com/u/openwhisk/repository/d
Re: Openwhisk in a standalone runnable jar (#4516)
Chetan thanks for thinking on Windows users +1 Just curious why the jar can’t be build in Windows can you log an issue for this? My 2 cents for Windows or Mac I think the best way to build the jar would be inside a docker container. A one liner with a single command should be able to produce the jar on a local workstation or devops pipeline. - Carlos Santana @csantanapr > On Jun 21, 2019, at 7:45 AM, Chetan Mehrotra > wrote: > > Just to share some more progress. With runnable jar its now possible > to run OpenWhisk standalone even on Windows and execute basic actions. > Tested it with Docker on Windows 2.0.0.3 on Windows 10 > > Note you would probably not be able to build the project on windows. > But copying the produced jar would let you run it on Windows. > > Chetan Mehrotra > > On Fri, Jun 21, 2019 at 5:13 PM Chetan Mehrotra > wrote: >> >> Hi Nick, >> >> For now just building the PR branch and running following command >> should get you going >> >> java -jar openwhisk-standalone-1.0.0-SNAPSHOT.jar >> >> You can use the default guest and whisk.system credentials to interact >> with it. I am in the process of writing a readme for various options >> exposed. Hope to get it done by Monday >> >> Chetan Mehrotra >> >>> On Fri, Jun 21, 2019 at 4:57 PM Nick Mitchell wrote: >>> >>> thanks chetan for doing this! >>> >>> could you provide some example startup sequences, e.g. with sample configs? >>> i'm willing to try this out for our CI/CD pipeline -- i'm sick of 1) >>> waiting 5-7 minutes for openwhisk to start up; and b) fighting ansible >>> versus xenial :) >>> >>> @starpit >>> >>> On Fri, Jun 21, 2019 at 12:44 AM Chetan Mehrotra >>> wrote: >>> >>>>> What's the performance like on startup time >>>> >>>> It starts in < 5 secs. >>>> >>>> So far no major blocking issue apart from fetching docker logs on Mac. >>>> Current approach of directly reading the log json does not work. So >>>> need to have a mac version which uses `docker logs` command to >>>> somewhat handle such a case. >>>> >>>> Chetan Mehrotra >>>> >>>>> On Thu, Jun 20, 2019 at 9:50 PM James Thomas wrote: >>>>> >>>>> That is mind-blowingly cool! >>>>> >>>>> What's the performance like on startup time? >>>>> >>>>> On Thu, 20 Jun 2019 at 06:14, Carlos Santana >>>> wrote: >>>>>> >>>>>> Genius! >>>>>> https://www.adminsub.net/tcp-udp-port-finder/whisker >>>>>> >>>>>> >>>>>> - Carlos Santana >>>>>> @csantanapr >>>>>> >>>>>>> On Jun 19, 2019, at 12:30 PM, David P Grove >>>> wrote: >>>>>>> >>>>>>> WhiskerControl >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> James Thomas >>>>
Re: oauth token verification in the controller
Rodric I think having additional authentication methods no one will object, but the devil are in the details :-) Also when you say things like “replace” with no more context some folks that are using the software in production, quickly jump into the conclusion on “Now I have thousands of end users suddenly can’t authenticate and applications in the field broken :sob: “ The current auth SPI I believe allows the controller to be customize to handle an authorization header of “Bearer” token instead of “Basic” If your are referring to OAuth 2.0 is quite large but maybe your referring to discussing “Scopes” in an OpenWhisk world, ability to have more grain control. For example ability to have a token with a scope have the ability to delete artifacts vs a token that is only allow to create but not delete vs a token that is only allow to invoke a trigger with “long” expiration time and nothing else. - Carlos Santana @csantanapr > On Jun 21, 2019, at 7:23 AM, Rodric Rabbah wrote: > > 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: Openwhisk in a standalone runnable jar (#4516)
Genius! https://www.adminsub.net/tcp-udp-port-finder/whisker - Carlos Santana @csantanapr > On Jun 19, 2019, at 12:30 PM, David P Grove wrote: > > WhiskerControl
Re: [ACTION REQUIRED] Nominations for PMC Chair for TLP graduation resolution
Already expressed this privately to both Dave and Rodric they are a good candidates to be chair and to not be afraid of the responsibilities. Is more of admin on point to keep us in sync with the board and mostly make sure we don’t miss the deadlines on managerial items Carlos On Wed, Jun 19, 2019 at 5:39 AM Rodric Rabbah wrote: > 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 tighten our processes in line with Apache > requirements. And he’s authored/submitted more than one report for our > poddling (something I haven’t done yet ;). > > -r > > > On Jun 19, 2019, at 6:14 AM, Bertrand Delacretaz > wrote: > > > >> On Wed, Jun 19, 2019 at 11:48 AM Justin Mclean > wrote: > >> ...Just a reminder, the chair is not a leadership role, but it it more > a secretarial and admin role... > > > > I was going to say that! > > > > In extreme cases the chair might have to make decisions on behalf of > > the PMC but in 19 years at Apache I don't remember this happening. > > > > The chair's role is really one of liaison with the Board, as Justin says. > > > > That doesn't mean it's not a cool role, but we shouldn't put a heavier > > burden on their shoulders than this! > > > > I support Rodric's nomination, and if there's a need note that we can > > also discuss and vote on this on the private list if preferred (as > > it's about people), and even use http://steve.apache.org/ for > > anonymous voting if people think this is required. I don't, but wanted > > to mention those options. > > > > Also, I think it's good to rotate the chair's role regularly, so that > > more people know how that works. So I'd suggest agreeing that this > > nomination is for one year initially. > > > > -Bertrand > -- Carlos Santana
Re: LICENSE file in repo
Thanks Craig for the notice I opened a Github issue https://github.com/apache/incubator-openwhisk-website/issues/385 Carlos On Fri, Jun 7, 2019 at 7:43 PM Craig Russell wrote: > Hi, > > Just noticed this LICENSE file > https://github.com/apache/incubator-openwhisk-website/blob/master/LICENSE.txt > that contains "Copyright 2015-2017 IBM Corporation". > > Surely this is a copy/paste error. > > Craig > > Craig L Russell > c...@apache.org > > -- Carlos Santana
Re: graduation related question
Ask Infra I know one of the Infra folks created a tool to get Github stats across all apache repos and I think also includes company affiliation. So the dashboard might be there and it might be a matter to filter to openwhisk repos. - Carlos Santana @csantanapr > On Jun 7, 2019, at 8:23 AM, Rodric Rabbah wrote: > > Justin M. has asked the following questions on the general list > relating to the graduation vote [1]: > > 1. Diversity of current committers and who they work for, and the same > for the proposed PMC (when that is decided). > 2. There seems to be a heavy reliance on communication on Slack. Is > this a barrier for people from other time zones from the main > developers or people who can’t work full time of the project? > > I have gathered all the contributors across our repos and the > histogramed contributions per contributor but I cannot automatically > determine their affiliations. I don't know how --- other projects have > done this (looking at the knative one in particular). Does anyone know > how to gather the affiliations automatically, or can someone recommend > a good way of gathering this information? > > In terms of the reliance on Slack - I think we've addressed this in > the past and clarified the modes of communication on our project web > page. I will point to that. If you are subscribed to general, please > feel free to chime in. > > -r > > [1] > https://lists.apache.org/thread.html/6dee587f87755cd9215e2627b7b6c254b13cee15c73622f89d0d7f91@%3Cgeneral.incubator.apache.org%3E
Re: [VOTE] Apache OpenWhisk graduation to Top Level Project
+1 Thanks to all contributors and users that took the project this far. Remember “community over code !” - Carlos Santana @csantanapr > On Jun 5, 2019, at 12:21 PM, Matt Hamann wrote: > > This is awesome! > > +1 for me. Let's graduate! > > > -Matt > matthew.ham...@gmail.com > > >> On Wed, Jun 5, 2019 at 11:16 AM Vincent S Hou wrote: >> >> Thank all the great efforts by OpenWhisk contributors. It is time for us >> to graduate. >> All the official modules, like openwhisk core, catalog, cli, runtimes, >> etc, have successfully gone through one or multiple releases under Apache >> as incubator. >> We have been familiar with all the legal processes of Apache. The modules >> have been mature enough to evolve as top level project. >> >> I vote: +1 Apache OpenWhisk should graduate. >> >> >> Best wishes. >> Vincent Hou (侯胜博) >> >> Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM >> Cloud >> >> Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: s...@us.ibm.com, >> Phone: +1(919)254-7182 >> Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United >> States >> >> -Rodric Rabbah wrote: - >> To: dev@openwhisk.apache.org >> From: Rodric Rabbah >> Date: 06/04/2019 05:26PM >> Subject: [EXTERNAL] [VOTE] Apache OpenWhisk graduation to Top Level Project >> >> Hi all, >> >> After a discussion among the Apache OpenWhisk community on the dev >> mailing list [1], we have completed all Trademark transfers, and we >> are now in the process of pruning the PMC roster, completing the >> podling status page and completing the project maturity model [2]. >> >> Apache OpenWhisk entered the incubator on November 23 2016. Since >> then, we have grown to be in the top 25 list of Apache projects by >> GitHub Stars at 4041, have 229 unique contributors across all our >> project repos, more than 2500 commits, and most importantly, our >> community has grown and is diversified beyond the initial founding >> contributors and organization. >> >> The project has come a long way in embracing The Apache Way, in no >> small part to our dedicated mentors and the community spirit that has >> grown along this journey. We are operating well as an Apache project >> and so we should take the next step. >> >> As such, I am calling a vote for Apache OpenWhisk to graduate to a top >> level project. If we agree that we should graduate to a top level >> project, the next step will be to draft a Resolution [3] for the PPMC >> and IPMC to vote upon. >> >> Please take a minute to vote on whether or not Apache OpenWhisk should >> graduate to a Top Level Project by responding with one of the >> following: >> >> [ ] +1 Apache OpenWhisk should graduate. >> [ ] +0 No opinion >> [ ] -1 Apache OpenWhisk should not graduate (please provide the reason) >> >> The VOTE is open for a minimum of 72 hours. Per Apache guidelines [4] >> I will notify the incubator mailing list that a community vote is >> under way. >> >> Thank you. >> -r >> (on behalf of the Apache OpenWhisk PPMC) >> >> [1] >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apache.org_thread.html_8daa3a05148f54ca82458777e2b2b5e25ba99d39dcf8ce7dd85d0188-40-253Cdev.openwhisk.apache.org-253E&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LUNmCHjmrhrkjp9ZF9fhwg&m=LFSSfkEdvRwfS3FkELMfDq_7zw2s2_TKfw_AXT9Dw2o&s=Gnn9hS-jCq6kxpUkV5YDjAvpeSZ2W9p1_XFdfvkjIa4&e= >> [2] >> https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_OPENWHISK_Project-2BMaturity-2BModel&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LUNmCHjmrhrkjp9ZF9fhwg&m=LFSSfkEdvRwfS3FkELMfDq_7zw2s2_TKfw_AXT9Dw2o&s=qtLpjM8ULRYiBYtOmML-UfW6byo2BgbC0Qaz9HSJubc&e= >> [3] >> https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_pages_viewpage.action-3FpageId-3D115526932&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LUNmCHjmrhrkjp9ZF9fhwg&m=LFSSfkEdvRwfS3FkELMfDq_7zw2s2_TKfw_AXT9Dw2o&s=YGyPOxDTHT-HjpQZb1_UMuX4dySHKqv0FH0AkPlJjpg&e= >> [4] >> https://urldefense.proofpoint.com/v2/url?u=https-3A__incubator.apache.org_guides_graduation.html-23community-5Fgraduation-5Fvote&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=LUNmCHjmrhrkjp9ZF9fhwg&m=LFSSfkEdvRwfS3FkELMfDq_7zw2s2_TKfw_AXT9Dw2o&s=oYAfkquuRCiMbdk0S-TF9_IG9jFe1OYc-qtxFDjBf2Q&e= >> >>
Re: [DISCUSS] - Release apigateway 0.10.0-incubating
+1 - Carlos Santana @csantanapr > On May 17, 2019, at 1:03 PM, David P Grove wrote: > > > I would like to start the release process for the apigateway module on > Monday. > > I propose using version number 0.10.0-incubating for this release. > > There are currently no open PRs against the repo. Anything coming soon > that we should wait for or any known blocking issues for a release? > > thanks, > > --dave
Re: [VOTE] Release Apache OpenWhisk Runtime Node.js (v0.14.0, rc1)
I didn’t see a [DISCUSS] thread before this [VOTE] thread This are the type of things that the board will be looking for graduation criteria to see if we follow the establish process in a consistent way with the community. [DISCUSS] thread allows to get buy in and to see if any one has an issue starting to cut an RC of something is almost ready and should be included or just wait for the next release, etc.. - Carlos Santana @csantanapr > On May 17, 2019, at 12:19 PM, James Thomas wrote: > > Hello, > > This is a call to vote on releasing version 1.14.0-incubating release > candidate rc1 of the following project module with artifacts > built from the Git repositories and commit IDs listed below. > > * Apache OpenWhisk Runtime Node.js: > 3bf5268https://github.com/apache/incubator-openwhisk-runtime-nodejs.git/commits/3bf5268 > > This release is comprised of source code distribution only. > > You can use this UNIX script to download the release and verify the > checklist > below:https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD > > Usage: > curl -s > "https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD"; > -o rcverify.sh > chmod +x rcverify.sh > rcverify.sh openwhisk-runtime-nodejs 'OpenWhisk Runtime Node.js' > 1.14.0-incubating rc1 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > Release verification checklist for reference: > [ ] Download links are valid. > [ ] Checksums and PGP signatures are valid. > [ ] DISCLAIMER is included. > [ ] Source code artifacts have correct names matching the current release. > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. > [ ] All files have license headers if necessary. > [ ] No compiled archives bundled in source archive. > > This majority vote is open for at least 72 hours. > > > -- > Regards, > James Thomas
Re: flatten structure of release directory
+1 - Carlos Santana @csantanapr > On Apr 23, 2019, at 4:48 PM, David P Grove wrote: > > > > I would like to flatten out our release directory structure so that the > most recent version of each artifact is simply available in our top-level > release directory. > > For unified releases, we would create a subdirectory (eg 19.05) and > replicate the specific individual components in that sub-directory (so it > is easy to manage the life-cycle of unified releases vs. individual > components). > > This is consistent with how at least a couple other projects manager their > release directory (see conversation about release dir structures > intermingled with the IPMC release voting at [1]). > > Lazy consensus, I'll wait 36 hours and then start reorganizing things and > submitting PRs to update the release-manager scripts. There will be a > window where we have some duplication of old & new structure while the > downloads page is being updated and scripts changed. > > thanks, > > --dave > > [1] > https://lists.apache.org/thread.html/328826d8d7a85be797211f05d40dd1c2d40b53546bca4678f0e741c3@%3Cgeneral.incubator.apache.org%3E
Re: Dropping supports for Docker Machine.
+1 I have used docker for Max for the longest time so far its good for doing dev and test locally. - Carlos Santana @csantanapr > On Apr 22, 2019, at 2:04 PM, Dascalita Dragos wrote: > > +1 as well. > >> On Mon, Apr 22, 2019 at 8:49 AM Rodric Rabbah wrote: >> >> +1 to remove old docker machine related docs. >> >> -r >> >>> On Mon, Apr 22, 2019 at 8:08 AM Dominic Kim wrote: >>> >>> Dear whiskers. >>> >>> I am working on upgrading Docker version in >>> https://github.com/apache/incubator-openwhisk/pull/4430. >>> And one thing comes up in my mind. >>> >>> These days, it seems Docker implicitly recommends to use Docker for mac( >>> https://docs.docker.com/docker-for-mac/install/) as they name it as >>> `Docker >>> Desktop for Mac` to express it is a standard way to use Docker in Mac. >>> And even they provide the guide to migrate from Docker-machine(Docker >>> Toolbox): https://docs.docker.com/docker-for-mac/docker-toolbox/ to >> Docker >>> For Mac. >>> Considering the relative easiness of setting up Docker for mac, it's not >>> surprising. (Though there are still fundamental limitations in Docker For >>> Mac.) >>> >>> With DockerForMacContainerFactory, it became easier to utilize Docker for >>> mac in mac hosts. >>> So I proposed to drop supports for Docker machine. >>> >>> Please share your opinion if you disagree with this. >>> If there's no objection, I will drop supports for Docker machine in >>> https://github.com/apache/incubator-openwhisk/pull/4430 >>> >>> Best regards >>> Dominic >>> >>
Re: Remove SDK commands from CLI?
Use the opportunity to clean the nginx routes, CLI was the only consumer - Carlos Santana @csantanapr > On Apr 22, 2019, at 2:02 PM, David P Grove wrote: > > > +1 to remove them. > > Does that also let us remove the routes from the nginx file in the main > repo [1]? > > --dave > > [1] > https://github.com/apache/incubator-openwhisk/blob/master/ansible/roles/nginx/templates/nginx.conf.j2#L140-#L146 > > James Thomas wrote on 04/18/2019 12:58:38 PM: >> >> Does anyone have any objections to removing the "SDK" command from the > wsk >> cli? >>
Re: Move default Node.js runtime to v10?
+1 to move to nodejs10 - Carlos Santana @csantanapr > On Apr 19, 2019, at 3:03 PM, Rodric Rabbah wrote: > > This is the catalog actions related issue that I opened at the time I > tried: https://github.com/apache/incubator-openwhisk-catalog/issues/294 > > Some of the actions which require packages available in the node6 runtime > fail in the newer node10 because we don't bundle any packages. So those > actions have to "zip" up their dependencies. The patch that was made was to > pin the catalog actions to node6 with the project deploy configuration. So > my assessment is that we can flip the default once again and should be OK > this time... but the catalog actions that are pinned to node6 will need to > be updated in a second phase. > > -r > > > >> On Thu, Apr 18, 2019 at 12:52 PM James Thomas wrote: >> >> On Wednesday's community call I asked about moving the default Nodejs >> version in the project to v10. >> >> Node.js 6 (which is the current default version) reaches "end of life" on >> April 30th according to https://github.com/nodejs/Release. Node.js 10 is >> the current LTS version and is supported until April 2021. >> >> Rodric mentioned this was started previously but ran into issues with the >> providers? >> https://github.com/apache/incubator-openwhisk/issues/4265 >> >> Does anyone have any issues with going forward with this work (once any >> issues have been resolved)? I see there is some work going on to fix the >> failures (https://github.com/apache/incubator-openwhisk/pull/4450) >> >> -- >> Regards, >> James Thomas >>
Re: Remove SDK commands from CLI?
+1 Folks should extending the current runtimes per language and not the docker sdk. For Swift it’s also ok to remove it as it’s not being maintained as no one is using it, and it doesn’t make sense to use it anymore since we have webactions and apigateway. - Carlos Santana @csantanapr On Apr 19, 2019, at 3:04 PM, Rodric Rabbah wrote: >> I didn't investigate the Swift SDK and wouldn't be sure if this even > works anymore > > There used to be a jenkins build for this but odds are it's rotted and we > should also remove it. > > -r
Re: Adding Runtime Rust to OpenWhisk
Forgot to mentioned in the mean time you can use the build or use the container image for Rust on IBM Cloud, shameless plug $ ibmcloud fn action update rust-demo func.rust --docker openwhisk/actionloop-rust-v1.34 --web true $ ibmcloud fn action get rust-demo --url https://us-south.functions.cloud.ibm.com/api/v1/web/r /default/rust-demo $ curl 'https://us-south.functions.cloud.ibm.com/api/v1/web/r /default/rust-demo?name=Carlos' Hello, Carlos $ hey 'https://us-south.functions.cloud.ibm.com/api/v1/web/ /default/rust-demo?name=Carlos' Summary: Total: 0.5985 secs Slowest: 0.3139 secs Fastest: 0.0492 secs Average: 0.1166 secs Requests/sec: 334.1532 gist has the code `func.rust` https://gist.github.com/csantanapr/be8948e1cd23bdb48f2b8ba14572a007 On Thu, Apr 11, 2019 at 11:20 PM Carlos Santana wrote: > Thanks +1 Michele and Roberto for your contributions for the Rust Runtime > [1] > > I just finished a PR that Michele started that enabled Travis CI [2] > > Now what's left if the integration to the deployment repos, tools, and docs > > I created an issue [3] with instructions and locations what needs to be > updated to add the alias runtime "rust:1.32" > > I added the labels "good first issue" and "help wanted" > > If anyone wants to help out go ahead > > [1] https://github.com/apache/incubator-openwhisk-runtime-rust > [2] https://travis-ci.org/apache/incubator-openwhisk-runtime-rust > [3] https://github.com/apache/incubator-openwhisk/issues/4443 > > -- > Carlos Santana > IBM STSM/Apache OpenWhisk PPMC > pache.org> > -- Carlos Santana
Adding Runtime Rust to OpenWhisk
Thanks +1 Michele and Roberto for your contributions for the Rust Runtime [1] I just finished a PR that Michele started that enabled Travis CI [2] Now what's left if the integration to the deployment repos, tools, and docs I created an issue [3] with instructions and locations what needs to be updated to add the alias runtime "rust:1.32" I added the labels "good first issue" and "help wanted" If anyone wants to help out go ahead [1] https://github.com/apache/incubator-openwhisk-runtime-rust [2] https://travis-ci.org/apache/incubator-openwhisk-runtime-rust [3] https://github.com/apache/incubator-openwhisk/issues/4443 -- Carlos Santana IBM STSM/Apache OpenWhisk PPMC pache.org>
Re: Please include rcverify logs inline in vote emails
Great idea Bertrand to have the digest of the script printed. +1 - Carlos Santana @csantanapr > On Apr 9, 2019, at 1:18 AM, Bertrand Delacretaz > wrote: > > Hi, > > Incubation mentor hat on - I've seen a few pastebin and similar links > to rcverify logs recently in VOTE threads. > > I think it's much better to include those logs inline so that they end > up in ASF mail archives (*). > > They are the kind of things that might be needed if for any reason we > want to to back to release votes later, and if logs are on external > systems there's no guarantee that they'll still be there. > > I contributed two minor changes to rcverify recently which output the > scripts digest as well as the digests of the verified source archives > - this makes it absolutely clear what was verified and with which > version of the script, so if we include that output in the mail > archives that's a solid record of verification and voting. > > -Bertrand
Re: [VOTE] Release Apache OpenWhisk Runtimes (v1.13.0-incubating, rc1)
+1 to all artifacts, I used the rcverify tool to assist with verification. Only 3 false positives found verifying license... failed (diff '/var/folders/q6/4ry_mh5s3cxbcb1r0jwh06x8gn/T/tmp.gGTx8uOo/incubator-openwhisk-runtime-go-1.13.0-incubating/LICENSE.txt' '/var/folders/q6/4ry_mh5s3cxbcb1r0jwh06x8gn/T/tmp.gGTx8uOo/LICENSE-2.0') scanning for binaries... failed (/var/folders/q6/4ry_mh5s3cxbcb1r0jwh06x8gn/T/tmp.gGTx8uOo/incubator-openwhisk-runtime-go-1.13.0-incubating/openwhisk/_test/pysample/exec) scanning for binaries... failed (/var/folders/q6/4ry_mh5s3cxbcb1r0jwh06x8gn/T/tmp.mM06ecli/incubator-openwhisk-runtime-php-1.13.0-incubating/core/php7.3Action/compile) Logs from rcverify: [1] [1] https://pastebin.com/2NG0Hg9F -- Carlos On Wed, Apr 3, 2019 at 11:31 AM Rodric Rabbah wrote: > Hi, > > This is a call to vote on releasing version 1.13.0-incubating release > candidate rc1 of the following 9 project modules with artifacts > built from the Git repositories and commit IDs listed below. > > * OpenWhisk Runtime Docker: > https://github.com/apache/incubator-openwhisk-runtime-docker.git > 48b8f4a239864edc178eb392a7eef287857a7a96 > > * OpenWhisk Runtime Dotnet: > https://github.com/apache/incubator-openwhisk-runtime-dotnet.git > 50df3bad2588c7b37425fad037ae3df73198ca22 > > * OpenWhisk Runtime Go: > https://github.com/apache/incubator-openwhisk-runtime-go.git > 31f0dd67885c17724718b16ba011baaed77dea16 > > * OpenWhisk Runtime Java: > https://github.com/apache/incubator-openwhisk-runtime-java.git > 9f27bab28905bdb66dc3526b5843eaaa6f9d026c > > * OpenWhisk Runtime Node.js: > https://github.com/apache/incubator-openwhisk-runtime-nodejs.git > c173d64cba124aeccc5c2c7f5db10bd18f5a03a9 > > * OpenWhisk Runtime PHP: > https://github.com/apache/incubator-openwhisk-runtime-php.git > 9c5d3d779425223488ca0f49100095736853f147 > > * OpenWhisk Runtime Python: > https://github.com/apache/incubator-openwhisk-runtime-python.git > aaeb2ff494e8785abd7a5fc0ba3d902752c47732 > > * OpenWhisk Runtime Ruby: > https://github.com/apache/incubator-openwhisk-runtime-ruby.git > b1afb74193646d599d363e765d755f2bb28f784c > > * OpenWhisk Runtime Swift: > https://github.com/apache/incubator-openwhisk-runtime-swift.git > 019024df95434fb3a4390ee0d88dea78af3fa0c9 > > This release comprises of source code distribution only. > > You can use this UNIX script to download the release and verify the > checklist below: > > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD > > Usage: > curl -s " > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD"; > -o rcverify.sh > chmod +x rcverify.sh > rcverify.sh openwhisk-runtime-docker 'OpenWhisk Runtime Docker' > 1.13.0-incubating > rcverify.sh openwhisk-runtime-dotnet 'OpenWhisk Runtime Dotnet' > 1.13.0-incubating > rcverify.sh openwhisk-runtime-go 'OpenWhisk Runtime Go' 1.13.0-incubating > rcverify.sh openwhisk-runtime-java 'OpenWhisk Runtime Java' > 1.13.0-incubating > rcverify.sh openwhisk-runtime-nodejs 'OpenWhisk Runtime Node.js' > 1.13.0-incubating > rcverify.sh openwhisk-runtime-php 'OpenWhisk Runtime PHP' 1.13.0-incubating > rcverify.sh openwhisk-runtime-python 'OpenWhisk Runtime Python' > 1.13.0-incubating > rcverify.sh openwhisk-runtime-ruby 'OpenWhisk Runtime Ruby' > 1.13.0-incubating > rcverify.sh openwhisk-runtime-swift 'OpenWhisk Runtime Swift' > 1.13.0-incubating > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > Release verification checklist for reference: > [ ] Download links are valid. > [ ] Checksums and PGP signatures are valid. > [ ] DISCLAIMER is included. > [ ] Source code artifacts have correct names matching the current > release. > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. > [ ] All files have license headers if necessary. > [ ] No compiled archives bundled in source archive. > > This majority vote is open for at least 72 hours. > > -r -- Carlos Santana
Re: Notes+Video posted from today's Tech. Int. call
Sorry I missed the meeting today, I'm out on bootcamp training all week, Just watched the meeting, I can't describe how excited and proud I am seeing topics related to ASF TLP process +1 Rodric R, A Tool to assist generating release artifacts +1 James T. A Tool to assist verifying the release artifacts +1 Vincent H, Finally an ASF CICD pipeline, no more manual testing or private/vendor PG testing to merge PRs I would moderate April 17, but I would be in Puerto Rico at the beach !! How about if Rodric gives away the Shirt, I will give out the Coffee Mug, if you host you will get 2 Swag Items ! -- Carlos On Wed, Apr 3, 2019 at 12:34 PM Rodric Rabbah wrote: > Thanks Matt - I fixed some typos. *If someone else would like to host the > next community call on April 17* --- *It’s really easy, as the moderator > you gather topics from the dev list and let the speakers do the hard work* > --- > *I will send that person their choice of Apache OpenWhisk shirt or coffee > mug. * > > *Shirts: *https://www.redbubble.com/shop/t-shirt/34185110?p=t-shirt > *Mugs etc*: > https://www.redbubble.com/people/comdev/works/34185110-apache-openwhisk > > -r > > > On Wed, Apr 3, 2019 at 12:05 PM Matt Rutkowski > wrote: > > > Thanks Tyson for hosting and Rodric for volunteering to be next up. > > > > Notes: > > > https://cwiki.apache.org/confluence/display/OPENWHISK/2019-04-03+OW+Tech+Int+-+Meeting+Notes > > Video: https://youtu.be/pw1BOpumZlQ > > > > Please feel to review/comment on Notes wiki. > > > > -mr > > > -- Carlos Santana
Re: release verification help
Using the website I would think it doesn’t count as verifying the artifacts. Just playing devils advocate here. Going to a website and selecting something from a Dropbox and see green checks don’t know if the useful for the person doing the voting. Maybe taking the code from the website or bash scripts and running locally seems more real. - Carlos Santana @csantanapr > On Mar 25, 2019, at 12:18 PM, James Thomas wrote: > > If anyone has any feature requests for http://apache.jamesthom.as please > open issues @ > https://github.com/jthomas/openwhisk-release-verification/issues > > PRs always welcome ;) It is just three (simple) Node.js openwhisk actions > powering the backend to do the verification. > > On Mon, 25 Mar 2019 at 15:05, Chetan Mehrotra > wrote: > >> Thanks Rodric and James for such tooling. This would greatly reduce the >> friction in voting for releases. >> >> In Apache Sling we have evolved the voting process over the time [1] which >> has helped in getting people to vote. >> >> Chetan Mehrotra >> [1] >> >> https://sling.apache.org/documentation/development/release-management.html#starting-the-vote >> >> >>> On Mon, Mar 25, 2019 at 8:19 PM Rodric Rabbah wrote: >>> >>> This email is in response to Chetan raising the following "May be we >>> automate some of the steps using a shell script similar to >>> >>> >> https://github.com/apache/sling-tooling-release/blob/master/check_staged_release.sh >>> " >>> in one of the recent release vote threads. >>> >>> Thanks to James Thomas, we have a web-based verification tool that >>> automates the release candidate checks so it's much easier now to verify >>> and vote on the releases. Source available at >>> https://github.com/jthomas/openwhisk-release-verification and you can >> try >>> it out here http://apache.jamesthom.as/ per comment on Slack earlier >>> today. >>> >>> And I opened a PR to add my bash scripts which I called `rcverify` here >>> https://github.com/apache/incubator-openwhisk-release/pull/254. This was >>> previously a gist which I'll delete if the PR is accepted (see [1] for >>> reference). >>> >>> [1] rcverify gist >>> https://gist.github.com/rabbah/0f9e138c9088758c30fe31f05b893041 >>> >>> -r >>> >> > > > -- > Regards, > James Thomas
Re: Added a "Security" page to website with simple, OW-specific instructions for vuln. reporting
It can exist Please let’s not create it - Carlos Santana @csantanapr > On Mar 21, 2019, at 8:58 AM, Bertrand Delacretaz > wrote: > > Hi, > >> On Thu, Mar 21, 2019 at 10:03 AM Carlos Santana wrote: >> ... >> -1 to have yet another ML list secur...@openwhisk.apache.org ... > > FWIW I was not saying that that list should exist, just that it *can* > exist if desired. > > -Bertrand
Re: Added a "Security" page to website with simple, OW-specific instructions for vuln. reporting
Yep that’s why I said let’s use the already 2 mailing lists secur...@apache.org and priv...@openwhisk.org Let’s not create a 3rd - Carlos Santana @csantanapr > On Mar 21, 2019, at 8:54 AM, Matt Sicker wrote: > > Security mailing lists should also be private and only accessible to PMC > members (and ASF members). > >> On Thu, Mar 21, 2019 at 04:03, Carlos Santana wrote: >> >> That’s fine to have a page and security mailing list. >> >> Who is from the PPMC is going to monitor the security@ mailing list? >> >> I’m already subscribe to private@ >> >> I would not want sensitive topics and reports to be discuss in this >> security ML is people anyone is allowed to be subscribe. >> >> The ASF process still need to be followed anyway and any reports we would >> need to loop in secur...@apache.org anyway >> >> I bet people would email by mistake secur...@openwhisk.apache.org with >> sensitive data when they should have use secur...@apache.org and also bet >> we will be explaining multiple time when to use each ML list. >> >> I we have such ML list I certainly will not be using it or subscribing and >> expect any serious reports and findings to find their way to private@ >> >> Is their are users that security questions on how to do something or >> someone sharing best practice for security they can certainly use the dev@ >> list we have today >> >> +1 to have a security page >> -1 to have yet another ML list secur...@openwhisk.apache.org >> >> - Carlos Santana >> @csantanapr >> >>> On Mar 21, 2019, at 4:28 AM, Bertrand Delacretaz >> wrote: >>> >>> Hi, >>> >>>> On Wed, Mar 20, 2019 at 10:43 PM Carlos Santana >> wrote: >>>> For security reports, ASF already have a process let's not improvise.. >>> >>> Agreed but it's fine for projects to have their own security page, as >>> long as the ASF process is followed. >>> >>>> ... Reported should send email to secur...@apache.org ... >>> >>> It's also ok for projects to have their own security@ list, see >>> https://sling.apache.org/project-information/security.html for an >>> example. >>> >>> -Bertrand >> > -- > Matt Sicker
Re: Added a "Security" page to website with simple, OW-specific instructions for vuln. reporting
That’s fine to have a page and security mailing list. Who is from the PPMC is going to monitor the security@ mailing list? I’m already subscribe to private@ I would not want sensitive topics and reports to be discuss in this security ML is people anyone is allowed to be subscribe. The ASF process still need to be followed anyway and any reports we would need to loop in secur...@apache.org anyway I bet people would email by mistake secur...@openwhisk.apache.org with sensitive data when they should have use secur...@apache.org and also bet we will be explaining multiple time when to use each ML list. I we have such ML list I certainly will not be using it or subscribing and expect any serious reports and findings to find their way to private@ Is their are users that security questions on how to do something or someone sharing best practice for security they can certainly use the dev@ list we have today +1 to have a security page -1 to have yet another ML list secur...@openwhisk.apache.org - Carlos Santana @csantanapr > On Mar 21, 2019, at 4:28 AM, Bertrand Delacretaz > wrote: > > Hi, > >> On Wed, Mar 20, 2019 at 10:43 PM Carlos Santana wrote: >> For security reports, ASF already have a process let's not improvise.. > > Agreed but it's fine for projects to have their own security page, as > long as the ASF process is followed. > >> ... Reported should send email to secur...@apache.org ... > > It's also ok for projects to have their own security@ list, see > https://sling.apache.org/project-information/security.html for an > example. > > -Bertrand
Re: Added a "Security" page to website with simple, OW-specific instructions for vuln. reporting
For security reports, ASF already have a process let's not improvise Reported should send email to secur...@apache.org The process explains how to handle artifacts to reproduce the vulnerability Security will inform the PMC private list and forward the email --cs On Wed, Mar 20, 2019 at 3:09 PM Matt Sicker wrote: > On Wed, 20 Mar 2019 at 12:52, Rodric Rabbah wrote: > > > > We went through a case last year where a company reported a vulnerability > > to us through security@a.o and we cc'ed them on all the communications. > I > > think that worked well. Are you suggesting we have our own project > security > > mailing list that goes to both our private list and security@a.o? > > Essentially, yes. This is more of a concern with larger projects (like > this one) which are more likely to have to deal with security issues > more often. It's essentially a way to segregate security traffic into > its own mailing list rather than using up private@ for everything > (which can get confusing depending on how much activity there is). > > > -- > Matt Sicker > -- Carlos Santana
Re: [VOTE] Release Apache OpenWhisk Client JS (incubating) 3.19.0
+1 I was able to verify the release artifacts for client-js 3.19 rc1 [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 headers if necessary. [x] No compiled archives bundled in source archive. On Mon, Mar 18, 2019 at 5:50 PM Dave Grove wrote: > I vote +1 Release as Apache OpenWhisk 3.19.0-incubating: OpenWhisk Client > JS > > I verified: > [ 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 repo. > [ X ] All files have license headers if necessary. > [ X ] No compiled archives bundled in source archive. > > --dave > > On 2019/03/18 18:14:39, James Thomas wrote: > > This is to call for a vote for the release of Apache OpenWhisk Client JS > > (incubating) 3.19.0 > > > > List of JIRA ticket(s) resolved for this release can be found at > > > > https://issues.apache.org/jira/browse/INCUBATOR-232. > > > > This release comprises of source code distribution only. There is only > one > > module within this release number 3.19.0. The artifact were built from > the > > following Git commit IDs: > > > >- > > > >openwhisk-client-js: 726b982, > > > > The source code artifact of openwhisk client js can be found at: > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-3.19.0-incubating-rc1/openwhisk-client-js-3.19.0-incubating-sources.tar.gz > > > > The SHA-512 checksum for the artifact of openwhisk client js is > > openwhisk-client-js-3.19.0-incubating-sources.tar.gz: 8D8FE6C5 48F5FE72 > > F5C5CC2E 1539416F 84B18BB7 D6A0075B 50CAFC22 55BFA27E C8E60B9D 6660E203 > > 72CEB667 EAE91474 DAB16D8B 764B5141 8B7595DE 78CBA217 > > > > which can can be found via: > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-3.19.0-incubating-rc1/openwhisk-client-js-3.19.0-incubating-sources.tar.gz.sha512 > > > > The signature of the artifact of openwhisk client js can be found via: > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-3.19.0-incubating-rc1/openwhisk-client-js-3.19.0-incubating-sources.tar.gz.asc > > > > KEYS file is available here: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/KEYS > > > > Please vote on releasing this package as Apache OpenWhisk > > 3.19.0-incubating: OpenWhisk Client JS > > > > The vote will be open for at least 72 hours. > > > > [ ] +1 Release as Apache OpenWhisk 3.19.0-incubating: OpenWhisk Client JS > > > > [ ] +0 no opinion > > > > [ ] -1 Do not release and the reason > > > > Checklist for reference: > > > > [ ] Download links are valid. > > > > [ ] Checksums and PGP signatures are valid. > > > > [ ] DISCLAIMER is included. > > > > [ ] Source code artifacts have correct names matching the current > release. > > > > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repo. > > > > [ ] All files have license headers if necessary. > > > > [ ] No compiled archives bundled in source archive. > > > > Thank you very much. > > > > -- > > Regards, > > James Thomas > > > -- Carlos Santana
Re: [VOTE] release Apache OpenWhisk CLI 0.10.0-incubating
+1 I was able to verify the release artifacts and build the wsk binary [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 headers if necessary. [x] No compiled archives bundled in source archive. On Sat, Mar 16, 2019 at 2:57 PM David P Grove wrote: > > > This is a call to vote on releasing version 0.10.0-incubating of the Apache > OpenWhisk CLI. > > The Apache OpenWhisk CLI provides the command line tooling for interacting > with Apache OpenWhisk. > > This release comprises of source code distribution only. There are three > modules (git repos) included in this CLI release. All artifacts were built > by PR#249 in the openwhisk-release repo from the following Git commit IDs: > * openwhisk-cli: eaf64ae > * openwhisk-client-go: 4286a82 > * openwhisk-wskdeploy: 7d79fd7 > > openwhisk-cli (55BEEB6D CDF621AB 7AA6098A 5DBCA55E 6D7E3B0C A3DAA7DF > B44103F8 CE30ACC9 13411ECC BFF18519 3E142EC3 D27AA081 E1D47F63 14E9E708 > 90646EC7 C13756D6) > src.tar.gz: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-cli-0.10.0-incubating-sources.tar.gz > sha512 checksum: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-cli-0.10.0-incubating-sources.tar.gz.sha512 > signature: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-cli-0.10.0-incubating-sources.tar.gz.asc > > openwhisk-client-go (068DBC87 533905DB D0089CAE 74FD0B91 109992D8 D843CAA4 > 01EA87B6 9CDC9550 6D555655 4679FF36 7A52414E DCC59126 E558085D 3E960DEB > 18804581 6B2FA019) > src.tar.gz: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-client-go-0.10.0-incubating-sources.tar.gz > sha512 checksum: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-client-go-0.10.0-incubating-sources.tar.gz.sha512 > signature: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-client-go-0.10.0-incubating-sources.tar.gz.asc > > openwhisk-wskdeploy (412B1E09 129F2884 A1D4E9DE 0A979B47 55A54FC5 61E1D328 > 325E8A12 AE504779 A2350B9F 4185582F 7782EEA5 AE9018CD 52E4AA4C 484B5211 > AA449B4B 9F9E2432) > src.tar.gz: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-wskdeploy-0.10.0-incubating-sources.tar.gz > sha512 checksum: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-wskdeploy-0.10.0-incubating-sources.tar.gz.sha512 > signature: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-wskdeploy-0.10.0-incubating-sources.tar.gz.asc > > All release artifacts were signed with key 72AF0CC22C4CF320. > KEYS file is available here: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/KEYS > > How to verify the artifacts can be found at: > https://cwiki.apache.org/confluence/display/OPENWHISK/How+to+verify+the > +release+checklist+and+vote+on+OpenWhisk+modules+under+Apache > > Please vote on releasing the three components of Apache OpenWhisk CLI > 0.10.0-incubating as described above. > > The vote will be open for at least 72 hours. > [ ] +1 Release as Apache OpenWhisk 0.10.0-incubating: openwhisk-cli, > openwhisk-client-go, openwhisk-wskdeploy > [ ] +0 no opinion > [ ] -1 Do not release and the reason > > Checklist for reference: > [ ] Download links are valid. > [ ] Checksums and PGP signatures are valid. > [ ] DISCLAIMER is included. > [ ] Source code artifacts have correct names matching the current release. > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. > [ ] All files have license headers if necessary. > [ ] No compiled archives bundled in source archive. > > regards, > > --dave > -- Carlos Santana
Re: [DISCUSS] Release event providers
+1 - Carlos Santana @csantanapr > On Mar 16, 2019, at 3:54 PM, David P Grove wrote: > > > > As part of the unified release, we will be doing the first Apache release > of the OpenWhisk event providers (openwhisk-package-alarms, > openwhisk-package-cloudant, openwhisk-package-kafka). > > I've taken a look at the pending PRs, and I think only the ones I just > submitted to add DISCLAIMER.txt, etc. are release blocking. Please comment > if you disagree (or want to get in any other changes before a release). > > These components all have had non-Apache releases in the past, and thus > have a history of version numbering that we need to not confuse. > > If we want to stick with the minimal increment under semvar, the initial > Apache releases would be numbered: >alarms: 1.12.5 >cloudant: 1.9.4 >kafka: 1.4.22 > > We could also decide to do a "major" bump to allow a clean Apache vs. > non-Apache break in the version numbers. In other words, we would make > this the 2.0.0 release of all three event provider modules. > > My strong inclination is to go with 2.0.0, but I would like to hear > thoughts from others. Assuming there are no technical blockers, I would > like to initiate a formal release process for these three components early > next week. > > thanks, > > --dave
Re: [DISCUSS] release openwhisk runtimes
At this point I’m ok with what ever plan as long we have a continuous train of releases and becomes an easy and habit process the nodejs runtime doesn’t have a hard dependency and doesn’t need to wait for client-js 3.19.0 I’m ok if Rodric wants to continue with plan release all the runtimes now. I can signup to do runtimes next release after this wave, for the next wave of runtimes I can pick up any changes including nodejs with new client-js and rust if it’s ready. - Carlos Santana @csantanapr > On Mar 16, 2019, at 8:54 AM, Dave Grove wrote: > > I think we will want to get openwhisk-client-js 3.19.0 into the > runtime-nodejs release. So we need to wait the 2x 72 hours for that release > process to go through before we can start a release runtime-nodejs. > > Rather than delay the rest of the runtimes for another week+, I think we > could break the runtimes into two waves and push ahead with most of the rest > of them. > > Opinions? Rodric, will you have time to manage a first wave of runtime > releases next week? > > --dave >
Re: OpenWhisk Apps on Knative
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
Re: [DISCUSS] release openwhisk CLI
+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?
tialization 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
>
--
Carlos Santana
Re: [DISCUSS] release openwhisk-client-js
+1 I think it make sense to make the version "3.19.0" Then after release pass, a convenient package can be posted to npm with a version that correlates with the previous one. We did the similar for runtimes -- Carlos On Thu, Mar 14, 2019 at 1:06 PM James Thomas wrote: > Hello whiskers. > > We want to do the first official apache release of the openwhisk-client-js > project. The project is very stable and doesn't change often, but we've now > had a few important PRs merge in the past month. > > https://github.com/apache/incubator-openwhisk-client-js/pull/147 > https://github.com/apache/incubator-openwhisk-client-js/pull/151 > https://github.com/apache/incubator-openwhisk-client-js/pull/152 > > I've opened a new PR to add the missing files necessary for a release. > https://github.com/apache/incubator-openwhisk-client-js/pull/154 > > Does anyone want to do anything before I cut the release? > > Speak now or forever hold your peace (until the next release...) > > -- > Regards, > James Thomas > -- Carlos Santana
Re: OpenWhisk Apps on Knative
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 will be able to have a > thinner OpenWhisk-specific layer. I don't think we should expect every > runtime system design decision we have made to hold constant as technology > evolves around us. But the system-level OpenWhisk runtime could completely > change without any disruption to the user-level programming model and > developer tooling. For example, IBM Cloud Functions switched from a > "classic" ansible-driven VM-based deployment to a Kubernetes-based > deployment of OpenWhisk in the middle of 2018. None of our customers > noticed or cared (from their perspective nothing changed and all their > existing programs still run just fine). > > Finally, the focus of this project is where the community takes it. We can > even go multiple directions simultaneously. That's how open source works :) > > > --dave
Re: Updating the docker version to the latest one
+1 - Carlos Santana @csantanapr > On Mar 13, 2019, at 5:39 AM, Dominic Kim wrote: > > Hi, > > Recently CVE in docker engine is reported. > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736 > > So I created this issue and want to start working on it. > https://github.com/apache/incubator-openwhisk/issues/4336 > > But I want to figure out if anybody would be broken by this first. > Since it would include changes in both the server and client, it could be a > breaking change. > > I am thinking of updating it to the latest version and looking for feedback. > The current latest version is 18.09.3 > > Best regards > Dominic
Re: Current status of Jenkins setup for OpenWhisk
Welcome back Vicent - Carlos Santana @csantanapr > On Mar 12, 2019, at 11:30 AM, Matt Rutkowski wrote: > > Welcome back Vincent! It is good to have your skill back to help the > project with multi-node staging! > > -Matt > > > > > > From: "Vincent S Hou" > To: dev@openwhisk.apache.org > Date: 03/12/2019 10:01 AM > Subject:Current status of Jenkins setup for OpenWhisk > > > > Hi OpenWhiskers, > > I have come back from my holiday last week, and officially start to work > this week. During the past few days, I have made some progress in terms of > getting the access to openwhisk VMs and Apache Jenkins. > > Current state: > My apache ID has granted root access to the VMs: > openwhisk-vm1-he-de.apache.org > openwhisk-vm2-he-de.apache.org > openwhisk-vm3-he-de.apache.org > > I am now able to use the command ssh openwhisk-vm1-he-de.apache.org -l apache ID> to access the VM via terminal. > > My Apache ID has been added into the hudson-jobadmin group: > https://urldefense.proofpoint.com/v2/url?u=https-3A__whimsy.apache.org_roster_group_hudson-2Djobadmin&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw&m=-e-Ty-ohYS2xvL-9BVb-Z5W25ZsmOFwxplXIE469IFU&s=LznFkcRufXe67pIkVWjsvbfexSapnQJZpVYWZIm_QbM&e= > , which means I have earned the admin access to Apache Jenkins environment > at > https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw&m=-e-Ty-ohYS2xvL-9BVb-Z5W25ZsmOFwxplXIE469IFU&s=DlXo7_7di99K3NIwYr-x16N_CGcSPBAmAK92cP5S5fw&e= > . I should be able to create build or pipeline. > > I have granted the user "jenkins" root access within three of these VMs. > > Work items to do: > Next, I will configured the ssh access among three of these VMs, since I > plan to use one VM as the master, launching all the services except > invoker, and the other two as designated nodes to launch invoker service. > > Travis CI has already tested the case, when all the openwhisk services are > installed on one server. I plan to use Jenkins to test openwhisk installed > in a distributed way. > > Welcome to chime in and add your comments, if you have any idea about how > to use these three VMs for OpenWhisk. > > Thank you. > > Best wishes. > Vincent Hou (侯胜博) > > Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM > Cloud > > Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: s...@us.ibm.com, > Phone: +1(919)254-7182 > Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United > States > > > > > >
Re: Use Gauge metric instead of Histogram where applicable PR #4327
Thanks Chettam for fixing we saw this problem in prod. +1 On Fri, Mar 8, 2019 at 8:22 PM Rodric Rabbah wrote: > Chetan opened this PR > https://github.com/apache/incubator-openwhisk/pull/4327 which fixes an > issue with using historgrams for some metrics where gauges should be used > instead. There was a brief exchange on slack [1, 2] in favor of this > change. > > The PR has two commits, the first I think is fine and non-breaking. The > second change as Chetan notes is "sort of a breaking change" but I agree > which him in that the existing histograms do not look very useful in some > cases. > > If you're interested in this PR please have a look and comment, otherwise > will apply lazy consensus to merge it. > > -r > > [1] > > https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552009389150600?thread_ts=1551982869.141200&cid=C3TPCAQG1 > > [2] > > https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1552014636150800?thread_ts=1551982869.141200&cid=C3TPCAQG1 > -- Carlos Santana
Re: Rust for OpenWhisk
Ha good point I didn’t know much about HasMap was only using jsonValue to
Marshall and unmarshall objects since that what I learn for initial tutorials
If the the value of the hashmap is jsonValue then it might ok, I just need to
see some examples of how to unmarshall and Marshall those HashMaps inside my
action code.
- Carlos Santana
@csantanapr
> On Mar 7, 2019, at 7:11 AM, Rodric Rabbah wrote:
>
> JsonValue is an enum that encompases any valid JSON value
> https://docs.rs/json/0.2.1/json/enum.JsonValue.html.
> So that signature is too generic IMO. The input should be a JSON object, so
> the dictionary has keys of type String and values of type JsonValue.
>
> For the result, perhaps using JsonResult instead is better
> https://docs.rs/json/0.2.1/json/type.JsonResult.html.
>
> -r
>
>> On Thu, Mar 7, 2019 at 6:56 AM Carlos Santana wrote:
>>
>> Hi Michele
>>
>> Thanks for all the work on helping on this I know you are very busy +1
>>
>> I wanted to discuss the main method signature and open a github issue but
>> issues are not enable in the rust repo [1]
>>
>> Did you open an INFRA ticket for infra people to configure and enable
>> Github Issues? Please share the link I want ping them on Slack
>>
>> I was trying to debate on the usage of HashMap vs. jsonValue for the main
>> handler method
>>
>> For example:
>> fn handler_b(param: JsonValue) -> Result {
>>let name = param["name"].as_str().unwrap();
>>if name == "" {
>>error!("Empty name in request");
>>return Err(serde_json::from_str(r#"{"message": "Empty name in
>> param",}"#).unwrap());
>>} else {
>>println!("The name is {}", name);
>>let json_str = r#"{"body": "Hello World",}"#;
>>let res = serde_json::from_str(json_str).unwrap();
>>return Ok(res);
>>}
>> }
>>
>> You can see the whole program in this gist [2] where I was playing with
>> different Types
>>
>> I also checked on how AWS Rust handler signature looked
>>
>> [1] https://github.com/apache/incubator-openwhisk-runtime-rust
>> [2]
>>
>> https://gist.github.com/csantanapr/50cae6a62b27192f32b1bd4801d8d7c4#file-rust_playground-rs-L40
>> [3] https://aws.amazon.com/blogs/opensource/rust-runtime-for-aws-lambda/
>>
>>
>>
>> On Wed, Mar 6, 2019 at 5:58 AM Michele Sciabarra
>> wrote:
>>
>>> Thanks to the effort of Roberto Diaz who provided the actionloop in rust,
>>> I built the Rust for OpenWhisk (ActionLoop powered, of course):
>>>
>>>
>>> ```
>>> $ wsk action create hello-rust src/lib.rs --docker
>>> actionloop/actionloop-rust-v1.32
>>> ok: created action hello-rust
>>> $ wsk action invoke hello-rust -r
>>> {
>>>"greeting": "Hello, stranger"
>>> }
>>> $ wsk action invoke hello-rust -r -p name Mike
>>> {
>>>"greeting": "Hello, Mike"
>>> }
>>> ```
>>>
>>> This is the rust hello world (probably it can be written better I am an
>>> absolute beginner in Rust...):
>>>
>>> ```
>>> extern crate serde_json;
>>>
>>> use std::collections::HashMap;
>>> use serde_json::Value;
>>>
>>> pub fn main(args: HashMap) -> HashMap {
>>>let name_opt = args.get("name");
>>>let name = if name_opt.is_some() {
>>>name_opt.unwrap().as_str().unwrap()
>>>} else {
>>>"stranger"
>>>};
>>>let mut out = HashMap::new();
>>>out.insert("greeting".to_string(), Value::String(format!("Hello, {}",
>>> name)));
>>>out
>>> }
>>> ```
>>>
>>> Now we should add all the tests and provide the runtimes for integrating
>>> into OpenWhisk...
>>>
>>> --
>>> Michele Sciabarra
>>> mich...@sciabarra.com
>>>
>>
>>
>> --
>> Carlos Santana
>>
>>
Re: Tech Interchange meeting Notes & Video posted
By the way all those links are also in the CWiki Meeting Notes for anyone
that wants to catched up async
https://cwiki.apache.org/confluence/display/OPENWHISK/2019-03-06+OW+Tech+Interchange+-+Meeting+Notes
On Thu, Mar 7, 2019 at 6:55 AM Rodric Rabbah wrote:
> Thanks Bertrand for the suggestion. I've updated the doc and the links are
> below for convenience as well.
>
> PRs reviewed/discussed:
> - Remove API key by default (“ready”)
> https://github.com/apache/incubator-openwhisk/pull/4284
> - Hadoop/YARN support (merged) New contributor Sam Hjelmfelt
> https://github.com/apache/incubator-openwhisk/pull/4129
> - Better multi-region support (review)
> https://github.com/apache/incubator-openwhisk/pull/4314
> - Karate (reviewed, what’s next?)
> https://github.com/apache/incubator-openwhisk/pull/3956
>
> -r
>
>
> On Thu, Mar 7, 2019 at 5:19 AM Bertrand Delacretaz >
> wrote:
>
> > On Wed, Mar 6, 2019 at 7:17 PM Rodric Rabbah wrote:
> > > ...Amazing that you can capture all that, everytime!...
> >
> > Indeed, thanks for this!
> >
> > And still I have a small request: it would be great to include links
> > to the PRs and tickets being discussed ("speak in URLs") so that
> > people who do not attend those meetings can follow. Maybe that's
> > something that the presenters can add after the fact, to avoid
> > overloading whoever takes notes.
> >
> > This goes back to the earlier discussions about enabling asynchronous
> > collaboration and putting casual contributors on an equal footing with
> > those who work full-time on the project, which is IMO an important
> > step towards graduating this project.
> >
> > -Bertrand
> >
>
--
Carlos Santana
Re: Rust for OpenWhisk
You can use this INFRA ticket [1] as template to open a new issue to setup
rust Github repo
[1] https://issues.apache.org/jira/browse/INFRA-16770
On Thu, Mar 7, 2019 at 6:55 AM Carlos Santana wrote:
> Hi Michele
>
>Thanks for all the work on helping on this I know you are very busy +1
>
> I wanted to discuss the main method signature and open a github issue but
> issues are not enable in the rust repo [1]
>
> Did you open an INFRA ticket for infra people to configure and enable
> Github Issues? Please share the link I want ping them on Slack
>
> I was trying to debate on the usage of HashMap vs. jsonValue for the main
> handler method
>
> For example:
> fn handler_b(param: JsonValue) -> Result {
> let name = param["name"].as_str().unwrap();
> if name == "" {
> error!("Empty name in request");
> return Err(serde_json::from_str(r#"{"message": "Empty name in
> param",}"#).unwrap());
> } else {
> println!("The name is {}", name);
> let json_str = r#"{"body": "Hello World",}"#;
> let res = serde_json::from_str(json_str).unwrap();
> return Ok(res);
> }
> }
>
> You can see the whole program in this gist [2] where I was playing with
> different Types
>
> I also checked on how AWS Rust handler signature looked
>
> [1] https://github.com/apache/incubator-openwhisk-runtime-rust
> [2]
> https://gist.github.com/csantanapr/50cae6a62b27192f32b1bd4801d8d7c4#file-rust_playground-rs-L40
> [3] https://aws.amazon.com/blogs/opensource/rust-runtime-for-aws-lambda/
>
>
>
> On Wed, Mar 6, 2019 at 5:58 AM Michele Sciabarra
> wrote:
>
>> Thanks to the effort of Roberto Diaz who provided the actionloop in rust,
>> I built the Rust for OpenWhisk (ActionLoop powered, of course):
>>
>>
>> ```
>> $ wsk action create hello-rust src/lib.rs --docker
>> actionloop/actionloop-rust-v1.32
>> ok: created action hello-rust
>> $ wsk action invoke hello-rust -r
>> {
>> "greeting": "Hello, stranger"
>> }
>> $ wsk action invoke hello-rust -r -p name Mike
>> {
>> "greeting": "Hello, Mike"
>> }
>> ```
>>
>> This is the rust hello world (probably it can be written better I am an
>> absolute beginner in Rust...):
>>
>> ```
>> extern crate serde_json;
>>
>> use std::collections::HashMap;
>> use serde_json::Value;
>>
>> pub fn main(args: HashMap) -> HashMap {
>> let name_opt = args.get("name");
>> let name = if name_opt.is_some() {
>> name_opt.unwrap().as_str().unwrap()
>> } else {
>> "stranger"
>> };
>> let mut out = HashMap::new();
>> out.insert("greeting".to_string(), Value::String(format!("Hello, {}",
>> name)));
>> out
>> }
>> ```
>>
>> Now we should add all the tests and provide the runtimes for integrating
>> into OpenWhisk...
>>
>> --
>> Michele Sciabarra
>> mich...@sciabarra.com
>>
>
>
> --
> Carlos Santana
>
>
--
Carlos Santana
Re: Rust for OpenWhisk
Hi Michele
Thanks for all the work on helping on this I know you are very busy +1
I wanted to discuss the main method signature and open a github issue but
issues are not enable in the rust repo [1]
Did you open an INFRA ticket for infra people to configure and enable
Github Issues? Please share the link I want ping them on Slack
I was trying to debate on the usage of HashMap vs. jsonValue for the main
handler method
For example:
fn handler_b(param: JsonValue) -> Result {
let name = param["name"].as_str().unwrap();
if name == "" {
error!("Empty name in request");
return Err(serde_json::from_str(r#"{"message": "Empty name in
param",}"#).unwrap());
} else {
println!("The name is {}", name);
let json_str = r#"{"body": "Hello World",}"#;
let res = serde_json::from_str(json_str).unwrap();
return Ok(res);
}
}
You can see the whole program in this gist [2] where I was playing with
different Types
I also checked on how AWS Rust handler signature looked
[1] https://github.com/apache/incubator-openwhisk-runtime-rust
[2]
https://gist.github.com/csantanapr/50cae6a62b27192f32b1bd4801d8d7c4#file-rust_playground-rs-L40
[3] https://aws.amazon.com/blogs/opensource/rust-runtime-for-aws-lambda/
On Wed, Mar 6, 2019 at 5:58 AM Michele Sciabarra
wrote:
> Thanks to the effort of Roberto Diaz who provided the actionloop in rust,
> I built the Rust for OpenWhisk (ActionLoop powered, of course):
>
>
> ```
> $ wsk action create hello-rust src/lib.rs --docker
> actionloop/actionloop-rust-v1.32
> ok: created action hello-rust
> $ wsk action invoke hello-rust -r
> {
> "greeting": "Hello, stranger"
> }
> $ wsk action invoke hello-rust -r -p name Mike
> {
> "greeting": "Hello, Mike"
> }
> ```
>
> This is the rust hello world (probably it can be written better I am an
> absolute beginner in Rust...):
>
> ```
> extern crate serde_json;
>
> use std::collections::HashMap;
> use serde_json::Value;
>
> pub fn main(args: HashMap) -> HashMap {
> let name_opt = args.get("name");
> let name = if name_opt.is_some() {
> name_opt.unwrap().as_str().unwrap()
> } else {
> "stranger"
> };
> let mut out = HashMap::new();
> out.insert("greeting".to_string(), Value::String(format!("Hello, {}",
> name)));
> out
> }
> ```
>
> Now we should add all the tests and provide the runtimes for integrating
> into OpenWhisk...
>
> --
> Michele Sciabarra
> mich...@sciabarra.com
>
--
Carlos Santana
Re: feedback on using Apache OpenWhisk name
I agree with Bertrand and having a links to a mailing list thread and Github issue helps the next time someone requests to the (P)PMC to review a proposal to use the mark - Carlos Santana @csantanapr > On Mar 7, 2019, at 5:15 AM, Bertrand Delacretaz > wrote: > > Hi, > >> On Wed, Mar 6, 2019 at 6:19 PM Matt Rutkowski wrote: >> ...In my experience, they get very agitated when Apache project names are >> used outside of Apache owned contexts > > It shouldn't be "they" - this (P)PMC should be careful about how its > marks are used, in order to demonstrate that it's protecting them > actively. > > Failure to do so might make it much harder to fight violations should > they appear...being unable to challenge someone using the OpenWhisk > name in a confusing and possibly damaging way would be bad. > > An obvious example nowadays is someone distributing a Docker image or > other binary named "OpenWhisk" and doing bad things...protecting our > marks means making sure such things cannot be confused with this > project's releases. > > The (P)PMC just needs to clearly define how its marks can be used, > based on the ASF recommendations, and collecting examples like > Rodric's is good for that. > > -Bertrand
Re: feedback on using Apache OpenWhisk name
+1 use apache.openwhisk.org - Carlos Santana @csantanapr > On Mar 6, 2019, at 4:40 AM, Bertrand Delacretaz > wrote: > >> On Wed, Mar 6, 2019 at 9:33 AM Carlos Santana wrote: >> >> ...they don’t use the https url to the Apache >> openwhisk website > > Good point, IMO the only URL to advertise is openwhisk.apache.org - > http or https is an implementation detail (and all redirects are in > place AFAICS) but "apache" is important. > > -Bertrand
Re: feedback on using Apache OpenWhisk name
I don’t see anything wrong, and it looks like fair use of “Powered by ...” I found a similar thing on Digital Ocean market place [1] 😉 using the “Power by Apache OpenWhisk” but they don’t use the https url to the Apache openwhisk website. [1] https://marketplace.digitalocean.com/apps/nimbella-lite — Carlos On Tue, Mar 5, 2019 at 11:23 AM Rodric Rabbah wrote: > Recently, an opportunity arose to provide a *virtual machine image* as a > one click deployment of OpenWhisk to appear in the market place for a cloud > provider. I reviewed the trademark details ( > https://www.apache.org/foundation/marks/faq) and concluded that the name > of > the image can at best refer to OpenWhisk using the “Powered by” approach… > which was too long for the formatting, so I opted for a different naming > approach (that omits Apache OpenWhisk entirely in the name) and used > the *Powered > by* language in the detailed description (with links to our project page). > > I created the following issue > https://github.com/apache/incubator-openwhisk/issues/4324 with more > details > and to solicit additional feedback that can help promote Apache/OpenWhisk, > and also document the text as a example for future use by others. > > I will close the issue by lazy consensus after 72 hours. > > -r > -- Carlos Santana
Re: [DISCUSS] release openwhisk runtimes
Both nodejs and actionloop PRs are merged -- Carlos On Mon, Mar 4, 2019 at 10:36 AM Carlos Santana wrote: > > For the nodejs bump PR I'm waiting for travis, if a committer sees the > green check by Travis before go ahead and merge it. > > For the actionloop PR looks good same thing, waiting on Travis to merge. > > We definitely need a Bot that handle comment commands (ie /merge) ala > ProBot or DerekBot :-) > > -- Carlos > > On Mon, Mar 4, 2019 at 8:22 AM Michele Sciabarra > wrote: > >> No there are no runtimes using v2 actionloop, yet. Probably the first >> will be rust and the new java. >> >> -- >> Michele Sciabarra >> mich...@sciabarra.com >> >> >> >> - Original message - >> From: David P Grove >> To: dev@openwhisk.apache.org >> Subject: Re: [DISCUSS] release openwhisk runtimes >> Date: Monday, March 04, 2019 2:08 PM >> >> >> Rob's PR to update the PHP version has been merged. >> >> We need to update the end year in all our notice files from 2018 to 2019 >> (I >> will submit PRs today). >> >> There's a pending PR [1] to bump NodeJS version to pick up latest security >> fixes that should merge today. >> >> We should get the update to the actionloop in [2] merged. >> >> Do downstream runtimes that use the actionloop need updates for [2] that >> we >> need to wait for? >> >> Is there anything else we need to wait on before we can proceed? >> >> --dave >> >> [1] https://github.com/apache/incubator-openwhisk-runtime-nodejs/pull/114 >> [2] https://github.com/apache/incubator-openwhisk-runtime-go/pull/72 >> >> On 2019/02/21 17:19:51, Rodric Rabbah wrote: >> > If you've contributed to one of these runtime repos please take a moment >> to> >> > read this and also review the runtime repo that you've worked on.> >> > >> > Do you (or anyone) have any reason to delay a release of the following> >> > runtime repositories as in, for example, are there any outstanding pull> >> > requests and patches to land? If not, I will start the release on >> Monday> >> > 2/25.> >> > >> > Runtimes (10 repos):> >> > - incubator-openwhisk-runtime-docker> >> > - incubator-openwhisk-runtime-dotnet> >> > - incubator-openwhisk-runtime-go> >> > - incubator-openwhisk-runtime-java> >> > - incubator-openwhisk-runtime-nodejs> >> > - incubator-openwhisk-runtime-php> >> > - incubator-openwhisk-runtime-python> >> > - incubator-openwhisk-runtime-ruby> >> > - incubator-openwhisk-runtime-swift> >> > - incubator-openwhisk-runtime-ballerina> >> > >> > -r> >> > >> >> -- Carlos Santana
Re: [DISCUSS] release openwhisk runtimes
For the nodejs bump PR I'm waiting for travis, if a committer sees the green check by Travis before go ahead and merge it. For the actionloop PR looks good same thing, waiting on Travis to merge. We definitely need a Bot that handle comment commands (ie /merge) ala ProBot or DerekBot :-) -- Carlos On Mon, Mar 4, 2019 at 8:22 AM Michele Sciabarra wrote: > No there are no runtimes using v2 actionloop, yet. Probably the first will > be rust and the new java. > > -- > Michele Sciabarra > mich...@sciabarra.com > > > > - Original message - > From: David P Grove > To: dev@openwhisk.apache.org > Subject: Re: [DISCUSS] release openwhisk runtimes > Date: Monday, March 04, 2019 2:08 PM > > > Rob's PR to update the PHP version has been merged. > > We need to update the end year in all our notice files from 2018 to 2019 (I > will submit PRs today). > > There's a pending PR [1] to bump NodeJS version to pick up latest security > fixes that should merge today. > > We should get the update to the actionloop in [2] merged. > > Do downstream runtimes that use the actionloop need updates for [2] that we > need to wait for? > > Is there anything else we need to wait on before we can proceed? > > --dave > > [1] https://github.com/apache/incubator-openwhisk-runtime-nodejs/pull/114 > [2] https://github.com/apache/incubator-openwhisk-runtime-go/pull/72 > > On 2019/02/21 17:19:51, Rodric Rabbah wrote: > > If you've contributed to one of these runtime repos please take a moment > to> > > read this and also review the runtime repo that you've worked on.> > > > > Do you (or anyone) have any reason to delay a release of the following> > > runtime repositories as in, for example, are there any outstanding pull> > > requests and patches to land? If not, I will start the release on > Monday> > > 2/25.> > > > > Runtimes (10 repos):> > > - incubator-openwhisk-runtime-docker> > > - incubator-openwhisk-runtime-dotnet> > > - incubator-openwhisk-runtime-go> > > - incubator-openwhisk-runtime-java> > > - incubator-openwhisk-runtime-nodejs> > > - incubator-openwhisk-runtime-php> > > - incubator-openwhisk-runtime-python> > > - incubator-openwhisk-runtime-ruby> > > - incubator-openwhisk-runtime-swift> > > - incubator-openwhisk-runtime-ballerina> > > > > -r> > > > >
Re: Greetings
Welcome Matt, happy to have you onboard !! - Carlos Santana @csantanapr > On Mar 2, 2019, at 1:21 PM, Justin Halsall wrote: > > Welcome Matt, we are super happy to have you! Greetings from Mexico City! > > Cheers, > Justin > > Sent from my iPhone > >> On Mar 2, 2019, at 11:55 AM, Matt Sicker wrote: >> >> Hello everyone, my name is Matt Sicker, and I've recently volunteered >> to be one of the mentors for this project. This is my first time being >> an Incubator mentor, and I'm excited to help out with this project as >> it is a very interesting one! >> >> Quick background on myself: I mostly work in the Logging Services >> project here. I also help the Secretary. Outside here, I'm also a >> developer of Jenkins and some of its core plugins. I really like free >> and open source developer-specific tooling and libraries, hence my >> interest in OpenWhisk. >> >> -- >> Matt Sicker >>
Re: Podling Report Reminder - March 2019
Thanks Dave, Bertrand is our this week but should be back Monday hope he sees the thread. Should we ping Matt the new mentor? On Fri, Mar 1, 2019 at 5:41 PM David P Grove wrote: > > > As discussed in the earlier thread [1]; I submitted the report from our > CWiki draft version about 20 minutes ago. We are done modulo mentor > sign-off. > > --dave > > [1] > > https://lists.apache.org/thread.html/5159e0fc5a37c80d528b6af07bf6dcd0a24445158a3b866cba27db42@%3Cdev.openwhisk.apache.org%3E > > > On 2019/03/01 22:36:18, jm...@apache.org wrote: > > Dear podling,> > > > > This email was sent by an automated system on behalf of the Apache> > > Incubator PMC. It is an initial reminder to give you plenty of time to> > > prepare your quarterly board report.> > > > > The board meeting is scheduled for Wed, 20 March 2019, 10:30 am PDT.> > > The report for your podling will form a part of the Incubator PMC> > > report. The Incubator PMC requires your report to be submitted 2 weeks> > > before the board meeting, to allow sufficient time for review and> > > submission (Wed, March 06).> > > > > Please submit your report with sufficient time to allow the Incubator> > > PMC, and subsequently board members to review and digest. Again, the> > > very latest you should submit your report is 2 weeks prior to the board> > > meeting.> > > > > Candidate names should not be made public before people are actually> > > elected, so please do not include the names of potential committers or> > > PPMC members in your report.> > > > > Thanks,> > > > > The Apache Incubator PMC> > > > > Submitting your Report> > > > > --> > > > > Your report should contain the following:> > > > > * Your project name> > > * A brief description of your project, which assumes no knowledge of> > > the project or necessarily of its field> > > * A list of the three most important issues to address in the move> > > towards graduation.> > > * Any issues that the Incubator PMC or ASF Board might wish/need to be> > > > aware of> > > * How has the community developed since the last report> > > * How has the project developed since the last report.> > > * How does the podling rate their own maturity.> > > > > This should be appended to the Incubator Wiki page at:> > > > > https://wiki.apache.org/incubator/March2019> > > > > Note: This is manually populated. You may need to wait a little before> > > this page is created from a template.> > > > > Mentors> > > ---> > > > > Mentors should review reports for their project(s) and sign them off on> > > the Incubator wiki page. Signing off reports shows that you are> > > following the project - projects that are not signed may raise alarms> > > for the Incubator PMC.> > > > > Incubator PMC> > > > -- Carlos Santana
Re: ActionLoop 1.0.2 with versioning and support for "more"...
I like the idea of using the major digit like a Dave suggested actionloop-v2:tag it matches the other runtimes like nodejs-v8:tag and nodejs-v10:tag - Carlos Santana @csantanapr > On Feb 27, 2019, at 3:14 PM, Michele Sciabarra wrote: > > The reason is to distinguish when there are significant changes. The runtime > is now built statically but the old one was not so if you want to use in an > alpine images you have to use this version. I do not plan to change the name > all the time only when there are significant changes, and should be rare. > Using a v2 is fine for me. > -- > Michele Sciabarra > mich...@sciabarra.com > > > > - Original message - > From: David P Grove > To: dev@openwhisk.apache.org > Subject: Re: ActionLoop 1.0.2 with versioning and support for "more"... > Date: Wednesday, February 27, 2019 8:18 PM > > "Michele Sciabarra" wrote on 02/27/2019 02:04:19 > PM: >> >> First and before all, I changed the name to actionloop-v1.0.2 so any >> build depending on it can retrieve the right version... (more >> version, if there is any potentially breaking change, will use a >> different name). >> > > I understand the desire to change the name. I don't like embedding a full > semantic version into the image name (as opposed to the image tag). > Perhaps actionloop-v2 is an acceptable compromise? > > We should be doing proper Apache releases of our runtimes and getting the > semvar into the image tags, not the image names. > > --dave >
Re: Welcome new Committer Olivier Tardieu
Woot !! Welcome Olivier -- Carlos On Wed, Feb 27, 2019 at 3:35 PM Rodric Rabbah wrote: > Welcome Olivier! > > -r > > > On Feb 27, 2019, at 3:34 PM, David P Grove wrote: > > > > > > OpenWhiskers, > > > > Yes! Another new Committer! > > > > Based on his ongoing and valuable contributions to the project, the > > OpenWhisk PPMC has elected Olivier Tardieu as a Committer and as a PPMC > > member and he has accepted the invitation. > > > > Please join me in welcoming him to his new role on the project! > > > > --dave > -- Carlos Santana
Re: Incubator quarterly report
LGTM I added a link to the maturity model even as reference Thanks Dave for handling this +1 -- Carlos On Wed, Feb 27, 2019 at 3:46 PM Dave Grove wrote: > A complete draft is now available on the CWIKI page referenced below. > > Please review and either edit directly or bring items needing discussion > to the dev list. If there are no outstanding discussion items by end of > day Friday 3/1, I will submit the report to the Incubator wiki for mentor > approval. > > thanks, > > --dave > > On 2019/02/26 18:46:11, "David P Grove" wrote: > > > > > > Our quarterly report is due by March 6. I would like to be able to post > > the completed draft by end-of day March 1 (Friday) so we can avoid being > > reminded that it is missing. > > > > I have made an initial draft, including updating the quoted project > > activity stats here. > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103091999 > > > > I could use some help in coming up with the list of ICLAs submitted...how > > was that done for prior reports? > > > > Having looked at previous reports submitted by many other podlings, I > feel > > that our typical previous report was too detailed. I propose we try to > > make this report shorter by eliding laundry lists of project-specific > > technical progress and focusing on the process-level questions that I > think > > is the main focus of the IPMC and ASF Board for the quarterly reports. > > > > --dave > > > -- Carlos Santana
Re: PR to enable actions on YARN
Ah ok Do you have a synopsis on how it compares to the options we use today like using docker or k8s pods? - Carlos Santana @csantanapr > On Feb 16, 2019, at 5:56 PM, Rodric Rabbah wrote: > > https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html > >> On Sat, Feb 16, 2019 at 5:56 PM Carlos Santana wrote: >> >> What is yarn? >> The nodejs package manager? https://yarnpkg.com/lang/en/ >> >> >> - Carlos Santana >> @csantanapr >> >>> On Feb 16, 2019, at 2:22 PM, Rodric Rabbah wrote: >>> >>> I want to thank Sam Hjelmfelt for walking me through his PR >>> https://github.com/apache/incubator-openwhisk/pull/4129 to allow >> actions to >>> run on YARN. He also showed me a live demo -- really neat. >>> >>> I'm making a final pass through the PR and will merge it in 72 hours if >>> there's no additional input by silent assent. >>> >>> -r >>
Re: switch docker compose to "lean"?
Yes +1 make compose lean - Carlos Santana @csantanapr > On Feb 16, 2019, at 1:21 PM, Rodric Rabbah wrote: > > A PR we recently merged add the ability to deploy openwhisk in a lean > configuration - without kafka/zookeeper (thanks Pavel!). Should the make > quick-start target for docker compose use it by default? > > I'm trying to reproduce failures reported in the slack channel for > docker-compose/make quick-start and it occurred to me we can startup even > faster with the lean configuration. > > -r
Re: PR to enable actions on YARN
What is yarn? The nodejs package manager? https://yarnpkg.com/lang/en/ - Carlos Santana @csantanapr > On Feb 16, 2019, at 2:22 PM, Rodric Rabbah wrote: > > I want to thank Sam Hjelmfelt for walking me through his PR > https://github.com/apache/incubator-openwhisk/pull/4129 to allow actions to > run on YARN. He also showed me a live demo -- really neat. > > I'm making a final pass through the PR and will merge it in 72 hours if > there's no additional input by silent assent. > > -r
Re: nodejs runtime packages in base images
With my vendor hat: This means anyone extending the base image in their Dockerfile need to delete the node_modules directory first before they do npm install to install the exact set of packages and their dependencies that they want. They would this for various reasons for example they went over all the dependency graph not just the top level and made sure there are no legal/license problems, security CVEs, and maybe some packages for their own purpose. This will increase the image size with a layer that never get use. The alternative is that the provider can have a Docker file that doesn’t extend the openwhisk base image and instead extend the nodejs base image and use the new from feature from Dockerfile to copy the 2 or 3 files out of the base openwhisk image. Now with my Apache Hat: You will need to blessed and do legal clearance of the npm packages and all their dependencies to make sure their are compatible with Apache and then maintain currency with the versions that for currency and also security patches. I know that nodejs6 includes a bunch of npm packages but I was hoping to delete nodejs:6 from the repo for this reason before graduation to avoid any problems when going into graduation. PS: Anyone is welcome to use the image ibmfunctions/action-nodejs-v10 for nodejs:10 in their runtimes.json is fully compatible with any openwhisk deployment. This is the one I use locally in my Mac with docker-compose deploy. - Carlos Santana @csantanapr > On Feb 16, 2019, at 8:57 AM, Dominic Kim wrote: > > +1 on this. > > > Best regards > Dominic > > > 2019년 2월 16일 (토) 오전 10:53, Rodric Rabbah 님이 작성: > >> Hello, >> >> A few times in recent weeks and twice this past week there was discussion >> on slack about our nodejs8 and nodejs10 images and the lack of packages in >> these images. As we move to deprecate nodejs6 with its coming end of life, >> this is worth re-considering: should we include some popular images in the >> base image? >> >> We had previously eschewed packages because the thought was providers roll >> their own. But I'm finding that our nodejs6 runtime more convenient for >> some development because of its built-in packages. >> >> So I opened a draft PR (new on GitHub!) to add some packages to our images >> here: >> https://github.com/apache/incubator-openwhisk-runtime-nodejs/pull/111 >> >> Feedback welcome and especially appreciated if you aren't a provider that >> runs their own images. >> >> -r >>
Re: good first issue tweets
+1 - Carlos Santana @csantanapr > On Feb 14, 2019, at 7:21 AM, Rodric Rabbah wrote: > > There is a github app https://github.com/rajatjindal/goodfirstissue which > can be installed/linked to a repo to monitor issues tagged as good first > issue, and then tweets out a link to those issues. > > Here are some of the tweets: > https://twitter.com/goodfirstissue > > Some users of the app: helm, openfaas, asyncy, and google's go-github repo. > > Thoughts on adding the app it to our openwhisk repos? > > -r
Re: [VOTE] - release Apache OpenWhisk Composer 0.10.0
I vote +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 headers if necessary. [x] No compiled archives bundled in source archive. 😄 $ gpg --print-md SHA512 openwhisk-composer-0.10.0-incubating-sources.tar.gz openwhisk-composer-0.10.0-incubating-sources.tar.gz: B81C71F4 7BF01403 28D5FC80 888FC76D 59A24AB1 59C0FADC 097B0909 BD76AEB9 BFA309D3 C2C443AE 2EC3DC50 0474B607 E9A20B73 8D993F51 4DEFEE5A 05C1AE00 ~/Downloads 😄 $ cat openwhisk-composer-0.10.0-incubating-sources.tar.gz.sha512 openwhisk-composer-0.10.0-incubating-sources.tar.gz: B81C71F4 7BF01403 28D5FC80 888FC76D 59A24AB1 59C0FADC 097B0909 BD76AEB9 BFA309D3 C2C443AE 2EC3DC50 0474B607 E9A20B73 8D993F51 4DEFEE5A 05C1AE00 ~/Downloads 😄 $ gpg --verify openwhisk-composer-0.10.0-incubating-sources.tar.gz.asc openwhisk-composer-0.10.0-incubating-sources.tar.gz gpg: Signature made Tue Feb 12 16:58:30 2019 PST gpg:using RSA key 72AF0CC22C4CF320 gpg: Good signature from "Vincent Hou (Release manager of OpenWhisk) < houshen...@apache.org>" [unknown] ~/Downloads 😄 $ tar -xvf openwhisk-composer-0.10.0-incubating-sources.tar.gz ~/Downloads/incubator-openwhisk-composer-0.10.0-incubating 😄 $ ~/dev/whisk/git/apache/incubator-openwhisk-utilities/scancode/scanCode.py --config ~/dev/whisk/git/apache/incubator-openwhisk-utilities/scancode/ASF-Release.cfg . Reading configuration file [/Users/csantanapr/dev/whisk/git/apache/incubator-openwhisk-utilities/scancode/ASF-Release.cfg]... /Users/csantanapr/dev/whisk/git/apache/incubator-openwhisk-utilities/scancode/scanCode.py:263: DeprecationWarning: This method will be removed in future versions. Use 'parser.read_file()' instead. config.readfp(file) Scanning files starting at [.]... All checks passed. ~/Downloads/incubator-openwhisk-composer-0.10.0-incubating 😄 $ npm test > openwhisk-composer@0.10.0 test /Users/csantana23/Downloads/incubator-openwhisk-composer-0.10.0-incubating > standard && mocha 216 passing (3m) 3 pending -- Carlos Santana On Tue, Feb 12, 2019 at 5:29 PM David P Grove wrote: > > > This is a call for the vote to release Apache OpenWhisk (Incubating): > Composer module version 0.10.0. > > Apache OpenWhisk Composer is a programming model for composing cloud > functions built on Apache OpenWhisk. The 0.10.0 release includes new > combinators for parallel execution and additional enhancements as described > in the ChangeLog ( > > https://github.com/apache/incubator-openwhisk-composer/blob/96ccab9c5cfab6f98ce564166f63f22b244a47fd/CHANGELOG.md > ). > > This release comprises of source code distribution only. There is only one > module within this release number 0.10.0. The artifact were built from the > following Git commit IDs: > * openwhisk-composer: 96ccab9c5cfab6f98ce564166f63f22b244a47fd > > The source code artifact of openwhisk composer can be found at: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-composer-0.10.0-incubating-sources.tar.gz > > > The SHA-512 checksum for the artifact of openwhisk composer is > openwhisk-composer-0.10.0-incubating-sources.tar.gz: > B81C71F4 7BF01403 28D5FC80 888FC76D 59A24AB1 59C0FADC 097B0909 BD76AEB9 > BFA309D3 > C2C443AE 2EC3DC50 0474B607 E9A20B73 8D993F51 4DEFEE5A 05C1AE00 > > which can can be found via: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-composer-0.10.0-incubating-sources.tar.gz.sha512 > > > The signature of the artifact of openwhisk composer can be found via: > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-composer-0.10.0-incubating-sources.tar.gz.asc > > KEYS file is available here: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/KEYS > > Please vote on releasing this package as Apache OpenWhisk > 0.10.0-incubating: > OpenWhisk Composer > > The vote will be open for at least 72 hours. > [ ] +1 Release as Apache OpenWhisk 0.10.0-incubating: openwhisk composer > [ ] +0 no opinion > [ ] -1 Do not release and the reason > > Checklist for reference: > [ ] Download links are valid. > [ ] Checksums and PGP signatures are valid. > [ ] DISCLAIMER is included. > [ ] Source code artifacts have correct names matching the current release. > [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. > [ ] All files have license headers if necessary. > [ ] No compiled archives bundled in source archive. > > regards, > > --dave > -- Carlos Santana
Re: outstanding PRs on openwhisk repo
Thank you Rodric for cleaning the house !! - Carlos Santana @csantanapr > On Feb 9, 2019, at 10:32 AM, Rodric Rabbah wrote: > > In preparing for the uber next release and staging, I went through all the > open pull requests and have merged all that were ready. There are at the > moment 25 open PRs remaining, of which another 5 I expect we can merge and > are waiting on a committer to hit the green merge button. > > Of the remaining PRs, some may be abandoned (I left comments in the PR), a > few need some discussion to make a decision (I also left comments in the > PR), and others require some review work. I may have asked some of you on > this help for help for which I thank you in advance. I have made sure all > the PRs have appropriate labels. > > If you are able to help with the remaining PRs, please take a look at the > list here: https://github.com/apache/incubator-openwhisk/pulls. Reviews > take effort and time and the time you spend is appreciated by contributors > and project maintainers alike. > > I thank you for your patience if you've been waiting on me specifically for > a review. I am hoping that this round of housekeeping will help us all > regain some velocity on accepting contributions. > > -r
Re: Prewarmed containers
Hi They are configured by the operator that deploys OpenWhisk by editing the runtimes.json [1] for example if you open the file you will see that nodejs6 look at the stemCell field it contains the values 2 and 256mb. This means that the invoker will always try to keep 2 containers of 256mb for nodejs6 as spare and ready to receive a new invocation. You can edit the runtimes manifest to declare stemCells for any runtime kind. [1] https://github.com/apache/incubator-openwhisk/blob/master/ansible/files/runtimes.json - Carlos Santana @csantanapr > On Feb 8, 2019, at 3:03 AM, Krzysztof Sobkowiak > wrote: > > Hi > > I was reading some discussions and blogs about prewarmed containers, but I > still have no idea how to > configure OpenWHisk to prewarm containers. I have seen a pull request, where > some kind of > containers can be defined as prewarmed and a count of prewarmed containers > can be defined. Can > someone clarify me where and how I can define it? > > Best regards > Krzysztof > > > > -- > Krzysztof Sobkowiak (@ksobkowiak) > > JEE & OSS Architect, Integration Architect > Apache Software Foundation Member (http://apache.org/) > Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/) > Senior Delivery Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)
Re: remove rotted distributed playbooks?
+1 -cs On Mon, Feb 4, 2019 at 5:40 PM Rodric Rabbah wrote: > The OpenWhisk repo includes a number of playbooks for setting up a > distributed openwhisk deployment, including provisioning and setup of VMs. > The instructions and playbooks have not been touched - for the most part - > since their introduction, are untested, and have already various bits of > rot. > > I am proposing that we remove them. For a distributed deployment with > ansible, modifying the local environment's host file should suffice. > Further, for swarm or kubernetes the deployment is entirely different also. > > I am proposing that we remove these files since there's clearly no effort > to keep them up to date. As further evidence of rot, there are several open > issues dating back to 2016, two open PRs with little attention, and one > abandoned PR (closed for reasons cited above). > > I've speculatively prepared a branch to remove the relevant bits and > request input... will proceed with silent consent if there are no > objections to removing these in 24 hours and open the PR. > > > https://github.com/apache/incubator-openwhisk/compare/master...rabbah:dist?expand=1 > > -r > > open PRs: > https://github.com/apache/incubator-openwhisk/pull/4232 > https://github.com/apache/incubator-openwhisk/pull/4107 > > closed/abandoned PR: > https://github.com/apache/incubator-openwhisk/pull/2915 > > open issues: > https://github.com/apache/incubator-openwhisk/issues/3989 > https://github.com/apache/incubator-openwhisk/issues/3733 > https://github.com/apache/incubator-openwhisk/issues/2220 > https://github.com/apache/incubator-openwhisk/issues/4235 > -- Carlos Santana
Re: Incubator Release Checklist/template
+1 Shaz Great suggestion - Carlos Santana @csantanapr > On Feb 1, 2019, at 4:58 PM, Shazron wrote: > > One suggestion: why not take advantage of Github Issue templates for > checklists? For example: > https://github.com/apache/cordova-new-committer-and-pmc > > File a new issue in the repo, get a fresh checklist > >> On Fri, Feb 1, 2019 at 1:44 AM Carlos Santana wrote: >> >> Justin shared this checklist in the IPM general mail list >> >> https://wiki.apache.org/incubator/IncubatorReleaseChecklist >> >> >> - Carlos Santana >> @csantanapr
Incubator Release Checklist/template
Justin shared this checklist in the IPM general mail list https://wiki.apache.org/incubator/IncubatorReleaseChecklist - Carlos Santana @csantanapr
Re: Openwhisk-user-events repository
I’m ok to be in main repo, image code lives there and then follow to be leverage in kube deploy and compose On Fri, Jan 25, 2019 at 5:43 PM Cosmin Stanciu wrote: > Yes, Chetan and I could take ownership on this and timely respond to any > issues or related changes. > I see that there is consensus on moving this to the main repo, we'll be > preparing a PR for the merge. > > Thx, > Cosmin > > > On 1/25/19, 11:39 AM, "Matt Rutkowski" wrote: > > I'm fine putting it in the main repo., as long as we have feature > ownership and assure that any issues and related PRs get actively > worked > on in a timely manner especially in the near term. > > -mr > > > > > From: Chetan Mehrotra > To: dev@openwhisk.apache.org > Date: 01/24/2019 10:04 PM > Subject:Re: Openwhisk-user-events repository > > > > > I’d favor adding this directly to the main openwhisk repository and > part > of the standard deployment, and related updates to other deployments. > > +1. I would also prefer to have it added to main repo as that would > help > in > enriching the user event going forward and keep them in sync > > Chetan Mehrotra > > > On Thu, Jan 24, 2019 at 3:09 AM Rodric Rabbah > wrote: > > > Cosmin, welcome! And thank you for the presentation today which I > just > > watched on replay. This is great to see and I think a huge addition > to > > openwhisk. OpenFaaS I think did a pretty good job early on of > integration > > metrics like this with the service and I’ve seen that resonate quite > well > > with that community. > > > > So this is awesome. I’d favor adding this directly to the main > openwhisk > > repository and part of the standard deployment, and related updates > to > > other deployments. > > > > Thanks Chetan also, I understood from the playback that you were also > > involved. > > > > -r > > > > > On Jan 23, 2019, at 3:51 PM, Cosmin Stanciu > > > wrote: > > > > > > Hi openwhiskers, > > > Thank you for the positive feedback from our tech exchange meeting > this > > morning and the willingness to add the `user monitoring services` as > part > > of the OW projects family. > > > > > > As you guys suggested, I’m starting a thread to discuss the best > place > > where we could move the current `openwhisk-user-events` > repository[1]: > > > > > > 1. Move it inside `incubator-openwhisk` > > > 2. Create a separate repo: `incubator-openwhisk-monitoring` > > > > > > I’ll be happy to do the transfer and update the documentation once > the > > decision is made. > > > > > > Regards, > > > Cosmin Stanciu > > > > > > [1] > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_adobe-2Dapiplatform_openwhisk-2Duser-2Devents%26d%3DDwIFaQ%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3D6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw%26m%3DymyDZzDWavSWlSDeWo5M_MSw-AnTH_2CBpnl5pYcACU%26s%3DF3fmSnMHrTfKvIhy1bhy6zoTCwnXvXX8luUq0LlFqig%26e&data=02%7C01%7Cstanciu%40adobe.com%7C9c08424565e149d055b008d682fccb6e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636840419586722110&sdata=UCGFKSIj1LfQaVtzAE6oYEX%2BpqDgzoUZMXt%2BzLTCzLA%3D&reserved=0= > > > > > > > > > > > > > > > -- Carlos Santana
Re: time for next OpenWhisk release wave?
I agree so we can start with first wave All runtimes repo, start a DISCUSS email thread to see if there is no objections to take what’s is currently the last commit on each of the runtime repos. If discuss is ok then next start creating the tgz for them and send the VOTE for dev list. - Carlos Santana @csantanapr > On Jan 24, 2019, at 9:57 AM, David P Grove wrote: > > > > Carlos Santana wrote on 01/23/2019 05:57:16 PM: >> >> I also vote for a git issue with checkboxes and deal with comments as we >> progress >> > > I created [1]. By my count a "complete" release would contain at least 21 > github repos (and I may have missed some; please add them). > > Will need some thought on how best to stage this to minimize the number of > rounds of voting we need. First step is to just get to a releasable > version of each repo... > > --dave > > [1] https://github.com/apache/incubator-openwhisk-release/issues/241
Re: time for next OpenWhisk release wave?
The release notes can also be done in the release repo short bullet of most important changes since the last release. Having release note is not required by the way but nice to have. I also vote for a git issue with checkboxes and deal with comments as we progress On Wed, Jan 23, 2019 at 5:51 PM David P Grove wrote: > > > > Carlos Santana wrote on 01/23/2019 05:16:15 PM: > > > > Is it just a matter of creating a branch "1.13.0-incubating" on the repo > > and adding a RELEASE.md file? > > > > Maybe just a CHANGELOG file on master? I think for at least some of the > runtime repos we more or less have this already. Other repos have been > less methodical and someone who has the knowledge will need to > reconstruct/generate from git history. > > Not really sure how best to go about this or how much practical value there > is in having detailed release notes. > > --dave > -- Carlos Santana
Re: time for next OpenWhisk release wave?
I agree with the plan Rodric Dave, What are your thinking for release notes? do you want to create the first one for one of the runtimes? I can create the other ones. Is it just a matter of creating a branch "1.13.0-incubating" on the repo and adding a RELEASE.md file? -- Carlos On Wed, Jan 23, 2019 at 4:48 PM Rodric Rabbah wrote: > Following up on this after watching today's community call replay. Dave > made the point that the big chunk of work toward this release is writing > release notes and deciding which of the components is ready. Several people > volunteered (Carlos, Matt) and I’m volunteering myself as well. > > I’d suggest we create an issue for each repo that we will include in the > release to deliver the release notes to start. > > Dave also pointed out that there’s a few staging phases to coordinate > which could take us about 3 weeks (largely because of the voting and 72hr > waiting periods). > > Dave: what else did I miss? > > -r > > > On Jan 7, 2019, at 4:55 PM, David P Grove wrote: > > > > > > > > I would like to see us push out a consolidated next release in the near > > future (by end of January?). I'd also like to see us attempt to > establish > > a regular cadence of such consolidated releases (perhaps quarterly?). > > > > We would start this release from the leaves of our dependency tree and > work > > up: > > 1) release all action runtimes that have changed since their last > > Apache release. > > 2) release cli tooling > > 3) release event providers > > 4) release core system (with pinned versions of runtimes, cli, and > > providers) > > 5) release packaging projects (kube-deploy, dev-tools, etc.) with > > pinned versions of entire system. > > > > I would also like to propose that although we keep semantic versioning of > > the sub-packages (openwhisk-runtime-java-x.y.z, openwhisk-cli-a.b.c, > etc), > > that we adopt a date-based version number for the consolidate > uber-release > > (eg OpenWhisk 19.01 if we actually manage to get this all out in > January). > > > > Opinions? > > > > --dave > > -- Carlos Santana
