Guys, thanks for the responses! Right now, i'm switched to 16.04 and this problem not blocking me. But, we should think about future.
To Evans Ye: > 1. What’s the trigger that you wanna have support for Ubuntu 18.04? Is it easier to make a shift to Ubuntu 18.04 if we wait for it to be more mature? If you start new project, the getting last stable version is a good choice, so, why don't do it?:) Apache Bigtop cut's support of ubuntu 14.04 before EOL of distribution, and the great choice is choose version with further EOL. Ubuntu 18.04 have newest packets, kernel, systemd. EOL of 16.04 is not too far, in 2021, and this is a date of ending maintenance support, without supporting new hardware. Supporting new hardware ends in this year. https://www.ubuntu.com/about/release-cycle > 2. The refactor is a total package. So if we upgrade the whole build system > for Ubuntu 18.04. Does the Debian side or even the RPM side gonna be > compatible for those OS specific tools? This is a great question! And this is a reason why i start discussion here:) I'm using only Ubuntu, and don't fully understand support of other distributions. But! As we saw, many of distribution switching to systemd and we should support it anyway. Debian, Ubuntu, Fedora, RHEL, all of these distribution switching to systemd. Sometime, supporting of 16.04 is ended, and then we should support new version. It's a good time to think about how to do it. To Olaf Flebbe: You are right, and my opinion is that the problem is a using "deploying tool" for one hadoop-distribution from many linux-distributions, from many versions, architectures. Every Linux distribution (with different version and architecture) have own versions of puppet, and this is a problem. If we want to support many of linux-distributives, then we should choice one of two: 1. Building own puppet as a toolchain, for all supported distributives. Not fork of puppet, but building all necessary components for all supported environments. Just a yet another repository, but with one version of puppet, modules and other dependencies. 2. Using something another for "deploying tool". Using something independent of distribution, for example, create toolkit-container with ansible (or anything else), that can go to container with current distributive and execute logic for building and deploying. Writing own "deploying-tool" for second choice is also a option, but more difficult and uncertain. The first way looks easier than the second. Or, of course, as you described it, we can drop supporting one of GNU/Linux distributives for supporting others, but this is a also strange. We does not support newest distributives, we dropping support before EOL, our toolchain is fully dependend of puppet and we can't go farther. What we should do if the dependencies are blocking us, as right now? I'm interesting in supporting Apache Bigtop project, and if you have any ideas how to support newest versions of distributives, i can write some parts of the code:) -- Mikhail Epikhin On Sat, Oct 6, 2018, at 12:58, Konstantin Boudnik wrote: > Piling up on Evans' points: doing the work right away might be a good idea. > However, considering the span and potential instability of the changes we > should do it on a branch and only put an essential work on master, that might > improve the overall state of the project. Say, upgrading to Puppet 5 might not > be taken well by CentOS7. And while I don't particularly care about what would > happen to it ;), it is a part of our supported matrix. > > Once we think the branch is ready to get merged, we'll bite the bullet and > move to the new "platform". > > Any comments? > Cos > > On Sat, Oct 06, 2018 at 01:46AM, Evans Ye wrote: > > Hi Mikhail, > > > > Thank you for sharing your survey of supporting Ubuntu 18.04 in bigtop. I’d > > like to take a step back and ask some really dumb questions if you dont > > mind ;) > > > > 1. What’s the trigger that you wanna have support for Ubuntu 18.04? Is it > > easier to make a shift to Ubuntu 18.04 if we wait for it to be more mature? > > 2. The refactor is a total package. So if we upgrade the whole build system > > for Ubuntu 18.04. Does the Debian side or even the RPM side gonna be > > compatible for those OS specific tools? > > > > Evans > > > > Mikhail Epikhin <[email protected]>於 2018年10月5日 週五，下午2:03寫道： > > > > > Hi folks! > > > > > > I wrote this post on github https://github.com/apache/bigtop/pull/374, > > > but, it will be better to move this discussion to mail. > > > > > > TL;DR > > > Just before support ubuntu 18.04 we should do some major things, and > > > before doing it we should reach an agreement: > > > > > > * Support puppet 5, current version is 3. > > > * Rewrite templating and code generation of initrd scripts and support > > > systemd services. > > > * Use aptly insteadof reprepro for debian-based distros? > > > > > > Okey, now longread: > > > > > > Ubuntu 18.04 supports only puppet 5, but in bigtop we are using puppet 3. > > > I've tried to using manifests from third version, but puppet fifth have > > > new > > > keyword like site, and some configs clashes with puppet 5. I fixed that, > > > but, i don't know, maybe some problems are still there. Living with > > > manifests for two versions is not good idea, so we need to choice one of > > > them and migrate all code to newest deploy system. > > > > > > Ubuntu 18.04 have magic converting tool from sysvinit to systemd services, > > > but it doesn't work with current initd scritps. I successfully tried to > > > write some of systemd services, but this way have a couple of shades: > > > a) We should generate this services as we generate initd services, but the > > > current way is a bit of weird. A lot of bash templating, and current "bash > > > templates" a not usable for new systemd services, just because the same > > > things in both ways are very different. Working with locks, pids, > > > controlling aliveness of a process, controlling user and group. I've tried > > > to change current bash templates, but the code looks ugly. > > > b) A lot of components. And each components have a lot of services. I just > > > can't write a templating script for all of this scripts, because every > > > service have own specific things in bash methods, and u cannot convert it > > > automatically, only by reading your eyes. > > > c) Current initrd scripts have custom features like rollingupgrade and > > > init in hdfs-namenode. Systemd doesn't support that, and the right ways is > > > -- create new systemd service only for that! For each custom feature and > > > action -- new systemd service. A lot of services. > > > > > > This is not blocker issue, but the execution of ./gradlew apt on builded > > > components doesn't support *.ddeb artifacts. Newest reprepro doesn't > > > support this files, and the problem looks like this > > > https://github.com/ros-infrastructure/buildfarm_deployment/issues/186 and > > > we have three ways: > > > a) skip these artifacts, weird way; > > > b) use new version of reprepro not from ubuntu repositories, which is also > > > weird; > > > c) use tool like https://www.aptly.info, which is more supportable and > > > powerful in features. > > > > > > If anyone have a time for support 18.04 it would be great for doing it > > > together with splitting this pull request to sub tasks and discussion it. > > > > > > So, anyone?:) > > > > > > --- > > > Mikhail Epikhin > > > > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature)
