Hi All, When it comes to choosing the official Apache Docker image for Heron we have to think of the licensing issues first. Everything that is installed into the container at build time with the exception of the "FROM" statement in the Dockerfile must be ALv2 compatible. OpenJDK is under GPLv2 which is not compatible with Apache. However we can get around this if we bring the OpenJDK into the container via a FROM statement. I've copied a reply from Dave in our dev list in a previous email. See below.
######## Start ######## Regarding OpenJDK and GPL2 - here is what Roman the VP, Legal wrote when answering Beam’s questions. Roman Shaposhnik commented on LEGAL-503: ---------------------------------------- Hey [~altay] if you would like to continue linking to the Docker release artifact from the https://beam.apache.org you will have: 1. Transition to the official ASF dockerhub org: https://hub.docker.com/u/apache 2. Start including that binary convenience artifact into your VOTE threads on Beam releases 3. Make sure that all Cat-X licenses are ONLY brought into your container via FROM statements ######## End ######## So at the end of the day, we need to use a container that has Java already installed in it so that when we create our official image we can inherit that java containing image via a FROM statement. - Josh On Sun, May 17, 2020 at 4:12 PM H W <[email protected]> wrote: > We use Centos 7 as well. > > On Sun, May 17, 2020 at 10:41 AM Nicholas Nezis <[email protected]> > wrote: > > > Some thoughts I'd like to add to the discussion: > > > > Debian and Ubuntu are somewhat similar. Would it make sense to pick one > of > > those and pair with Centos? > > > > I've run into issues with Ubuntu images having DNS issues in Kubernetes. > > https://github.com/kubernetes/kubeadm/issues/787 > > > > Ubuntu 14.04 should be removed. It was end of life last year. For those > of > > you using Heron in production, is anyone using Ubuntu 16? My vote would > be > > to remove it also. For what it's worth, my use case is in K8s and we use > > the Centos7 image on a Centos 7 OS. > > > > We should do a test of the official image and helm chart in Kubernetes > > (maybe with Kind https://kind.sigs.k8s.io/ ) as part of our release > > process. This might be nice to add as an integration test. > > > > > > > > > > > > > > > > On Sun, May 17, 2020, 12:37 PM Ning Wang <[email protected]> wrote: > > > > > That is a good point. We need to adjust the OS version accordingly too. > > > > > > On Sun, May 17, 2020 at 2:28 AM Windham Wong <[email protected] > > > > > wrote: > > > > > > > > > > > debian 10 has no python 2.7 support. Ubuntu 16.04 has no python 3.7+ > > dev > > > > library support. hope this helps > > > > -- > > > > Sent from myMail for Android Sunday, 17 May 2020, 11:34AM +08:00 from > > > Ning > > > > Wang [email protected] : > > > > > > > > >Hi, > > > > > > > > > >We have talked about it a few times in different places. Let's make > a > > > > >decision here. We don't have enough resources to support many docker > > > OSes > > > > >(technically we only support Debian, Ubuntu, and CentOS but each of > > them > > > > >has multiple versions). > > > > > > > > > >Things we have agreed on (my understanding) > > > > >- for binary release, we are going to choose one OS one version. I > > > > >remember that Debian 9 was the decision. An open question is: do we > > want > > > > to > > > > >switch to Debian 10 now? We haven't had a binary release yet, so > there > > > is > > > > >still time. As the main target, I think 1. the image should compile > > > > >successfully. and 2 the image should be tested: the tools and an > > example > > > > >topology. > > > > > > > > > >- for source release, we haven't talked about it very much. > > Personally I > > > > >feel it is a reasonable expectation that, if we have the Docker file > > in > > > > the > > > > >core folders, it should at least compile. Otherwise, it's a failed > > build > > > > >hence a failed release. We are not going to test run the tools and > > > > examples > > > > >for each release though. > > > > > > > > > >Finally, a question about OS versions. I believe at least two > releases > > > > >should be supported because most people don't upgrade to the latest > > > > version > > > > >when it is out in more serious scenarios, hence IMO the second > oldest > > > > could > > > > >often be more useful than the latest one from a convenience point of > > > view. > > > > >On the other hand, this is too flexible, and we will spend time > > thinking > > > > >about it again. I think a clear guideline could be helpful to us. > For > > > > >example: > > > > >- We only include only Debian (popular in the server world) and > Ubuntu > > > > >(popular in servers and workstations). > > > > >- for the main OS (Debian) we choose the latest to compile and test > > for > > > > our > > > > >binary release. > > > > >- for a given OS, only two versions (most likely the most and the > > second > > > > >recent releases) are included in the core source code and they need > to > > > be > > > > >fixed ASAP if they don't compile. > > > > >- OSs and other versions could be included in a special folder and > but > > > > >there is no guarantee that the code will compile. Fixes from the > > > community > > > > >are welcome. > > > > > > > > > > > > > > >How do you guys think? > > > > >--ning > > > > > > > > > >
