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 > > >
