You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by Michele Sciabarra <mi...@sciabarra.com> on 2019/05/10 08:30:09 UTC
Versioning and releasing the actionloop runtime
Hello all,
at this stage, the actionloop is used by Go 1.12, PHP 7.3, Python 3.7, Ruby 7.6, Rust and I have completed the work for Java 8 (PR will be sent in the next few days). There is also a step by step tutorial merged in the main repo. So it is becoming a bit "important".
The problem I see that we need to keep in sync the runtime with the docker images that uses it.
First and before all, as far as I know the runtime is backward compatible. Docker images currently uses it pulling the openwhisk/actionloop image and then copying the runtime in the docker images that needs it.
Unfortunately I discovered that the gradle plugin I used (gogradle) built the image linked dynamically so it was not usable with alpine based images for example. The the openwhisk/actionloop is dinamically linked with LIBC and does not work on alpine based images.
So I created a new version, where I also added some features to better support scripting languages, that is linked statically.
Currently, the PHP 7.3 and Python 3.7 runtimes uses openwhisk/actionloop and while the Rust, Ruby and the upcoming Java uses the -v2
I admit I do not like at all this situation, so I would like to improve it. My proposal
1. move the runtime in a separate repo (incubator-openwhisk-actionloop ? incubator-openwhisk-runtime-proxy ? pick your name) or even in the main repo
2. tag the runtime and release it with a name and a version number
3. change all the dockerfile that uses the runtime to build the runtime from sources themselves. It is not hard: just use a goimage as a builder, download and untar the release from apache archives and compile it.
I can volunteer to do all the work if approved.
--
Michele Sciabarra
michele@sciabarra.com
Re: Versioning and releasing the actionloop runtime
Posted by Michele Sciabarra <mi...@sciabarra.com>.
I am sorry of the situation but I would note I discussed this thing in maling list and I was recommended to use this name (check the archive).
In any case, I just did a PR for the new Java runtime and in this case I am using to build simply the command "go get github.com/apache/incubator-openwhisk-runtime-go/main" in the Dockerfile
https://github.com/apache/incubator-openwhisk-runtime-java/pull/84
It downloads the sources from GitHub and builds on the fly. I can do a PR to all the existing runtimes using actionloop to avoid using the actionloop-v2 and build from the sources.
When there will be an official release, all the docker images can be build downloading and compiling a released version.
PS the new actionloop java runtime passes all the existing tests, so it is compatible with the existing one, it is 10 times faster, and also accepts sources and compiles on the fly and also zips containing sources, resources, and jars and build a proper classpath for it. Looking forward for someone to review and merge it.
--
Michele Sciabarra
michele@sciabarra.com
----- Original message -----
From: Matt Rutkowski <mr...@us.ibm.com>
To: dev@openwhisk.apache.org
Subject: Re: Versioning and releasing the actionloop runtime
Date: Friday, May 10, 2019 7:24 PM
Since the ActionLoop is central to most of our runtime impls. and it is
featured as the means to author new ones (an SDK effectively), IMO it
should become part of the Apache release (and was a bit unsettled seeing
we were pushing Docker images named "actionloop-v2 to DockerHub implying
an official Apache version each time Go runtime was built by Travis
daily). The initial version should be brought in-line with our
corresponding runtime versioning and at the very least we need to
ackowledge its presence in the top-level README within the Go runtime
repo. In any event, the Travis YAML should be adjust to not push anything
with a "-v2" version as this has no official standing.
Kind regards,
Matt
From: "Michele Sciabarra" <mi...@sciabarra.com>
To: dev@openwhisk.apache.org
Date: 05/10/2019 03:30 AM
Subject: Versioning and releasing the actionloop runtime
Hello all,
at this stage, the actionloop is used by Go 1.12, PHP 7.3, Python 3.7,
Ruby 7.6, Rust and I have completed the work for Java 8 (PR will be sent
in the next few days). There is also a step by step tutorial merged in the
main repo. So it is becoming a bit "important".
The problem I see that we need to keep in sync the runtime with the docker
images that uses it.
First and before all, as far as I know the runtime is backward compatible.
Docker images currently uses it pulling the openwhisk/actionloop image
and then copying the runtime in the docker images that needs it.
Unfortunately I discovered that the gradle plugin I used (gogradle) built
the image linked dynamically so it was not usable with alpine based images
for example. The the openwhisk/actionloop is dinamically linked with LIBC
and does not work on alpine based images.
So I created a new version, where I also added some features to better
support scripting languages, that is linked statically.
Currently, the PHP 7.3 and Python 3.7 runtimes uses openwhisk/actionloop
and while the Rust, Ruby and the upcoming Java uses the -v2
I admit I do not like at all this situation, so I would like to improve
it. My proposal
1. move the runtime in a separate repo (incubator-openwhisk-actionloop ?
incubator-openwhisk-runtime-proxy ? pick your name) or even in the main
repo
2. tag the runtime and release it with a name and a version number
3. change all the dockerfile that uses the runtime to build the runtime
from sources themselves. It is not hard: just use a goimage as a builder,
download and untar the release from apache archives and compile it.
I can volunteer to do all the work if approved.
--
Michele Sciabarra
michele@sciabarra.com
Re: Versioning and releasing the actionloop runtime
Posted by Matt Rutkowski <mr...@us.ibm.com>.
Since the ActionLoop is central to most of our runtime impls. and it is
featured as the means to author new ones (an SDK effectively), IMO it
should become part of the Apache release (and was a bit unsettled seeing
we were pushing Docker images named "actionloop-v2 to DockerHub implying
an official Apache version each time Go runtime was built by Travis
daily). The initial version should be brought in-line with our
corresponding runtime versioning and at the very least we need to
ackowledge its presence in the top-level README within the Go runtime
repo. In any event, the Travis YAML should be adjust to not push anything
with a "-v2" version as this has no official standing.
Kind regards,
Matt
From: "Michele Sciabarra" <mi...@sciabarra.com>
To: dev@openwhisk.apache.org
Date: 05/10/2019 03:30 AM
Subject: Versioning and releasing the actionloop runtime
Hello all,
at this stage, the actionloop is used by Go 1.12, PHP 7.3, Python 3.7,
Ruby 7.6, Rust and I have completed the work for Java 8 (PR will be sent
in the next few days). There is also a step by step tutorial merged in the
main repo. So it is becoming a bit "important".
The problem I see that we need to keep in sync the runtime with the docker
images that uses it.
First and before all, as far as I know the runtime is backward compatible.
Docker images currently uses it pulling the openwhisk/actionloop image
and then copying the runtime in the docker images that needs it.
Unfortunately I discovered that the gradle plugin I used (gogradle) built
the image linked dynamically so it was not usable with alpine based images
for example. The the openwhisk/actionloop is dinamically linked with LIBC
and does not work on alpine based images.
So I created a new version, where I also added some features to better
support scripting languages, that is linked statically.
Currently, the PHP 7.3 and Python 3.7 runtimes uses openwhisk/actionloop
and while the Rust, Ruby and the upcoming Java uses the -v2
I admit I do not like at all this situation, so I would like to improve
it. My proposal
1. move the runtime in a separate repo (incubator-openwhisk-actionloop ?
incubator-openwhisk-runtime-proxy ? pick your name) or even in the main
repo
2. tag the runtime and release it with a name and a version number
3. change all the dockerfile that uses the runtime to build the runtime
from sources themselves. It is not hard: just use a goimage as a builder,
download and untar the release from apache archives and compile it.
I can volunteer to do all the work if approved.
--
Michele Sciabarra
michele@sciabarra.com