Re: Updating Kafka getting rid of Zookeeper
There’s also Apache Ratis if you want a RAFT library. Looks promising. — Matt Sicker > On Dec 20, 2022, at 20:00, Brendan Doyle wrote: > > Actually to Dom’s point, rather than UUID you can probably use the ip or > display name value to store as the key to guarantee uniqueness, but will be > reused on restart. And still no longer have to worry about tracking the > counter. > > Brendan > >> On Tue, Dec 20, 2022 at 8:54 PM Brendan Doyle wrote: >> >> I think it would be nice to make the invoker ids “memoryless” in that they >> just get a new id on restart. And this value can just be stored in etcd or >> any key value data store. The two major things that need to be dealt with >> on the new architecture to deal with that are 1. The healthcheck function >> is created using the invoker id as the name of the function so we need to >> make sure the function is deleted otherwise you’ll endlessly create the >> healthcheck functions and 2. the container creation kafka topics since >> they’re somewhat tied to the invoker and it’s assigned id. A new container >> creation topic would get created every time the invoker is restarted if it >> gets a new uuid every time (which maybe that’s okay as long as we can clean >> up old ones). Basically this all just boils down to we just need to make >> sure we’re accounting for cleaning up all side effect data that gets >> created by a new invoker uuid when it gets shut down. >> >> The ack / results kafka topics wouldn’t have to be adjusted to achieve >> this because they’re coordinated by the controllers. >> >> On the topic of removing kafka from the critical path, I’m in total >> agreement with Dom I think that would be a great architectural improvement >> goal for 2023. Since openwhisk is already at most once at this point, I >> don’t think kafka is adding any value from a persistence perspective and we >> now have zero down time graceful restarts to drain any in progress work >> before stopping. I presume most of the original value was from an ordering >> perspective giving some level of fairness of processing between components. >> >> >> >>> On Tue, Dec 20, 2022 at 7:48 PM Dominic Kim wrote: >>> >>> We can also consider ETCD. >>> ETCD supports a transaction API so we can make sure only one invoker can >>> be >>> assigned an IP at a time. >>> (Though ETCD is currently only enabled when a scheduler is enabled.) >>> >>> Aside from this, I also wanted to get rid of Kafka from the critical path >>> too as we can now use the scheduler(the new messaging queue). >>> Since Kafka is being used to deliver ContainerCreation messages and Ack + >>> Result messages, it would not be a simple task but we are already using >>> Akka-grpc and Akka-remote(cluster). >>> We can migrate to them. >>> >>> -dom >>> >>> >>> >>> >>> >>> >>> [image: Mailtrack] >>> < >>> https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality11; >>>> >>> Sender >>> notified by >>> Mailtrack >>> < >>> https://mailtrack.io?utm_source=gmail_medium=signature_campaign=signaturevirality11; >>>> >>> 22. >>> 12. 21. 오전 09:45:27 >>> >>> 2022년 12월 21일 (수) 오전 6:25, Michele Sciabarra 님이 >>> 작성: >>> >>>> I have a question: what if we just use UUID? >>>> That would be easy to implement. >>>> Unless there are other reasons because the id should be incremental >>>> numbers. >>>> I would like to try to get rid of this dependency because I really want >>> to >>>> update Kafka maybe using RedPanda or Kafka Kraft... >>>> >>>> -- >>>> Michele Sciabarra >>>> mich...@sciabarra.com >>>> >>>> - Original message - >>>> From: Brendan Doyle >>>> To: dev@openwhisk.apache.org >>>> Subject: Re: Updating Kafka getting rid of Zookeeper >>>> Date: Sunday, December 18, 2022 4:36 PM >>>> >>>> Yes this is one of the things I had in my list on slack of what I would >>>> like to see accomplished in 2023 since the only zookeeper use is storing >>>> the invoker id mappings. I think it should be doable, but the one tricky >>>> part is the synchronization that the zookeeper counter provides. >>> Whatever >>>> new mechanism that is used, it must be guaranteed that two new invok
Re: Free Travis-CI will go away for open source projects
If use of Kubernetes in CI is useful here, there's a thread on bui...@apache.org right now planning how to go about doing so. Note that GitHub Actions are also somewhat rate-limited across the ASF, so we might need some hybrid CI solutions depending on how long or frequently things are running. Moving from Travis is a good idea either way as it's even more rate-limited. On Fri, 20 Nov 2020 at 09:24, Carlos Santana wrote: > > 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: [DISCUSS] openwhisk-deploy-kube 1.0.0 and "OpenWhisk 20.11"
I think a release vote is appropriate, though whether or not it needs 3 +1s or can be done by lazy consensus is a detail to explore. Since this is a metapackage type thing, I can see it being done either way as it's similar to a parent pom in the Java world where you're just referencing several already released components. On Thu, 19 Nov 2020 at 15:26, David P Grove wrote: > > > > Hi, > > With the recent completion of the OpenWhisk 1.0.0 release, we are almost > ready to make our first unified release. As discussed quite a while ago, a > unified release simply bundles a compatible set of already-released > components into a time-based version number. The goal is to make it easier > for users to be able to download a complete set of all of our components > that are known to work together. > > To finally finish this process, we need to do two things: > > 1. Make a release of openwhisk-deploy-kube 1.0.0. There is a 1.0.0 branch > that is very close to being in final state. I hope to finalize it this > week and kick off a formal release vote. > > 2. Create a subdir 20.11 in our distribution svn and replicate the current > set of most-recent releases into it. Bertrand, Matt, and other ASF > experts. What is the correct process for this? Do we do a release VOTE on > a 20.11 meta-package by listing the already released artifacts that we are > going to bundle together in a VOTE thread? > > thanks, > > --dave
Re: [VOTE] Release Apache OpenWhisk Runtime Go (v1.16.0, rc1)
That’s from not bundling the gradle wrapper jar as the sources can’t include binaries (at least without the source for said binaries). I believe this problem has been since solved for the maven wrapper, but not for gradle. On Sat, Sep 26, 2020 at 10:32 Michele Sciabarra wrote: > Hmm before voting I have a question: > > The tarball verifies correctly but I tried to build and run the tests > before and I had this problem: > > > > ./gradlew distDocker > > Errore: impossibile trovare o caricare la classe principale > org.gradle.wrapper.GradleWrapperMain > > (english: cannot find or load the main class > org.gradle.wrapper.GradleWrapperMain) > > > > Is this normal / expected in the tarball? > > > > -- > > Michele Sciabarra > > mich...@sciabarra.com > > > > - Original message - > > From: David P Grove > > To: dev > > Subject: [VOTE] Release Apache OpenWhisk Runtime Go (v1.16.0, rc1) > > Date: Saturday, September 26, 2020 2:08 AM > > > > Hi, > > > > This is a call to vote on releasing version 1.16.0 release candidate rc1 of > > the following project module with artifacts built from the Git repositories > > and commit IDs listed below. > > > > * OpenWhisk Runtime Go: cd4328476bd3817e157fa3bb4a85981c9ab83472 > > > > > https://github.com/apache/openwhisk-runtime-go/commits/cd4328476bd3817e157fa3bb4a85981c9ab83472 > > > > > https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-runtime-go-1.16.0-sources.tar.gz > > > > > https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-runtime-go-1.16.0-sources.tar.gz.asc > > > > > https://dist.apache.org/repos/dist/dev/openwhisk/rc1/openwhisk-runtime-go-1.16.0-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=530cdd4 > > > > Usage: > > curl -s " > > > https://gitbox.apache.org/repos/asf?p=openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=530cdd4 > > " -o rcverify.sh > > chmod +x rcverify.sh > > rcverify.sh openwhisk-runtime-go 'OpenWhisk Runtime Go' 1.16.0 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 for at least 72 hours. > > > > > > [1] > > > https://github.com/apache/openwhisk-release/blob/master/docs/license_compliance.md > > -- Matt Sicker
Re: Upcoming wskdebug release 1.3
If you can send me your key, preferably encrypted to my GPG key, I can add it to the KEYS file for you. See second to last key in this file for a copy of the key: https://dist.apache.org/repos/dist/release/logging/KEYS On Tue, 28 Jul 2020 at 21:41, Matt Sicker wrote: > > The KEYS file is indeed PMC-only writable. I believe it’s because only PMC > members can sign the release as their release votes are binding. I can take > care of this. > > On Tue, Jul 28, 2020 at 21:30 Rodric Rabbah wrote: >> >> > Can a PMC member help out? I'm buried for the next few days on some >> non-OpenWhisk deadlines. >> >> Will try tomorrow. >> >> -r > > -- > Matt Sicker -- Matt Sicker
Re: Upcoming wskdebug release 1.3
The KEYS file is indeed PMC-only writable. I believe it’s because only PMC members can sign the release as their release votes are binding. I can take care of this. On Tue, Jul 28, 2020 at 21:30 Rodric Rabbah wrote: > > Can a PMC member help out? I'm buried for the next few days on some > non-OpenWhisk deadlines. > > Will try tomorrow. > > -r > -- Matt Sicker
Re: Discuss how to set environment variables in Java11 and more...
Oh yeah that definitely wouldn’t work.
On Sun, Mar 29, 2020 at 10:29 Carlos Santana wrote:
> -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
>
--
Matt Sicker
Re: Discuss how to set environment variables in Java11 and more...
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: Preview of a OpenWhisk IDE & Debugger... and an help request
eek. > > [1] https://github.com/adobe/wskdebug > > Cheers, > Alex > > Von: Michele Sciabarra > Gesendet: Monday, February 3, 2020 2:27:15 AM > An: dev@openwhisk.apache.org > Betreff: Re: Preview of a OpenWhisk IDE & Debugger... and an help request > > This is basically also what I am trying to do. > > I guess the difference is that you are doing this using the standard > nodejs runtime while I am doing the same using the goproxy. I am sure it is > also similar to the adobe/wskdebug that I tried to use, and works but it > specific to the node and java runtimes, without actionloop. > > My goal is to get the debugger for the "other" languages, most notabily > typescript python and go. > > Let's discuss on the call to see how we can align efforts. > > > -- > Michele Sciabarra > mich...@sciabarra.com > > - Original message - > From: Dominic Kim > To: dev@openwhisk.apache.org > Subject: Re: Preview of a OpenWhisk IDE & Debugger... and an help request > Date: Monday, February 03, 2020 10:52 AM > > Thank you for the details. > It seems what you are tying now is similar with our approach and can be > aligned with ours too as it is generic like you said. > > We enabled the debugging of Nodejs runtime with chrome DevTools protocol > https://chromedevtools.github.io/devtools-protocol/. > Our UI communicates with the real remote OW deployment. > We implemented one proxy server to correlate a debugging session with a > corresponding action container. > Since each action container is not exposed to public, we also have a > bridge > component on each invoker machine for location transparency. > > If I understood correctly, each container will connect to the IDE in a > reverse way in your version and similarly it connects to the proxy via > bridge in our version. > SoI think two versions can coexist, if we make the interface extensible. > > Maybe I can share more details at this interchange call. > > > Thanks > Best regards > Dominic. > > > > > 2020년 2월 3일 (월) 오후 4:47, Michele Sciabarra 님이 작성: > > > Hi Dominic > > > > the preliminary work I did was already submitted as a PR to build a > > standalone docker image (that is critical for my design). > > > > The rest the work is here: > https://github.com/sciabarracom/openwhisk-ide > > and uses the (upcoming) typescript runtime here > > https://github.com/sciabarracom/openwhisk-runtime-typescript. But do > not > > use it yet as it is pretty much work in progress, no documentation nor > it > > is even remotely stable. > > > > The key idea is to leverage the fact that actionloop launches a process > > for each action, and I am simplying putting the process in debug mode. > Then > > I am using Eclipse Theia, that is vscode in a browser, > > https://theia-ide.org/ as an editor and debugger interface. > > > > The key problem I have is to connect the action running under a debugger > > (problem solved) with the debugger client. So far I am just starting the > > action , asking to the action its IP and then connecting to it with the > > debugger. Problem is that the action may have a different IP > > > > I am now in the process of trying a different approach, where I > > communicate to the action the IP of the IDE and ask to the action to > > connect back, maybe creating a tunnel. In this way it could work in a > more > > generic way, even with a production whisk, as the only requirement will > be > > to have the client (that is itself a docker container) reachable by the > > action. > > > > -- > > Michele Sciabarra > > mich...@sciabarra.com > > > > - Original message - > > From: Dominic Kim > > To: dev@openwhisk.apache.org > > Subject: Re: Preview of a OpenWhisk IDE & Debugger... and an help > request > > Date: Monday, February 03, 2020 7:07 AM > > > > Hi Michele. > > Thank you for sharing great works. > > > > We here(Naver) are also using a web based debugging feature and I would > > like to align ours with yours. > > Is there any reference that I can follow up your works? > > Did you open any PR? > > > > And I want to share our version at this tech interchange call. > > > > > > Best regards > > Dominic > > > > > > 2020년 2월 2일 (일) 오전 7:02, Michele Sciabarra 님이 > 작성: > > > > > Great suggestion. I know how to pass configuration parameters, what is > > the > > > configuration to set? > > > > > > -- > > > Michele Sciabarra > > > mich...@sciabarra.com > > > > > > - Original message - > > > From: Rodric Rabbah > > > To: dev@openwhisk.apache.org > > > Subject: Re: Preview of a OpenWhisk IDE & Debugger... and an help > request > > > Date: Saturday, February 01, 2020 8:35 PM > > > > > > > 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. > > > > > > Did you try to change the pause grace configuration to an max int. > > > > > > -r > > > > > > -- Matt Sicker
Re: OpenWhisk as a single docker image?
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.mddata=02%7C01%7Ctnorris%40adobe.com%7Cfc313c39337a44a5882a08d7651a0cbc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637089034867332217sdata=OCnWo8R5OfbKLaSQCEeI%2B7pqz0ewp%2BYQGBK2msMoMtc%3Dreserved=0 > > -r > > > On Nov 9, 2019, at 8:18 AM, Michele Sciabarra > 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: Java 11 PR
I'm surprised extra dependencies aren't required. When we added support for Java 11 in Jenkins, we had to add some auto-installed modules to replace some Java SE APIs that aren't part of java.base and require implementations. On Thu, 31 Oct 2019 at 10:09, dan McWeeney wrote: > > There has been talk previously about moving to later java and scala versions. > I’ve got this all working in a PR[0], which passes travis. I was wondering if > there is some further testing that people think should be done. > > -dan > > [0] - https://github.com/apache/openwhisk/pull/4706 > -- Matt Sicker
Re: Playground UI for openwhisk
If we have an openwhisk formula, should that depend on the wsk cli as well? Or would it come with its own copy of the cli? Small design consideration ;) On Mon, 14 Oct 2019 at 05:51, Carlos Santana wrote: > 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 > -- Matt Sicker
Re: Welcome new committer Justin Halsall
Welcome, Justin! And thanks, David, for taking care of the announcement email. On Fri, 23 Aug 2019 at 15:03, David P Grove wrote: > > > It is my pleasure to share that Project Management Committee (PMC) for the > Apache OpenWhisk project has invited Justin Halsall to become a committer > and he has accepted. > > Justin has been a solid Contributor to and active community member within > the OpenWhisk project for some time. He is credited with creating the code > base used to seed the Ruby runtime of which he is a maintainer. In > addition, he has also supporting contributions to the project website repo > and in client tooling repos and helped add Brew support for wskdeploy. > Justin is a regular participant within our “dev” list and attends many of > our Tech. Interchange calls. > > Please join me in welcoming Justin to this new role on the project! > > --dave -- Matt Sicker
Re: [Contribution] wskdebug
A software grant will be needed for the donation to be accepted, for one. On Tue, 13 Aug 2019 at 16:07, Alexander Klimetschek wrote: > > Hi Dave, > > thanks. The IP clearance page says "The receiving PMC is responsible for > doing the work." but I am happy to help if there is anything I can do. > > The entire codebase is available and can be cloned from > https://github.com/adobe/wskdebug > > Cheers, > Alex > > > From: David P Grove > Sent: Tuesday, August 13, 2019 13:40 > To: dev@openwhisk.apache.org > Cc: Jesse MacFadyen ; Fil Maj ; Moritz Raho > ; Shazron Abdullah ; Simon Mac Donald > > Subject: Re: [Contribution] wskdebug > > > > Alexander Klimetschek wrote on 08/08/2019 12:27:57 AM: > > > > Hi OpenWhisk team, > > > > after presenting wskdebug in today's community call I would like > > to formally start the contribution process. There was agreement in > > the call to accept a contribution into Apache OpenWhisk. > > Great! > > The IP clearance process is described at [1]. The next steps would be get > a snapshot of the code together and fill out the IP Clearance form > describing it. > > --dave > > [1] http://incubator.apache.org/ip-clearance/ -- Matt Sicker
Re: Publishing a pre-release version of Standalone OpenWhisk
If we want a release for users to try, I think it would make sense to vote on an alpha release or similar. It’s not ideal to point users to unvetted releases, even if they’re early access. On Thu, Aug 1, 2019 at 07:17, Rodric Rabbah wrote: > It would certainly help in getting others to try it. > > Since the nightly builds are not releases and must not be labeled as > releases I think the issue you’re alluding to is not the same. > > -r > > > On Aug 1, 2019, at 4:57 AM, Chetan Mehrotra > wrote: > > > > Would it be useful to publish a pre-release version of Standalone > > OpenWhisk to simplify trials of this mode by users until we do a > > proper release of core repo? > > > > Currently I have a task open (#4525) to publish nightly release to > > Github org [1]. However based on some recent discussions I am not sure > > if its fine to push such nightly releases in automated way via Travis. > > > > Another option can be to push a snapshot build to Apache Maven repo > > [3] via some Jenkins job. However this work may take some time as we > > would need to upgrade Gradle to 5.x which has better Maven release > > support and which we need for supporting JDK 11 > > > > So was thinking to manually publish a pre-release build at [2] based > > on local build and eventually support publishing snapshot builds to > > Apache Maven repo > > > > Thoughts on what approach to take here? > > > > Chetan Mehrotra > > [1] https://github.com/apache/incubator-openwhisk/issues/4525 > > [2] https://github.com/apache/incubator-openwhisk/releases > > [3] https://repository.apache.org/ > -- Matt Sicker
Re: Proposal process for changes (was: A direction to take in a new component,...)
I like this! It would make a great starting point, and we might not even need to get more advanced any time soon. Good find! On Thu, 25 Jul 2019 at 02:00, Bertrand Delacretaz wrote: > > Hi, > > On Thu, Jul 18, 2019 at 8:36 PM Matt Sicker wrote: > > ...This is one of the situations where having some sort of proposal > > process can help align the various people and technical considerations > > a bit easier than mailing lists and PRs. There are numerous other > > communities with similar proposal processes (e.g., SIPs for Scala, > > KIPs for Kafka, JEPs and JSRs for Java, etc.) > > One lightweight example is https://github.com/apache/cordova-discuss , > with the process described at [1], basically: > > -Create an issue to define the rough shape of a proposal > -If there's consensus, create a Markdown document with the proposal > -Refine the proposal with pull requests > -Set a state on each proposal: draft, implementing, done, canceled etc. > > What I like about it is that it captures the history of each proposal > in a single place, with a minimal process. > > -Bertrand > > [1] https://github.com/apache/cordova-discuss/blob/master/proposals/README.md -- Matt Sicker
Re: Looking to contribute; which areas need some love?
This is turning into an incredible rabbit hole of programming languages and slightly relates to the recent discussion on that. So far, I've come across: Go, Python (2 and 3), Erlang, C (somehow?), JavaScript, Bash, Groovy (mostly via Gradle), and that's not even touching on the languages in use here! Anyways, the CouchDB patch to support DNS SRV records looks like a fruitful approach, so I'm trying to fix up the existing PR first before attempting the operator-based route. I did look at KubeDB, and it looks neat, though notes on how to create a new database integration are scarce at the moment. That framework does look very useful, though, for building a proper K8s operator for CouchDB which would make our own Helm charts simpler. On Sat, 20 Jul 2019 at 14:39, Michele Sciabarra wrote: > > I world consider addimg Couchdb support To a project like this > https://kubedb.com/ since is supports very different dbs probably it is > easier than starts from scratch > > -- > Michele Sciabarra > mich...@sciabarra.com > > > > - Original message - > From: Matt Sicker > To: dev@openwhisk.apache.org > Subject: Re: Looking to contribute; which areas need some love? > Date: Saturday, July 20, 2019 9:28 PM > > Unfortunately, the couchdb operator is unlicensed and hasn't been > updated in a couple years. That does indicate that the author is > _probably_ willing to either donate the code or attach a proper > license to it at least. I filed an issue [1], so perhaps this route > might work out after all. > > [1]: https://github.com/nicolai86/couchdb-operator/issues/1 > > On Sat, 20 Jul 2019 at 14:15, Matt Sicker wrote: > > > > Oh this is fun doing archeology on other projects (CouchDB in this > > case). I recognize one of the typical PR reviewers from elsewhere, and > > it appears that the DNS SRV based cluster discovery feature hasn't > > been merged upstream yet. This might turn into a neat opportunity for > > us to connect more with the CouchDB PMC. I'll link back any upstream > > issues. > > > > On Sat, 20 Jul 2019 at 14:02, Matt Sicker wrote: > > > > > > Thanks for the link! That looks like an even easier way to support > > > CouchDB for sure. I'll play around with each option to see which makes > > > more sense to prototype. > > > > > > On Sat, 20 Jul 2019 at 13:41, Michele Sciabarra > > > wrote: > > > > > > > > A critical aspect to consider is backup. There is an operator in the > > > > work (that is the primary reason so far to use an external CouchDB) > > > > There is an operator in the work that may be useful > > > > https://github.com/nicolai86/couchdb-operator > > > > > > > > -- > > > > Michele Sciabarra > > > > mich...@sciabarra.com > > > > > > > > > > > > > > > > - Original message - > > > > From: Matt Sicker > > > > To: dev@openwhisk.apache.org > > > > Subject: Re: Looking to contribute; which areas need some love? > > > > Date: Saturday, July 20, 2019 8:03 PM > > > > > > > > Continuing discussion in > > > > https://github.com/apache/incubator-openwhisk-deploy-kube/issues/498 > > > > > > > > On Sat, 20 Jul 2019 at 12:48, Matt Sicker wrote: > > > > > > > > > > So it seems that there's an incubating chart for CouchDB already which > > > > > might be adaptable: > > > > > https://github.com/helm/charts/tree/master/incubator/couchdb > > > > > > > > > > Main difference I already see is that they offer a StatefulSet for > > > > > clustering the CouchDB instances. Might not be too complicated. I'll > > > > > file an issue since I wasn't able to find any existing ones. > > > > > > > > > > On Fri, 19 Jul 2019 at 14:41, Matt Sicker wrote: > > > > > > > > > > > > That does sound like an interesting thing to do. I've been looking > > > > > > for > > > > > > an excuse to practice more Kubernetes things, so this could be > > > > > > rather > > > > > > practical there. > > > > > > > > > > > > On Fri, 19 Jul 2019 at 13:21, Michele Sciabarra > > > > > > wrote: > > > > > > > > > > > > > > In my opinion, given your experience with Kubernetes, a long > > > > > > > needed feature is to add support for clustered CouchDb in the > > > > > > > helm chart
Re: Looking to contribute; which areas need some love?
Unfortunately, the couchdb operator is unlicensed and hasn't been updated in a couple years. That does indicate that the author is _probably_ willing to either donate the code or attach a proper license to it at least. I filed an issue [1], so perhaps this route might work out after all. [1]: https://github.com/nicolai86/couchdb-operator/issues/1 On Sat, 20 Jul 2019 at 14:15, Matt Sicker wrote: > > Oh this is fun doing archeology on other projects (CouchDB in this > case). I recognize one of the typical PR reviewers from elsewhere, and > it appears that the DNS SRV based cluster discovery feature hasn't > been merged upstream yet. This might turn into a neat opportunity for > us to connect more with the CouchDB PMC. I'll link back any upstream > issues. > > On Sat, 20 Jul 2019 at 14:02, Matt Sicker wrote: > > > > Thanks for the link! That looks like an even easier way to support > > CouchDB for sure. I'll play around with each option to see which makes > > more sense to prototype. > > > > On Sat, 20 Jul 2019 at 13:41, Michele Sciabarra > > wrote: > > > > > > A critical aspect to consider is backup. There is an operator in the work > > > (that is the primary reason so far to use an external CouchDB) There is > > > an operator in the work that may be useful > > > https://github.com/nicolai86/couchdb-operator > > > > > > -- > > > Michele Sciabarra > > > mich...@sciabarra.com > > > > > > > > > > > > - Original message - > > > From: Matt Sicker > > > To: dev@openwhisk.apache.org > > > Subject: Re: Looking to contribute; which areas need some love? > > > Date: Saturday, July 20, 2019 8:03 PM > > > > > > Continuing discussion in > > > https://github.com/apache/incubator-openwhisk-deploy-kube/issues/498 > > > > > > On Sat, 20 Jul 2019 at 12:48, Matt Sicker wrote: > > > > > > > > So it seems that there's an incubating chart for CouchDB already which > > > > might be adaptable: > > > > https://github.com/helm/charts/tree/master/incubator/couchdb > > > > > > > > Main difference I already see is that they offer a StatefulSet for > > > > clustering the CouchDB instances. Might not be too complicated. I'll > > > > file an issue since I wasn't able to find any existing ones. > > > > > > > > On Fri, 19 Jul 2019 at 14:41, Matt Sicker wrote: > > > > > > > > > > That does sound like an interesting thing to do. I've been looking for > > > > > an excuse to practice more Kubernetes things, so this could be rather > > > > > practical there. > > > > > > > > > > On Fri, 19 Jul 2019 at 13:21, Michele Sciabarra > > > > > wrote: > > > > > > > > > > > > In my opinion, given your experience with Kubernetes, a long needed > > > > > > feature is to add support for clustered CouchDb in the helm chart. > > > > > > It is the only missing pieces to allow for a true ‘production’ > > > > > > CouchDb. Kafka is already clustered, CouchDb is not. David > > > > > > recommend to use an external one but it is not always an option > > > > > > when you have an internal deployment for example. > > > > > > > > > > > > -- > > > > > > Michele Sciabarra > > > > > > mich...@sciabarra.com > > > > > > > > > > > > > > > > > > > > > > > > - Original message - > > > > > > From: Matt Sicker > > > > > > To: dev@openwhisk.apache.org > > > > > > Subject: Looking to contribute; which areas need some love? > > > > > > Date: Friday, July 19, 2019 7:10 PM > > > > > > > > > > > > Hey all, I've been working on some other personal project the past > > > > > > few > > > > > > weekends, but I've been itching to explore this project more and > > > > > > make > > > > > > some code contributions. I see the main openwhisk repo is Scala/Akka > > > > > > which is tech that I've used before. However, I'm also interested in > > > > > > hearing which areas feel neglected right now and could use some > > > > > > attention. > > > > > > > > > > > > As a bonus, this can also start an idea of adding entries to > > > > > > https://helpwanted.apache.org/ to recruit more contributors. I see > > > > > > there's already some GSoC projects going on, so this is an > > > > > > additional > > > > > > resource that can be useful here. > > > > > > > > > > > > -- > > > > > > Matt Sicker > > > > > > > > > > > > > > > > > > > > > -- > > > > > Matt Sicker > > > > > > > > > > > > > > > > -- > > > > Matt Sicker > > > > > > > > > > > > -- > > > Matt Sicker > > > > > > > > > -- > > Matt Sicker > > > > -- > Matt Sicker -- Matt Sicker
Re: Looking to contribute; which areas need some love?
Oh this is fun doing archeology on other projects (CouchDB in this case). I recognize one of the typical PR reviewers from elsewhere, and it appears that the DNS SRV based cluster discovery feature hasn't been merged upstream yet. This might turn into a neat opportunity for us to connect more with the CouchDB PMC. I'll link back any upstream issues. On Sat, 20 Jul 2019 at 14:02, Matt Sicker wrote: > > Thanks for the link! That looks like an even easier way to support > CouchDB for sure. I'll play around with each option to see which makes > more sense to prototype. > > On Sat, 20 Jul 2019 at 13:41, Michele Sciabarra wrote: > > > > A critical aspect to consider is backup. There is an operator in the work > > (that is the primary reason so far to use an external CouchDB) There is an > > operator in the work that may be useful > > https://github.com/nicolai86/couchdb-operator > > > > -- > > Michele Sciabarra > > mich...@sciabarra.com > > > > > > > > - Original message - > > From: Matt Sicker > > To: dev@openwhisk.apache.org > > Subject: Re: Looking to contribute; which areas need some love? > > Date: Saturday, July 20, 2019 8:03 PM > > > > Continuing discussion in > > https://github.com/apache/incubator-openwhisk-deploy-kube/issues/498 > > > > On Sat, 20 Jul 2019 at 12:48, Matt Sicker wrote: > > > > > > So it seems that there's an incubating chart for CouchDB already which > > > might be adaptable: > > > https://github.com/helm/charts/tree/master/incubator/couchdb > > > > > > Main difference I already see is that they offer a StatefulSet for > > > clustering the CouchDB instances. Might not be too complicated. I'll > > > file an issue since I wasn't able to find any existing ones. > > > > > > On Fri, 19 Jul 2019 at 14:41, Matt Sicker wrote: > > > > > > > > That does sound like an interesting thing to do. I've been looking for > > > > an excuse to practice more Kubernetes things, so this could be rather > > > > practical there. > > > > > > > > On Fri, 19 Jul 2019 at 13:21, Michele Sciabarra > > > > wrote: > > > > > > > > > > In my opinion, given your experience with Kubernetes, a long needed > > > > > feature is to add support for clustered CouchDb in the helm chart. It > > > > > is the only missing pieces to allow for a true ‘production’ CouchDb. > > > > > Kafka is already clustered, CouchDb is not. David recommend to use an > > > > > external one but it is not always an option when you have an internal > > > > > deployment for example. > > > > > > > > > > -- > > > > > Michele Sciabarra > > > > > mich...@sciabarra.com > > > > > > > > > > > > > > > > > > > > - Original message - > > > > > From: Matt Sicker > > > > > To: dev@openwhisk.apache.org > > > > > Subject: Looking to contribute; which areas need some love? > > > > > Date: Friday, July 19, 2019 7:10 PM > > > > > > > > > > Hey all, I've been working on some other personal project the past few > > > > > weekends, but I've been itching to explore this project more and make > > > > > some code contributions. I see the main openwhisk repo is Scala/Akka > > > > > which is tech that I've used before. However, I'm also interested in > > > > > hearing which areas feel neglected right now and could use some > > > > > attention. > > > > > > > > > > As a bonus, this can also start an idea of adding entries to > > > > > https://helpwanted.apache.org/ to recruit more contributors. I see > > > > > there's already some GSoC projects going on, so this is an additional > > > > > resource that can be useful here. > > > > > > > > > > -- > > > > > Matt Sicker > > > > > > > > > > > > > > > > > -- > > > > Matt Sicker > > > > > > > > > > > > -- > > > Matt Sicker > > > > > > > > -- > > Matt Sicker > > > > > -- > Matt Sicker -- Matt Sicker
Re: Looking to contribute; which areas need some love?
Thanks for the link! That looks like an even easier way to support CouchDB for sure. I'll play around with each option to see which makes more sense to prototype. On Sat, 20 Jul 2019 at 13:41, Michele Sciabarra wrote: > > A critical aspect to consider is backup. There is an operator in the work > (that is the primary reason so far to use an external CouchDB) There is an > operator in the work that may be useful > https://github.com/nicolai86/couchdb-operator > > -- > Michele Sciabarra > mich...@sciabarra.com > > > > ----- Original message - > From: Matt Sicker > To: dev@openwhisk.apache.org > Subject: Re: Looking to contribute; which areas need some love? > Date: Saturday, July 20, 2019 8:03 PM > > Continuing discussion in > https://github.com/apache/incubator-openwhisk-deploy-kube/issues/498 > > On Sat, 20 Jul 2019 at 12:48, Matt Sicker wrote: > > > > So it seems that there's an incubating chart for CouchDB already which > > might be adaptable: > > https://github.com/helm/charts/tree/master/incubator/couchdb > > > > Main difference I already see is that they offer a StatefulSet for > > clustering the CouchDB instances. Might not be too complicated. I'll > > file an issue since I wasn't able to find any existing ones. > > > > On Fri, 19 Jul 2019 at 14:41, Matt Sicker wrote: > > > > > > That does sound like an interesting thing to do. I've been looking for > > > an excuse to practice more Kubernetes things, so this could be rather > > > practical there. > > > > > > On Fri, 19 Jul 2019 at 13:21, Michele Sciabarra > > > wrote: > > > > > > > > In my opinion, given your experience with Kubernetes, a long needed > > > > feature is to add support for clustered CouchDb in the helm chart. It > > > > is the only missing pieces to allow for a true ‘production’ CouchDb. > > > > Kafka is already clustered, CouchDb is not. David recommend to use an > > > > external one but it is not always an option when you have an internal > > > > deployment for example. > > > > > > > > -- > > > > Michele Sciabarra > > > > mich...@sciabarra.com > > > > > > > > > > > > > > > > - Original message - > > > > From: Matt Sicker > > > > To: dev@openwhisk.apache.org > > > > Subject: Looking to contribute; which areas need some love? > > > > Date: Friday, July 19, 2019 7:10 PM > > > > > > > > Hey all, I've been working on some other personal project the past few > > > > weekends, but I've been itching to explore this project more and make > > > > some code contributions. I see the main openwhisk repo is Scala/Akka > > > > which is tech that I've used before. However, I'm also interested in > > > > hearing which areas feel neglected right now and could use some > > > > attention. > > > > > > > > As a bonus, this can also start an idea of adding entries to > > > > https://helpwanted.apache.org/ to recruit more contributors. I see > > > > there's already some GSoC projects going on, so this is an additional > > > > resource that can be useful here. > > > > > > > > -- > > > > Matt Sicker > > > > > > > > > > > > > -- > > > Matt Sicker > > > > > > > > -- > > Matt Sicker > > > > -- > Matt Sicker > -- Matt Sicker
Re: Looking to contribute; which areas need some love?
Continuing discussion in https://github.com/apache/incubator-openwhisk-deploy-kube/issues/498 On Sat, 20 Jul 2019 at 12:48, Matt Sicker wrote: > > So it seems that there's an incubating chart for CouchDB already which > might be adaptable: > https://github.com/helm/charts/tree/master/incubator/couchdb > > Main difference I already see is that they offer a StatefulSet for > clustering the CouchDB instances. Might not be too complicated. I'll > file an issue since I wasn't able to find any existing ones. > > On Fri, 19 Jul 2019 at 14:41, Matt Sicker wrote: > > > > That does sound like an interesting thing to do. I've been looking for > > an excuse to practice more Kubernetes things, so this could be rather > > practical there. > > > > On Fri, 19 Jul 2019 at 13:21, Michele Sciabarra > > wrote: > > > > > > In my opinion, given your experience with Kubernetes, a long needed > > > feature is to add support for clustered CouchDb in the helm chart. It is > > > the only missing pieces to allow for a true ‘production’ CouchDb. Kafka > > > is already clustered, CouchDb is not. David recommend to use an external > > > one but it is not always an option when you have an internal deployment > > > for example. > > > > > > -- > > > Michele Sciabarra > > > mich...@sciabarra.com > > > > > > > > > > > > - Original message - > > > From: Matt Sicker > > > To: dev@openwhisk.apache.org > > > Subject: Looking to contribute; which areas need some love? > > > Date: Friday, July 19, 2019 7:10 PM > > > > > > Hey all, I've been working on some other personal project the past few > > > weekends, but I've been itching to explore this project more and make > > > some code contributions. I see the main openwhisk repo is Scala/Akka > > > which is tech that I've used before. However, I'm also interested in > > > hearing which areas feel neglected right now and could use some > > > attention. > > > > > > As a bonus, this can also start an idea of adding entries to > > > https://helpwanted.apache.org/ to recruit more contributors. I see > > > there's already some GSoC projects going on, so this is an additional > > > resource that can be useful here. > > > > > > -- > > > Matt Sicker > > > > > > > > > -- > > Matt Sicker > > > > -- > Matt Sicker -- Matt Sicker
Re: Looking to contribute; which areas need some love?
So it seems that there's an incubating chart for CouchDB already which might be adaptable: https://github.com/helm/charts/tree/master/incubator/couchdb Main difference I already see is that they offer a StatefulSet for clustering the CouchDB instances. Might not be too complicated. I'll file an issue since I wasn't able to find any existing ones. On Fri, 19 Jul 2019 at 14:41, Matt Sicker wrote: > > That does sound like an interesting thing to do. I've been looking for > an excuse to practice more Kubernetes things, so this could be rather > practical there. > > On Fri, 19 Jul 2019 at 13:21, Michele Sciabarra wrote: > > > > In my opinion, given your experience with Kubernetes, a long needed feature > > is to add support for clustered CouchDb in the helm chart. It is the only > > missing pieces to allow for a true ‘production’ CouchDb. Kafka is already > > clustered, CouchDb is not. David recommend to use an external one but it is > > not always an option when you have an internal deployment for example. > > > > -- > > Michele Sciabarra > > mich...@sciabarra.com > > > > > > > > - Original message - > > From: Matt Sicker > > To: dev@openwhisk.apache.org > > Subject: Looking to contribute; which areas need some love? > > Date: Friday, July 19, 2019 7:10 PM > > > > Hey all, I've been working on some other personal project the past few > > weekends, but I've been itching to explore this project more and make > > some code contributions. I see the main openwhisk repo is Scala/Akka > > which is tech that I've used before. However, I'm also interested in > > hearing which areas feel neglected right now and could use some > > attention. > > > > As a bonus, this can also start an idea of adding entries to > > https://helpwanted.apache.org/ to recruit more contributors. I see > > there's already some GSoC projects going on, so this is an additional > > resource that can be useful here. > > > > -- > > Matt Sicker > > > > > -- > Matt Sicker -- Matt Sicker
Re: Looking to contribute; which areas need some love?
That does sound like an interesting thing to do. I've been looking for an excuse to practice more Kubernetes things, so this could be rather practical there. On Fri, 19 Jul 2019 at 13:21, Michele Sciabarra wrote: > > In my opinion, given your experience with Kubernetes, a long needed feature > is to add support for clustered CouchDb in the helm chart. It is the only > missing pieces to allow for a true ‘production’ CouchDb. Kafka is already > clustered, CouchDb is not. David recommend to use an external one but it is > not always an option when you have an internal deployment for example. > > -- > Michele Sciabarra > mich...@sciabarra.com > > > > - Original message - > From: Matt Sicker > To: dev@openwhisk.apache.org > Subject: Looking to contribute; which areas need some love? > Date: Friday, July 19, 2019 7:10 PM > > Hey all, I've been working on some other personal project the past few > weekends, but I've been itching to explore this project more and make > some code contributions. I see the main openwhisk repo is Scala/Akka > which is tech that I've used before. However, I'm also interested in > hearing which areas feel neglected right now and could use some > attention. > > As a bonus, this can also start an idea of adding entries to > https://helpwanted.apache.org/ to recruit more contributors. I see > there's already some GSoC projects going on, so this is an additional > resource that can be useful here. > > -- > Matt Sicker > -- Matt Sicker
Looking to contribute; which areas need some love?
Hey all, I've been working on some other personal project the past few weekends, but I've been itching to explore this project more and make some code contributions. I see the main openwhisk repo is Scala/Akka which is tech that I've used before. However, I'm also interested in hearing which areas feel neglected right now and could use some attention. As a bonus, this can also start an idea of adding entries to https://helpwanted.apache.org/ to recruit more contributors. I see there's already some GSoC projects going on, so this is an additional resource that can be useful here. -- Matt Sicker
Re: A direction to take in a new component, "the scheduler"
This is one of the situations where having some sort of proposal process can help align the various people and technical considerations a bit easier than mailing lists and PRs. There are numerous other communities with similar proposal processes (e.g., SIPs for Scala, KIPs for Kafka, JEPs and JSRs for Java, etc.). Using such a process can help obtain active buy-in to these changes more than a PR or dev@ post might depending on the scale of the change. On Thu, 18 Jul 2019 at 12:49, Sven Lange-Last wrote: > > Hello Dominic and other discussion participants, > > we are in the great situation that Dominic (style95) volunteers to create > and verify an alternative OpenWhisk architecture that may solve some of > the problems that adopters of OpenWhisk may observe when running > production systems with high utilization. I really appreciate that Dominic > already invested and is willing to invest so much time. > > While I encourage Dominic to experiment with a different architecture, my > point of view is that it's in the interest of the project as well as all > adopters running OpenWhisk-based production systems to keep the project > stable. We need an approach where we can continue to evolve the existing > architecture and provide bug fixes without being slowed down or affected > by the work on or problems with the new architecture. At the same time, we > need a playground where we can work on the new architecture effectively > without negatively affecting the existing architecture. > > For me, this means: > > * We need feature flags / switches as suggested by Dominic and others that > keep the existing architecture enabled by default. > > * The standard deployment only configures and installs what is needed for > the existing architecture. Installing extra components like etcd takes > more time so that development, build and test cycles take longer. In > addition, extra components consume more resources so that brittle system > tests for the existing architecture may fail more often. > > * We need a good separation between tests for existing and new > architecture. System tests are often brittle and need special resources > like etcd. Such tests for the new architecture must not be part of the > existing gradle suites. I think that stable, fast-running unit tests can > be part of existing suites. > > * The Travis checks for pull requests must not contain system tests or > other brittle / long-running tests of the new architecture. We already > have some brittle tests today that occasionally fail Travis. As Dominic > suggested, extra build / deployment / test jobs that run separately would > be a great idea. > > I would like to add a different aspect... > > My experience is that the observed problems of an OpenWhisk based system > really depend on utilization and the workload mix (memory limits, action > duration, action container image, number of distinct actions, ...). And I > would expect that people running a few activations will have totally > different observations than those people running a system with hundreds of > invokers and millions of activations with a diverse workload mix. And > based on the observed problems, different contributors will probably try > to solve different problems and set different priorities. > > I had a great discussion with Dominic on these aspects. It turned out that > he observes different problems than I do when running a large production > environment. I'm very interested in Dominic's proposal - at the same time, > my impression is that it will not necessarily address the problems I see. > Still, we can learn a lot from Dominic's work. > > At some point in time, the OpenWhisk community probably needs to decide > whether to keep the existing architecture and evolve it - or to replace it > with the suggested architecture if it proves useful. My impression is that > Dominic only received limited feedback on his proposal and I'm guilty of > providing my feedback much too late. We should discuss the problems we > observe with running OpenWhisk more openly so that contributors can align > their work with the need of others. > > > Mit freundlichen Grüßen / Regards, > > Sven Lange-Last > Senior Software Engineer > IBM Cloud Functions > Apache OpenWhisk > > > E-mail: sven.lange-l...@de.ibm.com > Find me on: > > > Schoenaicher Str. 220 > Boeblingen, 71032 > Germany > > > > > IBM Deutschland Research & Development GmbH > Vorsitzende des Aufsichtsrats: Martina Koederitz > Geschäftsführung: Dirk Wittkopp > Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, > HRB 243294 > > -- Matt Sicker
Re: Congratulations to Apache OpenWhisk, an Apache Top-level project ! (was: Progress towards graduation continues...)
Hooray! On Thu, 18 Jul 2019 at 04:49, Erez Hadad wrote: > > Hear, hear! > Cheers to all! > > Regards, > -- Erez > > Erez Hadad, PhD > Cloud System Technologies > IBM Research - Haifa > email: er...@il.ibm.com > phone: +972-4-829-6509 > > > > > > From: Bertrand Delacretaz > To: OpenWhisk Dev > Date: 18/07/2019 11:31 > Subject:[EXTERNAL] Congratulations to Apache OpenWhisk, an Apache > Top-level project ! (was: Progress towards graduation continues...) > > > > Hi, > > On Thu, Jul 18, 2019 at 9:53 AM Rob Allen wrote: > > I see that the July board meeting of the ASF that took place yesterday > contained this: > > > The following resolutions were passed unanimously: > ... > > > Establish the Apache OpenWhisk Project (Dave Grove, VP) > ... > > Yes indeed and this means graduation is effective immediately, > congratulations to the whole team! > > It usually takes 4-6 weeks for the Board minutes to be approved and > appear at > https://urldefense.proofpoint.com/v2/url?u=https-3A__whimsy.apache.org_board_minutes_=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=Oo9B0p_tCCWIIum5GpjjqA=RPjmAed3E1C9kg9qILBY6ABceHAbkwUuDRFZps6fff0=y_wl_sPQcLoZ52QxqVKvJwtcVwjefeY58JXsPASeIwk= > but as the > resolution has been approved it is effective and the tasks listed at > https://urldefense.proofpoint.com/v2/url?u=http-3A__incubator.apache.org_guides_transferring.html=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=Oo9B0p_tCCWIIum5GpjjqA=RPjmAed3E1C9kg9qILBY6ABceHAbkwUuDRFZps6fff0=lBkgZsCpv5iV8ku3088NJpqnbivwh4-LBgrAxJr7b4U= > can start for the > transition to top-level project. > > Mentoring OpenWhisk on its way to incubation has been a pleasure and I > hope to meet more of its community members face to face eventually. > > -Bertrand (Who remembers very well the first phone call that led to > this, that I took outside on Berlin's Alexanderplatz. Fond memories > already ;-) > > > > -- Matt Sicker
Re: Using Rust for the KnativeWhisk controller
Now in general, I'd suggest that we use the appropriate language for each concern. This should probably be balanced by the number of languages in use as well as how feasible it would be for a community to grow around it. Rust might be appropriate for certain components, though I don't know enough about the language to make that recommendation. I'll note that in my experience, the more common the language, the more contributors you'll tend to get. For example, at Logging Services, we have a logging framework for Java, .NET, C++, and PHP, along with language-specific API wrappers for Scala and Kotlin. Of these five languages, the only component that receives a decent amount of attention is the Java one, and that's been the case for at least ten years now based on our prior board reports (from well before I joined the project). Part of that is also just probably due to the culture of each language (e.g., Kotlin and Scala projects are mostly GitHub ones, and the larger ones are commercially-supported OSS), so that might also be something to consider. On Thu, 18 Jul 2019 at 08:54, Matt Sicker wrote: > > I’ve barely used Go, and I agree with your rant. I usually just summarize by > “no parametric polymorphism” and the language geeks can fill in the blanks of > what type of language that results in. > > In that regard, I’d support using Go only in the areas where it makes sense. > I’ve found it to be useful for a quick C alternative or for some script like > glue code. Domain services and such seem absolutely painful for the reasons > you describe. > > On Thu, Jul 18, 2019 at 06:36, Michele Sciabarra > wrote: >> >> Sigh! Having used Go for over one year and half, and being the one who built >> the Go runtime and applied to another 5 languages, I know what is wrong with >> Go. >> >> Go is terribly bare-bone and expressing everything that is a bit complex is >> an excercise in patience. And a REST server is already too complicated for >> Go. Give a look to the mess that is the prototype kwsk. >> >> The pattern "if err != nil" everywhere is just plainly silly, you have 3 >> more lines in your code, 2 of them useless, for each error. Yes of course if >> can write a function that will "panic" for each error but also this is not >> better than ignoring all the errors and panicing when you meet it. >> >> Parsing JSON is another absurdity, you have to declare a full struct when >> you just need to access to a single value and ignore the rest... or >> navigate/cast/navigate/cast the struct until you get there. >> >> If you give a look to the AWS api for example, you would like to kill >> yourself: for each function call you need to create a full struct, because >> Go does not have any optional parameter and unless you write a function with >> a ton of parameters, there are no other options. >> >> You have to do basically the same for any swagger generated server, and >> unfortunately the current prototype of OpenWhisk for Knative is generated >> with swagger, and it is an absolute mess of boilerplate code and managing >> every call with a lot of verbose code involving complex structure that maps >> all the JONS of the API. >> >> I gave a look to the Project DD and I want to die the amount of messy >> boilerplate code there is. People says that Go is readable... I disagree. >> You have to dig into the code a lot until you find what you need. All thee >> documentations are huge list of functions with very long names. Go is a zero >> structure programming language, and gives me the feeling of PHP. Lower >> barrier to entry means also a proliferation of bad code. I believe it is not >> strange that while C++ is one of hardest language is also the language used >> by the best programmers developing the greatest apps. >> >> >> Go makes sense only in a limited ecosystem with "system level" programming >> but since unfortunately it covered the niche of being a "compiled" language >> in a world where Java is losing favour because of the mismanagement of >> Oracle, and Docker provides enough isolation where having a jvm in a >> container in a virtual machine is total nonsense... So there is a comeback >> to "native" code >> >> Yes of course there is a library to make it dynamic, there are code >> generator, there are tons of tools to overcome the limitations of Go... but >> there is also a solution: use a better language. >> >> >> -- >> Michele Sciabarra >> mich...@sciabarra.com >> >> - Original message - >> From: "Markus Thömmes" >&g
Re: Using Rust for the KnativeWhisk controller
Knative > > Serving. > > > > I "only" need a way to get action code, send it to a git server and > > trigger a Tekton Build and then a Knative Serving deploy. > > > > As long as I can access the runtime I am done for this project. I will > > probably just use a script to do that. > > > > -- > > Michele Sciabarra > > mich...@sciabarra.com > > > > - Original message - > > From: Dascalita Dragos > > To: dev@openwhisk.apache.org > > Subject: Re: Using Rust for the KnativeWhisk controller > > Date: Wednesday, July 17, 2019 10:59 PM > > > > I’m inserting my +1 for Go, based on the community adoption of Go; my > > perception is that it found its place as the de-facto language for > managing > > infrastructure. Akka is amazing for distributed programming model ... > > that’s my only argument for Scala, but this argument alone is not strong > > enough to go against the stream. > > > > > > What Controller functionality are you looking to re-implement ? The API > > used by WSK CLI ? Or more ? > > > > > > dragos > > > > > > On Wed, Jul 17, 2019 at 3:25 PM Matt Sicker wrote: > > > > > Ah, yes, Rust would be good for any performance-sensitive code or > > > modules needed. I haven't kept up to date with C++ since pre-'10, but > > > I'd imagine that it's easier to learn Rust than the latest version of > > > C++ at this point. > > > > > > On Wed, 17 Jul 2019 at 08:06, Michele Sciabarra > > > > wrote: > > > > > > > > Ok guys, I give up with rust. Will use Go. > > > > > > > > > > > > -- > > > > Michele Sciabarra > > > > mich...@sciabarra.com > > > > > > > > - Original message - > > > > From: "Markus Thömmes" > > > > To: dev@openwhisk.apache.org > > > > Subject: Re: Using Rust for the KnativeWhisk controller > > > > Date: Wednesday, July 17, 2019 9:16 AM > > > > > > > > +1 to all arguments. Rust's barrier of entry is considerably higher > > than > > > > that of Scala even. As much as I like the language's design, from a > > > > community attraction point-of-view we should absolutely opt for go, > > > > especially for things that are built around Kubernetes. > > > > > > > > That's of course to be taken with a grain of salt: If we have a > > use-case > > > > that requires the performance characteristics of Rust (especially > that > > > of a > > > > lacking garbage collector), we should absolutely choose for the > > > > implementation. Implementing a controller however sounds like a > > > > business-as-usual REST talk-to-a-database thingy and Go is perfect > for > > > that. > > > > > > > > Am Di., 16. Juli 2019 um 08:53 Uhr schrieb Martin Henke < > > > martin.he...@web.de > > > > >: > > > > > > > > > Michele, > > > > > > > > > > Two thoughts: > > > > > > > > > > 1) For writing a controller in Knative I recommend to choose Go > > > instead > > > > > of Rust (even when I like Rust more). > > > > > With Go you can leverage the fantastic Operator SDK from Redhat > which > > > > > makes writing controllers fairly > > > > > simple (I had my first one up and running in under an hour). > > > > > Link: https://github.com/operator-framework/operator-sdk > > > > > > > > > > The getting started guide is a good starting point: > > > > > https://github.com/operator-framework/getting-started > > > > > > > > > > It also addresses the lifecycle of an controller with the Lifecycle > > > > > Manager: > > > > > https://github.com/operator-framework/operator-lifecycle-manager > > > > > (I have not yet used this myself) > > > > > > > > > > > > > > > 2) I think we should clearly separate the Knative work from > Openwhisk > > > and > > > > > stay there with a strict Scala only policy > > > > > (with the existing exceptions). > > > > > Introducing more languages would in my opinion lead to maintenance > > > > > problems and the waste of build up skills. > > > > > > > > > > Regards, > > > > > Martin > > >
Re: A direction to take in a new component, "the scheduler"
Ooh, I love feature flags. I don’t know enough details to say whether an incremental refactoring like that would work here, but it’s usually a better idea than a full rewrite. On Thu, Jul 18, 2019 at 08:07, Rodric Rabbah wrote: > We should put together a roadmap that shows the evolution and all presents > a coherent view of all the moving parts. > > -r > > > On Jul 18, 2019, at 8:52 AM, Markus Thömmes > wrote: > > > > Hi, > > > > this sounds a lot like the "OpenWhisk 2.0" discussion we had in an older > > thread where I proposed an architectural overhaul. See this thread for > > context: > > > https://lists.apache.org/thread.html/d19306dd976138a153f48d32c5a55f2853e4b8ff405fc46f7260e905@%3Cdev.openwhisk.apache.org%3E > > > > There have been strong opinions in the past against overhauling. > > > > Cheers, > > Markus > > > > Am Do., 18. Juli 2019 um 13:42 Uhr schrieb Dominic Kim < > style9...@gmail.com > >> : > > > >> Recently I discussed the direction and a safe way to add a new component > >> with Sven Lange-Last. > >> Let me share the discussion results. > >> More feedbacks and critique are welcomed. > >> > >> Since the implementation includes a breaking architectural change, it > comes > >> with a risk. > >> It must not break any existing downstream system as well as the upstream > >> pipelines. > >> So all implementations should be disabled by default along with proper > >> switches. > >> > >> The new change would require many iterations to become stable enough > for a > >> production system. > >> It would be better to have a new separate (openwhisk) CI pipeline for > the > >> changes. > >> All unit/system tests will only be executed on the new CI pipeline. > >> > >> I will defer to Sven, he may add more comments. > >> > >> Best regards > >> Dominic > >> > -- Matt Sicker
Re: Re: Changing JavaScript SDK NPM Module Name: openwhisk => apache-openwhisk?
It’s likely a topic that is brought up by the board once in a while for those projects. On Wed, Jul 17, 2019 at 12:06, James Thomas wrote: > I've discovered the Cordova project publishes all their project repos > without the `apache-` prefix. > https://www.npmjs.com/search?q=cordova > > Same goes for thrift (https://www.npmjs.com/package/thrift). I've > guess there's precedence that maybe this isn't an issue? > > On Mon, 15 Jul 2019 at 18:17, Matt Sicker wrote: > > > > Most or all of the Apache projects that are distributed on Homebrew > > <https://brew.sh/> are named apache-foo. > > > > ...except for `wsk` and `wskdeploy` which are curiously lacking > > `apache-` prefixes as well. ;) > > > > On Mon, 15 Jul 2019 at 12:08, Matt Rutkowski > wrote: > > > > > > I too like the dash approach unless Apache likes having a domain name > > > style which implies (family) membership hierarchy. > > > > > > > > > > > > From: Matt Sicker > > > To: dev@openwhisk.apache.org > > > Date: 07/15/2019 12:05 PM > > > Subject:[EXTERNAL] Re: Changing JavaScript SDK NPM Module Name: > > > openwhisk => apache-openwhisk? > > > > > > > > > > > > The name with the dash looks nicer, agreed. In migrating from an old > > > package name to a new one where you already have existing users, I > > > haven't seen a solution to that myself quite yet, though I know that > > > Groovy has a similar problem where their packages are still published > > > under the `org.codehaus.groovy` group id instead of > > > `org.apache.groovy`. While Maven and NPM are quite different, the > > > method of migrating a package name is similarly not well-defined in > > > both systems. > > > > > > Does anyone have more info about how NPM runs their repository? Maybe > > > they can add in some redirects of some sort. > > > > > > On Mon, 15 Jul 2019 at 11:11, James Thomas > wrote: > > > > > > > > Reviewing the ASF guidelines on NPM packages to check our JS SDK > > > satifises > > > > all the rules[1] - we're supposed to be publishing the NPM package as > > > > "apacheopenwhisk" and not "openwhisk". This NPM library was > published at > > > ( > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.npmjs.com_package_openwhisk=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=NilRlnhMriE1MNYQW3S_Ni47FW8uu-CTsXNbM3FYkH8=C-3wIDNjUO6k1tpWW7WQA9d4c-lbe7KshNS1jAR6jxM= > > > ) before the project was donated to > > > > Apache. > > > > > > > > Moving from the library to publish at `apache-openwhisk` rather than > > > > `openwhisk`[2] is not technically challenging (and the new package > name > > > is > > > > available) but will cause numerous issues > > > > > > > > I'm asking for comments on what to do about this. Would like to > engage > > > the > > > > ASF mentors for advice as well. What does the community think about > > > this? > > > > > > > > The library has significant usage (NPM tells me the library is > averaging > > > 6k > > > > downloads a week) using the existing package name. GitHub lists 38K > > > > references to the module. > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_search-3Fq-3Drequire-2528-2522openwhisk-2522-2529-26type-3DCode=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=NilRlnhMriE1MNYQW3S_Ni47FW8uu-CTsXNbM3FYkH8=nIOIJxXhbd1TkXzWJVHx9-NAMQV4JuBsXbm1pEkX8u0= > > > > > > > > > > > All those external dependent projects, blog posts, documentation and > > > > tutorials, etc, that reference the library (and are outside of our > > > control) > > > > will be reliant on the old package name. These will still work (as > the > > > old > > > > library version will still be available from NPM) but never receive > new > > > > versions on installing the dependency. This may eventually mean the > old > > > > library doesn't work with future platform changes and/or lead to > > > security > > > > issues with outdated dependencies. > > > > > > > > I'm not sure if there's any leeway in the allowing the short-name for > > > the > > > > NPM library (given we follow all the
Re: Using Rust for the KnativeWhisk controller
Ah, yes, Rust would be good for any performance-sensitive code or modules needed. I haven't kept up to date with C++ since pre-'10, but I'd imagine that it's easier to learn Rust than the latest version of C++ at this point. On Wed, 17 Jul 2019 at 08:06, Michele Sciabarra wrote: > > Ok guys, I give up with rust. Will use Go. > > > -- > Michele Sciabarra > mich...@sciabarra.com > > - Original message - > From: "Markus Thömmes" > To: dev@openwhisk.apache.org > Subject: Re: Using Rust for the KnativeWhisk controller > Date: Wednesday, July 17, 2019 9:16 AM > > +1 to all arguments. Rust's barrier of entry is considerably higher than > that of Scala even. As much as I like the language's design, from a > community attraction point-of-view we should absolutely opt for go, > especially for things that are built around Kubernetes. > > That's of course to be taken with a grain of salt: If we have a use-case > that requires the performance characteristics of Rust (especially that of a > lacking garbage collector), we should absolutely choose for the > implementation. Implementing a controller however sounds like a > business-as-usual REST talk-to-a-database thingy and Go is perfect for that. > > Am Di., 16. Juli 2019 um 08:53 Uhr schrieb Martin Henke >: > > > Michele, > > > > Two thoughts: > > > > 1) For writing a controller in Knative I recommend to choose Go instead > > of Rust (even when I like Rust more). > > With Go you can leverage the fantastic Operator SDK from Redhat which > > makes writing controllers fairly > > simple (I had my first one up and running in under an hour). > > Link: https://github.com/operator-framework/operator-sdk > > > > The getting started guide is a good starting point: > > https://github.com/operator-framework/getting-started > > > > It also addresses the lifecycle of an controller with the Lifecycle > > Manager: > > https://github.com/operator-framework/operator-lifecycle-manager > > (I have not yet used this myself) > > > > > > 2) I think we should clearly separate the Knative work from Openwhisk and > > stay there with a strict Scala only policy > > (with the existing exceptions). > > Introducing more languages would in my opinion lead to maintenance > > problems and the waste of build up skills. > > > > Regards, > > Martin > > > > > > > On 15. Jul 2019, at 11:58, Michele Sciabarra > > wrote: > > > > > > Hello all, > > > > > > In my efforts to work a Kanative Whisk, I reached the point where I have > > a kit with tekton-pipelines, knatve-serving building an actionlooop based > > runtime. Now I need to implement a controller, in order to use the existing > > wsk tooling. > > > > > > I know there is a prototype kwsk implementation made by redhat, written > > in Go but looks like it is obsolete and unfinished, and to the best of my > > knowledge, abandoned. > > > > > > I would like to resume the effort of writing an updated controller. I > > actually already have a prototype using the Julia language. Julia is really > > awesome, Python simplicity and Go speed, but I feed the community would > > disagree on using Julia. Of course if I am wrong... let me know because > > that would be my preferred choice. > > > > > > However, I feel that, given our Scala background, Rust would be a much > > better choice for the KnativeWhisk controller. So I propose to use Rust > > for the KwhiskController. > > > > > > What does the community think of the proposal? > > > > > > > > > -- > > > Michele Sciabarra > > > mich...@sciabarra.com > > > > -- Matt Sicker
Re: Re: Changing JavaScript SDK NPM Module Name: openwhisk => apache-openwhisk?
Most or all of the Apache projects that are distributed on Homebrew <https://brew.sh/> are named apache-foo. ...except for `wsk` and `wskdeploy` which are curiously lacking `apache-` prefixes as well. ;) On Mon, 15 Jul 2019 at 12:08, Matt Rutkowski wrote: > > I too like the dash approach unless Apache likes having a domain name > style which implies (family) membership hierarchy. > > > > From: Matt Sicker > To: dev@openwhisk.apache.org > Date: 07/15/2019 12:05 PM > Subject:[EXTERNAL] Re: Changing JavaScript SDK NPM Module Name: > openwhisk => apache-openwhisk? > > > > The name with the dash looks nicer, agreed. In migrating from an old > package name to a new one where you already have existing users, I > haven't seen a solution to that myself quite yet, though I know that > Groovy has a similar problem where their packages are still published > under the `org.codehaus.groovy` group id instead of > `org.apache.groovy`. While Maven and NPM are quite different, the > method of migrating a package name is similarly not well-defined in > both systems. > > Does anyone have more info about how NPM runs their repository? Maybe > they can add in some redirects of some sort. > > On Mon, 15 Jul 2019 at 11:11, James Thomas wrote: > > > > Reviewing the ASF guidelines on NPM packages to check our JS SDK > satifises > > all the rules[1] - we're supposed to be publishing the NPM package as > > "apacheopenwhisk" and not "openwhisk". This NPM library was published at > ( > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.npmjs.com_package_openwhisk=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=NilRlnhMriE1MNYQW3S_Ni47FW8uu-CTsXNbM3FYkH8=C-3wIDNjUO6k1tpWW7WQA9d4c-lbe7KshNS1jAR6jxM= > ) before the project was donated to > > Apache. > > > > Moving from the library to publish at `apache-openwhisk` rather than > > `openwhisk`[2] is not technically challenging (and the new package name > is > > available) but will cause numerous issues > > > > I'm asking for comments on what to do about this. Would like to engage > the > > ASF mentors for advice as well. What does the community think about > this? > > > > The library has significant usage (NPM tells me the library is averaging > 6k > > downloads a week) using the existing package name. GitHub lists 38K > > references to the module. > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_search-3Fq-3Drequire-2528-2522openwhisk-2522-2529-26type-3DCode=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=NilRlnhMriE1MNYQW3S_Ni47FW8uu-CTsXNbM3FYkH8=nIOIJxXhbd1TkXzWJVHx9-NAMQV4JuBsXbm1pEkX8u0= > > > > > All those external dependent projects, blog posts, documentation and > > tutorials, etc, that reference the library (and are outside of our > control) > > will be reliant on the old package name. These will still work (as the > old > > library version will still be available from NPM) but never receive new > > versions on installing the dependency. This may eventually mean the old > > library doesn't work with future platform changes and/or lead to > security > > issues with outdated dependencies. > > > > I'm not sure if there's any leeway in the allowing the short-name for > the > > NPM library (given we follow all the other requirements)? This will be a > > significant amount of work just changing all the references in project > we > > control. > > > > If we do change the name - I'd assume `apache-openwhisk` is fine. Using > > `apacheopenwhisk` is slightly horrid > > > > [1] - > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_pages_viewpage.action-3FpageId-3D109454613=DwIBaQ=jf_iaSHvJObTbx-siA1ZOg=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw=NilRlnhMriE1MNYQW3S_Ni47FW8uu-CTsXNbM3FYkH8=ZshMeW40IVmdVpBrfK3b_ERcnaA4Bh7h3iqXvO_NDCc= > > > [2] - following NPM JS module conventions - apache-openwhisk is much > > preferable than a single word (apacheopenwhisk). > > > > -- > > Regards, > > James Thomas > > > > -- > Matt Sicker > > > > > -- Matt Sicker
Re: Using Rust for the KnativeWhisk controller
Oh wow, I didn't even know about the Scala repos myself; I need to dig around the code more! I really like Scala, though it has been a barrier to entry for several other projects that aren't Scala-specific (i.e., servers, databases, applications in general; for concrete examples, see Kafka and Spark). Go makes sense from an ecosystem point of view, though I don't have any strong opinions on that language other than it's still lacking parametric polymorphism, but so is C, so whatever. It's much easier to use and learn than C, so that is a huge plus for attracting more developers. It's also far easier to use than C++, another bonus. Rust sounds like a fantastic language, though without a larger developer community around it yet, it might not be appropriate for anything major or we'll end up with even less contributors than in the Scala case. Java also has some things in the pipeline for this which might be useful to consider if there's any desire to gradually port the Scala code to Java or something like that. On Mon, 15 Jul 2019 at 11:33, James Thomas wrote: > > +1 to what Matt has said. I've had this feedback multiple times from > developers that the usage of Scala is a barrier to getting involved in the > project. I understand the historical reasons for chosing Scala and realise > the language does give us lots of benefits for stability & productivity > once learnt. However, for new projects I'd +1 on using Go in the future. > > On Mon, 15 Jul 2019 at 17:20, Matt Rutkowski wrote: > > > IMO, one of the largest barriers to getting more (back-end) developers > > into OW has been the use of Scala (sig. learning curve will not even > > consider mounting) is by implementing in languages where the pool of active > > developers is lower. It seems that nearly 100% of Serverless technology > > "in the open" is being done in GoLang. If we wish to attract developers > > from Knative, OpenFaaS, Kubeless, Fission, Fn, IronFunctions, etc., they > > ALL use Go (which is not surprising as everyone is more-or-less looking at > > a Kube stack, also Go, for CN apps with Serverless being a subset). > > > > Personally, after experiencing Go, for wskdeploy/CLI it was a joy to learn > > (despite some tooling annoyances) and have listed it as a top requirement > > developers training. In fact, I had assumed that as we seek to mainstream > > on a Kube deployment we would want to unify around Go to continue to be > > relevant in the Serverless developer community in order to lower the > > barrier to entry/growth. > > > > My 2 cents. > > > > On 2019/07/15 09:58:58, "Michele Sciabarra" > > wrote: > > > Hello all, > > > > > > In my efforts to work a Kanative Whisk, I reached the point where I have > > a kit with tekton-pipelines, knatve-serving building an actionlooop based > > runtime. Now I need to implement a controller, in order to use the existing > > wsk tooling. > > > > > > I know there is a prototype kwsk implementation made by redhat, written > > in Go but looks like it is obsolete and unfinished, and to the best of my > > knowledge, abandoned. > > > > > > I would like to resume the effort of writing an updated controller. I > > actually already have a prototype using the Julia language. Julia is really > > awesome, Python simplicity and Go speed, but I feed the community would > > disagree on using Julia. Of course if I am wrong... let me know because > > that would be my preferred choice. > > > > > > However, I feel that, given our Scala background, Rust would be a much > > better choice for the KnativeWhisk controller. So I propose to use Rust > > for the KwhiskController. > > > > > > What does the community think of the proposal? > > > > > > > > > -- > > > Michele Sciabarra > > > mich...@sciabarra.com > > > > > > > > -- > Regards, > James Thomas -- Matt Sicker
Re: Welcome new PPMC members
Welcome, Rob and Michele! On Mon, 15 Jul 2019 at 11:44, Rodric Rabbah wrote: > > It is my pleasure to share that the OpenWhisk PPMC voted to invite Rob > Allen and Michele Sciabarra as new PPMC members based on their ongoing and > valuable contributions to the project. They have both accepted the > invitation. Rob and Michele were already project committers. > > Please join me in welcoming them to this new role on the project! > > -r -- Matt Sicker
Re: Updating our contributions guide
I've looked around for some existing guidelines around CLA requirements, and so far I've found this: https://www.apache.org/licenses/contributor-agreements.html#clas This relates eventually to the provenance of source code hosted at the ASF: https://www.apache.org/foundation/license-faq.html#provenance So basically, the general idea I've seen is that small, trivial changes do not require an ICLA, but anything non-trivial should request one in order to establish provenance of the code over time. Remember, safe, business-friendly licensing of all our software is the key point to address here, so anything we do here should align with that. Since trivial contributions are not usually covered by copyright, there's no need to establish more formalities around them. Larger ones would retain their own new copyright, and the ICLA is there to help ensure the contributions are made along the same rules as the ALv2. On Tue, 9 Jul 2019 at 03:06, Rodric Rabbah wrote: > > It was pointed out that our contributing guide sets a higher bar than other > Apache projects by requiring an ICLA. > > Looking at some of the other successful Apache projects they do a better job > explaining how to contribute, and all the ways someone can be contributor, > and how to open a PR, testing and how reviewing works. > > Should we revise the guidelines and contributions doc? Is anyone else > interested in helping out on these docs? > > -r -- Matt Sicker
Re: dockerhub "latest" update
Great progress! On Thu, 4 Jul 2019 at 17:50, David P Grove wrote: > > > > TL;DR: I changed `latest` on virtually all images yesterday. Some issues > in downstream repo CI/CD. Will work through them this weekend. > > In more detail, OpenWhisk has 50 repositories on dockerhub. 36 of them > are active (still being published/used). > > Of the active 36: > + for 25 of these repos, `latest` now corresponds to the image built from > the most recent Apache release (and the release is part of our current > "wave") > > + for 6 of these repos (5 runtimes + 1 kube-only image), there has not > been an official release and I removed the latest tag. I think for these 6 > the lack of latest has no real impact. > > + for 4 repos (ow-utils, invoker, controller, and scala), the last > official release was 9+ months ago, so I removed latest instead of setting > it to 0.9.0-incubating. This is exposing places we need to adjust in > downstream gitrepos. > > + the 36th repo is wskdeploy. I did not do anything here yet (I think we > may be able to eliminate this image entirely. If not, we need to modernize > its setup to tag with git hash commits). > > Gory details. Appended is the list of repos with a note of what latest is > now pointing to. (A few deprecated repos still have a latest tag for now > because they only contain one image called latest). > > ---dave > > > Active Images > - > > # Runtimes > action-ballerina-v0.990.2 -- NO RELEASE; REMOVED LATEST > actionloop-rust-v1.34 -- NO RELEASE; REMOVED LATEST > > actionloop-golang-v1.12 -- NO RELEASE; REMOVED LATEST > actionloop-java-v8 -- NO RELEASE; REMOVED LATEST > actionloop-ruby-v2.6 -- NO RELEASE; REMOVED LATEST > > actionloop-v2 -- DONE (1.13.0-incubating) > dockerskeleton -- DONE (1.13.0-incubating) > > action-dotnet-v2.2 -- DONE (1.13.0-incubating) > > actionloop-golang-v1.11 -- DONE (1.13.0-incubating) > > java8action -- DONE (1.13.0-incubating) > > nodejs6action -- DONE (1.14.0-incubating) > nodejsactionbase -- DONE (1.14.0-incubating) > action-nodejs-v8 -- DONE (1.14.0-incubating) > action-nodejs-v10 -- DONE (1.14.0-incubating) > action-nodejs-v12 -- DONE (1.14.0-incubating) > > action-php-v7.1 -- DONE (1.13.0-incubating) > action-php-v7.2 -- DONE (1.13.0-incubating) > action-php-v7.3 -- DONE (1.13.0-incubating) > > python2action -- DONE (1.13.0-incubating) > actionloop-python-v3.7 -- DONE (1.13.0-incubating) > python3aiaction -- DONE (1.13.0-incubating) > python3action -- DONE (1.13.0-incubating) > > action-ruby-v2.5 -- DONE (1.13.0-incubating) > > action-swift-v4.1 -- DONE (1.13.0-incubating) > action-swift-v4.2 -- DONE (1.13.0-incubating) > > # Core System > ow-utils -- REMOVED LATEST > invoker -- REMOVED LATEST > controller -- REMOVED LATEST > scala -- REMOVED LATEST > apigateway -- DONE (0.10.0-incubating) > > alarmprovider -- DONE (2.0.0-incubating) > cloudantprovider -- DONE (2.0.0-incubating) > kafkaprovider -- DONE (2.0.0-incubating) > > kube-invoker-agent -- NO RELEASE; REMOVED LATEST > > > # MISC > example -- DONE (1.13.0-incubating) > > wskdeploy TODO: Do we really need this image??? > > > Deprecated Images > --- > > # Old runtimes > > actionloop -- NO RELEASE; REMOVED LATEST > action-ballerina-v0.975 -- -- NO RELEASE; REMOVED LATEST > actionloop-golang-v1.10 -- tagged with master, no latest tag > action-swift-v3.1.1 -- NO RELEASE; REMOVED LATEST > action-swift-v4.0 -- NO RELEASE; REMOVED LATEST > swift3action -- NO RELEASE; REMOVED LATEST > javaaction > > # Samples > thumbnail > asciiart > spellcheck > > # Misc Stuff > ansible-runner -- NO RELEASE; REMOVED LATEST > script-runner -- NO RELEASE; REMOVED LATEST > couchdb-catalog > couchdb-snapshot -- NO RELEASE; REMOVED LATEST -- Matt Sicker
Re: automated builds of all runtimes now publishing using `nightly`
Fantastic, thanks for handling this! On Sun, 30 Jun 2019 at 06:19, David P Grove wrote: > > > > The travis setup for all the runtime repos has been changed to use the > nightly tag to indicate the most recent build from the master branch. > > I've submitted a PR to update runtimes.json for core repo's master branch > accordingly [1]. > > My plan is that 48 hours after [1] merges, I will go through all the > runtime images on dockerhub and change the latest tag to refer to the image > that was built from the last official release (1.13.0-incubating). In some > cases (due to image naming convention changes after the 1.13.0-incubating > release), there is no such tag. I believe in most (all?) cases I can > simply do some docker operations to publish the appropriate version of the > old-style name image under the new-style name with the 1.13.0-incubating > tag. > > --dave > > [1] https://github.com/apache/incubator-openwhisk/pull/4529 -- Matt Sicker
Re: [DISCUSS] Final draft of project Charter and graduation Resolution
"Serverless" and "Function" should probably be lowercase. Otherwise looks good! On Thu, 27 Jun 2019 at 10:40, Matt Rutkowski wrote: > > Given the feedback from previous threads both public and private on this > Resolution topic, including input from mentors, and the recent apparent > confirmation of Dave Grove as proposed VP/Chair for a future PMC being the > sole remaining nominee, I have updated the Wiki to represent the final draft > of the Resolution we would send to the IPMC general list for their review and > subsequent VOTE there. > > Please comment on this thread (and/or Wiki draft page) if anyone has any > changes we should make before sending to the IPMC. > > draft link: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=115526932 > > thx, > mr -- Matt Sicker
Re: exporting activation arguments to the environment
Based on the giant mess in Jenkins where parameters and environment variables sometimes get conflated, I'd definitely recommend making them separate, especially for inevitable security issues found related to them. ;) On Thu, 27 Jun 2019 at 07:00, Rodric Rabbah wrote: > > Thanks for the added feedback - keep it coming! > > Tyson is right in that we shouldn't let implementation concerns affect a > proper design and sacrifcie the experience. > > So in line with his concerns, is there a desire to facilitate environment > variables at all (user specified values, not system/context ones)? > > If so, then having thought about it some more, annotating every parameter > could be done as suggested say with a -e vs a -p. > > -r -- Matt Sicker
Re: oauth token verification in the controller
Using JWT with independently distributed keys for verifying authorization info has worked best for overall performance in my experience so far (in microservices generally; not tested with OW). Using that pattern minimizes auth server contact thanks to cryptographic verification of the JWT. Also handy against brute force attacks and other denial of service vectors. Has anyone tried that out yet using the oauth support? I’ve done exploration in the past for designing a highly available authorization service, and utilizing JWT (or some other message signing/encryption protocol) to validate the auth data provided by the auth server on login. I can dig up the blog post if anyone is interested. On Mon, Jun 24, 2019 at 22:07, Dominic Kim wrote: > It might not be directly related to the agenda but one small thing to note > is the response time of the auth/authz server should be considered as well. > When I implemented LDAP integration, the LDAP server was too slow. > It took about 100ms ~ 1s to authenticate users. > Even though I took advantage of the cache, I could not reduce the cold > start(in terms of authentication) latency, and I had to drop the LDAP > integration in the end. > In my case, LDAP is legacy, I didn't have many choices. > > So if the authentication backend is not fast as enough, you might need to > ponder some ways to overcome it. > > Regards > Dominic > > 2019년 6월 24일 (월) 오전 1:56, Martin Henke 님이 작성: > > > Rodric, > > > > IBM Cloud Functions hasn’t implemented OAuth, but JWT based bearer token > > based authentication based on the IBM Cloud IAM system. > > > > The first problem we encountered was that our bearer token did not > provide > > a namespace related context > > (which is only configured in the IAM system). The only obvious namespace > > related information is contained in the URI (but unfortunately not always > > when looking at the _ default). > > > > The next problem was the need to construct the Identity object (of which > > the namespace information is a key component) fully in the authorization > > code to not break the API handling (which brings us back to the missing > > namespace information). > > > > We overcame the problems by asking the user to provide missing namespace > > information via additional headers and by retrieving additional > > authorization related data from proprietiary data stores. > > > > There were more problems in the realm to provide the meaningful error > > messages. > > Nevertheless our implementation proves that OW is already able to handle > > JWT based bearer tokens and provide them to be used in outbound calls. > > > > Regards, > > Martin > > > > > Am 21.06.2019 um 13:23 schrieb Rodric Rabbah : > > > > > > 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 > > > > > -- Matt Sicker
Re: oauth token verification in the controller
As a budding security engineer, I’ll suggest to emphasize role based security authorization rather than a permission model. It’s easier to maintain over time, and it’ll map well to OAuth scopes as well as in JWT metadata, plus it’ll likely still adapt well to whatever new security standards are invented. On Fri, Jun 21, 2019 at 06:56, Carlos Santana wrote: > 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 > -- Matt Sicker
Re: Openwhisk in a standalone runnable jar (#4516)
Very cool! Port 8080 is a highly conflicted default port, though. ;) On Tue, 18 Jun 2019 at 08:37, Felix Meschberger wrote: > > Wow ! This goes a long way to developer ease of getting to know. > > Kudos ! > > Regards > Felix > > > Am 18.06.2019 um 15:22 schrieb Chetan Mehrotra : > > > > Hi Team, > > > > Recently based on some feedback by end users I felt a need for a > > simpler way to test out OpenWhisk for end users. Towards that end > > there is a new PR #4516 which enables launching OpenWhisk as a simple > > runnable jar. > > > > java -jar openwhisk-standalone-1.0.0-SNAPSHOT.jar > > > > Post this OpenWhisk server would be accessible over 8080 port and wsk > > can be configured to us that > > > > More details are provided at #4516 [1]. > > > > Thoughts? > > > > Chetan Mehrotra > > [1] https://github.com/apache/incubator-openwhisk/pull/4516 > -- Matt Sicker
Re: [ACTION REQUIRED] Nominations for PMC Chair for TLP graduation resolution
I'll note as a PMC Chair of another project here, it's not a heavy burden at all, especially if you're already reading the mailing lists and participating in release votes. Please be encouraged to volunteer to chair the PMC! On Tue, 18 Jun 2019 at 12:15, Rodric Rabbah wrote: > > This link http://www.apache.org/dev/pmc.html#chair is helpful to understand > the duties of the PMC chair. > > -r -- Matt Sicker
Re: status of openwhisk components releases
How well documented is release management here? Or how well automated would be an interesting question too. On Fri, Jun 14, 2019 at 14:27, Rodric Rabbah wrote: > Per this issue > https://github.com/apache/incubator-openwhisk-release/issues/241 we are > almost ready to cut a new release of the openwhisk repo. The last release > of the main repo was 0.9 and I wonder if we should cut the new release at > 1.0. Thoughts? > > We need to create a release candidate for the catalog and then we're ready > to work on the main repo! > > Anyone interested in being a release manager for either repo? I'm told > there are swag rewards too. > > -r > -- Matt Sicker
Re: managing our project trademarks
Yes, that'd be a great idea. Surprisingly, it's not that prominent on Maven's own site. Here's an example of their own docs about it: https://maven.apache.org/guides/plugin/guide-java-plugin-development.html On Wed, 12 Jun 2019 at 14:46, Rodric Rabbah wrote: > > > For example, the official project plugins follow a naming scheme of > maven-foo-plugin, while third party plugins follow a naming scheme of > foo-maven-plugin. Similar to the distinction between “Apache Maven Foo > Plugin” versus “Foo Plugin for Apache Maven”. > > This is useful - are you suggesting we document this on the trademarks page > also? > > > -r -- Matt Sicker
Re: managing our project trademarks
Good idea to define naming schemes like how maven does for plugins. For example, the official project plugins follow a naming scheme of maven-foo-plugin, while third party plugins follow a naming scheme of foo-maven-plugin. Similar to the distinction between “Apache Maven Foo Plugin” versus “Foo Plugin for Apache Maven”. Following Spark’s example is probably a good bet since they’re one of the top projects that gets trademark violations in the wild that I know of. On Wed, Jun 12, 2019 at 12:12, Matt Rutkowski wrote: > Rodric, > > Great reference and agree with Bertrand that we should copy Spark's > stellar example. > > To that end, please review PR which accomplishes that goal: > https://github.com/apache/incubator-openwhisk-website/pull/387/files > > Thanks, > Matt > > On 2019/06/12 11:15:51, Rodric Rabbah wrote: > > The discussion about our graduation on the general list [1] led to a > > question relating to how we manage the project trademarks. Specifically, > > our project website does not provide any guidance we can point to when > > needed. We have previously discussed the use of the OpenWhisk name in a > > prior instance [2] but did not document our guidance on the website. > Apache > > Spark is one example that might be useful for reference, available at > > http://spark.apache.org/trademarks.html. It provides appropriate links > to > > the ASF [3] and summarizes the key points of the policy. > > > > This email is to solicit help authoring our own project trademarks policy > > summary page, and to solicit feedback on additional points to summarize > > relating to the use of the name OpenWhisk. > > > > For example, how do we handle the use of OpenWhisk in a GitHub repository > > name? A small sample of searches on popular Apache project names leads > one > > to believe this is quite common. In some cases it may be sufficient for > > the repository to use the full project name "Apache OpenWhisk" > prominently > > in the project description and first mentions in the documentation (with > > links to the project website). When do we require an acknowledgement of > the > > trademark, or ask a repository to be renamed? > > > > -r > > > > [1] > > > https://lists.apache.org/thread.html/02dd71dcc6b2f326015954388c61d06d12f982fd64f34ee40e076171@%3Cgeneral.incubator.apache.org%3E > > > > [2] > > > https://lists.apache.org/thread.html/99e2431472d015fb23af38d1c2dab47ef9eb5a8a980cf2b80ca0035b@%3Cdev.openwhisk.apache.org%3E > > > > [3] https://www.apache.org/foundation/marks/faq/#products > > > -- Matt Sicker
Re: [REVIEW] draft proposal for TLP project charter and ASF board resolution
I'd suggest to avoid boxing ourselves in by an overly specific project mission. Anything that helps clarify the general field this project encompasses without being too specific about underlying technology. You can be more specific on the website, but it's not a great idea to get too formal in the legal documents without understanding their ramifications. :) On Thu, 6 Jun 2019 at 01:28, Rodric Rabbah wrote: > > I tweaked the wording a little Matt wrt faas/serverless. > > > should we say anything about supporting Cloud Native (i.e., 12-factors > implied, portable to any Container framework)? > > this is a good idea. "serverless" is still new and foreign to people > outside the serverless bubble. > > -r > > On Tue, Jun 4, 2019 at 1:56 PM Matt Rutkowski wrote: > > > > > > > On 2019/05/29 19:05:37, Matt Rutkowski wrote: > > > Dear Whiskers, > > > > > > As a community we have been discussing the possibility of graduation for > > quite some time. In the wake of the last legal hurdle being cleared (i.e., > > IBM completed transfer of all trademarks and name registrations to the ASF > > board) and in anticipation of a VOTE thread, I have created a page on our > > CWiki for drafting 2 artifacts we would need to present to the board as > > part of the process, that is the graduated project Charter (simple, > > straightforward) and the Resolution (which references the charter/project > > scope) to become a Top-Level-Project (TLP). > > > > > > I am asking you all, as you did for the Maturity model review, to please > > help develop/review/comment on these items as well: > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=115526932 > > > > > > Note that some background and links that describe the process and > > artifacts are included on the page as well. > > > > > > FYI, I brought this up as a topic on the agenda of today's Tech. Int. > > call if you want my unedited "take" on the process and these items: > > https://www.youtube.com/watch?v=kxxTLBC1QD8 > > > > > > Thanks for your help! > > > -Matt > > > > > > > Please check out the charter (simple sentence derived from our CWiki tag > > line) on proposal page and let me know if we should amend it in any way > > My Qs... > > > > do I need to say FaaS to qualify Serverless? > > should we say anything about supporting Cloud Native (i.e., 12-factors > > implied, portable to any Container framework)? > > -- Matt Sicker
Re: [VOTE] Apache OpenWhisk graduation to Top Level Project
+1 Exciting times ahead! On Tue, 4 Jun 2019 at 16:28, Dave Grove wrote: > > +1 Apache OpenWhisk should graduate. > > --dave > > On 2019/06/04 21:25:28, Rodric Rabbah wrote: > > 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://lists.apache.org/thread.html/8daa3a05148f54ca82458777e2b2b5e25ba99d39dcf8ce7dd85d0188@%3Cdev.openwhisk.apache.org%3E > > [2] > > https://cwiki.apache.org/confluence/display/OPENWHISK/Project+Maturity+Model > > [3] > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=115526932 > > [4] > > https://incubator.apache.org/guides/graduation.html#community_graduation_vote > > -- Matt Sicker
Re: Re: Incubator status report
I still can't edit the wiki. On Mon, 3 Jun 2019 at 09:55, Bertrand Delacretaz wrote: > > On Mon, Jun 3, 2019 at 4:50 PM Matt Rutkowski wrote: > >... You should now have edit access to the Wiki,.. > > Works indeed, thank you! > -Bertrand -- Matt Sicker
Re: [RESULT] [VOTE] Release Apache OpenWhisk API Gateway (v0.10.0-incubating, rc2)
Will do. On Mon, 3 Jun 2019 at 11:15, Dave Grove wrote: > > The voting is now closed. > > The vote has passed with 5 +1 votes (Rabbah, Dragos, Hamann, Thomas, > Rutowski) and no other votes cast. > > I will kick off an IPMC vote next. OpenWhisk mentors, please vote on the > IPMC thread so we can get our three binding +1 votes to move forward with > this release. > > --dave > > On 2019/05/29 21:50:35, "David P Grove" wrote: > > > > > > Hi, > > > > As discussed in [2], there was a regression in rc1 of apigateway. so > > we needed to generate a new release candidate once the fix had been merged. > > That has been done. Therefore... > > > > This is a call to vote on releasing version 0.10.0-incubating release > > candidate rc2 of the following project module with artifacts built from the > > Git repositories and commit IDs listed below. > > > > * OpenWhisk API Gateway: a737552c > > https://github.com/apache/incubator-openwhisk-apigateway/commits/a737552c > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc2/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc2/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz.asc > > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc2/openwhisk-apigateway-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-apigateway 'OpenWhisk API Gateway' 0.10.0-incubating > > rc2 > > > > 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 > > [2] > > https://lists.apache.org/thread.html/3a33c365fb755f364385bff06ac681912fd1af7a43a9b58a881d6b85@%3Cdev.openwhisk.apache.org%3E > > -- Matt Sicker
Re: Podling Report Reminder - June 2019
I did try to sign off on it, though I can’t edit the wiki yet. On Mon, Jun 3, 2019 at 06:42, Rob Allen wrote: > HI Bertrand, > > I think that Dave Grove said that he would be posting it on 4th June. > > Regards, > > Rob > > > On 3 Jun 2019, at 12:39, Bertrand Delacretaz > wrote: > > > > On Mon, Jun 3, 2019 at 12:22 PM Bertrand Delacretaz > > wrote: > >> ...The report needs to be submitted at > >> https://cwiki.apache.org/confluence/display/INCUBATOR/May2019 > > > > Sorry that's > https://cwiki.apache.org/confluence/display/INCUBATOR/June2019 > > > > -Bertrand > > -- Matt Sicker
Re: Incubator status report
+1 I can't seem to edit the wiki page, so you can add a signoff from me. On Tue, 28 May 2019 at 16:35, David P Grove wrote: > > > Our quarterly status report is due before June 5. > > I have created a page for us to draft out report here: > https://cwiki.apache.org/confluence/display/OPENWHISK/June+2019 > > NOTE: The Incubator reports are now using markdown formatting. This is > different than previous reports we have done. > > Please, just use markdown formatting within our report to make it easier to > cut & paste the contents directly into the overall incubator report. Do not > do any additional cwiki formatting,; use plain markdown. > > thanks, > > --dave -- Matt Sicker
Re: [jdk11] - Difference in java.time.Instant creation causing test failure
Isn’t there a truncate method on most of the temporal classes? You can truncate to milliseconds. On Tue, May 28, 2019 at 10:02, Chetan Mehrotra wrote: > Hi Team, > > As part of supporting JDK 11 I am seeing some test failure due to > change in behavior of way java.time.Instant now works. As noted in [1] > [2] with JDK 11 Instant.now is constructed with microsecond precision > [3] compared to millisecond in JDK 8 [4]. > > This causes issue when entities in test are compared after and before > persisting in DB. When we store the entity in DB then its stored with > millisecond precision while the in memory entity refers to Instant > value with microsecond precision which leads to test failures [5] when > such entity instances are checked for equality. > > So far my understanding is that this change in behaviour impacts on > test code and most likely it should not impact production code. > > So need to find a way to retain old behaviour for Instant. Possible options > > 1. Create an extension method for Instant like `Instant.nowInMillis` > and use that in Test case > 2. Use a custom `WhiskInstant` in our entity classes to have full > control on precision > > Any other which team may suggest > > Thoughts? > > Chetan Mehrotra > [1] > https://github.com/apache/incubator-openwhisk/issues/4217#issuecomment-496469481 > [2] https://github.com/h2database/h2database/issues/1178 > [3] > https://github.com/openjdk/jdk/blob/jdk-11%2B28/src/java.base/share/classes/java/time/Clock.java#L524 > [4] > https://github.com/openjdk/jdk/blob/jdk8-b120/jdk/src/share/classes/java/time/Clock.java#L470 > [5] https://scans.gradle.com/s/sf7udehikj6g2/tests/failed > -- Matt Sicker
Re: Podling Report Reminder - June 2019
Oh nice, my first report I can help out with. On Wed, 22 May 2019 at 03:41, 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, 19 June 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, June 05). > > 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://cwiki.apache.org/confluence/display/INCUBATOR/June2019 > > Note: This is manually populated. You may need to wait a little before > this page is created from a template. > > Note: The format of the report has changed to use markdown. > > 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 -- Matt Sicker
Re: A plan to (re) implement OpenWhisk on top of Knative
oo for the ingress part. I also plan to install a local Docker registry > >>>> Kubernetes registry, so we do not have to use DockerHub for everything. > >>>> All > >>>> of this can be done with existing command line tools in a few minutes in > >>>> any running Kubernetes deployment. > >>>> > >> > >>> Why specifying Gloo here? Do you need anything specific from Gloo itself? > >>> If not I'd propose to just keep it on a Knative Serving API surface level. > >> I want to build it on top of Knative serving, full stop. Currently, > >> installing Gloo is pretty easy and is more lightweight than Istio so I > >> will use it for my first implementation. > >> > >>>> > >>>> When I create an action, it will use Knative build that will work roughly > >>>> in this way: > >>>> > >>>> - create a configmap with the action code > >>>> - build the actin using ActionLoop precompilation feature that will > >>>> return > >>>> a zip file including all the needed to run the action > >>>> - create a new docker image extending the runtime with the new zip, using > >>>> Kaanico > >>>> - push the image in the local registry > >>> This feels like a fairly heavyweight process, we should be able to come up > >>> with a way to circumvent zipping entirely. Maybe the runtime can detect > >>> that the unzipped content is already there and skip the unzip step? > >> > >> Actually this is my first idea of how to use Knative build. And is not > >> complicated: when I create the action, a run a build that includes Kanico. > >> I generate a Dockerfile on the fly. The docker file uses the action > >> runtime that already know how to compile a script. And then I save an > >> image. I already implemented un "autoinit" so just launching the image > >> will give a runtime ready to run that execute an action already compiled. > >> > >> > >>> I'm fairly hesitant on the usage of a ConfigMap for storing the action > >>> code. It's all stored in the in-cluster etcd instance and it has a limit > >>> of > >>> 1M. This is at most a stop-gap solution to provide a PoC I think. Any > >>> ideas > >>> on how to "productize" this? > >> > >> ConfigMap can be mounted as files, so it is an easy way to feed an action > >> to a build. It is just an easy way to feed the action code to the Build. > >> > >> My initial constraint is that I want just to generate Kubernetes > >> descriptors to feed to kubectl. > >> Of course in the long run I can add some "file upload" storage. > >> > >> If I could to this file upload when invoking a build it could ideal as I > >> do not have to store anything anywhere, just process the code and generate > >> a single layer to execute actions to be store in the registry. > >> I will investigate better this area, I understand your concern. > >> > >>> > >>>> At this point you can run the action. ActionLoop will be extended to > >>>> support invocations in the format > >>>> "/v1/namespaces/namespace/actions/package/action". > >>> Why bother reimplementing this exact path? To obtain API compatibility > >>> with > >>> OpenWhisk as it is today? > >> > >> I want to implement a subset of the OpenWhisk API on top of Knative > >> serving. > >> Knative serving already does the scaling and routing, so what we need are > >> the "endpoints" to invoke actions. > >> > >> Since I do not want to add additional components, not at the first stage. > >> Just knative serve and build, the runtime and a controller script, the > >> runtime is the natural place where to "handle" the API invocations, since > >> Knative only generates the URL but not anything else. If I understood > >> well, Matt is adding a proxy. I do not want to add a proxy, just add to > >> the runtime the ability to respond to "API like" calls, at least those > >> regarding action invocation. > >> > >>>> It will do all the decoding required to invoke the action with the > >>>> expected paramenters (straight invocation thrhoug the actinloop protocol, > >>>> not proxies). > >>> Does this mean moving all of the Controller's "smartness" about incoming > >>> and outgoing HTTP requests (see the whole WebActions for example)? > >> > >> At least decoding web actions in the runtime, yes. Knative serving already > >> has routing and proxying. > >> So a true implementation on top of Knative requires IHMO this sacrifice. > >> Unless there is a way to keep the controller in a "Knative" compatible > >> way. Open to suggestions here. > >> > >>> Each action will then be exposed using an ingress with its specific > >>> invocation path. > >>> > >>> If the community agrees with this plan, I would create a repo > >>> `incubator-openwhisk-knative` to work on it. > >>> > >>> Thoughts? -- Matt Sicker
Re: Write down some documents which describe OW internals
I like the documentation approach as it allows for more documentation-driven feature enhancements. Similar to what I've suggested in the past about OpenWhisk Improvement Proposals. Also nice for more casual contributors who would otherwise be too intimidated by such a broad project. On Thu, 18 Apr 2019 at 03:56, Bertrand Delacretaz wrote: > > Hi, > > On Thu, Apr 18, 2019 at 10:44 AM Dominic Kim wrote: > > ...Initially, I`ve naively thought of two options. > > 1. Including docs in core repo. > > 2. Including docs in cwiki or wiki in core repo. ... > > To me a third option is blog posts, which have the advantage that they > don't need to be maintained: they express your current view, which > might still be valuable later even if it gets out of sync when things > evolve. OpenWhisk can get a blog at https://blogs.apache.org/ if > desired, or a blog section might be created at > http://openwhisk.apache.org/ for more informal content than what's > there now. > > Apart from that, consolidating docs is great, of course - I just > wanted to mention the difference between reference docs and > informative articles which are also useful. > > -Bertrand -- Matt Sicker
Re: Please include rcverify logs inline in vote emails
Agreed, good idea. On Tue, Apr 9, 2019 at 04:59, Carlos Santana wrote: > 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 > -- Matt Sicker
Re: [VOTE] Release Apache OpenWhisk Composer (v0.11.0-incubating, rc2)
+1 Verified with rcverify and false positives verified manually. On Fri, 5 Apr 2019 at 04:21, Rob Allen wrote: > > Hi, > > I am +1 to release OpenWhisk Composer: > 6bc3405280176e55618853ee8eae284c6e603806 > > Verified with rcverify & spot checks. > > Release verification checklist for reference: > > [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 > > > Regards, > > Rob > > > On 4 Apr 2019, at 22:23, Olivier Tardieu wrote: > > > > Hi, > > > > This is a call to vote on releasing version 0.11.0-incubating release > > candidate rc2 of the following 1 project modules with artifacts > > built from the Git repositories and commit IDs listed below. > > > > * OpenWhisk Composer: 6bc3405280176e55618853ee8eae284c6e603806 > > > > https://github.com/apache/incubator-openwhisk-composer.git/commits/6bc3405280176e55618853ee8eae284c6e603806 > > > > 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-composer 'OpenWhisk Composer' 0.11.0-incubating rc2 > > > > 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. > > > > Olivier > > > > -- > Development thoughts at http://akrabat.com > Daily Jotter for macOS at http://dailyjotter.com > -- Matt Sicker
Re: [VOTE] Release Apache OpenWhisk Runtime Go (v1.13.0-incubating, rc2)
Sorry, that looks like a false positive. Everything else passes verification by the script. On Sun, 7 Apr 2019 at 12:01, Matt Sicker wrote: > > Output from rcverify.sh: > > scanning for binaries... failed > (/var/folders/kv/8jx_1xhx50l86vzzmzhltd2cgn/T/tmp.xNrnFc0z/incubator-openwhisk-runtime-go-1.13.0-incubating/openwhisk/_test/pysample/exec) > > On Sun, 7 Apr 2019 at 08:28, Rodric Rabbah wrote: > > > > Hi, > > > > This is a call to vote on releasing version 1.13.0-incubating release > > candidate rc2 of the following project module with artifacts > > built from the Git repositories and commit IDs listed below. > > > > * OpenWhisk Runtime Go: ddd329946c1d061f256a274d6ccd23e527760e06 > > > > https://github.com/apache/incubator-openwhisk-runtime-go.git/commits/ddd329946c1d061f256a274d6ccd23e527760e06 > > > > 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-go 'OpenWhisk Runtime Go' 1.13.0-incubating > > rc2 > > > > 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. > > > > -- > Matt Sicker -- Matt Sicker
Re: [VOTE] Release Apache OpenWhisk Runtimes (v1.13.0-incubating, rc1)
+1 for all but the Go runtime (but +1 for the Go rc2) On Wed, 3 Apr 2019 at 11:31, 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 -- Matt Sicker
Re: [VOTE] Release Apache OpenWhisk Runtime Go (v1.13.0-incubating, rc2)
+1 On Sun, 7 Apr 2019 at 12:03, Matt Sicker wrote: > > Sorry, that looks like a false positive. Everything else passes > verification by the script. > > On Sun, 7 Apr 2019 at 12:01, Matt Sicker wrote: > > > > Output from rcverify.sh: > > > > scanning for binaries... failed > > (/var/folders/kv/8jx_1xhx50l86vzzmzhltd2cgn/T/tmp.xNrnFc0z/incubator-openwhisk-runtime-go-1.13.0-incubating/openwhisk/_test/pysample/exec) > > > > On Sun, 7 Apr 2019 at 08:28, Rodric Rabbah wrote: > > > > > > Hi, > > > > > > This is a call to vote on releasing version 1.13.0-incubating release > > > candidate rc2 of the following project module with artifacts > > > built from the Git repositories and commit IDs listed below. > > > > > > * OpenWhisk Runtime Go: ddd329946c1d061f256a274d6ccd23e527760e06 > > > > > > https://github.com/apache/incubator-openwhisk-runtime-go.git/commits/ddd329946c1d061f256a274d6ccd23e527760e06 > > > > > > 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-go 'OpenWhisk Runtime Go' 1.13.0-incubating > > > rc2 > > > > > > 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. > > > > > > > > -- > > Matt Sicker > > > > -- > Matt Sicker -- Matt Sicker
Re: [VOTE] Release Apache OpenWhisk Runtime Go (v1.13.0-incubating, rc2)
Output from rcverify.sh: scanning for binaries... failed (/var/folders/kv/8jx_1xhx50l86vzzmzhltd2cgn/T/tmp.xNrnFc0z/incubator-openwhisk-runtime-go-1.13.0-incubating/openwhisk/_test/pysample/exec) On Sun, 7 Apr 2019 at 08:28, Rodric Rabbah wrote: > > Hi, > > This is a call to vote on releasing version 1.13.0-incubating release > candidate rc2 of the following project module with artifacts > built from the Git repositories and commit IDs listed below. > > * OpenWhisk Runtime Go: ddd329946c1d061f256a274d6ccd23e527760e06 > > https://github.com/apache/incubator-openwhisk-runtime-go.git/commits/ddd329946c1d061f256a274d6ccd23e527760e06 > > 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-go 'OpenWhisk Runtime Go' 1.13.0-incubating rc2 > > 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. -- Matt Sicker
Re: [VOTE] release Apache OpenWhisk Package Alarm, Package Cloudant, and Package Kafka 2.0.0 (incubating)
+1 to the full checklist. Neat that there's an easy to use python script for helping validate. On Tue, 26 Mar 2019 at 07:48, David P Grove wrote: > > > > The Apache OpenWhisk Community has voted to make the first Apache release > of the OpenWhisk "Package Alarm", "Package Cloudant" and "Package Kafka" > components. > > The OpenWhisk dev list voting thread is here: > https://lists.apache.org/thread.html/e0fb73d8ca0d0c584650f4f5b8b02054f5c99d64895f3e5ace352234@%3Cdev.openwhisk.apache.org%3E > > We request that IPMC Members please review and vote on this incubator > release as described below. > > These three Apache OpenWhisk packages provide basic event-based programming > capabilities to an OpenWhisk deployment. > > This release comprises of source code distribution only. There are three > components (git repos) included in this release of the OpenWhisk Packages > Group. All release artifacts were built by PR#251 in the openwhisk-release > repo from the following Git commit IDs: > * openwhisk-package-alarms: dd6ab4d81c8893436e7242170d57951c089d5185 > * openwhisk-package-cloudant: ce5dac9cb0204fb2f78195d9e3f9364236613a31 > * openwhisk-package-kafka: 49820dd24170f24a37c02fae6ba7ec06e190423f > > openwhisk-package-alarms (C158D76 B5D9A53A AC10AC42 4CD5060C 7A6467D5 > E9624519 117E9C8C AB171590 CCC3505D 5C7E630D C41769B4 44F85F03 BBA40A6A > E04D2264 79FFA78B B3C5BFB8) > src.tar.gz: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-alarms-2.0.0-incubating-sources.tar.gz > sha512 checksum: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-alarms-2.0.0-incubating-sources.tar.gz > .sha512 > signature: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-alarms-2.0.0-incubating-sources.tar.gz > .asc > > openwhisk-package-cloudant (380E1BA8 EC3C72A8 09B10DCF 03BC1D2D 4BFA7E4F > 892995EE 39D26BBE 758AFD5D FA680E81 54A9C726 A0D386C5 B447C947 70D26385 > 2A8D07BF 5848318A 42A3BBDD) > src.tar.gz: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-cloudant-2.0.0-incubating-sources.tar.gz > sha512 checksum: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-cloudant-2.0.0-incubating-sources.tar.gz > .sha512 > signature: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-cloudant-2.0.0-incubating-sources.tar.gz > .asc > > openwhisk-package-kafka (303B8286 AA9B945D 1A740FCB 0DE908D5 A287FAF5 > C20A9DF9 4BBD2F16 C488DF4B 3E82A75B 9D071B1A E1CCDB54 7B623A36 5AC88E5D > 9994539B 00ECEA5D A066D156) > src.tar.gz: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-kafka-2.0.0-incubating-sources.tar.gz > sha512 checksum: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-kafka-2.0.0-incubating-sources.tar.gz > .sha512 > signature: > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-2.0.0-incubating-rc2/openwhisk-package-kafka-2.0.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 version 2.0.0-incubating of Apache OpenWhisk > Package Alarm, Package Cloudant, and Package Kafka as described above. > > The vote will be open for at least 72 hours. > [ ] +1 Release Apache OpenWhisk Package Alarm, Package Cloudant, and > Package Kafka 2.0.0-incubating > [ ] +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 -- Matt Sicker
Re: Execute OpenWhisk action via AWS Lambda
This sounds pretty neat. Could it lead to OpenWhisk being like the Kubernetes of serverless? :) On Fri, 29 Mar 2019 at 02:34, Bertrand Delacretaz wrote: > > Hi Chetan, > > On Fri, Mar 29, 2019 at 7:09 AM Chetan Mehrotra wrote: > > ...We recently did a POC around executing actions deployed on OpenWhisk > > via AWS Lambda... > > I think you forgot a link to https://en.wikipedia.org/wiki/Inception ;-) > > > ...3. Invoker can delegate execution to Lambda based on some policy... > > Out of curiosity, what kind of policies do you envision? > > Annotate the functions to indicate that they should run on Lambda, > decide based on the current load of other compute providers, these > kinds of things? > > -Bertrand -- Matt Sicker
Re: Pausing actions, waiting for human input etc.
What you're describing sounds a lot like what Jenkins does for user input steps in a build. A stateful task manager is required to do this as you've been exploring. For debugging purposes, do you think it may be simpler to write a dedicated service around this, or would a more serverless approach be that straightforward? I'm not very clear on the implementation details myself, so this is sort of spitballing here. On Wed, 27 Mar 2019 at 10:10, Bertrand Delacretaz wrote: > > Hi, > > Thank you everybody for you replies. > > I understand implementing this directly in OpenWhisk is challenging, > and especially this comment from Olivier: > > On Tue, Mar 26, 2019 at 6:12 PM Olivier Tardieu wrote: > > ...Alternatively, the dynamic creation of trigger-like and rule-like things > > can be pushed to an external system outside of OpenWhisk. This > > addresses issue number 2 and can also help with 1... > > makes me think that it's worth looking at how a distinct "state > machine service" can help with that, rather than making complex > changes to OpenWhisk itself. > > Maybe that service can be a set of OpenWhisk Actions...that would > avoid having to deploy additional services (outside of states > persistence) while not having to make core changes. At the cost of > some performance probably, but if it's about slow human-driven or > batch processing workflows that might not be a real problem. > > I'll think about a minimal prototype that would demonstrate that and > share it here if I succeed. > > -Bertrand -- Matt Sicker
Re: [RESULT][VOTE] Release Apache OpenWhisk Client JS (incubating) 3.19.0
On Tue, 26 Mar 2019 at 12:07, James Thomas wrote: > Non-binding +1: > Matt Sicker I think this might be wrong now that I'm a mentor? Or does it only apply to the IPMC vote? -- Matt Sicker
Re: Added a "Security" page to website with simple, OW-specific instructions for vuln. reporting
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
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
Re: Added a "Security" page to website with simple, OW-specific instructions for vuln. reporting
I'm not exactly sure on the process, but I think it's important to use a security-specific mailing list for tracking purposes. If the reports don't filter through secur...@apache.org, it makes sense to make a dedicated security@ mailing list for the project. On Wed, 20 Mar 2019 at 11:57, Rodric Rabbah wrote: > > Looks good to me - thanks Matt. > > -r -- Matt Sicker
Re: [VOTE] Release Apache OpenWhisk Client JS (incubating) 3.19.0
che.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 > > > > > > -- Matt Sicker
Re: [DISCUSS] graduation from the incubator
Oh, and if you all figure out a way to easily digest the notification info for dev@, that would be really cool, though I wouldn't consider it necessary for graduation. Other ASF projects I've either worked with or observed will all have their own spammy notification email for archiving all the commits, issues, and comments. Finding a way to make that more usable for contributors would be awesome, but I believe that is an orthogonal concern to synchronous chat in general. Then again, if you can digest a digest like that, maybe it will help more than I'd expect? On Tue, 19 Mar 2019 at 13:27, Matt Sicker wrote: > > So I have some agreements with Bertrand here. I obviously don't work > on this project full time (my full time work is involved in developing > Jenkins), and the Slack digests, while useful, are nearly impossible > to read whenever a large amount of discussion happens during a day, > particularly because synchronous communication is mixed in with the > typical development talk that would benefit most from being > asynchronous. Another limitation I find there is that I can't exactly > reply to digests, so having a longer term conversation that way > doesn't exactly work. > > Suppose, for example, I'm a contributor from a timezone not typically > aligned with the times most of the full time engineers work on this > project. Then having a back and forth conversation on Slack can easily > get lost in the history, particularly because I haven't exactly seen > judicious use of threads, either (which are themselves limited to a > single level of threading unlike email). The large amounts of > unnecessary messages that come in with a digest make it much harder to > follow the technical discussions compared to, say, the threads I've > seen on dev@ and GitHub issues. This also makes it harder for anyone > who didn't see the initial Slack thread to contribute to the > discussion. > > In all, I'm very impressed by the maturity of this project so far. > It's certainly a production-ready project from what I can tell, but > I'm still concerned about the chat. This would still be a concern even > if the ASF hosted Slack itself (which isn't currently possible > anyways) or some other chat service. Basically, in a distributed OSS > project like with ASF projects, I'd expect to be able to contribute > outside work hours (e.g., nights and weekends) as a hobby, and having > communications be focused in media such as mailing lists, forums, and > issue trackers makes it much easier to keep up to date with things, > filter out topics I don't care about, and maintain conversations over > a period longer than a few hours or days. For a work comparison, do > you bother reading all your missed Slack messages when you come back > from a week or two of vacation? If so, you're much faster than I am at > communication, and I'm already reading way too many mailing lists as > it is. :D > > My suggestion as to how to improve this wouldn't be the daily digest. > My suggestion would be to ensure any development conversations that > take place on Slack should be recreated on the mailing lists. This can > be based on or start from the digest or chat log, but coming up with a > summary of what was discussed along with providing an easier to use > anchor point for further discussion would go a long way toward helping > address this disconnect. As we typically say over in Commons or the > other more volunteer-driven projects at ASF: if it didn't happen on > the mailing list, it didn't happen! > > On Tue, 19 Mar 2019 at 12:25, Michael Marth wrote: > > > > Matt, all, > > > > Strongly agree. > > My understanding is that moving from ASF incubator to TLP is not (at all) a > > statement about the technology but a statement about the community, its > > diversity (in terms of stakeholders) and ability to carry forward the > > project. I agree with everyone on this thread that OpenWhisk has proven to > > have achieved that mile stone > > > > (but it does not hurt the cause to say that the technology runs in > > production and is solid) > > > > Cheers > > Michael > > > > > > > > On 19.03.19, 16:56, "Matt Rutkowski" wrote: > > > > Thanks Dave for raising graduation as a topic. > > > > To be clear... +1 (with stars) from me on moving to graduate... > > > > It is my belief that this project has reached a maturity level, with > > credits to its devoted community, over the last 2 plus years to graduate. > > It has been no small task to bring under Apache compliance the numerous > > repos. this project manages and to deal with the ever-changing landscape of > > Serverless and remain relevant as
Re: [DISCUSS] graduation from the incubator
urity model matrix on our CWIKI (see > https://cwiki.apache.org/confluence/display/OPENWHISK/Project+Maturity+Model) > to the best of my abilities and will be asking for comment/review/edits on a > separate thread once I complete my draft pass. > > In truth, over the course of the last 2 years, I have have truly > witnessed the community itself become a welcoming family that cares first and > foremost about the code and improving and enabling it for its user base while > establishing friendships that transcend other affiliations. > > Cheers, > Matt > > > On 2019/03/15 22:06:38, "David P Grove" wrote: > > > > > > I'd like to kick off a discussion to assess the project's readiness for > > graduation from the incubator. > > > > Per Rodric's recent stats [1], the community has developed nicely in > terms > > of code contribution. > > > > We've released a number of software components following the Apache > release > > process. We are in the midst of making our first "uber-release" across > all > > of our sub-components (expect at least 2 voting threads next week). > > > > Overall I think the community is active. Communication on the project > > slack is frequent (avg of >160 messages a day) and is now digested > daily to > > the dev list. (See [2] for stats). > > > > There are a couple procedural tasks we still need to complete, foremost > > being the formal transfer of the OpenWhisk trademarks from IBM to the > ASF. > > But I think we can assume that these tasks will be completed and start > > considering graduation in parallel. > > > > Please share your thoughts, > > > > --dave > > > > [1] > > > https://lists.apache.org/thread.html/b2217c61caad5c7a0369699d06d44e5cf688d3cba982e354a45b8c78@%3Cdev.openwhisk.apache.org%3E > > [2] > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103091999 > > > > -- Matt Sicker
Re: [VOTE] release Apache OpenWhisk CLI 0.10.0-incubating
+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. Some notes from testing releases: * Disclaimer file would be nice to have reflowed as a normal text file with ~80 character width limits, or at least written like a typical text source file where each sentence is on its own line. Sort of a personal preference, though when you compare the disclaimer with the other usual files (LICENSE and NOTICE), it's not consistent. * client-go doesn't seem to have any tests? I ran `make test` and got an error of no tests being available, though `make integration_test` passed ok. * Tested with Gradle 5.2.1 and Go 1.12.1. See next point for why. * I know this debate has been had ad nauseum, but including gradle wrapper scripts without the bootstrap binary (which isn't allowed, I know) makes it kind of pointless to include. This is more of an issue for people like myself who don't use Gradle that often but rely on scripts like gdub <https://github.com/dougborg/gdub> to help manage Gradle usage. I've seen some efforts on the Maven wrapper side of things to try and make a self-booting Java source file or similar to download the wrapper binary at runtime, and such a thing might be doable as a Groovy script or a Java "script" (Java 11 style). This is a usability concern to me because typical users who install Gradle on their machine will only have the latest version of Gradle available, so if your build isn't compatible with, say, 4.10.x or 5.2.x (e.g., some people still use Gradle 2.x, and 4.x is the first release of Gradle that removed deprecated APIs from 2.x), then I have the fun job of figuring out which version of Gradle I need. :( - For comparison, I didn't need to install some specific version of Make or Maven to test anything else. - I also just filed a ticket with gdub <https://github.com/dougborg/gdub/issues/31> to help support this use case. We'll see if this becomes a non-problem. :) * I haven't really combed through literally every file to ensure license headers and notice are correct, though I'm assuming this has been kept up to date so far. If that's not the case, then I'll have to dig through these releases in more depth next time. -- Matt Sicker
Greetings
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
