Re: I created a variant of the go runtime that is faster at init time
The go repo could hold the code to produce the 3 runtime images For example: action-loop-v1.0.1:tag action-go-v1.11:tag action-gccgo-v1.10:tag - Carlos Santana @csantanapr > On Dec 12, 2018, at 9:25 AM, Rodric Rabbah wrote: > > +1 “I think it would be better to organize around 1 git repo per language.” > > -r > >> On Dec 12, 2018, at 9:21 AM, David P Grove wrote: >> >> For the runtimes specifically, if it is technically feasible I think it >> would be better to organize around 1 git repo per language. >> >> That repo could contain multiple runtime variants with different degrees of >> maturity. Several of the runtime repos already contain multiple variants >> (nodejs, php, python). Can that pattern work for go too? >> >> --dave >> >> Carlos Santana ---12/12/2018 07:26:56 AM---My 2 cents about the "contrib" >> repo for best effort support and experimental code we already have a >> >> From: Carlos Santana >> To: dev@openwhisk.apache.org >> Date: 12/12/2018 07:26 AM >> Subject: Re: I created a variant of the go runtime that is faster at init >> time >> >> >> >> >> My 2 cents about the "contrib" repo for best effort support and >> experimental code we already have a repo >> >> It used be named incubator-openwhisk-experimental, but then we rename it to >> incubator-openwhisk-devtools [1] >> >> If any one has some cool experiments we have created a new folder in the >> repo and add some trivial travis test >> >> [1] https://github.com/apache/incubator-openwhisk-devtools >> -cs >> >> On Wed, Dec 12, 2018 at 2:13 AM Michele Sciabarra >> wrote: >> >>> Hmm, I understand the concern but I wonder HOW the "convenience" binaries >>> should be handled in practice. >>> >>> In OpenWhisk what it matters is the runtime you specify with --docker, so >>> that "convenience" is not really just a convenience, it is a core >>> requirement. >>> >>> We could setup an openwhisk contrib repository, but I cannot image a >>> single Travis build to be able to rebuild many images (at the moment I have >>> at least 4) and push all of them to docker hub... >>> >>> >>> -- >>> Michele Sciabarra >>> mich...@sciabarra.com >>> >>> - Original message - >>> From: Felix Meschberger >>> To: "dev@openwhisk.apache.org" >>> Subject: Re: I created a variant of the go runtime that is faster at init >>> time >>> Date: Wed, 12 Dec 2018 10:00:07 + >>> >>> Hi Michele >>> >>> This is shaky ground and we don’t want to be the next npm horror story. >>> >>> Technically speaking, at Apache we primarily release source packages, all >>> binary is pure convenience. Granted the convience today is what most people >>> use. >>> >>> So what we should primarily do, as Bertrand hinted, is have a contrib >>> repository. We can still have a contrib docker account into which the >>> OpenWhisk PMC can regularly „dump“ binary builds for convience. But it must >>> be clearly stated that those are not releases, have no release quality and >>> all the usual disclaimers. >>> >>> Regards >>> Felix >>> Am 12.12.2018 um 10:55 schrieb Michele Sciabarra >>> : Actually more than an account on GitHub it is important to have a docker >>> hub account named "openwhisk-contrib" so you can deploy an action with >>> something like: wsk create myaction --docker openwhisk-contrib/actionloop-gccgo-v1.10 To publish images, you can do sothing as simple as ask, maybe opening a >>> ticket, to push an image msciab/actionloop-gccgo-v1.10 to openwhisk-contrib/actionloop-gccgo-v1.10. -- Michele Sciabarra mich...@sciabarra.com - Original message - From: Bertrand Delacretaz To: dev@openwhisk.apache.org Subject: Re: I created a variant of the go runtime that is faster at >>> init time Date: Wed, 12 Dec 2018 10:45:43 +0100 Hi, On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra wrote: > > Indeed I was thinking to create a docker account "openwhisk-contrib" >>> to place those, let's say, unofficial images. > I am not sure who should own this account... Accounts with "openwhisk" in their name should be owned by the OpenWhisk (P)PMC as the name is a trademark of the Apache Software Foundation - technically being donated as we speak IIUC but that doesn't make a real difference. However what we are discussing here IMO is code repositories as code is what the ASF produces. I guess Felix's suggestion is to create one or a few openwhisk-contrib-* Git repositories under https://github.com/apache/ for such "contrib" modules. -Bertrand >>> >>> >> >> -- >> Carlos Santana >> >> >> >>
Re: "nightly" releases of clis (was Graduation)
Hi Bertrand, I hope I addressed some of your most recent comments with my PRs today. Please view the updated page here: https://openwhisk.incubator.apache.org/downloads.html Thanks, Matt On 2018/12/12 08:02:48, Bertrand Delacretaz wrote: > Hi Matt, > > On Tue, Dec 11, 2018 at 7:32 PM Matt Rutkowski wrote: > > ...https://github.com/apache/incubator-openwhisk-website/pull/353 ... > > Thank you very much for this. I like it, with a few minor comments. > > I'd prefer saying "Apache Releases" or "Apache OpenWhisk Releases" > instead of "Official Releases". > > It would be good to link to > http://www.apache.org/legal/release-policy.html somewhere, to provide > background information. > > > In some special cases, Committers on the project may choose to use > > GitHub to tag certain builds... > > Does that automatically cause those builds to appear as releases like > at https://github.com/apache/incubator-openwhisk-wskdeploy/releases ? > If not, GitHub tags are perfectly ok of course, but I think the mix of > Apache Releases and tagged builds there is a major source of confusion > and should be avoided. > > I would expect tags to appear only at (for example) > https://github.com/apache/incubator-openwhisk-wskdeploy/tags - and > document tag naming conventions might be useful for clarity if there > are none so far. > > -Bertrand >
Re: publishing developer-oriented binary artifacts
Thanks Dave for consolidating the various points of discussion. This is very helpful and the thoughtful recommendations. I agree on all parts with your assessment and direction, and will help out on driving the releases so we can get to a more cogent point. -r > On Dec 12, 2018, at 9:16 AM, David P Grove wrote: > > > > We have related conversations on mail threads [1] and [2]. I suggest we > consolidate to a new thread to nail down a policy that we can document. I > suspect it is pretty close to what we are operationally doing already, but > we need to write it down. > > 1. Publishing on dockerhub. > a. I suggest we only have one official dockerhub user, openwhisk. > Having multiple dockerhub accounts publishing on behalf of the project is > more likely to cause confusion about which images are sanctioned. > b. We should be uniformly tagging all developer-focused "nightly" docker > images with a git short hash (as done by the runtimes and core repo > already). This makes it very clear these are nightly/developer builds and > not sanctioned releases. > c. We should reserve the use of x.y.z semantic version tags for docker > images that exactly correspond to an official Apache Source Release. > d. Because of (c), we should be making more frequent Apache releases, > especially of the runtimes. Our release automation process makes this only > moderately burdensome and the more we use it, the easier it will become. > > 2. Publishing the wsk and wskdeploy clis > a. I think Carlos has mostly covered this in [3]. Key point is the > reservation of semantic versioning x.y.z tags to artifacts that correspond > to official Apache releases. > b. I do think it might be useful to preserve some number of previous > git-hash tagged interim releases of the clis, instead of always overwriting > 'latest', but perhaps this is harder to automate. > c. Again, we probably need to be making more frequent official Apache > source releases to provide the source artifacts that can generate > convenience binaries with x.y.z versions in a reasonable cadence. > > 3. Publishing on maven, npmjs, PyPI, etc. > a. Same basic principles, only artifacts that are directly derived from > an Apache source release can use semantic versioning tags. > b. To the extent supported by the package repository, we have a single > official project account for publishing artifacts. > > --dave > > [1] > https://lists.apache.org/thread.html/05ab690fc0c2acc17103dd183262180efaf27cdd78c49cc35c48f659@%3Cdev.openwhisk.apache.org%3E > [2] > https://lists.apache.org/thread.html/606120e4aaacce6b7940d070e86ae44aad7685d1d4191a5d3697f0c9@%3Cdev.openwhisk.apache.org%3E > [3] > https://lists.apache.org/thread.html/606120e4aaacce6b7940d070e86ae44aad7685d1d4191a5d3697f0c9@%3Cdev.openwhisk.apache.org%3E
Re: I created a variant of the go runtime that is faster at init time
+1 “I think it would be better to organize around 1 git repo per language.” -r > On Dec 12, 2018, at 9:21 AM, David P Grove wrote: > > For the runtimes specifically, if it is technically feasible I think it would > be better to organize around 1 git repo per language. > > That repo could contain multiple runtime variants with different degrees of > maturity. Several of the runtime repos already contain multiple variants > (nodejs, php, python). Can that pattern work for go too? > > --dave > > Carlos Santana ---12/12/2018 07:26:56 AM---My 2 cents about the "contrib" > repo for best effort support and experimental code we already have a > > From: Carlos Santana > To: dev@openwhisk.apache.org > Date: 12/12/2018 07:26 AM > Subject: Re: I created a variant of the go runtime that is faster at init time > > > > > My 2 cents about the "contrib" repo for best effort support and > experimental code we already have a repo > > It used be named incubator-openwhisk-experimental, but then we rename it to > incubator-openwhisk-devtools [1] > > If any one has some cool experiments we have created a new folder in the > repo and add some trivial travis test > > [1] https://github.com/apache/incubator-openwhisk-devtools > -cs > > On Wed, Dec 12, 2018 at 2:13 AM Michele Sciabarra > wrote: > > > Hmm, I understand the concern but I wonder HOW the "convenience" binaries > > should be handled in practice. > > > > In OpenWhisk what it matters is the runtime you specify with --docker, so > > that "convenience" is not really just a convenience, it is a core > > requirement. > > > > We could setup an openwhisk contrib repository, but I cannot image a > > single Travis build to be able to rebuild many images (at the moment I have > > at least 4) and push all of them to docker hub... > > > > > > -- > > Michele Sciabarra > > mich...@sciabarra.com > > > > - Original message - > > From: Felix Meschberger > > To: "dev@openwhisk.apache.org" > > Subject: Re: I created a variant of the go runtime that is faster at init > > time > > Date: Wed, 12 Dec 2018 10:00:07 + > > > > Hi Michele > > > > This is shaky ground and we don’t want to be the next npm horror story. > > > > Technically speaking, at Apache we primarily release source packages, all > > binary is pure convenience. Granted the convience today is what most people > > use. > > > > So what we should primarily do, as Bertrand hinted, is have a contrib > > repository. We can still have a contrib docker account into which the > > OpenWhisk PMC can regularly „dump“ binary builds for convience. But it must > > be clearly stated that those are not releases, have no release quality and > > all the usual disclaimers. > > > > Regards > > Felix > > > > > Am 12.12.2018 um 10:55 schrieb Michele Sciabarra > >: > > > > > > Actually more than an account on GitHub it is important to have a docker > > hub account named "openwhisk-contrib" so you can deploy an action with > > something like: > > > > > > wsk create myaction --docker openwhisk-contrib/actionloop-gccgo-v1.10 > > > > > > To publish images, you can do sothing as simple as ask, maybe opening a > > ticket, to push an image msciab/actionloop-gccgo-v1.10 > > > to openwhisk-contrib/actionloop-gccgo-v1.10. > > > > > > > > > > > > -- > > > Michele Sciabarra > > > mich...@sciabarra.com > > > > > > - Original message - > > > From: Bertrand Delacretaz > > > To: dev@openwhisk.apache.org > > > Subject: Re: I created a variant of the go runtime that is faster at > > init time > > > Date: Wed, 12 Dec 2018 10:45:43 +0100 > > > > > > Hi, > > > > > > On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra > > > wrote: > > >> > > >> Indeed I was thinking to create a docker account "openwhisk-contrib" > > to place those, let's say, unofficial images. > > >> I am not sure who should own this account... > > > > > > Accounts with "openwhisk" in their name should be owned by the > > > OpenWhisk (P)PMC as the name is a trademark of the Apache Software > > > Foundation - technically being donated as we speak IIUC but that > > > doesn't make a real difference. > > > > > > However what we are discussing here IMO is code repositories as code > > > is what the ASF produces. I guess Felix's suggestion is to create one > > > or a few openwhisk-contrib-* Git repositories under > > > https://github.com/apache/ for such "contrib" modules. > > > > > > -Bertrand > > > > > > -- > Carlos Santana > > > >
Re: I created a variant of the go runtime that is faster at init time
For the runtimes specifically, if it is technically feasible I think it would be better to organize around 1 git repo per language. That repo could contain multiple runtime variants with different degrees of maturity. Several of the runtime repos already contain multiple variants (nodejs, php, python). Can that pattern work for go too? --dave From: Carlos Santana To: dev@openwhisk.apache.org Date: 12/12/2018 07:26 AM Subject:Re: I created a variant of the go runtime that is faster at init time My 2 cents about the "contrib" repo for best effort support and experimental code we already have a repo It used be named incubator-openwhisk-experimental, but then we rename it to incubator-openwhisk-devtools [1] If any one has some cool experiments we have created a new folder in the repo and add some trivial travis test [1] https://github.com/apache/incubator-openwhisk-devtools -cs On Wed, Dec 12, 2018 at 2:13 AM Michele Sciabarra wrote: > Hmm, I understand the concern but I wonder HOW the "convenience" binaries > should be handled in practice. > > In OpenWhisk what it matters is the runtime you specify with --docker, so > that "convenience" is not really just a convenience, it is a core > requirement. > > We could setup an openwhisk contrib repository, but I cannot image a > single Travis build to be able to rebuild many images (at the moment I have > at least 4) and push all of them to docker hub... > > > -- > Michele Sciabarra > mich...@sciabarra.com > > - Original message - > From: Felix Meschberger > To: "dev@openwhisk.apache.org" > Subject: Re: I created a variant of the go runtime that is faster at init > time > Date: Wed, 12 Dec 2018 10:00:07 + > > Hi Michele > > This is shaky ground and we don’t want to be the next npm horror story. > > Technically speaking, at Apache we primarily release source packages, all > binary is pure convenience. Granted the convience today is what most people > use. > > So what we should primarily do, as Bertrand hinted, is have a contrib > repository. We can still have a contrib docker account into which the > OpenWhisk PMC can regularly „dump“ binary builds for convience. But it must > be clearly stated that those are not releases, have no release quality and > all the usual disclaimers. > > Regards > Felix > > > Am 12.12.2018 um 10:55 schrieb Michele Sciabarra >: > > > > Actually more than an account on GitHub it is important to have a docker > hub account named "openwhisk-contrib" so you can deploy an action with > something like: > > > > wsk create myaction --docker openwhisk-contrib/actionloop-gccgo-v1.10 > > > > To publish images, you can do sothing as simple as ask, maybe opening a > ticket, to push an image msciab/actionloop-gccgo-v1.10 > > to openwhisk-contrib/actionloop-gccgo-v1.10. > > > > > > > > -- > > Michele Sciabarra > > mich...@sciabarra.com > > > > - Original message - > > From: Bertrand Delacretaz > > To: dev@openwhisk.apache.org > > Subject: Re: I created a variant of the go runtime that is faster at > init time > > Date: Wed, 12 Dec 2018 10:45:43 +0100 > > > > Hi, > > > > On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra > > wrote: > >> > >> Indeed I was thinking to create a docker account "openwhisk-contrib" > to place those, let's say, unofficial images. > >> I am not sure who should own this account... > > > > Accounts with "openwhisk" in their name should be owned by the > > OpenWhisk (P)PMC as the name is a trademark of the Apache Software > > Foundation - technically being donated as we speak IIUC but that > > doesn't make a real difference. > > > > However what we are discussing here IMO is code repositories as code > > is what the ASF produces. I guess Felix's suggestion is to create one > > or a few openwhisk-contrib-* Git repositories under > > https://github.com/apache/ for such "contrib" modules. > > > > -Bertrand > > -- Carlos Santana
publishing developer-oriented binary artifacts
We have related conversations on mail threads [1] and [2]. I suggest we consolidate to a new thread to nail down a policy that we can document. I suspect it is pretty close to what we are operationally doing already, but we need to write it down. 1. Publishing on dockerhub. a. I suggest we only have one official dockerhub user, openwhisk. Having multiple dockerhub accounts publishing on behalf of the project is more likely to cause confusion about which images are sanctioned. b. We should be uniformly tagging all developer-focused "nightly" docker images with a git short hash (as done by the runtimes and core repo already). This makes it very clear these are nightly/developer builds and not sanctioned releases. c. We should reserve the use of x.y.z semantic version tags for docker images that exactly correspond to an official Apache Source Release. d. Because of (c), we should be making more frequent Apache releases, especially of the runtimes. Our release automation process makes this only moderately burdensome and the more we use it, the easier it will become. 2. Publishing the wsk and wskdeploy clis a. I think Carlos has mostly covered this in [3]. Key point is the reservation of semantic versioning x.y.z tags to artifacts that correspond to official Apache releases. b. I do think it might be useful to preserve some number of previous git-hash tagged interim releases of the clis, instead of always overwriting 'latest', but perhaps this is harder to automate. c. Again, we probably need to be making more frequent official Apache source releases to provide the source artifacts that can generate convenience binaries with x.y.z versions in a reasonable cadence. 3. Publishing on maven, npmjs, PyPI, etc. a. Same basic principles, only artifacts that are directly derived from an Apache source release can use semantic versioning tags. b. To the extent supported by the package repository, we have a single official project account for publishing artifacts. --dave [1] https://lists.apache.org/thread.html/05ab690fc0c2acc17103dd183262180efaf27cdd78c49cc35c48f659@%3Cdev.openwhisk.apache.org%3E [2] https://lists.apache.org/thread.html/606120e4aaacce6b7940d070e86ae44aad7685d1d4191a5d3697f0c9@%3Cdev.openwhisk.apache.org%3E [3] https://lists.apache.org/thread.html/606120e4aaacce6b7940d070e86ae44aad7685d1d4191a5d3697f0c9@%3Cdev.openwhisk.apache.org%3E
Re: I created a variant of the go runtime that is faster at init time
The book is name learning OpenWhisk, it’s ok to have a matching Github .org/repo I don’t see any problem you are not using “openwhisk” to miss represent I think to make it legit, send request to the PPMC at priv...@openwhisk.apache.org asking if it’s ok. This is similar as if someone that wants to create a cool logo T-shirt for an OpenWhisk learning workshop Meetup and what to use the logo or brand or modify the logo a bit. - Carlos Santana @csantanapr > On Dec 12, 2018, at 5:50 AM, Michele Sciabarra wrote: > > >> Accounts with "openwhisk" in their name should be owned by the >> OpenWhisk (P)PMC as the name is a trademark of the Apache Software >> Foundation - technically being donated as we speak IIUC but that >> doesn't make a real difference. > > Uh oh... I created a github organizations named "learning-openwhisk" that > contains all the sources of the book, also titled "Learning OpenWhisk" being > published by O'Reilly should I drop that GitHub organization and move > everything in some other place to avoid... legal issues ? :)
Re: I created a variant of the go runtime that is faster at init time
> Accounts with "openwhisk" in their name should be owned by the >OpenWhisk (P)PMC as the name is a trademark of the Apache Software >Foundation - technically being donated as we speak IIUC but that >doesn't make a real difference. Uh oh... I created a github organizations named "learning-openwhisk" that contains all the sources of the book, also titled "Learning OpenWhisk" being published by O'Reilly should I drop that GitHub organization and move everything in some other place to avoid... legal issues ? :)
Re: I created a variant of the go runtime that is faster at init time
Actually, the issue is where to publish in Docker Hub the contrib runtimes, like the `actionloop-gccgo-v1.11` I did that produces smaller executable but uses a different Go compiler, with all the consequences of being "different" (it is not the mainstream one). It won't go on the standard set of images but some users can find useful. If someone on behalf of apache registers that docker hub username ("openwhisk-contrib), we may publish some of those images also there, keeping them separated. I think it does not matter where the actual github source repo is. For example, that one could be included in the golang repo for example, just published under "openwhisk-contrib" so it is somewhat part of the community work but not the officially released one. As a side note for example I am trying also to do a PyPy python runtime, another "variant" that could be useful but not official. Source coud go in the python runtime but published on the openwhisk-contrib docker hub account. -- Michele Sciabarra mich...@sciabarra.com - Original message - From: Carlos Santana To: dev@openwhisk.apache.org Subject: Re: I created a variant of the go runtime that is faster at init time Date: Wed, 12 Dec 2018 04:26:29 -0800 My 2 cents about the "contrib" repo for best effort support and experimental code we already have a repo It used be named incubator-openwhisk-experimental, but then we rename it to incubator-openwhisk-devtools [1] If any one has some cool experiments we have created a new folder in the repo and add some trivial travis test [1] https://github.com/apache/incubator-openwhisk-devtools -cs On Wed, Dec 12, 2018 at 2:13 AM Michele Sciabarra wrote: > Hmm, I understand the concern but I wonder HOW the "convenience" binaries > should be handled in practice. > > In OpenWhisk what it matters is the runtime you specify with --docker, so > that "convenience" is not really just a convenience, it is a core > requirement. > > We could setup an openwhisk contrib repository, but I cannot image a > single Travis build to be able to rebuild many images (at the moment I have > at least 4) and push all of them to docker hub... > > > -- > Michele Sciabarra > mich...@sciabarra.com > > - Original message - > From: Felix Meschberger > To: "dev@openwhisk.apache.org" > Subject: Re: I created a variant of the go runtime that is faster at init > time > Date: Wed, 12 Dec 2018 10:00:07 + > > Hi Michele > > This is shaky ground and we don’t want to be the next npm horror story. > > Technically speaking, at Apache we primarily release source packages, all > binary is pure convenience. Granted the convience today is what most people > use. > > So what we should primarily do, as Bertrand hinted, is have a contrib > repository. We can still have a contrib docker account into which the > OpenWhisk PMC can regularly „dump“ binary builds for convience. But it must > be clearly stated that those are not releases, have no release quality and > all the usual disclaimers. > > Regards > Felix > > > Am 12.12.2018 um 10:55 schrieb Michele Sciabarra >: > > > > Actually more than an account on GitHub it is important to have a docker > hub account named "openwhisk-contrib" so you can deploy an action with > something like: > > > > wsk create myaction --docker openwhisk-contrib/actionloop-gccgo-v1.10 > > > > To publish images, you can do sothing as simple as ask, maybe opening a > ticket, to push an image msciab/actionloop-gccgo-v1.10 > > to openwhisk-contrib/actionloop-gccgo-v1.10. > > > > > > > > -- > > Michele Sciabarra > > mich...@sciabarra.com > > > > - Original message - > > From: Bertrand Delacretaz > > To: dev@openwhisk.apache.org > > Subject: Re: I created a variant of the go runtime that is faster at > init time > > Date: Wed, 12 Dec 2018 10:45:43 +0100 > > > > Hi, > > > > On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra > > wrote: > >> > >> Indeed I was thinking to create a docker account "openwhisk-contrib" > to place those, let's say, unofficial images. > >> I am not sure who should own this account... > > > > Accounts with "openwhisk" in their name should be owned by the > > OpenWhisk (P)PMC as the name is a trademark of the Apache Software > > Foundation - technically being donated as we speak IIUC but that > > doesn't make a real difference. > > > > However what we are discussing here IMO is code repositories as code > > is what the ASF produces. I guess Felix's suggestion is to create one > > or a few openwhisk-contrib-* Git repositories under > > https://github.com/apache/ for such "contrib" modules. > > > > -Bertrand > > -- Carlos Santana
Re: I created a variant of the go runtime that is faster at init time
My 2 cents about the "contrib" repo for best effort support and experimental code we already have a repo It used be named incubator-openwhisk-experimental, but then we rename it to incubator-openwhisk-devtools [1] If any one has some cool experiments we have created a new folder in the repo and add some trivial travis test [1] https://github.com/apache/incubator-openwhisk-devtools -cs On Wed, Dec 12, 2018 at 2:13 AM Michele Sciabarra wrote: > Hmm, I understand the concern but I wonder HOW the "convenience" binaries > should be handled in practice. > > In OpenWhisk what it matters is the runtime you specify with --docker, so > that "convenience" is not really just a convenience, it is a core > requirement. > > We could setup an openwhisk contrib repository, but I cannot image a > single Travis build to be able to rebuild many images (at the moment I have > at least 4) and push all of them to docker hub... > > > -- > Michele Sciabarra > mich...@sciabarra.com > > - Original message - > From: Felix Meschberger > To: "dev@openwhisk.apache.org" > Subject: Re: I created a variant of the go runtime that is faster at init > time > Date: Wed, 12 Dec 2018 10:00:07 + > > Hi Michele > > This is shaky ground and we don’t want to be the next npm horror story. > > Technically speaking, at Apache we primarily release source packages, all > binary is pure convenience. Granted the convience today is what most people > use. > > So what we should primarily do, as Bertrand hinted, is have a contrib > repository. We can still have a contrib docker account into which the > OpenWhisk PMC can regularly „dump“ binary builds for convience. But it must > be clearly stated that those are not releases, have no release quality and > all the usual disclaimers. > > Regards > Felix > > > Am 12.12.2018 um 10:55 schrieb Michele Sciabarra >: > > > > Actually more than an account on GitHub it is important to have a docker > hub account named "openwhisk-contrib" so you can deploy an action with > something like: > > > > wsk create myaction --docker openwhisk-contrib/actionloop-gccgo-v1.10 > > > > To publish images, you can do sothing as simple as ask, maybe opening a > ticket, to push an image msciab/actionloop-gccgo-v1.10 > > to openwhisk-contrib/actionloop-gccgo-v1.10. > > > > > > > > -- > > Michele Sciabarra > > mich...@sciabarra.com > > > > - Original message - > > From: Bertrand Delacretaz > > To: dev@openwhisk.apache.org > > Subject: Re: I created a variant of the go runtime that is faster at > init time > > Date: Wed, 12 Dec 2018 10:45:43 +0100 > > > > Hi, > > > > On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra > > wrote: > >> > >> Indeed I was thinking to create a docker account "openwhisk-contrib" > to place those, let's say, unofficial images. > >> I am not sure who should own this account... > > > > Accounts with "openwhisk" in their name should be owned by the > > OpenWhisk (P)PMC as the name is a trademark of the Apache Software > > Foundation - technically being donated as we speak IIUC but that > > doesn't make a real difference. > > > > However what we are discussing here IMO is code repositories as code > > is what the ASF produces. I guess Felix's suggestion is to create one > > or a few openwhisk-contrib-* Git repositories under > > https://github.com/apache/ for such "contrib" modules. > > > > -Bertrand > > -- Carlos Santana
Re: "nightly" releases of clis (was Graduation)
To help with the confusion I try to clean up the "releases" github pages for both CLIs wsk and wskdeploy https://github.com/apache/incubator-openwhisk-wskdeploy/releases https://github.com/apache/incubator-openwhisk-cli/releases The tag "latest" means nightly and is mark in red as "pre-release" Apache OpenWhisk Releases right now should be tag as x.y.z-incubating and is mark in green "latest-releaes" Any tags with `x.y.z` this are old before we cut the first Apache OpenWhisk release. One weird thing I found was in wskdeploy there is a 0.9;9 and 0.9.8-incubating, I left 0.9.9 just in case someone is using the convenient binaries Can't remember if I created that tag or someone else. But it would not matter that much if we cut another release of the CLIs soon, and then we can delete this 0.9.8 binaries On Wed, Dec 12, 2018 at 12:03 AM Bertrand Delacretaz wrote: > Hi Matt, > > On Tue, Dec 11, 2018 at 7:32 PM Matt Rutkowski > wrote: > > ...https://github.com/apache/incubator-openwhisk-website/pull/353 ... > > Thank you very much for this. I like it, with a few minor comments. > > I'd prefer saying "Apache Releases" or "Apache OpenWhisk Releases" > instead of "Official Releases". > > It would be good to link to > http://www.apache.org/legal/release-policy.html somewhere, to provide > background information. > > > In some special cases, Committers on the project may choose to use > > GitHub to tag certain builds... > > Does that automatically cause those builds to appear as releases like > at https://github.com/apache/incubator-openwhisk-wskdeploy/releases ? > If not, GitHub tags are perfectly ok of course, but I think the mix of > Apache Releases and tagged builds there is a major source of confusion > and should be avoided. > > I would expect tags to appear only at (for example) > https://github.com/apache/incubator-openwhisk-wskdeploy/tags - and > document tag naming conventions might be useful for clarity if there > are none so far. > > -Bertrand > -- Carlos Santana
Re: Tagging the actionloop with a name matching the version
I think we should instea ddo a Apache Release cut across all runtime repos and including the recent new ones like Go, DotNet. I know this is something Dave Grove and Rodric want to drive soon We can do one single email to vote for all runtimes It should take about a week, depending how fast we get the minimum 3 votes from IPMC I think after the cut release with a version tag like 1.13-incubating for all runtimes, I don't anticipate large changes for actionloop -- Carlos On Wed, Dec 12, 2018 at 2:21 AM Michele Sciabarra wrote: > Hello all, > > at the moment there are, using actionloop: > > - my upcoming runtime for Python > - on the work a runtime for PHP > - the newly announced Crystal runtime > > I am using now, to build the images, the > > FROM actionloop as builder > > but I am a bit afraid of getting the wrong version (it happened to me) > > I know we cannot really do a release because of the complexities, but some > tagging is necessary > > So my idea is to give at least a name, like actionloop-v1.0.1, to be > upgraded when we change it. > > (I do not expect many changes, at the moment it is pretty stable and I > have not changed it in months). > > Can I proceed with a PR for it? > > -- > Michele Sciabarra > mich...@sciabarra.com > -- Carlos Santana
Tagging the actionloop with a name matching the version
Hello all, at the moment there are, using actionloop: - my upcoming runtime for Python - on the work a runtime for PHP - the newly announced Crystal runtime I am using now, to build the images, the FROM actionloop as builder but I am a bit afraid of getting the wrong version (it happened to me) I know we cannot really do a release because of the complexities, but some tagging is necessary So my idea is to give at least a name, like actionloop-v1.0.1, to be upgraded when we change it. (I do not expect many changes, at the moment it is pretty stable and I have not changed it in months). Can I proceed with a PR for it? -- Michele Sciabarra mich...@sciabarra.com
Re: I created a variant of the go runtime that is faster at init time
Hmm, I understand the concern but I wonder HOW the "convenience" binaries should be handled in practice. In OpenWhisk what it matters is the runtime you specify with --docker, so that "convenience" is not really just a convenience, it is a core requirement. We could setup an openwhisk contrib repository, but I cannot image a single Travis build to be able to rebuild many images (at the moment I have at least 4) and push all of them to docker hub... -- Michele Sciabarra mich...@sciabarra.com - Original message - From: Felix Meschberger To: "dev@openwhisk.apache.org" Subject: Re: I created a variant of the go runtime that is faster at init time Date: Wed, 12 Dec 2018 10:00:07 + Hi Michele This is shaky ground and we don’t want to be the next npm horror story. Technically speaking, at Apache we primarily release source packages, all binary is pure convenience. Granted the convience today is what most people use. So what we should primarily do, as Bertrand hinted, is have a contrib repository. We can still have a contrib docker account into which the OpenWhisk PMC can regularly „dump“ binary builds for convience. But it must be clearly stated that those are not releases, have no release quality and all the usual disclaimers. Regards Felix > Am 12.12.2018 um 10:55 schrieb Michele Sciabarra : > > Actually more than an account on GitHub it is important to have a docker hub > account named "openwhisk-contrib" so you can deploy an action with something > like: > > wsk create myaction --docker openwhisk-contrib/actionloop-gccgo-v1.10 > > To publish images, you can do sothing as simple as ask, maybe opening a > ticket, to push an image msciab/actionloop-gccgo-v1.10 > to openwhisk-contrib/actionloop-gccgo-v1.10. > > > > -- > Michele Sciabarra > mich...@sciabarra.com > > - Original message - > From: Bertrand Delacretaz > To: dev@openwhisk.apache.org > Subject: Re: I created a variant of the go runtime that is faster at init time > Date: Wed, 12 Dec 2018 10:45:43 +0100 > > Hi, > > On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra > wrote: >> >> Indeed I was thinking to create a docker account "openwhisk-contrib" to >> place those, let's say, unofficial images. >> I am not sure who should own this account... > > Accounts with "openwhisk" in their name should be owned by the > OpenWhisk (P)PMC as the name is a trademark of the Apache Software > Foundation - technically being donated as we speak IIUC but that > doesn't make a real difference. > > However what we are discussing here IMO is code repositories as code > is what the ASF produces. I guess Felix's suggestion is to create one > or a few openwhisk-contrib-* Git repositories under > https://github.com/apache/ for such "contrib" modules. > > -Bertrand
Re: I created a variant of the go runtime that is faster at init time
Hi Michele This is shaky ground and we don’t want to be the next npm horror story. Technically speaking, at Apache we primarily release source packages, all binary is pure convenience. Granted the convience today is what most people use. So what we should primarily do, as Bertrand hinted, is have a contrib repository. We can still have a contrib docker account into which the OpenWhisk PMC can regularly „dump“ binary builds for convience. But it must be clearly stated that those are not releases, have no release quality and all the usual disclaimers. Regards Felix > Am 12.12.2018 um 10:55 schrieb Michele Sciabarra : > > Actually more than an account on GitHub it is important to have a docker hub > account named "openwhisk-contrib" so you can deploy an action with something > like: > > wsk create myaction --docker openwhisk-contrib/actionloop-gccgo-v1.10 > > To publish images, you can do sothing as simple as ask, maybe opening a > ticket, to push an image msciab/actionloop-gccgo-v1.10 > to openwhisk-contrib/actionloop-gccgo-v1.10. > > > > -- > Michele Sciabarra > mich...@sciabarra.com > > - Original message - > From: Bertrand Delacretaz > To: dev@openwhisk.apache.org > Subject: Re: I created a variant of the go runtime that is faster at init time > Date: Wed, 12 Dec 2018 10:45:43 +0100 > > Hi, > > On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra > wrote: >> >> Indeed I was thinking to create a docker account "openwhisk-contrib" to >> place those, let's say, unofficial images. >> I am not sure who should own this account... > > Accounts with "openwhisk" in their name should be owned by the > OpenWhisk (P)PMC as the name is a trademark of the Apache Software > Foundation - technically being donated as we speak IIUC but that > doesn't make a real difference. > > However what we are discussing here IMO is code repositories as code > is what the ASF produces. I guess Felix's suggestion is to create one > or a few openwhisk-contrib-* Git repositories under > https://github.com/apache/ for such "contrib" modules. > > -Bertrand
Re: I created a variant of the go runtime that is faster at init time
Hi Michele „Dynamic libraries included in the container" was the answer I was looking for. Thanks Regards Felix > Am 12.12.2018 um 10:49 schrieb Michele Sciabarra : > > To answer to the second part of your question: > > if you compile a Go program with the native go compiler, the final executable > links statically everything including the garbage collector and other stuff. > If you use gccgo, those things are dynamic libraries and are not included in > the executable. > > I created the gccgo image using ubuntu (bionic) and installing the gccgo > package, hence all the required dynamic libraries are included in the docker > image. > > Furthermore, the executable is created by the image itself (using the > precompilation feature of the "actionloop" image) so the executable is > created BY the image FOR the image and the dynamic libraries match. > > The same happens for the switf image, to create say an executable for swift > 4.2.1 you have to use the image for swift 4.2.1 with the -compile flag, and > it will produce an action that can be run in the same image. > > -- > Michele Sciabarra > mich...@sciabarra.com > > - Original message - > From: Felix Meschberger > To: "dev@openwhisk.apache.org" > Subject: Re: I created a variant of the go runtime that is faster at init time > Date: Wed, 12 Dec 2018 09:09:58 + > > Hi > > From the sidelines… > > I understand that there is limited bandwidth to support all sorts of runtimes > .. But I wonder, whether such a thing would not have a space in some sort of > an „unsupported“ contrib area ? > > I myself like the idea of smaller binaries but wonder how you solve the > dynmic linking issue of provisioning the dependency dynamic libraries in the > container ? > > Regards > Felix > >> Am 11.12.2018 um 17:47 schrieb Michele Sciabarra : >> >> I am perfectly fine if we do not provide a gccgo runtime, it was not a big >> work, and I did it to see if it is possible to generate small executables >> also for go, since the swift one is very small. >> >> Aside from the fact that actionloop-gccgo-v1.10 is the faster runtime both >> in run and init time (a personal satisfaction) if the init time is NOT a >> problem, I agree that there are no reasons to provide also an official gccgo >> version. >> >> On Slack Markus asked to measure also the Init time but in all honesty I do >> not know how important is to provide also faster init time. >> >> -- >> Michele Sciabarra >> mich...@sciabarra.com >> >> - Original message - >> From: Carlos Santana >> To: dev@openwhisk.apache.org >> Subject: Re: I created a variant of the go runtime that is faster at init >> time >> Date: Tue, 11 Dec 2018 07:58:19 -0800 >> >> Let’s stick with the 1.11 stock compiler, produces greater portability abs >> allows us to make updates to the base linux image with low risk for braking >> an exec built previously >> >> Not worth for the init, in general a busy app doesn’t suffer a lot of cold >> start and on the flip side a infrequent app can leverage stemcell a/prewarm >> >> I think if you want to investigate maybe opening an issue or start >> discussion with go community on how the compiler can be improve if if their >> flags that we are not using to optimized the binary >> >> — Carlos >> >> >> On Tue, Dec 11, 2018 at 7:46 AM David P Grove wrote: >> >>> >>> Sorry. >>> >>> I mean do not bother providing a gccgo variant of the go runtime. Stick >>> with the official golang compiler at 1.11. I don't see the small speedup >>> in init time as being enough to justify supporting two variants of go >>> actions. >>> >>> --dave >>> >>> >>> Michele Sciabarra wrote on 12/11/2018 10:37:56 AM: >>> From: Michele Sciabarra To: dev@openwhisk.apache.org Date: 12/11/2018 10:38 AM Subject: Re: I created a variant of the go runtime that is faster atinit >>> time Sorry not sure what you mean. Do you suggest I apply the change to use gccgo in the official runtime, even if it is stuck at go 1.10 (the latest is go 1.11) or I drop the idea of providing another runtime that is faster to initialize? Would not be better to release both a gccgo 1.10 and a golang 1.11 instead so I leave the choice to users? The first produces smaller binaries but it is a bit slower and it is stuck to go 1.10, the second is faster but it is slower to initialize because the executable is bigger.-- Michele Sciabarra mich...@sciabarra.com - Original message - From: David P Grove To: dev@openwhisk.apache.org Subject: Re: I created a variant of the go runtime that is faster at init timeDate: Tue, 11 Dec 2018 10:17:51 -0500 Michele Sciabarra wrote on 12/11/2018 07:23:14 AM:> > Then I created a variant of the go runtime, using GccGo. GccGo is a > Go compiler, updated to Go version 1.10, that compiles using the Gcc >
Re: I created a variant of the go runtime that is faster at init time
Yes, a single contrib repository. I guess we still would want to lock it down but be more open to accept contributions, provided IP is properly transferred Regards Felix > Am 12.12.2018 um 10:45 schrieb Bertrand Delacretaz : > > Hi, > > On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra > wrote: >> >> Indeed I was thinking to create a docker account "openwhisk-contrib" to >> place those, let's say, unofficial images. >> I am not sure who should own this account... > > Accounts with "openwhisk" in their name should be owned by the > OpenWhisk (P)PMC as the name is a trademark of the Apache Software > Foundation - technically being donated as we speak IIUC but that > doesn't make a real difference. > > However what we are discussing here IMO is code repositories as code > is what the ASF produces. I guess Felix's suggestion is to create one > or a few openwhisk-contrib-* Git repositories under > https://github.com/apache/ for such "contrib" modules. > > -Bertrand
Re: I created a variant of the go runtime that is faster at init time
To answer to the second part of your question: if you compile a Go program with the native go compiler, the final executable links statically everything including the garbage collector and other stuff. If you use gccgo, those things are dynamic libraries and are not included in the executable. I created the gccgo image using ubuntu (bionic) and installing the gccgo package, hence all the required dynamic libraries are included in the docker image. Furthermore, the executable is created by the image itself (using the precompilation feature of the "actionloop" image) so the executable is created BY the image FOR the image and the dynamic libraries match. The same happens for the switf image, to create say an executable for swift 4.2.1 you have to use the image for swift 4.2.1 with the -compile flag, and it will produce an action that can be run in the same image. -- Michele Sciabarra mich...@sciabarra.com - Original message - From: Felix Meschberger To: "dev@openwhisk.apache.org" Subject: Re: I created a variant of the go runtime that is faster at init time Date: Wed, 12 Dec 2018 09:09:58 + Hi >From the sidelines… I understand that there is limited bandwidth to support all sorts of runtimes .. But I wonder, whether such a thing would not have a space in some sort of an „unsupported“ contrib area ? I myself like the idea of smaller binaries but wonder how you solve the dynmic linking issue of provisioning the dependency dynamic libraries in the container ? Regards Felix > Am 11.12.2018 um 17:47 schrieb Michele Sciabarra : > > I am perfectly fine if we do not provide a gccgo runtime, it was not a big > work, and I did it to see if it is possible to generate small executables > also for go, since the swift one is very small. > > Aside from the fact that actionloop-gccgo-v1.10 is the faster runtime both > in run and init time (a personal satisfaction) if the init time is NOT a > problem, I agree that there are no reasons to provide also an official gccgo > version. > > On Slack Markus asked to measure also the Init time but in all honesty I do > not know how important is to provide also faster init time. > > -- > Michele Sciabarra > mich...@sciabarra.com > > - Original message - > From: Carlos Santana > To: dev@openwhisk.apache.org > Subject: Re: I created a variant of the go runtime that is faster at init time > Date: Tue, 11 Dec 2018 07:58:19 -0800 > > Let’s stick with the 1.11 stock compiler, produces greater portability abs > allows us to make updates to the base linux image with low risk for braking > an exec built previously > > Not worth for the init, in general a busy app doesn’t suffer a lot of cold > start and on the flip side a infrequent app can leverage stemcell a/prewarm > > I think if you want to investigate maybe opening an issue or start > discussion with go community on how the compiler can be improve if if their > flags that we are not using to optimized the binary > > — Carlos > > > On Tue, Dec 11, 2018 at 7:46 AM David P Grove wrote: > >> >> Sorry. >> >> I mean do not bother providing a gccgo variant of the go runtime. Stick >> with the official golang compiler at 1.11. I don't see the small speedup >> in init time as being enough to justify supporting two variants of go >> actions. >> >> --dave >> >> >> Michele Sciabarra wrote on 12/11/2018 10:37:56 AM: >> >>> From: Michele Sciabarra >>> To: dev@openwhisk.apache.org >>> Date: 12/11/2018 10:38 AM >>> Subject: Re: I created a variant of the go runtime that is faster atinit >> time >>> >>> Sorry not sure what you mean. Do you suggest I apply the change to use >>> gccgo in the official runtime, even if it is stuck at go 1.10 (the >>> latest is go 1.11) or I drop the idea of providing another runtime that >>> is faster to initialize? Would not be better to release both a gccgo >>> 1.10 and a golang 1.11 instead so I leave the choice to users? The first >>> produces smaller binaries but it is a bit slower and it is stuck to go >>> 1.10, the second is faster but it is slower to initialize because the >>> executable is bigger.-- >>> Michele Sciabarra >>> mich...@sciabarra.com >>> >>> >>> >>> - Original message - >>> From: David P Grove >>> To: dev@openwhisk.apache.org >>> Subject: Re: I created a variant of the go runtime that is faster at >>> init timeDate: Tue, 11 Dec 2018 10:17:51 -0500 >>> >>> Michele Sciabarra wrote on 12/11/2018 >>> 07:23:14 AM:> Then I created a variant of the go runtime, using GccGo. GccGo is a Go compiler, updated to Go version 1.10, that compiles using the Gcc compiler infrastructure. As a result, it produces dynamically linked executables that are smaller than the binaries produced by the standard Go compiler. ... GccGo is a bit slower than Go (but it is still the second faster runtime) but it is now the faster at init time because the executable is around 50k (and
Re: I created a variant of the go runtime that is faster at init time
Hi, On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra wrote: > > Indeed I was thinking to create a docker account "openwhisk-contrib" to > place those, let's say, unofficial images. > I am not sure who should own this account... Accounts with "openwhisk" in their name should be owned by the OpenWhisk (P)PMC as the name is a trademark of the Apache Software Foundation - technically being donated as we speak IIUC but that doesn't make a real difference. However what we are discussing here IMO is code repositories as code is what the ASF produces. I guess Felix's suggestion is to create one or a few openwhisk-contrib-* Git repositories under https://github.com/apache/ for such "contrib" modules. -Bertrand
Re: I created a variant of the go runtime that is faster at init time
Indeed I was thinking to create a docker account "openwhisk-contrib" to place those, let's say, unofficial images. I am not sure who should own this account, I think should be owned by the community(not me) but with a less strict policy to accept images. -- Michele Sciabarra mich...@sciabarra.com - Original message - From: Felix Meschberger To: "dev@openwhisk.apache.org" Subject: Re: I created a variant of the go runtime that is faster at init time Date: Wed, 12 Dec 2018 09:09:58 + Hi >From the sidelines… I understand that there is limited bandwidth to support all sorts of runtimes .. But I wonder, whether such a thing would not have a space in some sort of an „unsupported“ contrib area ? I myself like the idea of smaller binaries but wonder how you solve the dynmic linking issue of provisioning the dependency dynamic libraries in the container ? Regards Felix > Am 11.12.2018 um 17:47 schrieb Michele Sciabarra : > > I am perfectly fine if we do not provide a gccgo runtime, it was not a big > work, and I did it to see if it is possible to generate small executables > also for go, since the swift one is very small. > > Aside from the fact that actionloop-gccgo-v1.10 is the faster runtime both > in run and init time (a personal satisfaction) if the init time is NOT a > problem, I agree that there are no reasons to provide also an official gccgo > version. > > On Slack Markus asked to measure also the Init time but in all honesty I do > not know how important is to provide also faster init time. > > -- > Michele Sciabarra > mich...@sciabarra.com > > - Original message - > From: Carlos Santana > To: dev@openwhisk.apache.org > Subject: Re: I created a variant of the go runtime that is faster at init time > Date: Tue, 11 Dec 2018 07:58:19 -0800 > > Let’s stick with the 1.11 stock compiler, produces greater portability abs > allows us to make updates to the base linux image with low risk for braking > an exec built previously > > Not worth for the init, in general a busy app doesn’t suffer a lot of cold > start and on the flip side a infrequent app can leverage stemcell a/prewarm > > I think if you want to investigate maybe opening an issue or start > discussion with go community on how the compiler can be improve if if their > flags that we are not using to optimized the binary > > — Carlos > > > On Tue, Dec 11, 2018 at 7:46 AM David P Grove wrote: > >> >> Sorry. >> >> I mean do not bother providing a gccgo variant of the go runtime. Stick >> with the official golang compiler at 1.11. I don't see the small speedup >> in init time as being enough to justify supporting two variants of go >> actions. >> >> --dave >> >> >> Michele Sciabarra wrote on 12/11/2018 10:37:56 AM: >> >>> From: Michele Sciabarra >>> To: dev@openwhisk.apache.org >>> Date: 12/11/2018 10:38 AM >>> Subject: Re: I created a variant of the go runtime that is faster atinit >> time >>> >>> Sorry not sure what you mean. Do you suggest I apply the change to use >>> gccgo in the official runtime, even if it is stuck at go 1.10 (the >>> latest is go 1.11) or I drop the idea of providing another runtime that >>> is faster to initialize? Would not be better to release both a gccgo >>> 1.10 and a golang 1.11 instead so I leave the choice to users? The first >>> produces smaller binaries but it is a bit slower and it is stuck to go >>> 1.10, the second is faster but it is slower to initialize because the >>> executable is bigger.-- >>> Michele Sciabarra >>> mich...@sciabarra.com >>> >>> >>> >>> - Original message - >>> From: David P Grove >>> To: dev@openwhisk.apache.org >>> Subject: Re: I created a variant of the go runtime that is faster at >>> init timeDate: Tue, 11 Dec 2018 10:17:51 -0500 >>> >>> Michele Sciabarra wrote on 12/11/2018 >>> 07:23:14 AM:> Then I created a variant of the go runtime, using GccGo. GccGo is a Go compiler, updated to Go version 1.10, that compiles using the Gcc compiler infrastructure. As a result, it produces dynamically linked executables that are smaller than the binaries produced by the standard Go compiler. ... GccGo is a bit slower than Go (but it is still the second faster runtime) but it is now the faster at init time because the executable is around 50k (and zipped it is only 17k). I am unsure if replace GccGo in the official runtime or provide both. The fact that the executable is small so it leads to faster init time I think it is important, but the GccGo compiler it is a bit behind in term of language support. >>> >>> My advice is to stick with the official runtime. I think that is >>> betterfor end users. >>> >>> --dave >>> >> > -- > Carlos Santana >
Re: I created a variant of the go runtime that is faster at init time
On Wed, Dec 12, 2018 at 10:10 AM Felix Meschberger wrote: > ...I wonder, whether such a thing would not have a space in some sort of an > „unsupported“ > contrib area ?... Big +1, with my incubation mentor hat on - having modules which are not guaranteed to be supported, nor part of the core product, is great in terms of community as long as they are clearly marked as such. It can help bring more active committers, expand the project scope etc. while keeping the core nice and tight. -Bertrand
Re: I created a variant of the go runtime that is faster at init time
Hi From the sidelines… I understand that there is limited bandwidth to support all sorts of runtimes .. But I wonder, whether such a thing would not have a space in some sort of an „unsupported“ contrib area ? I myself like the idea of smaller binaries but wonder how you solve the dynmic linking issue of provisioning the dependency dynamic libraries in the container ? Regards Felix > Am 11.12.2018 um 17:47 schrieb Michele Sciabarra : > > I am perfectly fine if we do not provide a gccgo runtime, it was not a big > work, and I did it to see if it is possible to generate small executables > also for go, since the swift one is very small. > > Aside from the fact that actionloop-gccgo-v1.10 is the faster runtime both > in run and init time (a personal satisfaction) if the init time is NOT a > problem, I agree that there are no reasons to provide also an official gccgo > version. > > On Slack Markus asked to measure also the Init time but in all honesty I do > not know how important is to provide also faster init time. > > -- > Michele Sciabarra > mich...@sciabarra.com > > - Original message - > From: Carlos Santana > To: dev@openwhisk.apache.org > Subject: Re: I created a variant of the go runtime that is faster at init time > Date: Tue, 11 Dec 2018 07:58:19 -0800 > > Let’s stick with the 1.11 stock compiler, produces greater portability abs > allows us to make updates to the base linux image with low risk for braking > an exec built previously > > Not worth for the init, in general a busy app doesn’t suffer a lot of cold > start and on the flip side a infrequent app can leverage stemcell a/prewarm > > I think if you want to investigate maybe opening an issue or start > discussion with go community on how the compiler can be improve if if their > flags that we are not using to optimized the binary > > — Carlos > > > On Tue, Dec 11, 2018 at 7:46 AM David P Grove wrote: > >> >> Sorry. >> >> I mean do not bother providing a gccgo variant of the go runtime. Stick >> with the official golang compiler at 1.11. I don't see the small speedup >> in init time as being enough to justify supporting two variants of go >> actions. >> >> --dave >> >> >> Michele Sciabarra wrote on 12/11/2018 10:37:56 AM: >> >>> From: Michele Sciabarra >>> To: dev@openwhisk.apache.org >>> Date: 12/11/2018 10:38 AM >>> Subject: Re: I created a variant of the go runtime that is faster atinit >> time >>> >>> Sorry not sure what you mean. Do you suggest I apply the change to use >>> gccgo in the official runtime, even if it is stuck at go 1.10 (the >>> latest is go 1.11) or I drop the idea of providing another runtime that >>> is faster to initialize? Would not be better to release both a gccgo >>> 1.10 and a golang 1.11 instead so I leave the choice to users? The first >>> produces smaller binaries but it is a bit slower and it is stuck to go >>> 1.10, the second is faster but it is slower to initialize because the >>> executable is bigger.-- >>> Michele Sciabarra >>> mich...@sciabarra.com >>> >>> >>> >>> - Original message - >>> From: David P Grove >>> To: dev@openwhisk.apache.org >>> Subject: Re: I created a variant of the go runtime that is faster at >>> init timeDate: Tue, 11 Dec 2018 10:17:51 -0500 >>> >>> Michele Sciabarra wrote on 12/11/2018 >>> 07:23:14 AM:> Then I created a variant of the go runtime, using GccGo. GccGo is a Go compiler, updated to Go version 1.10, that compiles using the Gcc compiler infrastructure. As a result, it produces dynamically linked executables that are smaller than the binaries produced by the standard Go compiler. ... GccGo is a bit slower than Go (but it is still the second faster runtime) but it is now the faster at init time because the executable is around 50k (and zipped it is only 17k). I am unsure if replace GccGo in the official runtime or provide both. The fact that the executable is small so it leads to faster init time I think it is important, but the GccGo compiler it is a bit behind in term of language support. >>> >>> My advice is to stick with the official runtime. I think that is >>> betterfor end users. >>> >>> --dave >>> >> > -- > Carlos Santana >
Re: "nightly" releases of clis (was Graduation)
Hi Matt, On Tue, Dec 11, 2018 at 7:32 PM Matt Rutkowski wrote: > ...https://github.com/apache/incubator-openwhisk-website/pull/353 ... Thank you very much for this. I like it, with a few minor comments. I'd prefer saying "Apache Releases" or "Apache OpenWhisk Releases" instead of "Official Releases". It would be good to link to http://www.apache.org/legal/release-policy.html somewhere, to provide background information. > In some special cases, Committers on the project may choose to use > GitHub to tag certain builds... Does that automatically cause those builds to appear as releases like at https://github.com/apache/incubator-openwhisk-wskdeploy/releases ? If not, GitHub tags are perfectly ok of course, but I think the mix of Apache Releases and tagged builds there is a major source of confusion and should be avoided. I would expect tags to appear only at (for example) https://github.com/apache/incubator-openwhisk-wskdeploy/tags - and document tag naming conventions might be useful for clarity if there are none so far. -Bertrand