openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent S Hou" <s...@us.ibm.com>
Subject Re: [DISCUSSION]: Proposing to use 1.12.0 as the version for all runtimes for the first-time release under Apache
Date Tue, 28 Aug 2018 19:14:38 GMT
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" <groved@us.ibm.com> wrote: -----
To: dev@openwhisk.apache.org
From: "David P Grove" <groved@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" <shou@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" <groved@us.ibm.com> wrote: -----
To: dev@openwhisk.apache.org
From: "David P Grove" <groved@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 <justin@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




  




Mime
View raw message