You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by Mikhail Epikhin <mi...@epikhin.net> on 2018/10/05 06:03:19 UTC
Ubuntu 18.04 support
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
Re: Ubuntu 18.04 support
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi Mikhail,
Let's discuss this one-by-one:
puppet versioning is a long standing problem, since every distribution had its own version of puppet bundled.
Additionially the packages from puppetlabs do not support all the range of architectures.
I doublechecked and it seems puppetlabs now supports ppc64le starting with puppet5, but still misses to support aarch64 aka arm64 .
http://apt.puppetlabs.com/pool/xenial/puppet5/p/puppet-agent/ <http://apt.puppetlabs.com/pool/xenial/puppet5/p/puppet-agent/>
Mixing puppetlabs and OS supplied packages on different platforms poses a problem: Binaries and Config Files are in different places, creating a huge task to write and test platform independent scripts.
So let's stick with OS supplied packages, since these support all archs (amd64/ppc64le/aarch64)
OS & prepackaged puppet
Debian 9 | 4.8.2
ubuntu 16.04 | 3.8.5
fedora 26 | 4 ? *** EOL ***
rhel-7 / epel | 3.6.2
opensuse 42.3 | 3.8.7
opensuse 15 | ----- puppet not included any more ---
Right now we are struggeling to get the mixed puppet3 and puppet4 systems running
NEW: ubuntu 18.04 | puppet 5.4.0
NEW: fedora 29 | 5.5.1
NEW: Debian buster (testing) | 5.5.6
Supporting fedora > 26 is complicated since fedora includes an own hadoop distribution incompatble with bigtop.
Debian buster is still testing with no release date announced AFAIK.
IMHO puppet5 can only be done if we drop fedora (because of its own hadoop), opensuse (lack of puppet5), ubunt16.04 (lack of puppet5 for aarch64), move to Debian testing and use puppetlab's puppet5 for RHEL-7 . We are dropping a lot of problems--and customers :-)
Do you have suggestions how to mitigate this problem?
Olaf
> Am 05.10.2018 um 19:46 schrieb Evans Ye <ev...@apache.org>:
>
> 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 <mi...@epikhin.net>於 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
>>
Re: Ubuntu 18.04 support
Posted by Mikhail Epikhin <mi...@epikhin.net>.
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 <mi...@epikhin.net>於 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)
Re: Ubuntu 18.04 support
Posted by Konstantin Boudnik <co...@apache.org>.
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 <mi...@epikhin.net>於 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
> >
Re: Ubuntu 18.04 support
Posted by Evans Ye <ev...@apache.org>.
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 <mi...@epikhin.net>於 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
>