Elasticsearch has been merged[1]. Thanks to Jun for adding puppet and Smoke Test within that PR.
[1] https://github.com/apache/bigtop/pull/566 Kengo Seki <[email protected]> 於 2019年12月13日 週五 09:30 寫道： > Jun and Evans, sorry for my late response. > > > So if that Jira (BIGTOP-3219) can be done in next week, do you think it > is > > OK to include Elasticsearch-5.6.14 in v1.5? > > Of course! I'm looking forward to it. > > Kengo Seki <[email protected]> > > On Fri, Dec 6, 2019 at 8:08 PM Evans Ye <[email protected]> wrote: > > > > I'm a +1 for this. I can help on the ci side so that adding one more > > package for release is easier. > > > > Jun HE <[email protected]> 於 2019年12月6日 週五 15:41 寫道： > > > > > Hi, Kengo, > > > > > > I just noticed you updated the BOM of Bigtop v1.5 on BIGTOP-3123. > > > > > > One thing I'd like to know your and other folks' thought on > Elasticsearch > > > as Bigtop component. > > > There is a ticket (https://issues.apache.org/jira/browse/BIGTOP-3219) > for > > > this. And I've finished most of the sub-works > > > (build/packaging/deployement). Patch could be found at: > > > https://github.com/apache/bigtop/pull/566 > > > For the smoke test part I think it could be done in this weekend. > > > > > > So if that Jira (BIGTOP-3219) can be done in next week, do you think > it is > > > OK to include Elasticsearch-5.6.14 in v1.5? > > > > > > Regards, > > > > > > Jun > > > > > > Kengo Seki <[email protected]> 于2019年11月22日周五 上午12:09写道： > > > > > > > Thanks for the comments, everyone! > > > > If there's still no objection in a few days, I'm going to update > > > > BIGTOP-3123's description. > > > > > > > > > 'contrib' module will be easier for us to maintain traditional > distros > > > > and cnb. > > > > > > > > Agreed. I think that merging the cnb branch later will be a hard work > > > too. > > > > > > > > > What do you think about the components? > > > > > Is there a list of components you'd like to upgrade? > > > > > > > > I'd like to upgrade the following components: > > > > > > > > - Zookeeper: 3.4.13 > > > > - Hadoop: 3.2.1 (or 2.10.0 if packaging Hadoop 3 is too hard, as Olaf > > > > mentioned before) > > > > - HBase: 2.2.2 > > > > - Hive: 3.1.2 > > > > - Tez: 0.9.2 > > > > - Spark: 2.4.4 (or 3.0.0, if GA is released before long) > > > > - Phoenix: 5.0.0 > > > > - Kafka: 2.3.1 > > > > - Ignite: 2.7.6 > > > > - Zeppelin: 0.8.2 > > > > > > > > My Teammates and I are trying to package them, and all of them > > > > are successfully built anyway. But we have not tested them yet, > > > > and I'm sure many problems will be found from now, just as Olaf > > > > already came across on Hadoop 3... :) > > > > > > > > > the community was lean to the direction of having important > component > > > > better supported > > > > > instead of spending resources for 20~30 components. > > > > > > > > Totally agreed. If we succeed to package Hadoop 3, > > > > I'd like to drop inactive components which can't be built with it, > > > > at least for now. > > > > > > > > > Just one concern about the puppet recipes compatibility across > multiple > > > > puppet versions > > > > > > > > Exactly. I think it's difficult to support Puppet 3, 4 and 5 with a > > > > single manifest or config file, > > > > so I'm thinking to create a new "puppet5" directory beside the > > > > existing "puppet" directory > > > > and put the manifests and config files for Puppet 5 into it (and when > > > > we drop the distros > > > > using Puppet 3 and 4 completely in the future, we can drop the > > > > existing "puppet" directory > > > > and promote "puppet5" to "puppet"). > > > > If it doesn't work as expected, I'll ask you the possibility to drop > > > > old versions in the next release again. > > > > > > > > > one source of problems was using puppet-forge for instance for > > > > puppet-stdlib and puppet-apt, > > > > > > > > Yeah, puppet modules seem to be installed into > /usr/share/puppet/modules > > > > via apt on Debian 9 and Ubuntu 16.04, while /etc/puppet/modules via > > > > `puppet module install` on CentOS 7, as you said. > > > > Maybe we have to consolidate them somehow, or specify both of them > > > > for `--modulepath` (I'm not sure if it works though), or choose > either of > > > > them > > > > in accordance with the distro. > > > > > > > > Kengo Seki <[email protected]> > > > > > > > > On Thu, Nov 21, 2019 at 3:17 PM Olaf Flebbe <[email protected]> wrote: > > > > > > > > > > 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 <[email protected]>: > > > > > > > > > > > > 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 <[email protected]> 于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 (김영우) <[email protected]> 於 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 <[email protected] > > > > > > 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 <[email protected]> > > > > > >>>> > > > > > >>> > > > > > >> > > > > > > > >
