You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by Olaf Flebbe <of...@oflebbe.de> on 2017/11/01 21:46:28 UTC
bigtop next : platform bitrot
Hi,
While doing some regression tests with bigtop-1.2.1 I clearly saw we have some distros now getting outdated giving us more and more headaches.
IMHO, for current trunk, to be contained in next release we should chose:
debian:
I propose to replace debian-8 by debian-9 . debian-9 is the current stable now.
opensuse:
Replace opensuse-42.1 by opensuse-42.3
ubuntu:
remove ubuntu-14.04 because this will be obsolete as old LTS by bigtop next release
centos:
Can we discontinue centos-6 now ?
puppet 4:
Some of our code is subject to bitrod because of puppet modules are advancing (specifically apt module)
I propose to advance our platforms to install puppet4 or later by default.
This places a problem at least for ubuntu-16.04 and debian8 on non x86 platforms (ie ppc64le, aarch64) , since these platforms are not supported by puppetlabs where we usually get puppet from.
Therefore I propose to remove debian-8-aarch64 , ubuntu-16.04-aarch64, ubuntu-16.04-ppc64le in bigtop trunk .
Or is there a puppet4 suitable for ubuntu-16.04 somewhere ?
ubuntu-17.* and debian-9 do contain puppet4 in distro.
We may support ubuntu 17.10 for now and upgrading to LTS when it is released
Maybe it would be a good idea to only support aarch64 and ppc64le on fast moving distros (fedora, ubuntu non LTS) for now in order to get upstream updates fast.
maven-3.9
gradle 4.2 (4.3?)
Thoughts, opinions?
Cheers,
Olaf
Re: bigtop next : platform bitrot
Posted by Evans Ye <ev...@apache.org>.
Direction-wise I'm very much agree with most of the points that Olaf made.
Even for components, I'm more flavor of including newer versions. But in
order to do so, we need to spend time on upgrading them.
Which is why I think reducing the coverage but improving the quality of
components is something we can do.
> Can we discontinue centos-6 now ?
I already reached out to my friends who I think is still on CentOS 6. But
the concept here is we'll do CentOS only if people wants to maintain it
fully. I personally will spend time on improving other areas of Bigtop.
> Therefore I propose to remove debian-8-aarch64 , ubuntu-16.04-aarch64,
ubuntu-16.04-ppc64le in bigtop trunk .
I think we should just take a step back. Given that folks have contributed,
and are contributing things around PPC64LE and AARCH64 in Bigtop, we should
hear there voice first. But during 1.2.1 release indeed I find it's hard to
keep these distros up to the pace. A better collaboration might solve the
problem.
> Puppet 4...
Or having those distros pined to Puppet 3? But the maintaining effort goes
to Puppet 3 only distros.
On a boarder spectrum of Bigtop next, I'd like to improve our integration
testing stuffs.
BTW we've had a similar discussion before. Let me recall that here FYR:
https://docs.google.com/document/d/1F2Gxu8GARQDZXgqHn12LKkQ5wCV_AF4b_tVmjYB6YfA/edit
2017-11-06 1:43 GMT+08:00 Olaf Flebbe <of...@oflebbe.de>:
> Hi Peter,
>
> I had a short look into opensuse-42.3. it only contains the outdated
> puppet-3.8 .
> thumbleweed seems not to contain puppet et all.
>
> We could use puppet from puppetlabs (sles 12 build seems to install, at
> least) for opensuse 42.3,
> That would bring opensuse back on par with respect to other platforms.
>
> But the perspective of supporting aarch64, ppc64le will be not possible
> with this attempt,
> since puppetlabs does not support this platform with its own builds.
>
> Since tumbleweed does not contain no puppet any more, I see big problems
> for opensuse-15 (sic!) in future.
>
> Do you know any other puppet4 repos for opensuse ? Do you have the
> rational why puppet4 is not included (not even puppet3)?
>
> The other solution would be to turn away from puppet completly, but that
> would be a very major task.
>
> Greetings,
> Olaf
>
>
>
>
> Am 05.11.2017 um 05:40 schrieb Peter Linnell <pl...@scribus.net>:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 1 Nov 2017 22:46:28 +0100
> Olaf Flebbe <of...@oflebbe.de> wrote:
>
> Hi,
>
> While doing some regression tests with bigtop-1.2.1 I clearly saw we
> have some distros now getting outdated giving us more and more
> headaches.
>
> IMHO, for current trunk, to be contained in next release we should
> chose:
>
> debian:
> I propose to replace debian-8 by debian-9 . debian-9 is the current
> stable now.
>
> opensuse:
> Replace opensuse-42.1 by opensuse-42.3
>
> ubuntu:
> remove ubuntu-14.04 because this will be obsolete as old LTS by
> bigtop next release
>
> centos:
> Can we discontinue centos-6 now ?
>
> puppet 4:
> Some of our code is subject to bitrod because of puppet modules are
> advancing (specifically apt module)
>
> I propose to advance our platforms to install puppet4 or later by
> default.
>
> This places a problem at least for ubuntu-16.04 and debian8 on non
> x86 platforms (ie ppc64le, aarch64) , since these platforms are not
> supported by puppetlabs where we usually get puppet from.
>
> Therefore I propose to remove debian-8-aarch64 ,
> ubuntu-16.04-aarch64, ubuntu-16.04-ppc64le in bigtop trunk .
>
> Or is there a puppet4 suitable for ubuntu-16.04 somewhere ?
>
> ubuntu-17.* and debian-9 do contain puppet4 in distro.
> We may support ubuntu 17.10 for now and upgrading to LTS when it is
> relea
>
> Maybe it would be a good idea to only support aarch64 and ppc64le
>
> fast moving distros (fedora, ubuntu non LTS) for now in order to get
> upstream updates fast.
>
> maven-3.9
>
> gradle 4.2 (4.3?)
>
> Thoughts, opinions?
>
> Cheers,
> Olaf
>
>
>
> Hello Olaf,
>
> A good synopsis and I agree with most.
>
> aarch64 and ppc64le should work for openSUSE 42.3. If not, I am happy
> to look into issues.
>
> What would be interesting to explore is openSUSE Tumbleweed, which is a
> rolling distro with the newest versions of everything, but tested with
> a ton of automated QA. E.g Java 9, GCC 7.x latest etc. This should
> help us with upcoming versions of toolchains for all distros. Just a
> thought....
>
> Thanks!
>
> Peter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iEYEARECAAYFAln+lk8ACgkQ73uV5/YBZtplPACgitk0vItmryydTdhowp7oIq+p
> N+UAoLbU2CsDbcXEzlgVOL7kFOj8UBmO
> =oR/i
> -----END PGP SIGNATURE-----
>
>
>
Re: bigtop next : platform bitrot
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi Peter,
I had a short look into opensuse-42.3. it only contains the outdated puppet-3.8 .
thumbleweed seems not to contain puppet et all.
We could use puppet from puppetlabs (sles 12 build seems to install, at least) for opensuse 42.3,
That would bring opensuse back on par with respect to other platforms.
But the perspective of supporting aarch64, ppc64le will be not possible with this attempt,
since puppetlabs does not support this platform with its own builds.
Since tumbleweed does not contain no puppet any more, I see big problems for opensuse-15 (sic!) in future.
Do you know any other puppet4 repos for opensuse ? Do you have the rational why puppet4 is not included (not even puppet3)?
The other solution would be to turn away from puppet completly, but that would be a very major task.
Greetings,
Olaf
> Am 05.11.2017 um 05:40 schrieb Peter Linnell <pl...@scribus.net>:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 1 Nov 2017 22:46:28 +0100
> Olaf Flebbe <of@oflebbe.de <ma...@oflebbe.de>> wrote:
>
>> Hi,
>>
>> While doing some regression tests with bigtop-1.2.1 I clearly saw we
>> have some distros now getting outdated giving us more and more
>> headaches.
>>
>> IMHO, for current trunk, to be contained in next release we should
>> chose:
>>
>> debian:
>> I propose to replace debian-8 by debian-9 . debian-9 is the current
>> stable now.
>>
>> opensuse:
>> Replace opensuse-42.1 by opensuse-42.3
>>
>> ubuntu:
>> remove ubuntu-14.04 because this will be obsolete as old LTS by
>> bigtop next release
>>
>> centos:
>> Can we discontinue centos-6 now ?
>>
>> puppet 4:
>> Some of our code is subject to bitrod because of puppet modules are
>> advancing (specifically apt module)
>>
>> I propose to advance our platforms to install puppet4 or later by
>> default.
>>
>> This places a problem at least for ubuntu-16.04 and debian8 on non
>> x86 platforms (ie ppc64le, aarch64) , since these platforms are not
>> supported by puppetlabs where we usually get puppet from.
>>
>> Therefore I propose to remove debian-8-aarch64 ,
>> ubuntu-16.04-aarch64, ubuntu-16.04-ppc64le in bigtop trunk .
>>
>> Or is there a puppet4 suitable for ubuntu-16.04 somewhere ?
>>
>> ubuntu-17.* and debian-9 do contain puppet4 in distro.
>> We may support ubuntu 17.10 for now and upgrading to LTS when it is
>> relea
>>
>> Maybe it would be a good idea to only support aarch64 and ppc64le
>>
>> fast moving distros (fedora, ubuntu non LTS) for now in order to get
>> upstream updates fast.
>>
>> maven-3.9
>>
>> gradle 4.2 (4.3?)
>>
>> Thoughts, opinions?
>>
>> Cheers,
>> Olaf
>
>
> Hello Olaf,
>
> A good synopsis and I agree with most.
>
> aarch64 and ppc64le should work for openSUSE 42.3. If not, I am happy
> to look into issues.
>
> What would be interesting to explore is openSUSE Tumbleweed, which is a
> rolling distro with the newest versions of everything, but tested with
> a ton of automated QA. E.g Java 9, GCC 7.x latest etc. This should
> help us with upcoming versions of toolchains for all distros. Just a
> thought....
>
> Thanks!
>
> Peter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iEYEARECAAYFAln+lk8ACgkQ73uV5/YBZtplPACgitk0vItmryydTdhowp7oIq+p
> N+UAoLbU2CsDbcXEzlgVOL7kFOj8UBmO
> =oR/i
> -----END PGP SIGNATURE-----
Re: bigtop next : platform bitrot
Posted by Peter Linnell <pl...@scribus.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 1 Nov 2017 22:46:28 +0100
Olaf Flebbe <of...@oflebbe.de> wrote:
> Hi,
>
> While doing some regression tests with bigtop-1.2.1 I clearly saw we
> have some distros now getting outdated giving us more and more
> headaches.
>
> IMHO, for current trunk, to be contained in next release we should
> chose:
>
> debian:
> I propose to replace debian-8 by debian-9 . debian-9 is the current
> stable now.
>
> opensuse:
> Replace opensuse-42.1 by opensuse-42.3
>
> ubuntu:
> remove ubuntu-14.04 because this will be obsolete as old LTS by
> bigtop next release
>
> centos:
> Can we discontinue centos-6 now ?
>
> puppet 4:
> Some of our code is subject to bitrod because of puppet modules are
> advancing (specifically apt module)
>
> I propose to advance our platforms to install puppet4 or later by
> default.
>
> This places a problem at least for ubuntu-16.04 and debian8 on non
> x86 platforms (ie ppc64le, aarch64) , since these platforms are not
> supported by puppetlabs where we usually get puppet from.
>
> Therefore I propose to remove debian-8-aarch64 ,
> ubuntu-16.04-aarch64, ubuntu-16.04-ppc64le in bigtop trunk .
>
> Or is there a puppet4 suitable for ubuntu-16.04 somewhere ?
>
> ubuntu-17.* and debian-9 do contain puppet4 in distro.
> We may support ubuntu 17.10 for now and upgrading to LTS when it is
> relea
>
> Maybe it would be a good idea to only support aarch64 and ppc64le
>
> fast moving distros (fedora, ubuntu non LTS) for now in order to get
> upstream updates fast.
>
> maven-3.9
>
> gradle 4.2 (4.3?)
>
> Thoughts, opinions?
>
> Cheers,
> Olaf
Hello Olaf,
A good synopsis and I agree with most.
aarch64 and ppc64le should work for openSUSE 42.3. If not, I am happy
to look into issues.
What would be interesting to explore is openSUSE Tumbleweed, which is a
rolling distro with the newest versions of everything, but tested with
a ton of automated QA. E.g Java 9, GCC 7.x latest etc. This should
help us with upcoming versions of toolchains for all distros. Just a
thought....
Thanks!
Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAln+lk8ACgkQ73uV5/YBZtplPACgitk0vItmryydTdhowp7oIq+p
N+UAoLbU2CsDbcXEzlgVOL7kFOj8UBmO
=oR/i
-----END PGP SIGNATURE-----
Re: bigtop next : platform bitrot
Posted by Arnaud Launay <as...@launay.org>.
Le Fri, Nov 10, 2017 at 09:39:14PM -0500, Peter Linnell a écrit:
> 2. As puppetlabs only supports x86, using their upstream packages is
> less than ideal. Dropping support for non-x86 arches is very
> undesirable for many many reasons.
Yes, that was one thing I did not saw. I thought they would offer
more support than just the classic x86/amd64, so my idea is
not sustainable. Sorry !
Saltstack might be a good "answer", but I've no idea how much
work it might represent. Maybe it should be compared to the
burden of finding/compiling/whatever a recent puppet for the
unsupported arch ?
> 4. Can we move to a fully docker infra ?
As long as I can compile packages with:
./gradlew deb
without having to deploy the docker crap, I personally don't care :)
Arnaud.
Re: bigtop next : platform bitrot
Posted by Marcin Juszkiewicz <ma...@linaro.org>.
19.11.2017 23:05 "Olaf Flebbe" <of...@oflebbe.de> napisał(a):
Hi Marcin,
Thanks for you suggestion: implemeted this via BIGTOP-2934. Things are a
lot cleaner now. However, provisioner has to be adapted as well with
BIGTOP-2935
Can we get puppet changes later backported to 1.2 branch?
I am learning how bigtop build works to be able to build it on AArch64 and
then work out adding machines to CI.
Re: bigtop next : platform bitrot
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi Marcin,
Thanks for you suggestion: implemeted this via BIGTOP-2934. Things are a lot cleaner now. However, provisioner has to be adapted as well with BIGTOP-2935
Regards,
Olaf
> Am 19.11.2017 um 00:34 schrieb Olaf Flebbe <of...@oflebbe.de>:
>
> Hi
>
>> Am 17.11.2017 um 13:49 schrieb Marcin Juszkiewicz <ma...@linaro.org>:
>>
>> W dniu 11.11.2017 o 23:29, Olaf Flebbe pisze:
>>> I am withdrawing my proposal to upgrade puppet to version 4 on all
>>> platforms. The provisioner will be a different story, but there may
>>> be workarounds, too.
>>
>> Do we need Puppet 3.8 or is 3.6.2 good enough?
>>
>> EPEL has 3.6.2 version available for all architectures which would allow
>> us to keep centos-7 images for aarch64 and ppc64le.
>
> hm, had to doublecheck this.
>
> With some tweaks I was able to build images for centos-7 on amd64 and run a basic provisioner with puppet-3.6 if I was using the epel puppetlabs-stdlib package rather the puppetlabs stdlib download.
>
> Hopefully some of tweaks are related to broken functionality of docker edge on my macbook.
>
> I just realized there is no ppc64le version of centos7 in dockerhub so I cannot test on ppc64le.
>
> The docker installation on bigtop arm slave is corrupt (permission denied on docker socket) .
> So I cannot test that on arm as well.
>
> Downgrade puppet on centos to the epel version seems a viable solution.
>
> Best,
> Olaf
Re: bigtop next : platform bitrot
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi
> Am 17.11.2017 um 13:49 schrieb Marcin Juszkiewicz <ma...@linaro.org>:
>
> W dniu 11.11.2017 o 23:29, Olaf Flebbe pisze:
>> I am withdrawing my proposal to upgrade puppet to version 4 on all
>> platforms. The provisioner will be a different story, but there may
>> be workarounds, too.
>
> Do we need Puppet 3.8 or is 3.6.2 good enough?
>
> EPEL has 3.6.2 version available for all architectures which would allow
> us to keep centos-7 images for aarch64 and ppc64le.
hm, had to doublecheck this.
With some tweaks I was able to build images for centos-7 on amd64 and run a basic provisioner with puppet-3.6 if I was using the epel puppetlabs-stdlib package rather the puppetlabs stdlib download.
Hopefully some of tweaks are related to broken functionality of docker edge on my macbook.
I just realized there is no ppc64le version of centos7 in dockerhub so I cannot test on ppc64le.
The docker installation on bigtop arm slave is corrupt (permission denied on docker socket) .
So I cannot test that on arm as well.
Downgrade puppet on centos to the epel version seems a viable solution.
Best,
Olaf
Re: bigtop next : platform bitrot
Posted by Marcin Juszkiewicz <ma...@linaro.org>.
W dniu 11.11.2017 o 23:29, Olaf Flebbe pisze:
> I am withdrawing my proposal to upgrade puppet to version 4 on all
> platforms. The provisioner will be a different story, but there may
> be workarounds, too.
Do we need Puppet 3.8 or is 3.6.2 good enough?
EPEL has 3.6.2 version available for all architectures which would allow
us to keep centos-7 images for aarch64 and ppc64le.
Re: bigtop next : platform bitrot
Posted by Peter Linnell <pl...@apache.org>.
On Sat, 11 Nov 2017 23:29:53 +0100
Olaf Flebbe <of...@oflebbe.de> wrote:
> Hi,
> >
> > Well, this presents a difficult choice:
> >
> > 1. openSUSE/SLES 12 has dropped puppet as of 3.8.5 I do not know
> > the reason why this was dropped.
> >
> > I do know salt has been chosen for a lot of SUSE offerings, not just
> > SLES, but SUSE Manager, SUSE Storage. Going forward Salt is the go
> > to configuration engine for SUSE.
>
> Thanks for the input!
>
> >
> > 2. As puppetlabs only supports x86, using their upstream packages is
> > less than ideal. Dropping support for non-x86 arches is very
> > undesirable for many many reasons.
>
> I updated puppet container and tested bigtop_toolchain. I may have
> overestimated the problems with mixing puppet-4 and puppet-3 recipes.
> Seems like the problems i faced previously are mostly debian-8 and
> centos-6 related. Without these platforms, docker image creation runs
> surprisingly smooth.
>
> I am withdrawing my proposal to upgrade puppet to version 4 on all
> platforms. The provisioner will be a different story, but there may
> be workarounds, too.
>
> > 3. Switching to Salt, which is multi platform and with the openSUSE
> > build server, we could create a project much like I did for protobuf
> > and provide a single version of Salt for all supported distros. OBS
> > supports building on Arm, Power flavors and x86 - even mainframe for
> > all our supported distros.
>
> What I missed when I investigated puppet alternatives is that the
> Salt repositories aren't all-arch as well.
>
> So I quickly looked into building Salt on ubuntu 16.04 on ppc64le.
> With all the dependencies installed ( a lot) , it's a simple "pip
> install" command. Easy, but not what I wanted to achieve to have
> something ready-made.
>
> And yes, OBS might be handy to build and install Salt that way.
> packaging is clearly needed.
>
> Since bigtop_toolchain still works with mixed puppet version, I will
> not put much effort in this direction now.
>
> >
> > I have no idea how much work this would be, but I can say I do like
> > Salt and find it easy to grasp, coming from puppet and CF Engine.
> >
> > 4. Can we move to a fully docker infra ?
>
> Not 100% sure.
>
> Olaf
>
>
Well I am hoping in the coming few months to have more time for Bigtop
and, while I cannot commit, I do _want_ to spend some time
helping to getting our toolchain and distros updated. OBS is certainly
something I know well and perhaps we should create a bigtop repo, where
we can build all the packages needed.
The great thing about OBS is its support is unmatched for non-86
platforms. Arm5 to mainframes with pretty much every modern arch in
between. OBS supports all the distros we support. As an example, way
back when at CLoudera, I built a common version of puppet for all the
platforms supported then and it was not terribly difficult.
I'll just need some help on the Debian/Ubuntu side, as I am just not as
experienced with .deb
Cheers,
Peter
Re: bigtop next : platform bitrot
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi,
>
> Well, this presents a difficult choice:
>
> 1. openSUSE/SLES 12 has dropped puppet as of 3.8.5 I do not know the
> reason why this was dropped.
>
> I do know salt has been chosen for a lot of SUSE offerings, not just
> SLES, but SUSE Manager, SUSE Storage. Going forward Salt is the go to
> configuration engine for SUSE.
Thanks for the input!
>
> 2. As puppetlabs only supports x86, using their upstream packages is
> less than ideal. Dropping support for non-x86 arches is very
> undesirable for many many reasons.
I updated puppet container and tested bigtop_toolchain. I may have overestimated the problems with mixing puppet-4 and puppet-3 recipes. Seems like the problems i faced previously are mostly debian-8 and centos-6 related. Without these platforms, docker image creation runs surprisingly smooth.
I am withdrawing my proposal to upgrade puppet to version 4 on all platforms. The provisioner will be a different story, but there may be workarounds, too.
> 3. Switching to Salt, which is multi platform and with the openSUSE
> build server, we could create a project much like I did for protobuf
> and provide a single version of Salt for all supported distros. OBS
> supports building on Arm, Power flavors and x86 - even mainframe for
> all our supported distros.
What I missed when I investigated puppet alternatives is that the Salt repositories aren't all-arch as well.
So I quickly looked into building Salt on ubuntu 16.04 on ppc64le. With all the dependencies installed ( a lot) , it's a simple "pip install" command.
Easy, but not what I wanted to achieve to have something ready-made.
And yes, OBS might be handy to build and install Salt that way. packaging is clearly needed.
Since bigtop_toolchain still works with mixed puppet version, I will not put much effort in this direction now.
>
> I have no idea how much work this would be, but I can say I do like
> Salt and find it easy to grasp, coming from puppet and CF Engine.
>
> 4. Can we move to a fully docker infra ?
Not 100% sure.
Olaf
Re: bigtop next : platform bitrot
Posted by Peter Linnell <pl...@apache.org>.
On Thu, 9 Nov 2017 22:53:34 +0100
Arnaud Launay <as...@launay.org> wrote:
> Le Thu, Nov 09, 2017 at 09:48:30PM +0100, Olaf Flebbe a écrit:
> > c) please fill in your suggestion, if you are at least
> > pondering with the idea to help bigtop community going that
> > way.
> > -----------> So my next question to bigtop community
> > <-------------- Would you like to follow bigtop the a), b) or c)
> > way ? a) Somehow nailing/hammering/soldering puppet-3.8 and
> > puppet-4.x support into Bigtop.
>
> c via a -> use puppet repositories ? That way:
>
> PRO: you're pretty sure to have _the_ version you want to support
> PRO: available on every puppet supported platform
> PRO: you don't have to worry about the dependencies hell
>
> CONS: it's *huge* (about 110M last time I checked), and
> duplicates a lot of system packages... But at least it's
> contained in /opt/puppetlabs, it doesn't pollute much more (apart
> from /var/log and /etc/puppetlabs, and a profile.d file to add
> the PATH).
>
> > b) Reengineer part of the puppet recipies to saltstack,
> > potentially to replacing it altogether.
>
> Might be good too, but I suspect it would be much work than just
> homogenizing around one single version.
>
> Arnaud.
Well, this presents a difficult choice:
1. openSUSE/SLES 12 has dropped puppet as of 3.8.5 I do not know the
reason why this was dropped.
I do know salt has been chosen for a lot of SUSE offerings, not just
SLES, but SUSE Manager, SUSE Storage. Going forward Salt is the go to
configuration engine for SUSE.
2. As puppetlabs only supports x86, using their upstream packages is
less than ideal. Dropping support for non-x86 arches is very
undesirable for many many reasons.
3. Switching to Salt, which is multi platform and with the openSUSE
build server, we could create a project much like I did for protobuf
and provide a single version of Salt for all supported distros. OBS
supports building on Arm, Power flavors and x86 - even mainframe for
all our supported distros.
I have no idea how much work this would be, but I can say I do like
Salt and find it easy to grasp, coming from puppet and CF Engine.
4. Can we move to a fully docker infra ?
Cheers,
Peter
Re: bigtop next : platform bitrot
Posted by Jay Vyas <ja...@gmail.com>.
Still not ready to go 100% containers ?:)
> On Nov 9, 2017, at 5:43 PM, Olaf Flebbe <of...@oflebbe.de> wrote:
>
> Hi Arnauld,
>
>> c via a -> use puppet repositories ? That way:
>
>> PRO: you're pretty sure to have _the_ version you want to support
>> PRO: available on every puppet supported platform
>> PRO: you don't have to worry about the dependencies hell
>>
>> CONS: it's *huge* (about 110M last time I checked), and
>> duplicates a lot of system packages... But at least it's
>> contained in /opt/puppetlabs, it doesn't pollute much more (apart
>> from /var/log and /etc/puppetlabs, and a profile.d file to add
>> the PATH).
>
> CONS: Then we have to say goodbye to all non-x86 platforms. A no-go IMO.
>
> puppetlabs repos do not support non-x86 platforms. Or do I miss something ?
>
> Olaf
Re: bigtop next : platform bitrot
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi Arnauld,
> c via a -> use puppet repositories ? That way:
> PRO: you're pretty sure to have _the_ version you want to support
> PRO: available on every puppet supported platform
> PRO: you don't have to worry about the dependencies hell
>
> CONS: it's *huge* (about 110M last time I checked), and
> duplicates a lot of system packages... But at least it's
> contained in /opt/puppetlabs, it doesn't pollute much more (apart
> from /var/log and /etc/puppetlabs, and a profile.d file to add
> the PATH).
CONS: Then we have to say goodbye to all non-x86 platforms. A no-go IMO.
puppetlabs repos do not support non-x86 platforms. Or do I miss something ?
Olaf
Re: bigtop next : platform bitrot
Posted by Arnaud Launay <as...@launay.org>.
Le Thu, Nov 09, 2017 at 09:48:30PM +0100, Olaf Flebbe a écrit:
> c) please fill in your suggestion, if you are at least
> pondering with the idea to help bigtop community going that
> way.
> -----------> So my next question to bigtop community <--------------
> Would you like to follow bigtop the a), b) or c) way ?
> a) Somehow nailing/hammering/soldering puppet-3.8 and
> puppet-4.x support into Bigtop.
c via a -> use puppet repositories ? That way:
PRO: you're pretty sure to have _the_ version you want to support
PRO: available on every puppet supported platform
PRO: you don't have to worry about the dependencies hell
CONS: it's *huge* (about 110M last time I checked), and
duplicates a lot of system packages... But at least it's
contained in /opt/puppetlabs, it doesn't pollute much more (apart
from /var/log and /etc/puppetlabs, and a profile.d file to add
the PATH).
> b) Reengineer part of the puppet recipies to saltstack,
> potentially to replacing it altogether.
Might be good too, but I suspect it would be much work than just
homogenizing around one single version.
Arnaud.
Re: bigtop next : platform bitrot
Posted by Evans Ye <ev...@apache.org>.
Jay,
I see some Hadoop ecosystem projects already moving to K8S:
Flink:
https://ci.apache.org/projects/flink/flink-docs-release-1.3/setup/kubernetes.html
Spark: https://spark-summit.org/2017/speakers/tim-chen/
HDFS:
https://spark-summit.org/2017/events/hdfs-on-kubernetes-lessons-learned/
Can you provide your expertise to suggest what angle should we approaching
this?
I see building images with components packaged is one way to go. But that's
much more complicate than directly integrations mentioned above.
Best,
Evans Ye
2017-11-21 9:26 GMT+08:00 Evans Ye <ev...@apache.org>:
> Marchin,
>
> As RM for 1.2.1 I don't recommend that way since two branches has diverged.
> Back-porting can result in too much effort.
>
> If we have fairly enough changes(the OS refresh indeed is), we can
> directly release 1.3 based on master.
>
>
>
> 2017-11-21 3:35 GMT+08:00 Olaf Flebbe <of...@oflebbe.de>:
>
>> Hi,
>>
>> > Fedora 27 got released last week. Can we jump to it instead of 26?
>>
>>
>> Right now, even fedora26 seems to create a lot of open points. Will try
>> to solve them first, since these issues will surely pop up in 27 as well.
>>
>> I may try to add fedora-27 if I have to touch the CI config in near
>> future. I quickly am running now out of my spare time
>>
>> Olaf
>>
>
>
Re: bigtop next : platform bitrot
Posted by Evans Ye <ev...@apache.org>.
Marchin,
As RM for 1.2.1 I don't recommend that way since two branches has diverged.
Back-porting can result in too much effort.
If we have fairly enough changes(the OS refresh indeed is), we can directly
release 1.3 based on master.
2017-11-21 3:35 GMT+08:00 Olaf Flebbe <of...@oflebbe.de>:
> Hi,
>
> > Fedora 27 got released last week. Can we jump to it instead of 26?
>
>
> Right now, even fedora26 seems to create a lot of open points. Will try to
> solve them first, since these issues will surely pop up in 27 as well.
>
> I may try to add fedora-27 if I have to touch the CI config in near
> future. I quickly am running now out of my spare time
>
> Olaf
>
Re: bigtop next : platform bitrot
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi,
> Fedora 27 got released last week. Can we jump to it instead of 26?
Right now, even fedora26 seems to create a lot of open points. Will try to solve them first, since these issues will surely pop up in 27 as well.
I may try to add fedora-27 if I have to touch the CI config in near future. I quickly am running now out of my spare time
Olaf
Re: bigtop next : platform bitrot
Posted by Marcin Juszkiewicz <ma...@linaro.org>.
09.11.2017 21:48 "Olaf Flebbe" <of...@oflebbe.de> napisał(a):
Bigtoppers,
Thanks for the Input !
Let me summarize the feedback so far (please correct me if I got something
wrong!)
1) x86 Platforms seems to be more or less consent:
* replace debian-8 by debian-9
* replace opensuse 42.1 by opensuse 42.3 (x)
* replace fedora-25 by fedora-26
Fedora 27 got released last week. Can we jump to it instead of 26?
Re: bigtop next : platform bitrot
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi Jun,
> And one more thing is that I found docker hub has provided multi-arch
> support for its main distro images(Ubuntu/Fedora/Debian).
> We can use unified bigtop-* images for these distros despite the underlying
> hw arch.
Please file an JIRA with your suggestion. I like the idea !
Olaf
Re: bigtop next : platform bitrot
Posted by Jun HE <ry...@gmail.com>.
2017-11-10 4:48 GMT+08:00 Olaf Flebbe <of...@oflebbe.de>:
> (x) puppet4 from puppetlabs needed because of missing puppet4 support.
> (only x86 support from puppetlabs)
>
>
> 2) non-x86 Platforms
>
> * debian-9
> * fedora-26
> * ubuntu-16.04 would fall off (!)
>
> To summarize: two important platform (centos7 / ubuntu16) can not be
> supported because of the puppet4 requirement.
> Opensuse seems to have dropped puppet support completly.
Ubuntu-16.04 is current LTS and is a popular distro for arm64 users. I
would like to suggest to keep this distro in support list.
> OPTIONS:
>
> a) IMHO it would be possible to place (more or less ugly) workarounds
> into bigtop to enable puppet-3.8 recipies for ubuntu-16.04 .
>
> b) I did some initial investigation for replacing puppet, so we could have
> broader non-x86 support.
>
> We are using puppet for two things:
>
> First to automate installing development environment (docker images) and
> secondly for deploying.
>
> IMHO It would be easy to "only" replace bigtop_toolchain by something else
> in order to enable buildiing for more non-x86 platforms.
> So we do not have to touch the much more advanced depyloment recipies,
> consequently we cannot use puppet to deploy on platforms without puppet4.
>
> My suggestion: The orchestration/automation tool saltstack seems similar
> with respect to puppet, conceptwise.
>
> PROS:
> * It seems to be a lot faster
> * Similar concepts
> * It may be possible to use the same saltstack version on every platform,
> which would be a huge plus
> * much broader Linux Distribution support (see
> https://docs.saltstack.com/en/latest/topics/installation/index.html )
> * Standard install uses standard distribution components not overriding
> tools
> * Additionally it has some features to be used as an orchestation tool to
> bootstrap cloud, docker, kubernetes whatever environments potentially
> replacing the vagrant provisioner.
> * Its python (sorry couldn't resist: cos will place this under CONS)
>
> CONS:
> * It is a lot of work
> * And it is a lot more work if we chose to port deployment as well
>
> c) please fill in your suggestion, if you are at least pondering with the
> idea to help bigtop community going that way.
-----------> So my next question to bigtop community <--------------
>
> Would you like to follow bigtop the a), b) or c) way ?
>
> a) Somehow nailing/hammering/soldering puppet-3.8 and puppet-4.x support
> into Bigtop.
> b) Reengineer part of the puppet recipies to saltstack, potentially to
> replacing it altogether.
>
If non-x86 support will not show in puppet-4, I think switch to saltstack
would be a better choice. And I'll be glad to help on this.
> c) Anyone having a different super shiny concept ?
Best,
> Olaf
>
>
And one more thing is that I found docker hub has provided multi-arch
support for its main distro images(Ubuntu/Fedora/Debian).
We can use unified bigtop-* images for these distros despite the underlying
hw arch.
Re: bigtop next : platform bitrot
Posted by Olaf Flebbe <of...@oflebbe.de>.
Bigtoppers,
Thanks for the Input !
Let me summarize the feedback so far (please correct me if I got something wrong!)
1) x86 Platforms seems to be more or less consent:
* replace debian-8 by debian-9
* replace opensuse 42.1 by opensuse 42.3 (x)
* replace fedora-25 by fedora-26
* drop centos-6
* keep centos-7 (x)
* drop ubuntu-14.04
* keep ubuntu-16.04 (x)
(x) puppet4 from puppetlabs needed because of missing puppet4 support. (only x86 support from puppetlabs)
2) non-x86 Platforms
* debian-9
* fedora-26
* ubuntu-16.04 would fall off (!)
To summarize: two important platform (centos7 / ubuntu16) can not be supported because of the puppet4 requirement.
Opensuse seems to have dropped puppet support completly.
OPTIONS:
a) IMHO it would be possible to place (more or less ugly) workarounds into bigtop to enable puppet-3.8 recipies for ubuntu-16.04 .
b) I did some initial investigation for replacing puppet, so we could have broader non-x86 support.
We are using puppet for two things:
First to automate installing development environment (docker images) and secondly for deploying.
IMHO It would be easy to "only" replace bigtop_toolchain by something else in order to enable buildiing for more non-x86 platforms.
So we do not have to touch the much more advanced depyloment recipies, consequently we cannot use puppet to deploy on platforms without puppet4.
My suggestion: The orchestration/automation tool saltstack seems similar with respect to puppet, conceptwise.
PROS:
* It seems to be a lot faster
* Similar concepts
* It may be possible to use the same saltstack version on every platform, which would be a huge plus
* much broader Linux Distribution support (see https://docs.saltstack.com/en/latest/topics/installation/index.html )
* Standard install uses standard distribution components not overriding tools
* Additionally it has some features to be used as an orchestation tool to bootstrap cloud, docker, kubernetes whatever environments potentially replacing the vagrant provisioner.
* Its python (sorry couldn't resist: cos will place this under CONS)
CONS:
* It is a lot of work
* And it is a lot more work if we chose to port deployment as well
c) please fill in your suggestion, if you are at least pondering with the idea to help bigtop community going that way.
-----------> So my next question to bigtop community <--------------
Would you like to follow bigtop the a), b) or c) way ?
a) Somehow nailing/hammering/soldering puppet-3.8 and puppet-4.x support into Bigtop.
b) Reengineer part of the puppet recipies to saltstack, potentially to replacing it altogether.
c) Anyone having a different super shiny concept ?
Best,
Olaf
Re: bigtop next : platform bitrot
Posted by Marcin Juszkiewicz <ma...@linaro.org>.
W dniu 01.11.2017 o 22:46, Olaf Flebbe pisze:
To introduce: I work Red Hat and due to my assignment to Linaro I work
on aarch64 support in several distributions (mostly Debian).
> While doing some regression tests with bigtop-1.2.1 I clearly saw we
> have some distros now getting outdated giving us more and more
> headaches.
>
> IMHO, for current trunk, to be contained in next release we should
> chose:
>
> debian: I propose to replace debian-8 by debian-9 . debian-9 is the
> current stable now.
Fully agree.
> opensuse: Replace opensuse-42.1 by opensuse-42.3
Can not comment - never used.
> ubuntu: remove ubuntu-14.04 because this will be obsolete as old LTS
> by bigtop next release
Same as Debian - 16.04 is current LTS and despite showing it's age it is
still in use.
I would also suggest upgrading Fedora 25 to 26 at same time.
> puppet 4: Some of our code is subject to bitrod because of puppet
> modules are advancing (specifically apt module)
>
> I propose to advance our platforms to install puppet4 or later by
> default.
>
> This places a problem at least for ubuntu-16.04 and debian8 on non
> x86 platforms (ie ppc64le, aarch64) , since these platforms are not
> supported by puppetlabs where we usually get puppet from.
Debian 9, Fedora 26 have Puppet 4.x available. Looks like only Ubuntu
16.04 is an issue.
Basing on out-of-distro packages is easiest way to get rid of !x86
architectures. Seen that far too many times.
> Maybe it would be a good idea to only support aarch64 and ppc64le on
> fast moving distros (fedora, ubuntu non LTS) for now in order to get
> upstream updates fast.
CentOS 7, Debian 9 are supported on both those architectures.