hi one source of problems was using puppet-forge for instance for puppet-stdlib and puppet-apt, since they require rather new versions. look out for 'puppet module install ....'. While all distros using apt do have matching prepackaged versions in their repository.
other was different search paths of all these versions. we never fixed that consistently. olaf Von meinem iPad gesendet > Am 21.11.2019 um 03:43 schrieb Jun HE <ju...@apache.org>: > > I'm fine with the new distros list. Just one concern about the puppet > recipes compatibility across multiple puppet versions (3.8.5 for > Ubuntu-16.04, 4.8.2 for Debian-9, and 5.x for other new distros). I didn't > do any investigation yet. If such issues arise, I'll vote for drop distros > with older puppet. > > Evans Ye <evan...@apache.org> 于2019年11月21日周四 上午1:51写道： > >> Fine by me for the OS side. >> What do you think about the components? Is there a list of components you'd >> like to upgrade? >> We can target a subset of current supported matrix as we previously >> discussed about this and the community was lean to the direction of having >> important component better supported instead of spending resources for >> 20~30 components. >> >> Youngwoo Kim (김영우) <yw...@apache.org> 於 2019年11月20日 週三 上午9:41寫道： >> >>> Kengo, >>> >>> Looks good to me. I think puppet on CentOS 8 would be fine. >>> >>> On Cloud Native Bigtop, I believe we should consider that components as a >>> 'contrib' at this point. >>> I'm considering about Jay's idea, making 'CNB' on master as a contrib >>> module. A development branch is good but on our "two-tracks" development, >>> 'contrib' module will be easier for us to maintain traditional distros >> and >>> cnb. >>> >>> Thanks, >>> Youngwoo >>> >>>> On Wed, Nov 20, 2019 at 9:28 AM Kengo Seki <sek...@apache.org> wrote: >>> >>>> Hi folks, >>>> >>>> I'd like to discuss the target distros for the next 1.5.0 release [1], >>>> because over 1.5 years have passed since Ubuntu 18.04 was released >>>> and the next LTS will be released within half a year. In addition, >>>> Fedora 26 and openSUSE 42.3 have already been EOL'd. >>>> >>>> (I understand the "Cloud Native Bigtop" project is going on >>>> and am really looking forward to it, but my customers still requires >>>> the traditional software stack :) >>>> >>>> Based on the past discussion [2], here's my proposal: >>>> >>>> - Add Debian 10, Fedora 31 and Ubuntu 18.04 as the target distros >>>> and use the puppet package provided by each distro, so that >>>> we can support all CPU architectures (x86_64, aarch64, and ppc64le). >>>> Their puppet versions are 5.4.0 (ubuntu) and 5.5.10 (debian and >>> fedora). >>>> >>>> Keep Debian 9 and Ubuntu 16.04 since they are still in the support >>>> period. >>>> >>>> Drop Fedora 26 since it has reached to the EOL on 2018-05-29. >>>> >>>> - Add CentOS 8. Unfortunately, that version doesn't seem to >>>> provide the distro's puppet package, even including EPEL. >>>> Even though, I'd like to support it since that distro >>>> (and RHEL8) are widely used especially in enterprise systems. >>>> So, as the next best option, how about using Puppet 5.5 provided by >>>> Puppetlabs and only supporting the x86_64 architecture on this >> version? >>>> >>>> Keep CentOS 7 since it's still in the support period. >>>> >>>> - Drop openSUSE 42.3 since it has reached to the EOL on 2019-07-01 >>>> and don't add a new version of that distro, as discussed in [2]. >>>> >>>> To summarize the above, the supported distros and their versions >>>> in the 1.5.0 release are as follows: >>>> >>>> - CentOS 7, 8 (8 is only supported on x86_64) >>>> - Debian 9, 10 >>>> - Fedora 31 >>>> - Ubuntu 16.04, 18.04 >>>> >>>> Does this sound reasonable? I'd appreciate any comments or suggestions. >>>> >>>> (Honestly, I'd actually like to drop CentOS 7, Debian 9, and Ubuntu >>> 16.04, >>>> so that we can consolidate the Puppet version to 5.x. >>>> But it may be too aggressive for users.) >>>> >>>> [1]: https://issues.apache.org/jira/browse/BIGTOP-3123 >>>> [2]: >>>> >>> >> https://lists.apache.org/thread.html/26e14cf36e9cfd61e0de581ed83bf305565c2e65234f1ce3bfb97628@%3Cdev.bigtop.apache.org%3E >>>> >>>> Kengo Seki <sek...@apache.org> >>>> >>> >>
