You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by Vincent S Hou <sh...@us.ibm.com> on 2018/08/27 15:40:33 UTC
[DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for
the first-time release under Apache
Hi OpenWhiskers,
We are on our way to release OpenWhisk runtimes under Apache for the first time. As you may notice or not, each individual runtime repository has already used
its own version numbers as the build tag for quite a while. In order not to disrupt the current versioning number and also accommodating the release work under Apache, I would like to propose 1.12.0 as the version number for the first time we release the six runtimes under Apache, because this version number is the minimum
nominator I find for all the runtimes so far.
We now have following runtimes, which have already released with their version numbers:
docker skeleton v1.3.3
python2 v1.0.3
python3 v.1.0.3
node8 v1.12.0
node6 v1.12.0
php7.2 v1.0.2
swift4.1 v1.0.8
java8 v1.1.2
I think 1.12.0 can match them all, and then use it as a common ground to move on with further version numbers. I would like to hear your comments.
If no objection is heard, I will move on with 1.12.0 for the runtimes to be released under Apache for the first time.
Best wishes,
Vincent Hou
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Posted by Rodric Rabbah <ro...@gmail.com>.
If the plan was to break up the one repo only to then make all the versions for the new repos the same than we’ve accomplished nothing but created a big management headache.
The different components do in fact have different cadences as already noted and we should not be forcing all versions to be the same. It makes no sense to me.
- The openwhisk repo pins it’s dependence’s on the runtimes via the runtime manifest. We use latest in head, and can use specific versions in a release.
- The cli works against “api/v1” which is the external host api where changes are backward compatible.
- The packages also depend on the same “api/v1”.
-r
> On Aug 27, 2018, at 2:04 PM, Vincent S Hou <sh...@us.ibm.com> wrote:
>
> As far as I know, OpenWhisk has a big issue with the versioning we cannot disregard.
>
> OpenWhisk runs as a whole platform, which consists of multiple projects/modules. The optimal pattern is that all the modules release at a time with the same version number, so that we can match them, and we know under this certain version number, all the modules will work together.
>
> Right now, we have the following modules under 0.9.0 or at least 0.9.X
> openwhisk
> openwhisk-catalog,
> openwhisk-client-go
> openwhisk-cli,
> openwhisk-wskdeploy,
> openwhisk-deploy-kube,
> openwhisk-apigateway
>
> I plan bundle all of them together in one tar.gz, so that they can be downloaded in one compressed file for convenience. I suggest and insist that at least 7 of these modules can keep up the same version and able to be released synchronously in future, because OpenWhisk is so far a platform, depending on multiple modules to release. If we mismatch the version numbers in future, how could we know whether 1.2.0 CLI is able to run on top of 1.1.0 openwhisk??
>
> The same issue will happen to runtimes as well. How do we know if 1.13.0 nodejs can match the 1.1.0 openwhisk? Of course, each repository should run on its owns, and release on its own cycle. However, openwhisk is not that "INTELLIGENT" yet to do so. If we propose one version for the 6 runtimes, like 1.12.0(I wish too much it could still be 0.9.0, but as a respect for the reality, I accept it can be some other version). After they are released, we can add a document somewhere, saying that 0.9.0 openwhisk modules match 1.12.0 runtimes, and we can make sure that all the 1.12.0 runtimes able to run in 0.9.0 openwhisk with no problem.
>
> If we release runtimes individually, we should create a matrix describing like 1.12.0 nodejs, docker skeleton v1.3.3, python v1.0.3, node8 v1.12.0, php7.2 v1.0.2,
> swift4.1 v1.0.8, java8 v1.1.2 can really work on 0.9.0 openwhisk. As each runtime module develops, we have to keep on updating this matrix. Is this something we love to have? Or is there a better way to do it? Based on the reality, why don't we get the first release of all the modules of openwhisk out for the first time using the easiest way? We can come up to the solution later and keep this discussion open. Otherwise, we have to resolve this issue ASAP before we release anything.
>
>
>
> Best wishes.
> Vincent Hou (侯胜博)
>
> Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud
>
> Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
> Phone: +1(919)254-7182
> Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States
>
> -----"David P Grove" <gr...@us.ibm.com> wrote: -----
> To: dev@openwhisk.apache.org
> From: "David P Grove" <gr...@us.ibm.com>
> Date: 08/27/2018 01:34PM
> Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
>
>
> "Vincent S Hou" <sh...@us.ibm.com> wrote on 08/27/2018 12:39:01 PM:
>>
>> For convenience of release management in Apache.
>> * We can send one or two vote email(s) instead of 6.
>
> I realize that it will make the initial release more convenient. I don't
> think this is a compelling reason however.
>
>> * The download page of openwhisk.org can allocate one section to
>> offer the download links of runtimes.
>
>
> I don't think this is a good pattern. I predict we will be releasing
> runtimes in individual cadences, driven by changes in the upstream base
> language runtime, CVEs that need to be fixed via a new runtime release,
> etc. So I think the download for the runtime needs to be organized by
> runtime, then by version within each runtime, not by openwhisk version.
>
> --dave
>
>>
>>
>>
>> Best wishes.
>> Vincent Hou (侯胜博)
>>
>> Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM
> Cloud
>>
>> Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
>> Phone: +1(919)254-7182
>> Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United
> States
>>
>> -----Rodric Rabbah <ro...@gmail.com> wrote: -----
>> To: dev@openwhisk.apache.org
>> From: Rodric Rabbah <ro...@gmail.com>
>> Date: 08/27/2018 11:45AM
>> Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version
>> for all runtimes for the first-time release under Apache
>>
>> Why do they all need to start from the same version?
>>
>>> On Mon, Aug 27, 2018 at 11:40 AM, Vincent S Hou <sh...@us.ibm.com> wrote:
>>>
>>> Hi OpenWhiskers,
>>>
>>> We are on our way to release OpenWhisk runtimes under Apache for the
> first
>>> time. As you may notice or not, each individual runtime repository has
>>> already used
>>> its own version numbers as the build tag for quite a while. In order
> not
>>> to disrupt the current versioning number and also accommodating the
> release
>>> work under Apache, I would like to propose 1.12.0 as the version number
> for
>>> the first time we release the six runtimes under Apache, because this
>>> version number is the minimum
>>> nominator I find for all the runtimes so far.
>>>
>>> We now have following runtimes, which have already released with their
>>> version numbers:
>>> docker skeleton v1.3.3
>>> python2 v1.0.3
>>> python3 v.1.0.3
>>> node8 v1.12.0
>>> node6 v1.12.0
>>> php7.2 v1.0.2
>>> swift4.1 v1.0.8
>>> java8 v1.1.2
>>>
>>> I think 1.12.0 can match them all, and then use it as a common ground
> to
>>> move on with further version numbers. I would like to hear your
> comments.
>>> If no objection is heard, I will move on with 1.12.0 for the runtimes
> to
>>> be released under Apache for the first time.
>>>
>>> Best wishes,
>>> Vincent Hou
>>>
>>>
>>>
>>
>
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes
for the first-time release under Apache
Posted by Vincent S Hou <sh...@us.ibm.com>.
As far as I know, OpenWhisk has a big issue with the versioning we cannot disregard.
OpenWhisk runs as a whole platform, which consists of multiple projects/modules. The optimal pattern is that all the modules release at a time with the same version number, so that we can match them, and we know under this certain version number, all the modules will work together.
Right now, we have the following modules under 0.9.0 or at least 0.9.X
openwhisk
openwhisk-catalog,
openwhisk-client-go
openwhisk-cli,
openwhisk-wskdeploy,
openwhisk-deploy-kube,
openwhisk-apigateway
I plan bundle all of them together in one tar.gz, so that they can be downloaded in one compressed file for convenience. I suggest and insist that at least 7 of these modules can keep up the same version and able to be released synchronously in future, because OpenWhisk is so far a platform, depending on multiple modules to release. If we mismatch the version numbers in future, how could we know whether 1.2.0 CLI is able to run on top of 1.1.0 openwhisk??
The same issue will happen to runtimes as well. How do we know if 1.13.0 nodejs can match the 1.1.0 openwhisk? Of course, each repository should run on its owns, and release on its own cycle. However, openwhisk is not that "INTELLIGENT" yet to do so. If we propose one version for the 6 runtimes, like 1.12.0(I wish too much it could still be 0.9.0, but as a respect for the reality, I accept it can be some other version). After they are released, we can add a document somewhere, saying that 0.9.0 openwhisk modules match 1.12.0 runtimes, and we can make sure that all the 1.12.0 runtimes able to run in 0.9.0 openwhisk with no problem.
If we release runtimes individually, we should create a matrix describing like 1.12.0 nodejs, docker skeleton v1.3.3, python v1.0.3, node8 v1.12.0, php7.2 v1.0.2,
swift4.1 v1.0.8, java8 v1.1.2 can really work on 0.9.0 openwhisk. As each runtime module develops, we have to keep on updating this matrix. Is this something we love to have? Or is there a better way to do it? Based on the reality, why don't we get the first release of all the modules of openwhisk out for the first time using the easiest way? We can come up to the solution later and keep this discussion open. Otherwise, we have to resolve this issue ASAP before we release anything.
Best wishes.
Vincent Hou (侯胜博)
Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud
Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States
-----"David P Grove" <gr...@us.ibm.com> wrote: -----
To: dev@openwhisk.apache.org
From: "David P Grove" <gr...@us.ibm.com>
Date: 08/27/2018 01:34PM
Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
"Vincent S Hou" <sh...@us.ibm.com> wrote on 08/27/2018 12:39:01 PM:
>
> For convenience of release management in Apache.
> * We can send one or two vote email(s) instead of 6.
I realize that it will make the initial release more convenient. I don't
think this is a compelling reason however.
> * The download page of openwhisk.org can allocate one section to
> offer the download links of runtimes.
I don't think this is a good pattern. I predict we will be releasing
runtimes in individual cadences, driven by changes in the upstream base
language runtime, CVEs that need to be fixed via a new runtime release,
etc. So I think the download for the runtime needs to be organized by
runtime, then by version within each runtime, not by openwhisk version.
--dave
>
>
>
> Best wishes.
> Vincent Hou (侯胜博)
>
> Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM
Cloud
>
> Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
> Phone: +1(919)254-7182
> Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United
States
>
> -----Rodric Rabbah <ro...@gmail.com> wrote: -----
> To: dev@openwhisk.apache.org
> From: Rodric Rabbah <ro...@gmail.com>
> Date: 08/27/2018 11:45AM
> Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version
> for all runtimes for the first-time release under Apache
>
> Why do they all need to start from the same version?
>
> On Mon, Aug 27, 2018 at 11:40 AM, Vincent S Hou <sh...@us.ibm.com> wrote:
>
> > Hi OpenWhiskers,
> >
> > We are on our way to release OpenWhisk runtimes under Apache for the
first
> > time. As you may notice or not, each individual runtime repository has
> > already used
> > its own version numbers as the build tag for quite a while. In order
not
> > to disrupt the current versioning number and also accommodating the
release
> > work under Apache, I would like to propose 1.12.0 as the version number
for
> > the first time we release the six runtimes under Apache, because this
> > version number is the minimum
> > nominator I find for all the runtimes so far.
> >
> > We now have following runtimes, which have already released with their
> > version numbers:
> > docker skeleton v1.3.3
> > python2 v1.0.3
> > python3 v.1.0.3
> > node8 v1.12.0
> > node6 v1.12.0
> > php7.2 v1.0.2
> > swift4.1 v1.0.8
> > java8 v1.1.2
> >
> > I think 1.12.0 can match them all, and then use it as a common ground
to
> > move on with further version numbers. I would like to hear your
comments.
> > If no objection is heard, I will move on with 1.12.0 for the runtimes
to
> > be released under Apache for the first time.
> >
> > Best wishes,
> > Vincent Hou
> >
> >
> >
>
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes
for the first-time release under Apache
Posted by David P Grove <gr...@us.ibm.com>.
"Vincent S Hou" <sh...@us.ibm.com> wrote on 08/27/2018 12:39:01 PM:
>
> For convenience of release management in Apache.
> * We can send one or two vote email(s) instead of 6.
I realize that it will make the initial release more convenient. I don't
think this is a compelling reason however.
> * The download page of openwhisk.org can allocate one section to
> offer the download links of runtimes.
I don't think this is a good pattern. I predict we will be releasing
runtimes in individual cadences, driven by changes in the upstream base
language runtime, CVEs that need to be fixed via a new runtime release,
etc. So I think the download for the runtime needs to be organized by
runtime, then by version within each runtime, not by openwhisk version.
--dave
>
>
>
> Best wishes.
> Vincent Hou (侯胜博)
>
> Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM
Cloud
>
> Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
> Phone: +1(919)254-7182
> Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United
States
>
> -----Rodric Rabbah <ro...@gmail.com> wrote: -----
> To: dev@openwhisk.apache.org
> From: Rodric Rabbah <ro...@gmail.com>
> Date: 08/27/2018 11:45AM
> Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version
> for all runtimes for the first-time release under Apache
>
> Why do they all need to start from the same version?
>
> On Mon, Aug 27, 2018 at 11:40 AM, Vincent S Hou <sh...@us.ibm.com> wrote:
>
> > Hi OpenWhiskers,
> >
> > We are on our way to release OpenWhisk runtimes under Apache for the
first
> > time. As you may notice or not, each individual runtime repository has
> > already used
> > its own version numbers as the build tag for quite a while. In order
not
> > to disrupt the current versioning number and also accommodating the
release
> > work under Apache, I would like to propose 1.12.0 as the version number
for
> > the first time we release the six runtimes under Apache, because this
> > version number is the minimum
> > nominator I find for all the runtimes so far.
> >
> > We now have following runtimes, which have already released with their
> > version numbers:
> > docker skeleton v1.3.3
> > python2 v1.0.3
> > python3 v.1.0.3
> > node8 v1.12.0
> > node6 v1.12.0
> > php7.2 v1.0.2
> > swift4.1 v1.0.8
> > java8 v1.1.2
> >
> > I think 1.12.0 can match them all, and then use it as a common ground
to
> > move on with further version numbers. I would like to hear your
comments.
> > If no objection is heard, I will move on with 1.12.0 for the runtimes
to
> > be released under Apache for the first time.
> >
> > Best wishes,
> > Vincent Hou
> >
> >
> >
>
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all
runtimes for the first-time release under Apache
Posted by Rodric Rabbah <ro...@gmail.com>.
> I have been working my bones out during the past months to make sure
openwhisk, openwhisk-catalog, openwhisk-cli, openwhisk-client-go,
openwhisk-wskdeploy, openwhisk-apigateway, openwhisk-deploy-kube under
0.9.x version matching, and they work together. As long as the runtimes
work ok with them, they are good to release even in one tar.gz to work as
the openwhisk platform.
For sure, you have done a ton of work on pushing the many releases through.
This is a great deal of effort and important for openwhisk, and also for
graduating from incubation. It isn't said enough: Thank you!
-r
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all
runtimes for the first-time release under Apache
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, Aug 28, 2018 at 9:46 PM David P Grove <gr...@us.ibm.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...
FWIW we have a similar problem in Apache Sling which consists of many
(like around 300) modules which are released individually and which
you have to assemble to create a Sling server application.
The way it works is based on OSGi version numbers and requirements,
where (in brief) one can say that module A version 1.0.14 requires
module B versions 2.12.42 to 2.42.27 included - expressing
dependencies based on ranges of version numbers.
I think the same can work for OpenWhisk: release each module on its
own cadence as needed, ideally use semantic versioning to express API
and other incompatible changes, and regularly update a single "master
assembly list" where you test a given set of version numbers together
and declare that as a workable setup. Testing all possible
combinations is not practical, but regularly declaring known sets of
combinations as good, based on strong automated tests, works.
I'm not much familiar with OpenWhisk internals so hopefully this makes
sense - the main thing I want to say is that keeping version numbers
in sync is painful, whereas maintaining a single list of compatible
version number ranges, that's updated from time to time, is easier.
-Bertrand
[1] https://semver.org/
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all
runtimes for the first-time release under Apache
Posted by Justin Halsall <ju...@juice10.com>.
Just to confirm:
> On Aug 28, 2018, at 10:19 PM, Carlos Santana <cs...@gmail.com> wrote:
> 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.
...
> Nothing to do with runtimes you can use any version of any runtime old or
> new openwhisk will work fine.
I just verified and indeed my issues where related to the controller and the invoker, not the runtimes in this case.
You can disregard that from my earlier email.
Thanks for pointing that out Carlos
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all
runtimes for the first-time release under Apache
Posted by Carlos Santana <cs...@gmail.com>.
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 <ro...@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
>
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all
runtimes for the first-time release under Apache
Posted by Rodric Rabbah <ro...@gmail.com>.
> ... 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
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Posted by Rob Allen <ro...@akrabat.com>.
Hi,
How will this work when we need to do new releases of one runtime and not another?
E.g. PHP 7.3 is due soon and so I’ll be updating the PHP runtime for this. Assuming semantic versioning, we’ll need 1.13.0 for openwhisk-runtime-php as it’s a new feature, not a bug fix. 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?
i.e. 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.
Regards,
Rob
> On 28 Aug 2018, at 22:55, Vincent S Hou <sh...@us.ibm.com> wrote:
>
> Good. I am totally support getting rid of the old tagging system and embrace the way in Apache, and move on the future releases with it.
> 1.12.0 is the latest version for the old system across runtimes, and the earliest start for the new Apache version.
> To me, it is a perfect pick.
>
> In future, we should stop releasing multiple tags for different kinds in one repository. For example, nodejs 6 and nodejs 8, we should try to keep them
> under the same versioning number. As long as code is in the same repo, it should stick to the same version. If it is not obeyed, we have to revive the old tagging system, we are using now.
>
> Best wishes.
> Vincent Hou (侯胜博)
>
> Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud
>
> Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
> Phone: +1(919)254-7182
> Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States
>
> -----"David P Grove" <gr...@us.ibm.com> wrote: -----
> To: dev@openwhisk.apache.org
> From: "David P Grove" <gr...@us.ibm.com>
> Date: 08/28/2018 03:46PM
> Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
>
> "Vincent S Hou" <sh...@us.ibm.com> wrote on 08/28/2018 03:14:38 PM:
>>
>> The version number we choose for openwhisk runtimes to be released
>> under Apache as an incubator is a separate versioning system from
>> what we have already as GitHub tags. The apache version will not
>> break anything we have as legacy. The only difference it brings is
>> just a new tag.
>>
>> If we pick up 1.12.0-incubating for all the runtimes, all the source
>> code of runtimes are packaged in the artifacts available in
>> Apache SVN server. When they are released, a new tag 1.12.0-
>> incubating is added to the GitHub, but with some variations. Take
>> nodejs for instance, we added two tags
>> 6@1.12.0-incubating and 8@1.12.0-incubating to the same commit, so
>> that nodejs 8 will push 1.12.0-incubating image to dockerhub and
>> nodejs 6 will push 1.12.0-incubating as well. It is possible that
>> the new 1.12.0-incubating nodejs 8 image equals to an existing
>> image, like 1.9.0 or latest, but that is totally acceptable.
>> The same rule applies to any other runtime repository.
>>
>> The old GitHub tagging system can still work and develop as planned.
>> The new Apache versioning system can grow in parallel without any
>> interference. Right now, the apache version always ends with -
>> incubating because openwhisk is an incubator, so that we can clearly
>> distinguish it. In future, when we graduate, we can make sure the
>> apache version ends with -apache. All the docker images in dockerhub
>> are tagged with -incubating or -apache, without affecting the
>> existing GitHub tags we have.
>>
>> This is why I root for using the same Apache version for all the
>> openwhisk runtimes. It does not influence anything we currently have.
>>
>>
>
> Hi Vincent,
>
> I don't object to starting at 1.12.0 (or whatever the lowest unused
> number is across all previous tags). Version number space is cheap, we
> can skip some to align if you really want to do it that way. I don't think
> it is that useful, but I also don't think it is harmful.
>
> However, I do think we need to stop using the old system and only
> tag/release using the Apache process going forward. As pointed out in
> Bertrand's blog post [1], there are very solid reasons to do it that way.
> Assuming we do this, 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. I think this is fine, but I think we should
> realize now that is going to happen and not assume we will have aligned
> version numbers any time in the future (except perhaps for 2.0, 3.0. etc).
>
> --dave
>
> [1] https://blogs.apache.org/foundation/entry/success-at-apache-the-apache1
>
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes
for the first-time release under Apache
Posted by Vincent S Hou <sh...@us.ibm.com>.
Good. I am totally support getting rid of the old tagging system and embrace the way in Apache, and move on the future releases with it.
1.12.0 is the latest version for the old system across runtimes, and the earliest start for the new Apache version.
To me, it is a perfect pick.
In future, we should stop releasing multiple tags for different kinds in one repository. For example, nodejs 6 and nodejs 8, we should try to keep them
under the same versioning number. As long as code is in the same repo, it should stick to the same version. If it is not obeyed, we have to revive the old tagging system, we are using now.
Best wishes.
Vincent Hou (侯胜博)
Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud
Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States
-----"David P Grove" <gr...@us.ibm.com> wrote: -----
To: dev@openwhisk.apache.org
From: "David P Grove" <gr...@us.ibm.com>
Date: 08/28/2018 03:46PM
Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
"Vincent S Hou" <sh...@us.ibm.com> wrote on 08/28/2018 03:14:38 PM:
>
> The version number we choose for openwhisk runtimes to be released
> under Apache as an incubator is a separate versioning system from
> what we have already as GitHub tags. The apache version will not
> break anything we have as legacy. The only difference it brings is
> just a new tag.
>
> If we pick up 1.12.0-incubating for all the runtimes, all the source
> code of runtimes are packaged in the artifacts available in
> Apache SVN server. When they are released, a new tag 1.12.0-
> incubating is added to the GitHub, but with some variations. Take
> nodejs for instance, we added two tags
> 6@1.12.0-incubating and 8@1.12.0-incubating to the same commit, so
> that nodejs 8 will push 1.12.0-incubating image to dockerhub and
> nodejs 6 will push 1.12.0-incubating as well. It is possible that
> the new 1.12.0-incubating nodejs 8 image equals to an existing
> image, like 1.9.0 or latest, but that is totally acceptable.
> The same rule applies to any other runtime repository.
>
> The old GitHub tagging system can still work and develop as planned.
> The new Apache versioning system can grow in parallel without any
> interference. Right now, the apache version always ends with -
> incubating because openwhisk is an incubator, so that we can clearly
> distinguish it. In future, when we graduate, we can make sure the
> apache version ends with -apache. All the docker images in dockerhub
> are tagged with -incubating or -apache, without affecting the
> existing GitHub tags we have.
>
> This is why I root for using the same Apache version for all the
> openwhisk runtimes. It does not influence anything we currently have.
>
>
Hi Vincent,
I don't object to starting at 1.12.0 (or whatever the lowest unused
number is across all previous tags). Version number space is cheap, we
can skip some to align if you really want to do it that way. I don't think
it is that useful, but I also don't think it is harmful.
However, I do think we need to stop using the old system and only
tag/release using the Apache process going forward. As pointed out in
Bertrand's blog post [1], there are very solid reasons to do it that way.
Assuming we do this, 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. I think this is fine, but I think we should
realize now that is going to happen and not assume we will have aligned
version numbers any time in the future (except perhaps for 2.0, 3.0. etc).
--dave
[1] https://blogs.apache.org/foundation/entry/success-at-apache-the-apache1
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes
for the first-time release under Apache
Posted by David P Grove <gr...@us.ibm.com>.
"Vincent S Hou" <sh...@us.ibm.com> wrote on 08/28/2018 03:14:38 PM:
>
> The version number we choose for openwhisk runtimes to be released
> under Apache as an incubator is a separate versioning system from
> what we have already as GitHub tags. The apache version will not
> break anything we have as legacy. The only difference it brings is
> just a new tag.
>
> If we pick up 1.12.0-incubating for all the runtimes, all the source
> code of runtimes are packaged in the artifacts available in
> Apache SVN server. When they are released, a new tag 1.12.0-
> incubating is added to the GitHub, but with some variations. Take
> nodejs for instance, we added two tags
> 6@1.12.0-incubating and 8@1.12.0-incubating to the same commit, so
> that nodejs 8 will push 1.12.0-incubating image to dockerhub and
> nodejs 6 will push 1.12.0-incubating as well. It is possible that
> the new 1.12.0-incubating nodejs 8 image equals to an existing
> image, like 1.9.0 or latest, but that is totally acceptable.
> The same rule applies to any other runtime repository.
>
> The old GitHub tagging system can still work and develop as planned.
> The new Apache versioning system can grow in parallel without any
> interference. Right now, the apache version always ends with -
> incubating because openwhisk is an incubator, so that we can clearly
> distinguish it. In future, when we graduate, we can make sure the
> apache version ends with -apache. All the docker images in dockerhub
> are tagged with -incubating or -apache, without affecting the
> existing GitHub tags we have.
>
> This is why I root for using the same Apache version for all the
> openwhisk runtimes. It does not influence anything we currently have.
>
>
Hi Vincent,
I don't object to starting at 1.12.0 (or whatever the lowest unused
number is across all previous tags). Version number space is cheap, we
can skip some to align if you really want to do it that way. I don't think
it is that useful, but I also don't think it is harmful.
However, I do think we need to stop using the old system and only
tag/release using the Apache process going forward. As pointed out in
Bertrand's blog post [1], there are very solid reasons to do it that way.
Assuming we do this, 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. I think this is fine, but I think we should
realize now that is going to happen and not assume we will have aligned
version numbers any time in the future (except perhaps for 2.0, 3.0. etc).
--dave
[1] https://blogs.apache.org/foundation/entry/success-at-apache-the-apache1
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes
for the first-time release under Apache
Posted by Vincent S Hou <sh...@us.ibm.com>.
Hi everyone,
The version number we choose for openwhisk runtimes to be released under Apache as an incubator is a separate versioning system from what we have already as GitHub tags. The apache version will not break anything we have as legacy. The only difference it brings is just a new tag.
If we pick up 1.12.0-incubating for all the runtimes, all the source code of runtimes are packaged in the artifacts available in
Apache SVN server. When they are released, a new tag 1.12.0-incubating is added to the GitHub, but with some variations. Take nodejs for instance, we added two tags
6@1.12.0-incubating and 8@1.12.0-incubating to the same commit, so that nodejs 8 will push 1.12.0-incubating image to dockerhub and nodejs 6 will push 1.12.0-incubating as well. It is possible that the new 1.12.0-incubating nodejs 8 image equals to an existing image, like 1.9.0 or latest, but that is totally acceptable.
The same rule applies to any other runtime repository.
The old GitHub tagging system can still work and develop as planned. The new Apache versioning system can grow in parallel without any interference. Right now, the apache version always ends with -incubating because openwhisk is an incubator, so that we can clearly distinguish it. In future, when we graduate, we can make sure the apache version ends with -apache. All the docker images in dockerhub are tagged with -incubating or -apache, without affecting the existing GitHub tags we have.
This is why I root for using the same Apache version for all the openwhisk runtimes. It does not influence anything we currently have.
Best wishes.
Vincent Hou (侯胜博)
Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud
Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States
Hi David,
If I pick the commit ID 1fb97e9 for openwhisk-deploy-kube, which is a merge on Jun 28. Is it OK for the openwhisk release 0.9.0?
Best wishes.
Vincent Hou (侯胜博)
Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud
Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States
-----"David P Grove" <gr...@us.ibm.com> wrote: -----
To: dev@openwhisk.apache.org
From: "David P Grove" <gr...@us.ibm.com>
Date: 08/27/2018 02:42PM
Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Hi Vincent,
I respect the work that has been done and all that has been learned.
I agree there is a core set of repositories that need to be released together to make a platform.
But, we make a significant error in the order of release and continuing to use the "latest" tag in released branches. This is not your fault. We collectively missed it.
I am sorry but 0.9.0 openwhisk and 0.9.0 openwhisk-deploy-kube are not compatible. The core openwhisk release is from June 29. There have been multiple configuration changes in the core project since June 29 that have been reflected in openwhisk-0.9.0 deploy-kube. If you built a set of docker images from the 0.9.0 openwhisk src release they could not be successfully deployed using the 0.9.0 deploy-kube src release because the set of configuration flags for the controller/invoker are not compatible.
One possible solution to salvage 0.9.0 as a coherent set of source files is to remove openwhisk-kube-deploy from the 0.9.0 release. I don't know if this will be enough. There have also been changes in the various runtime projects since June 29 to match changes made in the core system post 0.9.0. It is possible that these are all forward/backward compatible, but I do not know that we have tested them to verify that. We will need to do a significant amount of testing if we want to be able to tell uses that they can actually use the 0.9.0 release as a coherent set of source files to build an OpenWhisk deployment themselves.
--dave
"Vincent S Hou" ---08/27/2018 02:13:59 PM---Hi Dave, > As it is, the 0.9.0 release is only useful for practice with the Apache
From: "Vincent S Hou" <sh...@us.ibm.com>
To: dev@openwhisk.apache.org
Date: 08/27/2018 02:13 PM
Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Hi Dave,
> As it is, the 0.9.0 release is only useful for practice with the Apache
> release process. The various source artifacts tagged 0.9.0 are not
> actually compatible with each other.
I am upset if you say this. I have been working my bones out during the past months to make sure
openwhisk, openwhisk-catalog, openwhisk-cli, openwhisk-client-go, openwhisk-wskdeploy, openwhisk-apigateway, openwhisk-deploy-kube
under 0.9.x version matching, and they work together. As long as the runtimes work ok with them, they are good to release even in one tar.gz to work as the openwhisk platform.
0.9.0 is not just an Apache practice. I know it is not perfect and has tons of things to improve it, but I have already tried my best. At the beginning, I hope all the modules including runtimes can have 0.9.0, so that all of them can release in one tar.gz, which is the basic standard I set for openwhisk to release for the first time under Apache. We are RELEASING really "intellectual asset" under Apache, that people can use. Not for practice with the Apache release process.
Best wishes.
Vincent Hou (侯胜博)
Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud
Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States
-----"David P Grove" <gr...@us.ibm.com> wrote: -----
To: dev@openwhisk.apache.org
From: "David P Grove" <gr...@us.ibm.com>
Date: 08/27/2018 01:46PM
Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Justin Halsall <ju...@juice10.com> wrote on 08/27/2018 01:16:41 PM:
>
> I recently bumped into docker-compose always pulling in the latest
> version of our containers but then failing because we had changed
> some of the dependent variables in the docker image but forgot to do
> so in our Docker Compose configuration files. With the centralized
> runtime manifest we could easily lock our deployments (including
> docker compose) to a release version with limited hassle.
>
Also been thinking about this. We do have a central manifest already
(runtime.json + ansible group_vars/all in the core project). The mistake we
made is that we left all these tags at "latest" in the 0.9.0 release
(arguably because there had not been a release of the sub-projects yet, so
there was nothing else to use as a tag value).
In future releases, we need to first officially release any of the "leaf"
projects that aren't current, then branch the core repo into a release
branch, then commit a version of runtime.json (and other ansible files) on
this branch that pulls from a fixed tag (not latest) for all the other
projects. Same thing for the kube-deploy, docker-compose, etc. -- branch,
commit fixed tags for images, then release.
As it is, the 0.9.0 release is only useful for practice with the Apache
release process. The various source artifacts tagged 0.9.0 are not
actually compatible with each other.
--dave
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes
for the first-time release under Apache
Posted by Vincent S Hou <sh...@us.ibm.com>.
Hi all,
There are 6 runtime projects to be release for the first time under Apache. I am gonna send off 6 vote mails soon for the votes, since each of them has individual version number. Please take your time to vote on them.
Best wishes.
Vincent Hou (侯胜博)
Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud
Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States
-----"Vincent S Hou" <sh...@us.ibm.com> wrote: -----
To: dev@openwhisk.apache.org
From: "Vincent S Hou" <sh...@us.ibm.com>
Date: 08/27/2018 03:35PM
Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Hi David,
If I pick the commit ID 1fb97e9 for openwhisk-deploy-kube, which is a merge on Jun 28. Is it OK for the openwhisk release 0.9.0?
Best wishes.
Vincent Hou (侯胜博)
Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud
Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States
-----"David P Grove" <gr...@us.ibm.com> wrote: -----
To: dev@openwhisk.apache.org
From: "David P Grove" <gr...@us.ibm.com>
Date: 08/27/2018 02:42PM
Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Hi Vincent,
I respect the work that has been done and all that has been learned.
I agree there is a core set of repositories that need to be released together to make a platform.
But, we make a significant error in the order of release and continuing to use the "latest" tag in released branches. This is not your fault. We collectively missed it.
I am sorry but 0.9.0 openwhisk and 0.9.0 openwhisk-deploy-kube are not compatible. The core openwhisk release is from June 29. There have been multiple configuration changes in the core project since June 29 that have been reflected in openwhisk-0.9.0 deploy-kube. If you built a set of docker images from the 0.9.0 openwhisk src release they could not be successfully deployed using the 0.9.0 deploy-kube src release because the set of configuration flags for the controller/invoker are not compatible.
One possible solution to salvage 0.9.0 as a coherent set of source files is to remove openwhisk-kube-deploy from the 0.9.0 release. I don't know if this will be enough. There have also been changes in the various runtime projects since June 29 to match changes made in the core system post 0.9.0. It is possible that these are all forward/backward compatible, but I do not know that we have tested them to verify that. We will need to do a significant amount of testing if we want to be able to tell uses that they can actually use the 0.9.0 release as a coherent set of source files to build an OpenWhisk deployment themselves.
--dave
"Vincent S Hou" ---08/27/2018 02:13:59 PM---Hi Dave, > As it is, the 0.9.0 release is only useful for practice with the Apache
From: "Vincent S Hou" <sh...@us.ibm.com>
To: dev@openwhisk.apache.org
Date: 08/27/2018 02:13 PM
Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Hi Dave,
> As it is, the 0.9.0 release is only useful for practice with the Apache
> release process. The various source artifacts tagged 0.9.0 are not
> actually compatible with each other.
I am upset if you say this. I have been working my bones out during the past months to make sure
openwhisk, openwhisk-catalog, openwhisk-cli, openwhisk-client-go, openwhisk-wskdeploy, openwhisk-apigateway, openwhisk-deploy-kube
under 0.9.x version matching, and they work together. As long as the runtimes work ok with them, they are good to release even in one tar.gz to work as the openwhisk platform.
0.9.0 is not just an Apache practice. I know it is not perfect and has tons of things to improve it, but I have already tried my best. At the beginning, I hope all the modules including runtimes can have 0.9.0, so that all of them can release in one tar.gz, which is the basic standard I set for openwhisk to release for the first time under Apache. We are RELEASING really "intellectual asset" under Apache, that people can use. Not for practice with the Apache release process.
Best wishes.
Vincent Hou (侯胜博)
Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud
Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States
-----"David P Grove" <gr...@us.ibm.com> wrote: -----
To: dev@openwhisk.apache.org
From: "David P Grove" <gr...@us.ibm.com>
Date: 08/27/2018 01:46PM
Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Justin Halsall <ju...@juice10.com> wrote on 08/27/2018 01:16:41 PM:
>
> I recently bumped into docker-compose always pulling in the latest
> version of our containers but then failing because we had changed
> some of the dependent variables in the docker image but forgot to do
> so in our Docker Compose configuration files. With the centralized
> runtime manifest we could easily lock our deployments (including
> docker compose) to a release version with limited hassle.
>
Also been thinking about this. We do have a central manifest already
(runtime.json + ansible group_vars/all in the core project). The mistake we
made is that we left all these tags at "latest" in the 0.9.0 release
(arguably because there had not been a release of the sub-projects yet, so
there was nothing else to use as a tag value).
In future releases, we need to first officially release any of the "leaf"
projects that aren't current, then branch the core repo into a release
branch, then commit a version of runtime.json (and other ansible files) on
this branch that pulls from a fixed tag (not latest) for all the other
projects. Same thing for the kube-deploy, docker-compose, etc. -- branch,
commit fixed tags for images, then release.
As it is, the 0.9.0 release is only useful for practice with the Apache
release process. The various source artifacts tagged 0.9.0 are not
actually compatible with each other.
--dave
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes
for the first-time release under Apache
Posted by Vincent S Hou <sh...@us.ibm.com>.
Hi David,
If I pick the commit ID 1fb97e9 for openwhisk-deploy-kube, which is a merge on Jun 28. Is it OK for the openwhisk release 0.9.0?
Best wishes.
Vincent Hou (侯胜博)
Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud
Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States
-----"David P Grove" <gr...@us.ibm.com> wrote: -----
To: dev@openwhisk.apache.org
From: "David P Grove" <gr...@us.ibm.com>
Date: 08/27/2018 02:42PM
Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Hi Vincent,
I respect the work that has been done and all that has been learned.
I agree there is a core set of repositories that need to be released together to make a platform.
But, we make a significant error in the order of release and continuing to use the "latest" tag in released branches. This is not your fault. We collectively missed it.
I am sorry but 0.9.0 openwhisk and 0.9.0 openwhisk-deploy-kube are not compatible. The core openwhisk release is from June 29. There have been multiple configuration changes in the core project since June 29 that have been reflected in openwhisk-0.9.0 deploy-kube. If you built a set of docker images from the 0.9.0 openwhisk src release they could not be successfully deployed using the 0.9.0 deploy-kube src release because the set of configuration flags for the controller/invoker are not compatible.
One possible solution to salvage 0.9.0 as a coherent set of source files is to remove openwhisk-kube-deploy from the 0.9.0 release. I don't know if this will be enough. There have also been changes in the various runtime projects since June 29 to match changes made in the core system post 0.9.0. It is possible that these are all forward/backward compatible, but I do not know that we have tested them to verify that. We will need to do a significant amount of testing if we want to be able to tell uses that they can actually use the 0.9.0 release as a coherent set of source files to build an OpenWhisk deployment themselves.
--dave
"Vincent S Hou" ---08/27/2018 02:13:59 PM---Hi Dave, > As it is, the 0.9.0 release is only useful for practice with the Apache
From: "Vincent S Hou" <sh...@us.ibm.com>
To: dev@openwhisk.apache.org
Date: 08/27/2018 02:13 PM
Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Hi Dave,
> As it is, the 0.9.0 release is only useful for practice with the Apache
> release process. The various source artifacts tagged 0.9.0 are not
> actually compatible with each other.
I am upset if you say this. I have been working my bones out during the past months to make sure
openwhisk, openwhisk-catalog, openwhisk-cli, openwhisk-client-go, openwhisk-wskdeploy, openwhisk-apigateway, openwhisk-deploy-kube
under 0.9.x version matching, and they work together. As long as the runtimes work ok with them, they are good to release even in one tar.gz to work as the openwhisk platform.
0.9.0 is not just an Apache practice. I know it is not perfect and has tons of things to improve it, but I have already tried my best. At the beginning, I hope all the modules including runtimes can have 0.9.0, so that all of them can release in one tar.gz, which is the basic standard I set for openwhisk to release for the first time under Apache. We are RELEASING really "intellectual asset" under Apache, that people can use. Not for practice with the Apache release process.
Best wishes.
Vincent Hou (侯胜博)
Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud
Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States
-----"David P Grove" <gr...@us.ibm.com> wrote: -----
To: dev@openwhisk.apache.org
From: "David P Grove" <gr...@us.ibm.com>
Date: 08/27/2018 01:46PM
Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Justin Halsall <ju...@juice10.com> wrote on 08/27/2018 01:16:41 PM:
>
> I recently bumped into docker-compose always pulling in the latest
> version of our containers but then failing because we had changed
> some of the dependent variables in the docker image but forgot to do
> so in our Docker Compose configuration files. With the centralized
> runtime manifest we could easily lock our deployments (including
> docker compose) to a release version with limited hassle.
>
Also been thinking about this. We do have a central manifest already
(runtime.json + ansible group_vars/all in the core project). The mistake we
made is that we left all these tags at "latest" in the 0.9.0 release
(arguably because there had not been a release of the sub-projects yet, so
there was nothing else to use as a tag value).
In future releases, we need to first officially release any of the "leaf"
projects that aren't current, then branch the core repo into a release
branch, then commit a version of runtime.json (and other ansible files) on
this branch that pulls from a fixed tag (not latest) for all the other
projects. Same thing for the kube-deploy, docker-compose, etc. -- branch,
commit fixed tags for images, then release.
As it is, the 0.9.0 release is only useful for practice with the Apache
release process. The various source artifacts tagged 0.9.0 are not
actually compatible with each other.
--dave
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes
for the first-time release under Apache
Posted by David P Grove <gr...@us.ibm.com>.
Hi Vincent,
I respect the work that has been done and all that has been learned.
I agree there is a core set of repositories that need to be released
together to make a platform.
But, we make a significant error in the order of release and
continuing to use the "latest" tag in released branches. This is not your
fault. We collectively missed it.
I am sorry but 0.9.0 openwhisk and 0.9.0 openwhisk-deploy-kube are
not compatible. The core openwhisk release is from June 29. There have
been multiple configuration changes in the core project since June 29 that
have been reflected in openwhisk-0.9.0 deploy-kube. If you built a set of
docker images from the 0.9.0 openwhisk src release they could not be
successfully deployed using the 0.9.0 deploy-kube src release because the
set of configuration flags for the controller/invoker are not compatible.
One possible solution to salvage 0.9.0 as a coherent set of source
files is to remove openwhisk-kube-deploy from the 0.9.0 release. I don't
know if this will be enough. There have also been changes in the various
runtime projects since June 29 to match changes made in the core system
post 0.9.0. It is possible that these are all forward/backward compatible,
but I do not know that we have tested them to verify that. We will need
to do a significant amount of testing if we want to be able to tell uses
that they can actually use the 0.9.0 release as a coherent set of source
files to build an OpenWhisk deployment themselves.
--dave
From: "Vincent S Hou" <sh...@us.ibm.com>
To: dev@openwhisk.apache.org
Date: 08/27/2018 02:13 PM
Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for
all runtimes for the first-time release under Apache
Hi Dave,
> As it is, the 0.9.0 release is only useful for practice with the Apache
> release process. The various source artifacts tagged 0.9.0 are not
> actually compatible with each other.
I am upset if you say this. I have been working my bones out during the
past months to make sure
openwhisk, openwhisk-catalog, openwhisk-cli, openwhisk-client-go,
openwhisk-wskdeploy, openwhisk-apigateway, openwhisk-deploy-kube
under 0.9.x version matching, and they work together. As long as the
runtimes work ok with them, they are good to release even in one tar.gz to
work as the openwhisk platform.
0.9.0 is not just an Apache practice. I know it is not perfect and has tons
of things to improve it, but I have already tried my best. At the
beginning, I hope all the modules including runtimes can have 0.9.0, so
that all of them can release in one tar.gz, which is the basic standard I
set for openwhisk to release for the first time under Apache. We are
RELEASING really "intellectual asset" under Apache, that people can use.
Not for practice with the Apache release process.
Best wishes.
Vincent Hou (侯胜博)
Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM
Cloud
Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United
States
-----"David P Grove" <gr...@us.ibm.com> wrote: -----
To: dev@openwhisk.apache.org
From: "David P Grove" <gr...@us.ibm.com>
Date: 08/27/2018 01:46PM
Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all
runtimes for the first-time release under Apache
Justin Halsall <ju...@juice10.com> wrote on 08/27/2018 01:16:41 PM:
>
> I recently bumped into docker-compose always pulling in the latest
> version of our containers but then failing because we had changed
> some of the dependent variables in the docker image but forgot to do
> so in our Docker Compose configuration files. With the centralized
> runtime manifest we could easily lock our deployments (including
> docker compose) to a release version with limited hassle.
>
Also been thinking about this. We do have a central manifest already
(runtime.json + ansible group_vars/all in the core project). The mistake we
made is that we left all these tags at "latest" in the 0.9.0 release
(arguably because there had not been a release of the sub-projects yet, so
there was nothing else to use as a tag value).
In future releases, we need to first officially release any of the "leaf"
projects that aren't current, then branch the core repo into a release
branch, then commit a version of runtime.json (and other ansible files) on
this branch that pulls from a fixed tag (not latest) for all the other
projects. Same thing for the kube-deploy, docker-compose, etc. -- branch,
commit fixed tags for images, then release.
As it is, the 0.9.0 release is only useful for practice with the Apache
release process. The various source artifacts tagged 0.9.0 are not
actually compatible with each other.
--dave
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes
for the first-time release under Apache
Posted by Vincent S Hou <sh...@us.ibm.com>.
Hi Dave,
> As it is, the 0.9.0 release is only useful for practice with the Apache
> release process. The various source artifacts tagged 0.9.0 are not
> actually compatible with each other.
I am upset if you say this. I have been working my bones out during the past months to make sure
openwhisk, openwhisk-catalog, openwhisk-cli, openwhisk-client-go, openwhisk-wskdeploy, openwhisk-apigateway, openwhisk-deploy-kube
under 0.9.x version matching, and they work together. As long as the runtimes work ok with them, they are good to release even in one tar.gz to work as the openwhisk platform.
0.9.0 is not just an Apache practice. I know it is not perfect and has tons of things to improve it, but I have already tried my best. At the beginning, I hope all the modules including runtimes can have 0.9.0, so that all of them can release in one tar.gz, which is the basic standard I set for openwhisk to release for the first time under Apache. We are RELEASING really "intellectual asset" under Apache, that people can use. Not for practice with the Apache release process.
Best wishes.
Vincent Hou (侯胜博)
Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud
Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States
-----"David P Grove" <gr...@us.ibm.com> wrote: -----
To: dev@openwhisk.apache.org
From: "David P Grove" <gr...@us.ibm.com>
Date: 08/27/2018 01:46PM
Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Justin Halsall <ju...@juice10.com> wrote on 08/27/2018 01:16:41 PM:
>
> I recently bumped into docker-compose always pulling in the latest
> version of our containers but then failing because we had changed
> some of the dependent variables in the docker image but forgot to do
> so in our Docker Compose configuration files. With the centralized
> runtime manifest we could easily lock our deployments (including
> docker compose) to a release version with limited hassle.
>
Also been thinking about this. We do have a central manifest already
(runtime.json + ansible group_vars/all in the core project). The mistake we
made is that we left all these tags at "latest" in the 0.9.0 release
(arguably because there had not been a release of the sub-projects yet, so
there was nothing else to use as a tag value).
In future releases, we need to first officially release any of the "leaf"
projects that aren't current, then branch the core repo into a release
branch, then commit a version of runtime.json (and other ansible files) on
this branch that pulls from a fixed tag (not latest) for all the other
projects. Same thing for the kube-deploy, docker-compose, etc. -- branch,
commit fixed tags for images, then release.
As it is, the 0.9.0 release is only useful for practice with the Apache
release process. The various source artifacts tagged 0.9.0 are not
actually compatible with each other.
--dave
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes
for the first-time release under Apache
Posted by David P Grove <gr...@us.ibm.com>.
Justin Halsall <ju...@juice10.com> wrote on 08/27/2018 01:16:41 PM:
>
> I recently bumped into docker-compose always pulling in the latest
> version of our containers but then failing because we had changed
> some of the dependent variables in the docker image but forgot to do
> so in our Docker Compose configuration files. With the centralized
> runtime manifest we could easily lock our deployments (including
> docker compose) to a release version with limited hassle.
>
Also been thinking about this. We do have a central manifest already
(runtime.json + ansible group_vars/all in the core project). The mistake we
made is that we left all these tags at "latest" in the 0.9.0 release
(arguably because there had not been a release of the sub-projects yet, so
there was nothing else to use as a tag value).
In future releases, we need to first officially release any of the "leaf"
projects that aren't current, then branch the core repo into a release
branch, then commit a version of runtime.json (and other ansible files) on
this branch that pulls from a fixed tag (not latest) for all the other
projects. Same thing for the kube-deploy, docker-compose, etc. -- branch,
commit fixed tags for images, then release.
As it is, the 0.9.0 release is only useful for practice with the Apache
release process. The various source artifacts tagged 0.9.0 are not
actually compatible with each other.
--dave
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Posted by Justin Halsall <ju...@juice10.com>.
I’ve been giving some thought about this recently. Maybe we could create a central repo with a JSON or Yaml manifest file that includes the names or our docker runtime images and the hashes/versions. We could tag/release these with version numbers synchronized with our main repository (in our current case 0.9.0).
All our deployments would then read this centralized manifest to see which runtimes to pull in for their corresponding version numbers.
This might allow us to vote in one location as the new version would include all dependent docker images.
This would also be helpful when adding a new runtime. If all our deployment methods pull in the centralized file to read the runtimes available we won’t have to hardcode all the different runtimes we have in each deployment method.
I recently bumped into docker-compose always pulling in the latest version of our containers but then failing because we had changed some of the dependent variables in the docker image but forgot to do so in our Docker Compose configuration files. With the centralized runtime manifest we could easily lock our deployments (including docker compose) to a release version with limited hassle.
Cheers,
Justin
Sent from my iPhone
> On Aug 27, 2018, at 12:39 PM, Vincent S Hou <sh...@us.ibm.com> wrote:
>
> For convenience of release management in Apache.
> * We can send one or two vote email(s) instead of 6.
> * The download page of openwhisk.org can allocate one section to offer the download links of runtimes.
>
>
>
> Best wishes.
> Vincent Hou (侯胜博)
>
> Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud
>
> Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
> Phone: +1(919)254-7182
> Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States
>
> -----Rodric Rabbah <ro...@gmail.com> wrote: -----
> To: dev@openwhisk.apache.org
> From: Rodric Rabbah <ro...@gmail.com>
> Date: 08/27/2018 11:45AM
> Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
>
> Why do they all need to start from the same version?
>
>> On Mon, Aug 27, 2018 at 11:40 AM, Vincent S Hou <sh...@us.ibm.com> wrote:
>>
>> Hi OpenWhiskers,
>>
>> We are on our way to release OpenWhisk runtimes under Apache for the first
>> time. As you may notice or not, each individual runtime repository has
>> already used
>> its own version numbers as the build tag for quite a while. In order not
>> to disrupt the current versioning number and also accommodating the release
>> work under Apache, I would like to propose 1.12.0 as the version number for
>> the first time we release the six runtimes under Apache, because this
>> version number is the minimum
>> nominator I find for all the runtimes so far.
>>
>> We now have following runtimes, which have already released with their
>> version numbers:
>> docker skeleton v1.3.3
>> python2 v1.0.3
>> python3 v.1.0.3
>> node8 v1.12.0
>> node6 v1.12.0
>> php7.2 v1.0.2
>> swift4.1 v1.0.8
>> java8 v1.1.2
>>
>> I think 1.12.0 can match them all, and then use it as a common ground to
>> move on with further version numbers. I would like to hear your comments.
>> If no objection is heard, I will move on with 1.12.0 for the runtimes to
>> be released under Apache for the first time.
>>
>> Best wishes,
>> Vincent Hou
>>
>>
>>
>
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes
for the first-time release under Apache
Posted by Vincent S Hou <sh...@us.ibm.com>.
For convenience of release management in Apache.
* We can send one or two vote email(s) instead of 6.
* The download page of openwhisk.org can allocate one section to offer the download links of runtimes.
Best wishes.
Vincent Hou (侯胜博)
Advisory Software Engineer, OpenWhisk Contributor, Open Technology, IBM Cloud
Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States
-----Rodric Rabbah <ro...@gmail.com> wrote: -----
To: dev@openwhisk.apache.org
From: Rodric Rabbah <ro...@gmail.com>
Date: 08/27/2018 11:45AM
Subject: Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Why do they all need to start from the same version?
On Mon, Aug 27, 2018 at 11:40 AM, Vincent S Hou <sh...@us.ibm.com> wrote:
> Hi OpenWhiskers,
>
> We are on our way to release OpenWhisk runtimes under Apache for the first
> time. As you may notice or not, each individual runtime repository has
> already used
> its own version numbers as the build tag for quite a while. In order not
> to disrupt the current versioning number and also accommodating the release
> work under Apache, I would like to propose 1.12.0 as the version number for
> the first time we release the six runtimes under Apache, because this
> version number is the minimum
> nominator I find for all the runtimes so far.
>
> We now have following runtimes, which have already released with their
> version numbers:
> docker skeleton v1.3.3
> python2 v1.0.3
> python3 v.1.0.3
> node8 v1.12.0
> node6 v1.12.0
> php7.2 v1.0.2
> swift4.1 v1.0.8
> java8 v1.1.2
>
> I think 1.12.0 can match them all, and then use it as a common ground to
> move on with further version numbers. I would like to hear your comments.
> If no objection is heard, I will move on with 1.12.0 for the runtimes to
> be released under Apache for the first time.
>
> Best wishes,
> Vincent Hou
>
>
>
Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all
runtimes for the first-time release under Apache
Posted by Rodric Rabbah <ro...@gmail.com>.
Why do they all need to start from the same version?
On Mon, Aug 27, 2018 at 11:40 AM, Vincent S Hou <sh...@us.ibm.com> wrote:
> Hi OpenWhiskers,
>
> We are on our way to release OpenWhisk runtimes under Apache for the first
> time. As you may notice or not, each individual runtime repository has
> already used
> its own version numbers as the build tag for quite a while. In order not
> to disrupt the current versioning number and also accommodating the release
> work under Apache, I would like to propose 1.12.0 as the version number for
> the first time we release the six runtimes under Apache, because this
> version number is the minimum
> nominator I find for all the runtimes so far.
>
> We now have following runtimes, which have already released with their
> version numbers:
> docker skeleton v1.3.3
> python2 v1.0.3
> python3 v.1.0.3
> node8 v1.12.0
> node6 v1.12.0
> php7.2 v1.0.2
> swift4.1 v1.0.8
> java8 v1.1.2
>
> I think 1.12.0 can match them all, and then use it as a common ground to
> move on with further version numbers. I would like to hear your comments.
> If no objection is heard, I will move on with 1.12.0 for the runtimes to
> be released under Apache for the first time.
>
> Best wishes,
> Vincent Hou
>
>
>