openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Date Wed, 29 Aug 2018 02:19:58 GMT
To the point of runtimes compatibility:

The runtimes and have a simple API based on two endpoints /init and /run
and this have not change, and we have done our best to keep the contract
between invoker and runtime stable so far.
If Justin saw problems in the docker-compose deploy, it's due to the fact
that deploy config changes happened in openwhisk core repo that affect
other deployment methods downstream like kube, openshift, mesos, and
docker-compose because they are located in other repos and changes in core
repo are not coordinated with the other repos. Which is ok I think since
the focal points keep track of core changes like Dave does for kube.
Nothing to do with runtimes you can use any version of any runtime old or
new openwhisk will work fine.

In terms of versioning and release, we want to keep some sanity :-)
For the source release I think we want to release a single tgz match a
single runtime type/flavor repo.

Today we can produce different runtimes for one flavor/type of programming
language for a single repo.

I think we should be able to release a runtime module for a each
flavor/type (nodejs, php, swift, docket, python, java, ruby).
Each repo when built can produce different runtime container images with a
specific image name and tag

For example I'm OK if we want to use the version `0.9.0-incubating` and
then as we want to release a single runtime module/repo it can be done even
if only affects one of the embedded runtimes inside.

For example we can do a branch `0.9.0-incubating` and this branch will have
a a helper build file/script that has the image names and tags of the
embedded runtimes.

Here how I envision how it could work:
./release/build.sh [runtime-kind]

$ tar -xvf openwhisk-runtime-nodejs-0.9.0-incubating-sources.tar.gz
$ cd openwhisk-runtime-nodejs-0.9.0-incubating-sources/
$ ./release/build.sh
docker image built: nodejs6action:1.12.0
docker image built: action-nodejs-v8:1.9.0
or just to build a single embedded runtime kind:
$ ./release/build.sh action-nodejs-v8
docker image built: action-nodejs-v8:1.9.0


$ tar -xvf openwhisk-runtime-php-0.9.0-incubating-sources.tar.gz
$ cd openwhisk-runtime-php-0.9.0-incubating-sources/
$ ./release/build.sh
docker image built: action-php-v7.1:1.0.3
docker image built: action-php-v7.2:1.0.2

If we want to release nodejs module it might just have one change addition
nodejs10 support

Then we can relese version `0.10.0-incubating` of the nodejs runtime this
will be the tgz openwhisk-runtime-nodejs-0.10.0-incubating-sources.tar.gz
Then should be able to:
$ tar -xvf openwhisk-runtime-nodejs-0.10.0-incubating-sources.tar.gz
$ cd openwhisk-runtime-nodejs-0.10.0-incubating-sources/
$ ./release/build.sh
docker image built: nodejs6action:1.12.0
docker image built: action-nodejs-v8:1.9.0
docker image built: action-nodejs-v10:1.0.0
or
$ ./release/build.sh action-nodejs-v10
docker image built: action-nodejs-v10:1.0.0
$ docker images
REPOSITORY
          TAG                                       IMAGE ID
CREATED             SIZE
action-nodejs-v10
           1.0.0                                    a868b562fae9        1
hours ago        539MB

Same thing for php we can release the php module 0.10.0-incubating, etc..
and it can have a new runtime, or just bug fixes, or currency updates
The tgz, will have inside an individual CHANGELOG per embedded runtime
`kind` like the repo today

Take into account the scope that we are discussing here is an Apache source
release only, which is the release of a source tgz only.

-- Carlos



On Tue, Aug 28, 2018 at 6:14 PM Rodric Rabbah <rodric@gmail.com> wrote:

> > ... we will very quickly have runtimes having Apache releases on their
> own cadence and the version numbers won't align with each other or with
> openwhisk core.
>
> We have to fully realize this now --- otherwise, as I stated earlier, I
> don't see what we've gained from splitting the one repo into so many other
> than process overhead.
>
> If it makes it easier to cut the first release of all the runtimes starting
> at the same X, then OK from my side also. But we absolutely must recognize
> we will have to release different versions of the runtimes and a release of
> a new PHP runtime should not cause all the runtimes to be re-released.
>
> So to Rob's question: "Will all the other runtimes and OpenWhisk itself
> need to be released as 1.13.0 because the PHP 7.3 runtime was added to
> openwhisk-runtime-php?"... no releasing PHP 7.3 should not cause all the
> other runtimes to be released at a new version number.
>
> > I don’t understand how the versioning of runtimes will work so that users
> know that a given runtime works with a given rest-of-OpenWhisk.
>
> This is a good question we haven't addressed.
>
> I would expect that when we cut a release of a future version of openwhisk,
> it should specify the version of the runtimes that it is compatible with in
> the runtime manifest. We did not do that for 0.9 nor could we, since the
> phase ordering was backward.
>
> -r
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message