Hi Evans, In my environment, using the latest official CentOS image instead of puppetlabs' one seems to work, as follows. So I don't think we have to drop the Vagrant provisioner in this release and would like to propose to simply update default values in vagrantconfig.yaml, but I'm not also strongly against dropping it if you think we should reduce maintenance cost on it in this opportunity. :)
``` ~/repos/bigtop/provisioner/vagrant$ git diff diff --git a/provisioner/vagrant/vagrantconfig.yaml b/provisioner/vagrant/vagrantconfig.yaml index a25690d2..bee87293 100644 --- a/provisioner/vagrant/vagrantconfig.yaml +++ b/provisioner/vagrant/vagrantconfig.yaml @@ -15,8 +15,8 @@ memory_size: 4096 number_cpus: 1 -box: "puppetlabs/centos-7.2-64-nocm" -repo: "http://repos.bigtop.apache.org/releases/1.3.0/centos/7/x86_64"; +box: "centos/7" +repo: "http://repos.bigtop.apache.org/releases/1.5.0/centos/7/x86_64"; num_instances: 1 distro: centos components: [hdfs, yarn, mapreduce] ~/repos/bigtop/provisioner/vagrant$ vagrant up (snip) ==> bigtop1: Notice: Roles to deploy: [resourcemanager, nodemanager, mapred-app, hadoop-client, mapred-app, namenode, datanode] (snip) ==> bigtop1: Notice: Finished catalog run in 364.53 seconds ==> bigtop1: Configuring cache buckets... ~/repos/bigtop/provisioner/vagrant$ vagrant ssh (snip) [vagrant@bigtop1 ~]$ sudo jps 3812 JobHistoryServer 4212 NameNode 5993 Jps 3978 NodeManager 3531 ResourceManager 3438 WebAppProxyServer 4447 DataNode [vagrant@bigtop1 ~]$ hadoop version Hadoop 2.10.1 Subversion https://gitbox.apache.org/repos/asf/bigtop.git -r 81ad7b000cec0503b9a1d5521fdaf0129443b536 Compiled by jenkins on 2020-11-28T10:07Z Compiled with protoc 2.5.0 >From source with checksum 12fc83747448c6d239c8a4e93b4fa294 This command was run using /usr/lib/hadoop/hadoop-common-2.10.1.jar [vagrant@bigtop1 ~]$ sudo -u yarn yarn jar /usr/lib/hadoop-mapreduce/hadoop-mapreduce-examples.jar pi 1 1 (snip) Job Finished in 29.655 seconds Estimated value of Pi is 4.00000000000000000000 ``` Kengo Seki <[email protected]> On Sun, Dec 13, 2020 at 12:40 AM Evans Ye <[email protected]> wrote: > > I think having that malfunction feature removed is better to make 1.5 > release quality stay untainted. If go for RC1 the effort is small since > all the build/repo/artifacts can stay AS-IS. Just the code need to be > modified. > However, you're right that it's for testing purpose so either way is ok. > > I don't think this worth to block the release though. I can still fire up a > JIRA for tracking. > > Luca Toscano <[email protected]> 於 2020年12月12日 週六 下午7:53寫道： > > > Hi Evans, > > > > I don't know exactly what it is the typical use case for the Vagrant > > provisioner, but I guess it should be mostly testing, so I think it > > should be fine for the purposes of the 1.5 release to leave it aside > > (and fix it later on). > > Do you have more details about the systemd failure? Maybe we could > > open a quick jira with details so people can chime in and check, to > > speed up the release :) > > > > Luca > > > > On Sat, Dec 12, 2020 at 10:55 AM Evans Ye <[email protected]> wrote: > > > > > > I'm still running tests but one thing need to discuss with folks first. > > > > > > The provisioner/vagrant component is failing in my test. > > > > > > ==> bigtop1: Error: Could not start Service[hadoop-yarn-proxyserver]: > > > Execution of '/bin/systemctl start hadoop-yarn-proxyserver' returned 1: > > Job > > > for hadoop-yarn-proxyserver.service failed. See "systemctl status > > > hadoop-yarn-proxyserver.service" and "journalctl -xe" for details. > > > > > > Seems it's due to the systemd changing. I searched on vagrant box but I > > see > > > NO NEW box for centos/ubuntu from puppetlabs. Also, our CI test does not > > > cover this component so it's likely to have bug down the road. Therefore, > > > I'm proposing to remove the component in 1.5 release. How do the folks > > > think? > > > > > > Evans > > > > > > > > > Kengo Seki <[email protected]> 於 2020年12月8日 週二 下午9:55寫道： > > > > > > > Luca and Evans, > > > > > > > > Thank you for testing the RC! Sure, I think we can wait for that until > > > > this weekend :) > > > > > > > > Kengo Seki <[email protected]> > > > > > > > > On Tue, Dec 8, 2020 at 6:24 PM Evans Ye <[email protected]> wrote: > > > > > > > > > > I'm really happy to see the release candidate is finally out. > > > > > With this timing the community will close this year with a strong > > result. > > > > > Thank you all for the efforts! > > > > > Let me find time this week to evaluate and vote. > > > > > > > > > > - Evans > > > > > > > > > > Luca Toscano <[email protected]> 於 2020年12月8日 週二 下午4:47寫道： > > > > > > > > > > > Hi! > > > > > > > > > > > > On Mon, Dec 7, 2020 at 12:47 AM Kengo Seki <[email protected]> > > wrote: > > > > > > > > > > > > > > This is the vote for release 1.5.0 of Apache Bigtop. > > > > > > > > > > > > > > It fixes the following issues: > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311420&version=12345178 > > > > > > > > > > > > > > The vote will be going for at least 72 hours and will be closed > > on > > > > > > Wednesday, > > > > > > > December 9th, 2020 at 5pm PST. Please download, test and vote > > with > > > > > > > > > > > > This is a great news, really glad to see 1.5.0 finally coming out! > > I > > > > > > might be able to try the debian-9 packages on a testing cluster > > with > > > > > > Bigtop 1.4 + Kerberos by the end of this week, but it would delay a > > > > > > bit the 72h. If this is ok, I'll keep this list posted with result > > (or > > > > > > if I don't manage to test properly). > > > > > > > > > > > > Luca > > > > > > > > > > > >
