You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by Roman Shaposhnik <ro...@shaposhnik.org> on 2017/03/30 01:51:15 UTC
[VOTE] Release Bigtop version 1.2.0
This is the vote for release 1.2.0 of Apache Bigtop.
It fixes the following issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311420&version=12334717
The vote will close on Tuesday, April 4th, 2017 at noon PDT.
Please download, test and vote with
[ ] +1, accept RC1 as the official 1.2.0 release of Apache Bigtop
[ ] +0, I don't care either way,
[ ] -1, do not accept RC1 as the official 1.2.0 release of Apache
Bigtop, because...
Source and binary files:
https://dist.apache.org/repos/dist/dev/bigtop/1.2.0-RC1
Maven staging repo:
https://repository.apache.org/content/repositories/orgapachebigtop-1010
The git tag to be voted upon is rel/1.2.0-RC1
The convenience binary artifacts are available for testing at the locations
indicated by repo file. The easiest way to test those is to use our docker
provisioner. E.g.
$ cd provisioner/docker
$ ./docker-hadoop.sh -C config_XXX.yaml -c 3
Bigtop's KEYS file containing PGP keys we use to sign the release:
https://dist.apache.org/repos/dist/release/bigtop/KEYS
Thanks,
Roman.
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Mar 29, 2017 at 6:51 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> This is the vote for release 1.2.0 of Apache Bigtop.
>
> It fixes the following issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311420&version=12334717
>
> The vote will close on Tuesday, April 4th, 2017 at noon PDT.
> Please download, test and vote with
>
> [ ] +1, accept RC1 as the official 1.2.0 release of Apache Bigtop
> [ ] +0, I don't care either way,
> [ ] -1, do not accept RC1 as the official 1.2.0 release of Apache
> Bigtop, because...
+1 (binding).
Thanks,
Roman.
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Bruno Mahé <bm...@apache.org>.
Hi Olaf,
Thanks for the tip!
I did not install the toolchain and was hoping I would not have to.
I will try again with the specific versions of the required libraries
and tools.
Thanks,
Bruno
On 04/02/2017 01:23 AM, Olaf Flebbe wrote:
> Hi Bruno,
>
> Did you install the toolchain first?
> https://cwiki.apache.org/confluence/display/BIGTOP/How+to+build+Bigtop-trunk
> The toolchain will install a suitable protoc compiler.
>
> However, I recommend to use the the existing docker images we provide.
>
> BTW: Does anybody has on the agenda to tag the _existing_ trunk-docker
> images to 1.2.0-something ?
> If not, I can volunteer.
>
> Olaf
>
>
>> Am 02.04.2017 um 08:43 schrieb Bruno Mah <bmahe@apache.org
>> <ma...@apache.org>>:
>>
>> Looks like Fedora 25 is not supported. I cannot build hadoop:
>>
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] BUILD FAILURE
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Total time: 03:06 min
>> [INFO] Finished at: 2017-04-01T23:19:59-07:00
>> [INFO] Final Memory: 81M/756M
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] Failed to execute goal
>> org.apache.hadoop:hadoop-maven-plugins:2.7.3:protoc (compile-protoc)
>> on project hadoop-common:
>> org.apache.maven.plugin.MojoExecutionException: protoc version is
>> 'libprotoc 2.6.1', expected version is '2.5.0' -> [Help 1]
>> [ERROR]
>>
>>
>> On 04/01/2017 11:13 PM, Bruno Mah wrote:
>>> The following command fails for me:
>>>
>>> ./gradlew rpm
>>>
>>>
>>> With the output:
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] BUILD FAILURE
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] Total time: 04:35 min
>>> [INFO] Finished at: 2017-04-01T23:10:16-07:00
>>> [INFO] Final Memory: 73M/806M
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [ERROR] Failed to execute goal on project ambari-metrics-storm-sink:
>>> Could not resolve dependencies for project
>>> org.apache.ambari:ambari-metrics-storm-sink:jar:2.5.0.0.0: Failure
>>> to find org.apache.storm:storm-core:jar:1.1.0-SNAPSHOT in
>>> http://repo.hortonworks.com/content/groups/public/ was cached in the
>>> local repository, resolution will not be reattempted until the
>>> update interval of apache-hadoop has elapsed or updates are forced
>>> -> [Help 1]
>>>
>>>
>>> Am I missing something?
>>> I am on Fedora 25.
>>>
>>> Note: It's kind of odd to have a SNAPSHOT dependency on a release
>>> though.
>>>
>>> On 03/29/2017 06:51 PM, Roman Shaposhnik wrote:
>>>> This is the vote for release 1.2.0 of Apache Bigtop.
>>>>
>>>> It fixes the following issues:
>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311420&version=12334717
>>>>
>>>> The vote will close on Tuesday, April 4th, 2017 at noon PDT.
>>>> Please download, test and vote with
>>>>
>>>> [ ] +1, accept RC1 as the official 1.2.0 release of Apache Bigtop
>>>> [ ] +0, I don't care either way,
>>>> [ ] -1, do not accept RC1 as the official 1.2.0 release of Apache
>>>> Bigtop, because...
>>>>
>>>> Source and binary files:
>>>> https://dist.apache.org/repos/dist/dev/bigtop/1.2.0-RC1
>>>>
>>>> Maven staging repo:
>>>> https://repository.apache.org/content/repositories/orgapachebigtop-1010
>>>>
>>>> The git tag to be voted upon is rel/1.2.0-RC1
>>>>
>>>> The convenience binary artifacts are available for testing at the
>>>> locations
>>>> indicated by repo file. The easiest way to test those is to use our
>>>> docker
>>>> provisioner. E.g.
>>>> $ cd provisioner/docker
>>>> $ ./docker-hadoop.sh -C config_XXX.yaml -c 3
>>>>
>>>> Bigtop's KEYS file containing PGP keys we use to sign the release:
>>>> https://dist.apache.org/repos/dist/release/bigtop/KEYS
>>>>
>>>> Thanks,
>>>> Roman.
>>>
>>
>
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi Bruno,
Did you install the toolchain first?
https://cwiki.apache.org/confluence/display/BIGTOP/How+to+build+Bigtop-trunk <https://cwiki.apache.org/confluence/display/BIGTOP/How+to+build+Bigtop-trunk>
The toolchain will install a suitable protoc compiler.
However, I recommend to use the the existing docker images we provide.
BTW: Does anybody has on the agenda to tag the _existing_ trunk-docker images to 1.2.0-something ?
If not, I can volunteer.
Olaf
> Am 02.04.2017 um 08:43 schrieb Bruno Mahé <bm...@apache.org>:
>
> Looks like Fedora 25 is not supported. I cannot build hadoop:
>
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 03:06 min
> [INFO] Finished at: 2017-04-01T23:19:59-07:00
> [INFO] Final Memory: 81M/756M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.hadoop:hadoop-maven-plugins:2.7.3:protoc (compile-protoc) on project hadoop-common: org.apache.maven.plugin.MojoExecutionException: protoc version is 'libprotoc 2.6.1', expected version is '2.5.0' -> [Help 1]
> [ERROR]
>
>
> On 04/01/2017 11:13 PM, Bruno Mahé wrote:
>> The following command fails for me:
>>
>> ./gradlew rpm
>>
>>
>> With the output:
>> [INFO] ------------------------------------------------------------------------
>> [INFO] BUILD FAILURE
>> [INFO] ------------------------------------------------------------------------
>> [INFO] Total time: 04:35 min
>> [INFO] Finished at: 2017-04-01T23:10:16-07:00
>> [INFO] Final Memory: 73M/806M
>> [INFO] ------------------------------------------------------------------------
>> [ERROR] Failed to execute goal on project ambari-metrics-storm-sink: Could not resolve dependencies for project org.apache.ambari:ambari-metrics-storm-sink:jar:2.5.0.0.0: Failure to find org.apache.storm:storm-core:jar:1.1.0-SNAPSHOT in http://repo.hortonworks.com/content/groups/public/ was cached in the local repository, resolution will not be reattempted until the update interval of apache-hadoop has elapsed or updates are forced -> [Help 1]
>>
>>
>> Am I missing something?
>> I am on Fedora 25.
>>
>> Note: It's kind of odd to have a SNAPSHOT dependency on a release though.
>>
>> On 03/29/2017 06:51 PM, Roman Shaposhnik wrote:
>>> This is the vote for release 1.2.0 of Apache Bigtop.
>>>
>>> It fixes the following issues:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311420&version=12334717
>>>
>>> The vote will close on Tuesday, April 4th, 2017 at noon PDT.
>>> Please download, test and vote with
>>>
>>> [ ] +1, accept RC1 as the official 1.2.0 release of Apache Bigtop
>>> [ ] +0, I don't care either way,
>>> [ ] -1, do not accept RC1 as the official 1.2.0 release of Apache
>>> Bigtop, because...
>>>
>>> Source and binary files:
>>> https://dist.apache.org/repos/dist/dev/bigtop/1.2.0-RC1
>>>
>>> Maven staging repo:
>>> https://repository.apache.org/content/repositories/orgapachebigtop-1010
>>>
>>> The git tag to be voted upon is rel/1.2.0-RC1
>>>
>>> The convenience binary artifacts are available for testing at the locations
>>> indicated by repo file. The easiest way to test those is to use our docker
>>> provisioner. E.g.
>>> $ cd provisioner/docker
>>> $ ./docker-hadoop.sh -C config_XXX.yaml -c 3
>>>
>>> Bigtop's KEYS file containing PGP keys we use to sign the release:
>>> https://dist.apache.org/repos/dist/release/bigtop/KEYS
>>>
>>> Thanks,
>>> Roman.
>>
>
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Bruno Mahé <bm...@apache.org>.
Looks like Fedora 25 is not supported. I cannot build hadoop:
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 03:06 min
[INFO] Finished at: 2017-04-01T23:19:59-07:00
[INFO] Final Memory: 81M/756M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.hadoop:hadoop-maven-plugins:2.7.3:protoc (compile-protoc) on
project hadoop-common: org.apache.maven.plugin.MojoExecutionException:
protoc version is 'libprotoc 2.6.1', expected version is '2.5.0' -> [Help 1]
[ERROR]
On 04/01/2017 11:13 PM, Bruno Mah� wrote:
> The following command fails for me:
>
> ./gradlew rpm
>
>
> With the output:
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 04:35 min
> [INFO] Finished at: 2017-04-01T23:10:16-07:00
> [INFO] Final Memory: 73M/806M
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project ambari-metrics-storm-sink:
> Could not resolve dependencies for project
> org.apache.ambari:ambari-metrics-storm-sink:jar:2.5.0.0.0: Failure to
> find org.apache.storm:storm-core:jar:1.1.0-SNAPSHOT in
> http://repo.hortonworks.com/content/groups/public/ was cached in the
> local repository, resolution will not be reattempted until the update
> interval of apache-hadoop has elapsed or updates are forced -> [Help 1]
>
>
> Am I missing something?
> I am on Fedora 25.
>
> Note: It's kind of odd to have a SNAPSHOT dependency on a release though.
>
> On 03/29/2017 06:51 PM, Roman Shaposhnik wrote:
>> This is the vote for release 1.2.0 of Apache Bigtop.
>>
>> It fixes the following issues:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311420&version=12334717
>>
>> The vote will close on Tuesday, April 4th, 2017 at noon PDT.
>> Please download, test and vote with
>>
>> [ ] +1, accept RC1 as the official 1.2.0 release of Apache Bigtop
>> [ ] +0, I don't care either way,
>> [ ] -1, do not accept RC1 as the official 1.2.0 release of Apache
>> Bigtop, because...
>>
>> Source and binary files:
>> https://dist.apache.org/repos/dist/dev/bigtop/1.2.0-RC1
>>
>> Maven staging repo:
>> https://repository.apache.org/content/repositories/orgapachebigtop-1010
>>
>> The git tag to be voted upon is rel/1.2.0-RC1
>>
>> The convenience binary artifacts are available for testing at the
>> locations
>> indicated by repo file. The easiest way to test those is to use our
>> docker
>> provisioner. E.g.
>> $ cd provisioner/docker
>> $ ./docker-hadoop.sh -C config_XXX.yaml -c 3
>>
>> Bigtop's KEYS file containing PGP keys we use to sign the release:
>> https://dist.apache.org/repos/dist/release/bigtop/KEYS
>>
>> Thanks,
>> Roman.
>
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Bruno Mahé <bm...@apache.org>.
The following command fails for me:
./gradlew rpm
With the output:
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 04:35 min
[INFO] Finished at: 2017-04-01T23:10:16-07:00
[INFO] Final Memory: 73M/806M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal on project ambari-metrics-storm-sink:
Could not resolve dependencies for project
org.apache.ambari:ambari-metrics-storm-sink:jar:2.5.0.0.0: Failure to
find org.apache.storm:storm-core:jar:1.1.0-SNAPSHOT in
http://repo.hortonworks.com/content/groups/public/ was cached in the
local repository, resolution will not be reattempted until the update
interval of apache-hadoop has elapsed or updates are forced -> [Help 1]
Am I missing something?
I am on Fedora 25.
Note: It's kind of odd to have a SNAPSHOT dependency on a release though.
On 03/29/2017 06:51 PM, Roman Shaposhnik wrote:
> This is the vote for release 1.2.0 of Apache Bigtop.
>
> It fixes the following issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311420&version=12334717
>
> The vote will close on Tuesday, April 4th, 2017 at noon PDT.
> Please download, test and vote with
>
> [ ] +1, accept RC1 as the official 1.2.0 release of Apache Bigtop
> [ ] +0, I don't care either way,
> [ ] -1, do not accept RC1 as the official 1.2.0 release of Apache
> Bigtop, because...
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/bigtop/1.2.0-RC1
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachebigtop-1010
>
> The git tag to be voted upon is rel/1.2.0-RC1
>
> The convenience binary artifacts are available for testing at the locations
> indicated by repo file. The easiest way to test those is to use our docker
> provisioner. E.g.
> $ cd provisioner/docker
> $ ./docker-hadoop.sh -C config_XXX.yaml -c 3
>
> Bigtop's KEYS file containing PGP keys we use to sign the release:
> https://dist.apache.org/repos/dist/release/bigtop/KEYS
>
> Thanks,
> Roman.
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Jun He <ju...@linaro.org>.
Hi, Olaf,
For BIGTOP-2716 <https://issues.apache.org/jira/browse/BIGTOP-2716> and
BIGTOP-2717 <https://issues.apache.org/jira/browse/BIGTOP-2717>, how about
leave comment/link in ReleaseNotes, and bump them to latest release version
in next 1.3.0 release?
Thus we can avoid to provide patches which will be probably removed in
future release, and "in general Bigtop doesn't patch upstreams". ;)
regards,
Jun
On 30 March 2017 at 13:54, Olaf Flebbe <of...@oflebbe.de> wrote:
> Hi Roman,
>
> Thanks for you efforts! CI looks really good now.
>
> What was the consensus for the BIGTOP-2716
> <https://issues.apache.org/jira/browse/BIGTOP-2716> ?
> We only support the current bigtop/slaves docker images, knowing it will
> break if regenerated? Fine for me.
>
> Greetings,
> Olaf
>
>
>
> Am 30.03.2017 um 03:51 schrieb Roman Shaposhnik <ro...@shaposhnik.org>:
>
> This is the vote for release 1.2.0 of Apache Bigtop.
>
> It fixes the following issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12311420&version=12334717
>
> The vote will close on Tuesday, April 4th, 2017 at noon PDT.
> Please download, test and vote with
>
> [ ] +1, accept RC1 as the official 1.2.0 release of Apache Bigtop
> [ ] +0, I don't care either way,
> [ ] -1, do not accept RC1 as the official 1.2.0 release of Apache
> Bigtop, because...
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/bigtop/1.2.0-RC1
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachebigtop-1010
>
> The git tag to be voted upon is rel/1.2.0-RC1
>
> The convenience binary artifacts are available for testing at the locations
> indicated by repo file. The easiest way to test those is to use our docker
> provisioner. E.g.
> $ cd provisioner/docker
> $ ./docker-hadoop.sh -C config_XXX.yaml -c 3
>
> Bigtop's KEYS file containing PGP keys we use to sign the release:
> https://dist.apache.org/repos/dist/release/bigtop/KEYS
>
> Thanks,
> Roman.
>
>
>
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Olaf Flebbe <of...@oflebbe.de>.
Oh <censored>/&$"/!§%/&!</censored>. Sorry.
Thanx,
Olaf
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Mar 31, 2017 at 10:55 AM, Evans Ye <ev...@apache.org> wrote:
> -1
Evans, could you please substantiate your -1?
> Good news:
> Binary convenient packages looks good except ppc64le
> https://ci.bigtop.apache.org/view/Releases/job/Bigtop-1.2.0/
>
> Bad news:
> Ambari 2.5 can't build on ppc64le
> https://ci.bigtop.apache.org/view/Releases/job/Bigtop-1.2.0/OS=ubuntu-16.04-ppc64le/3/console
> https://ci.bigtop.apache.org/view/Releases/job/Bigtop-1.2.0/OS=fedora-25-ppc64le/3/console
>
> Both error message looks to have something to do with
> ambari/ambari-2.5.0/ambari-web/node/with_new_path.sh
> I don't have expertise in Ambari.
> Someone has expertise can grab a hand?
As we agreed before -- for Bigtop 1.2.0 we only require native packages to build
on non-x86 architectures. The rest will be take from appropriate x86 builds.
This is how I constructed the binary convenience artifacts that are
out for the vote.
Thanks,
Roman.
Re: [VOTE] Release Bigtop version 1.2.0
Posted by "MrAsanjar ." <af...@gmail.com>.
+1
Even, as Roman suggested, I believe x86 version of Ambari should function
the same on ppc64le, but I have not tested this scenario yet.
It important to note, x86 built Zeppelin and Tez passed the test.
On Sat, Apr 1, 2017 at 12:39 AM, Konstantin Boudnik <co...@apache.org> wrote:
> One way of doing this is to make Weather Report of our standard CI
> process. Anyway...
>
> +1 on the release
> --
> Take care,
> Konstantin (Cos) Boudnik
> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
>
> Disclaimer: Opinions expressed in this email are those of the author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.
>
>
> On Fri, Mar 31, 2017 at 10:11 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> > On Fri, Mar 31, 2017 at 8:49 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
> >> I have deployed a trivial cluster and ran some MapReduce example and
> >> everything worked!
> >>
> >> The bad news: I found some bugs in the Ignite's deployment (or rather
> >> the discrepancies in 1.9's expectations for the configuration files).
> >> It isn't perhaps a blocker, but I would like to spend a bit of time
> >> (hopefully over the weekend) to fix it.
> >>
> >> I would be ok if we don't consider this as a blocker though.
> >
> > I'd advocate for the same here. In fact, I'd say -- lets focus on
> > core functionality working in 1.2 and once it is out focus on CI
> > to make sure things like Puppet stay functional.
> >
> > Thanks,
> > Roman.
>
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Evans Ye <ev...@apache.org>.
Thanks for pointing out. I can do a manual retag and push.
Olaf Flebbe <of...@oflebbe.de>於 2017年4月6日 週四，下午12:25寫道：
> please do not regenerate the images!
>
> it will trigger the 1.8.0_121 bug related to javascript in javadocs. retag
> it.
>
>
>
> had no time to do it in time.
>
>
>
> > Am 04.04.2017 um 21:03 schrieb Evans Ye <ev...@apache.org>:
>
> >
>
> > +1.
>
> >
>
> > Signatures looks good.
>
> > Tested docker and vagrant provisioners.
>
> > Though discovered many deployment(puppet) issues, we can fix it later.
>
> >
>
> > Echo Olaf's suggestion, we should push 1.2 toolchain images.
>
> > I can help to do that using our Jenkins:
>
> >
>
> > https://ci.bigtop.apache.org/view/Docker/job/Docker-Toolchain-1.2.0/
>
> >
>
> >
>
> >
>
> > 2017-04-04 8:41 GMT+08:00 Roman Shaposhnik <ro...@shaposhnik.org>:
>
> >
>
> >> Hi Ed!
>
> >>
>
> >>> On Mon, Apr 3, 2017 at 1:09 PM, Ed Espino <es...@apache.org> wrote:
>
> >>> I'm on the Apache HAWQ Incubator project. Our initial binary release
> will
>
> >>> be validated against TLP Apache Bigtop. Coincidentally, our release
> paths
>
> >>> are crossing as both projects are currently in the early stages of
> their
>
> >>> respective voting processes. I have a few of very preliminary
>
> >>> "Observations" to share as I am getting acquainted with Bigtop. I'm
> also
>
> >>> fairly new to the Apache release processes and my comments might be
>
> >>> slightly off point (so please bear with me).
>
> >>
>
> >> First of all -- welcome to the Bigtop community and thanks for taking
> time
>
> >> to share your feedback. See my comments inline below:
>
> >>
>
> >>> LICENSE: I noticed the LICENSE file only contains the ASF v2.0
>
> >>> license. Is there a need to mention the licenses of the
>
> >>> tools recommended for rapid provisioning (example; Vagrant,
>
> >>> Docker, Puppet) or other non-ASF projects?
>
> >>
>
> >> Strictly speaking: no. Sine these tools are not being touched in any way
>
> >> by the Bigtop codebase. This is similar to how we don't mention the
>
> >> license of make when we ship makefiles.
>
> >>
>
> >>> NOTICE: Copyright year needs to be updated (currently 2014)
>
> >>>
>
> >>> Should it change to a range (2014-2017)?
>
> >>
>
> >> Great catch! I filed https://issues.apache.org/jira/browse/BIGTOP-2731
>
> >>
>
> >>> OBSERVATION: The format of the hashes is not super convenient for an
>
> >>> automatic comparison. Being compatible with command
>
> >>> line tools would be helpful.
>
> >>
>
> >> Good point, but our checksums are generated automatically by doing
>
> >> a Maven release to the ASF Maven repo. That determines the format.
>
> >> Once we complete our transition to Gradle in 1.3.0 -- I'll try to see if
>
> >> we can make the format more friendly.
>
> >>
>
> >>> ======================================================================
>
> >>> GIT TAG
>
> >>> ======================================================================
>
> >>>
>
> >>> Git tag matches src (except .git*)
>
> >>> commit: 5a2a1a86b17f73260229137b0b008385fd32bfae
>
> >>>
>
> >>> OBSERVATION: I noticed the commit hash was not provided. I've seen
>
> >>> several podling votes with them. Should the hash also
>
> >>> been provided along with the corresponding tag?
>
> >>
>
> >> Given that tags under rel/ are supposed to be immutable I don't see a
>
> >> strong
>
> >> reason for why hash would be required. This wasn't the case a year or so
>
> >> ago and that's probably why you see hashes still being given.
>
> >>
>
> >>> ======================================================================
>
> >>> Apache RAT
>
> >>> ======================================================================
>
> >>>
>
> >>> The "gradlew rat" execution passed.
>
> >>>
>
> >>> OBSERVATIONS:
>
> >>>
>
> >>> * Initially I ran using maven and have come to know I should use
>
> >>> gradle. For grins, I generated a RAT Report summary using maven
>
> >>> which intentionally did not have any exclusions identified.
>
> >>>
>
> >>> Here is the "mvn apache-rat:check" summary which generated
>
> >>> a few followup observations (below):
>
> >>>
>
> >>> *****************************************************
>
> >>> Summary
>
> >>> -------
>
> >>> Generated at: 2017-04-03T11:59:14-07:00
>
> >>>
>
> >>> Notes: 97
>
> >>> Binaries: 9
>
> >>> Archives: 3
>
> >>> Standards: 1994
>
> >>>
>
> >>> Apache Licensed: 1353
>
> >>> Generated Documents: 0
>
> >>>
>
> >>> JavaDocs are generated, thus a license header is optional.
>
> >>> Generated files do not require license headers.
>
> >>>
>
> >>> 641 Unknown Licenses
>
> >>>
>
> >>> *****************************************************
>
> >>>
>
> >>> * Should the yaml files included in the release have ASF headers? It
>
> >>> is possible the parsers have troubles with comment ASF headers. But
>
> >>> then again, maybe the current parsers can handle them.
>
> >>
>
> >> Another great find. I believe originally we had problems with Puppet and
>
> >> Juju
>
> >> YAML parser somehow choking on comments. I'm pretty sure that is no
> longer
>
> >> the case -- but we need to make sure. I filed
>
> >> https://issues.apache.org/jira/browse/BIGTOP-2732
>
> >> to address this.
>
> >>
>
> >>> * There are three archives. Are these acceptable?
>
> >>>
>
> >>> +
>
> >>> bigtop-packages/src/charm/giraph/layer-giraph/resources/
>
> >> giraph-examples-1.1.0.jar
>
> >>> + bigtop-tests/test-artifacts/hadoop/src/main/resources/cachedir.jar
>
> >>> +
>
> >>>
> bigtop-tests/test-artifacts/hadoop/src/main/resources/test_data/test.zip
>
> >>
>
> >> I don't think these represent a problem, but you're right it would be
>
> >> much nicer not
>
> >> to have them on the exclusion list. We'll try to look into that as
>
> >> part of BIGTOP-2732.
>
> >> I think the ones in test are OK either way -- but the one in charms
>
> >> can be fixed.
>
> >>
>
> >> Thanks,
>
> >> Roman.
>
> >>
>
>
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Olaf Flebbe <of...@oflebbe.de>.
please do not regenerate the images!
it will trigger the 1.8.0_121 bug related to javascript in javadocs. retag it.
had no time to do it in time.
> Am 04.04.2017 um 21:03 schrieb Evans Ye <ev...@apache.org>:
>
> +1.
>
> Signatures looks good.
> Tested docker and vagrant provisioners.
> Though discovered many deployment(puppet) issues, we can fix it later.
>
> Echo Olaf's suggestion, we should push 1.2 toolchain images.
> I can help to do that using our Jenkins:
>
> https://ci.bigtop.apache.org/view/Docker/job/Docker-Toolchain-1.2.0/
>
>
>
> 2017-04-04 8:41 GMT+08:00 Roman Shaposhnik <ro...@shaposhnik.org>:
>
>> Hi Ed!
>>
>>> On Mon, Apr 3, 2017 at 1:09 PM, Ed Espino <es...@apache.org> wrote:
>>> I'm on the Apache HAWQ Incubator project. Our initial binary release will
>>> be validated against TLP Apache Bigtop. Coincidentally, our release paths
>>> are crossing as both projects are currently in the early stages of their
>>> respective voting processes. I have a few of very preliminary
>>> "Observations" to share as I am getting acquainted with Bigtop. I'm also
>>> fairly new to the Apache release processes and my comments might be
>>> slightly off point (so please bear with me).
>>
>> First of all -- welcome to the Bigtop community and thanks for taking time
>> to share your feedback. See my comments inline below:
>>
>>> LICENSE: I noticed the LICENSE file only contains the ASF v2.0
>>> license. Is there a need to mention the licenses of the
>>> tools recommended for rapid provisioning (example; Vagrant,
>>> Docker, Puppet) or other non-ASF projects?
>>
>> Strictly speaking: no. Sine these tools are not being touched in any way
>> by the Bigtop codebase. This is similar to how we don't mention the
>> license of make when we ship makefiles.
>>
>>> NOTICE: Copyright year needs to be updated (currently 2014)
>>>
>>> Should it change to a range (2014-2017)?
>>
>> Great catch! I filed https://issues.apache.org/jira/browse/BIGTOP-2731
>>
>>> OBSERVATION: The format of the hashes is not super convenient for an
>>> automatic comparison. Being compatible with command
>>> line tools would be helpful.
>>
>> Good point, but our checksums are generated automatically by doing
>> a Maven release to the ASF Maven repo. That determines the format.
>> Once we complete our transition to Gradle in 1.3.0 -- I'll try to see if
>> we can make the format more friendly.
>>
>>> ======================================================================
>>> GIT TAG
>>> ======================================================================
>>>
>>> Git tag matches src (except .git*)
>>> commit: 5a2a1a86b17f73260229137b0b008385fd32bfae
>>>
>>> OBSERVATION: I noticed the commit hash was not provided. I've seen
>>> several podling votes with them. Should the hash also
>>> been provided along with the corresponding tag?
>>
>> Given that tags under rel/ are supposed to be immutable I don't see a
>> strong
>> reason for why hash would be required. This wasn't the case a year or so
>> ago and that's probably why you see hashes still being given.
>>
>>> ======================================================================
>>> Apache RAT
>>> ======================================================================
>>>
>>> The "gradlew rat" execution passed.
>>>
>>> OBSERVATIONS:
>>>
>>> * Initially I ran using maven and have come to know I should use
>>> gradle. For grins, I generated a RAT Report summary using maven
>>> which intentionally did not have any exclusions identified.
>>>
>>> Here is the "mvn apache-rat:check" summary which generated
>>> a few followup observations (below):
>>>
>>> *****************************************************
>>> Summary
>>> -------
>>> Generated at: 2017-04-03T11:59:14-07:00
>>>
>>> Notes: 97
>>> Binaries: 9
>>> Archives: 3
>>> Standards: 1994
>>>
>>> Apache Licensed: 1353
>>> Generated Documents: 0
>>>
>>> JavaDocs are generated, thus a license header is optional.
>>> Generated files do not require license headers.
>>>
>>> 641 Unknown Licenses
>>>
>>> *****************************************************
>>>
>>> * Should the yaml files included in the release have ASF headers? It
>>> is possible the parsers have troubles with comment ASF headers. But
>>> then again, maybe the current parsers can handle them.
>>
>> Another great find. I believe originally we had problems with Puppet and
>> Juju
>> YAML parser somehow choking on comments. I'm pretty sure that is no longer
>> the case -- but we need to make sure. I filed
>> https://issues.apache.org/jira/browse/BIGTOP-2732
>> to address this.
>>
>>> * There are three archives. Are these acceptable?
>>>
>>> +
>>> bigtop-packages/src/charm/giraph/layer-giraph/resources/
>> giraph-examples-1.1.0.jar
>>> + bigtop-tests/test-artifacts/hadoop/src/main/resources/cachedir.jar
>>> +
>>> bigtop-tests/test-artifacts/hadoop/src/main/resources/test_data/test.zip
>>
>> I don't think these represent a problem, but you're right it would be
>> much nicer not
>> to have them on the exclusion list. We'll try to look into that as
>> part of BIGTOP-2732.
>> I think the ones in test are OK either way -- but the one in charms
>> can be fixed.
>>
>> Thanks,
>> Roman.
>>
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Evans Ye <ev...@apache.org>.
+1.
Signatures looks good.
Tested docker and vagrant provisioners.
Though discovered many deployment(puppet) issues, we can fix it later.
Echo Olaf's suggestion, we should push 1.2 toolchain images.
I can help to do that using our Jenkins:
https://ci.bigtop.apache.org/view/Docker/job/Docker-Toolchain-1.2.0/
2017-04-04 8:41 GMT+08:00 Roman Shaposhnik <ro...@shaposhnik.org>:
> Hi Ed!
>
> On Mon, Apr 3, 2017 at 1:09 PM, Ed Espino <es...@apache.org> wrote:
> > I'm on the Apache HAWQ Incubator project. Our initial binary release will
> > be validated against TLP Apache Bigtop. Coincidentally, our release paths
> > are crossing as both projects are currently in the early stages of their
> > respective voting processes. I have a few of very preliminary
> > "Observations" to share as I am getting acquainted with Bigtop. I'm also
> > fairly new to the Apache release processes and my comments might be
> > slightly off point (so please bear with me).
>
> First of all -- welcome to the Bigtop community and thanks for taking time
> to share your feedback. See my comments inline below:
>
> > LICENSE: I noticed the LICENSE file only contains the ASF v2.0
> > license. Is there a need to mention the licenses of the
> > tools recommended for rapid provisioning (example; Vagrant,
> > Docker, Puppet) or other non-ASF projects?
>
> Strictly speaking: no. Sine these tools are not being touched in any way
> by the Bigtop codebase. This is similar to how we don't mention the
> license of make when we ship makefiles.
>
> > NOTICE: Copyright year needs to be updated (currently 2014)
> >
> > Should it change to a range (2014-2017)?
>
> Great catch! I filed https://issues.apache.org/jira/browse/BIGTOP-2731
>
> > OBSERVATION: The format of the hashes is not super convenient for an
> > automatic comparison. Being compatible with command
> > line tools would be helpful.
>
> Good point, but our checksums are generated automatically by doing
> a Maven release to the ASF Maven repo. That determines the format.
> Once we complete our transition to Gradle in 1.3.0 -- I'll try to see if
> we can make the format more friendly.
>
> > ======================================================================
> > GIT TAG
> > ======================================================================
> >
> > Git tag matches src (except .git*)
> > commit: 5a2a1a86b17f73260229137b0b008385fd32bfae
> >
> > OBSERVATION: I noticed the commit hash was not provided. I've seen
> > several podling votes with them. Should the hash also
> > been provided along with the corresponding tag?
>
> Given that tags under rel/ are supposed to be immutable I don't see a
> strong
> reason for why hash would be required. This wasn't the case a year or so
> ago and that's probably why you see hashes still being given.
>
> > ======================================================================
> > Apache RAT
> > ======================================================================
> >
> > The "gradlew rat" execution passed.
> >
> > OBSERVATIONS:
> >
> > * Initially I ran using maven and have come to know I should use
> > gradle. For grins, I generated a RAT Report summary using maven
> > which intentionally did not have any exclusions identified.
> >
> > Here is the "mvn apache-rat:check" summary which generated
> > a few followup observations (below):
> >
> > *****************************************************
> > Summary
> > -------
> > Generated at: 2017-04-03T11:59:14-07:00
> >
> > Notes: 97
> > Binaries: 9
> > Archives: 3
> > Standards: 1994
> >
> > Apache Licensed: 1353
> > Generated Documents: 0
> >
> > JavaDocs are generated, thus a license header is optional.
> > Generated files do not require license headers.
> >
> > 641 Unknown Licenses
> >
> > *****************************************************
> >
> > * Should the yaml files included in the release have ASF headers? It
> > is possible the parsers have troubles with comment ASF headers. But
> > then again, maybe the current parsers can handle them.
>
> Another great find. I believe originally we had problems with Puppet and
> Juju
> YAML parser somehow choking on comments. I'm pretty sure that is no longer
> the case -- but we need to make sure. I filed
> https://issues.apache.org/jira/browse/BIGTOP-2732
> to address this.
>
> > * There are three archives. Are these acceptable?
> >
> > +
> > bigtop-packages/src/charm/giraph/layer-giraph/resources/
> giraph-examples-1.1.0.jar
> > + bigtop-tests/test-artifacts/hadoop/src/main/resources/cachedir.jar
> > +
> > bigtop-tests/test-artifacts/hadoop/src/main/resources/test_data/test.zip
>
> I don't think these represent a problem, but you're right it would be
> much nicer not
> to have them on the exclusion list. We'll try to look into that as
> part of BIGTOP-2732.
> I think the ones in test are OK either way -- but the one in charms
> can be fixed.
>
> Thanks,
> Roman.
>
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
Hi Ed!
On Mon, Apr 3, 2017 at 1:09 PM, Ed Espino <es...@apache.org> wrote:
> I'm on the Apache HAWQ Incubator project. Our initial binary release will
> be validated against TLP Apache Bigtop. Coincidentally, our release paths
> are crossing as both projects are currently in the early stages of their
> respective voting processes. I have a few of very preliminary
> "Observations" to share as I am getting acquainted with Bigtop. I'm also
> fairly new to the Apache release processes and my comments might be
> slightly off point (so please bear with me).
First of all -- welcome to the Bigtop community and thanks for taking time
to share your feedback. See my comments inline below:
> LICENSE: I noticed the LICENSE file only contains the ASF v2.0
> license. Is there a need to mention the licenses of the
> tools recommended for rapid provisioning (example; Vagrant,
> Docker, Puppet) or other non-ASF projects?
Strictly speaking: no. Sine these tools are not being touched in any way
by the Bigtop codebase. This is similar to how we don't mention the
license of make when we ship makefiles.
> NOTICE: Copyright year needs to be updated (currently 2014)
>
> Should it change to a range (2014-2017)?
Great catch! I filed https://issues.apache.org/jira/browse/BIGTOP-2731
> OBSERVATION: The format of the hashes is not super convenient for an
> automatic comparison. Being compatible with command
> line tools would be helpful.
Good point, but our checksums are generated automatically by doing
a Maven release to the ASF Maven repo. That determines the format.
Once we complete our transition to Gradle in 1.3.0 -- I'll try to see if
we can make the format more friendly.
> ======================================================================
> GIT TAG
> ======================================================================
>
> Git tag matches src (except .git*)
> commit: 5a2a1a86b17f73260229137b0b008385fd32bfae
>
> OBSERVATION: I noticed the commit hash was not provided. I've seen
> several podling votes with them. Should the hash also
> been provided along with the corresponding tag?
Given that tags under rel/ are supposed to be immutable I don't see a strong
reason for why hash would be required. This wasn't the case a year or so
ago and that's probably why you see hashes still being given.
> ======================================================================
> Apache RAT
> ======================================================================
>
> The "gradlew rat" execution passed.
>
> OBSERVATIONS:
>
> * Initially I ran using maven and have come to know I should use
> gradle. For grins, I generated a RAT Report summary using maven
> which intentionally did not have any exclusions identified.
>
> Here is the "mvn apache-rat:check" summary which generated
> a few followup observations (below):
>
> *****************************************************
> Summary
> -------
> Generated at: 2017-04-03T11:59:14-07:00
>
> Notes: 97
> Binaries: 9
> Archives: 3
> Standards: 1994
>
> Apache Licensed: 1353
> Generated Documents: 0
>
> JavaDocs are generated, thus a license header is optional.
> Generated files do not require license headers.
>
> 641 Unknown Licenses
>
> *****************************************************
>
> * Should the yaml files included in the release have ASF headers? It
> is possible the parsers have troubles with comment ASF headers. But
> then again, maybe the current parsers can handle them.
Another great find. I believe originally we had problems with Puppet and Juju
YAML parser somehow choking on comments. I'm pretty sure that is no longer
the case -- but we need to make sure. I filed
https://issues.apache.org/jira/browse/BIGTOP-2732
to address this.
> * There are three archives. Are these acceptable?
>
> +
> bigtop-packages/src/charm/giraph/layer-giraph/resources/giraph-examples-1.1.0.jar
> + bigtop-tests/test-artifacts/hadoop/src/main/resources/cachedir.jar
> +
> bigtop-tests/test-artifacts/hadoop/src/main/resources/test_data/test.zip
I don't think these represent a problem, but you're right it would be
much nicer not
to have them on the exclusion list. We'll try to look into that as
part of BIGTOP-2732.
I think the ones in test are OK either way -- but the one in charms
can be fixed.
Thanks,
Roman.
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Ed Espino <es...@apache.org>.
I'm on the Apache HAWQ Incubator project. Our initial binary release will
be validated against TLP Apache Bigtop. Coincidentally, our release paths
are crossing as both projects are currently in the early stages of their
respective voting processes. I have a few of very preliminary
"Observations" to share as I am getting acquainted with Bigtop. I'm also
fairly new to the Apache release processes and my comments might be
slightly off point (so please bear with me).
Regards,
-=e
## ======================================================================
## Apache Bigtop
## 1.2.0-RC1
## ======================================================================
file(s):
bigtop-1.2.0-project.tar.gz
bigtop-1.2.0-project.tar.gz.asc
bigtop-1.2.0-project.tar.gz.asc.md5
bigtop-1.2.0-project.tar.gz.asc.sha1
bigtop-1.2.0-project.tar.gz.md5
bigtop-1.2.0-project.tar.gz.sha1
======================================================================
Spot checked LICENSE/NOTICE files
======================================================================
LICENSE: I noticed the LICENSE file only contains the ASF v2.0
license. Is there a need to mention the licenses of the
tools recommended for rapid provisioning (example; Vagrant,
Docker, Puppet) or other non-ASF projects?
NOTICE: Copyright year needs to be updated (currently 2014)
Should it change to a range (2014-2017)?
======================================================================
PGP Signature
======================================================================
Signature is good:
Verification:
gpg2 --verify bigtop-1.2.0-project.tar.gz.asc
gpg: assuming signed data in 'bigtop-1.2.0-project.tar.gz'
gpg: Signature made Wed Mar 29 18:37:48 2017 PDT
gpg: using DSA key 13971DA39475BD5D
gpg: Good signature from "Roman V Shaposhnik (CODE SIGNING KEY) <
rvs@apache.org>" [unknown]
gpg: aka "Roman V Shaposhnik <rv...@apache.org>" [unknown]
gpg: aka "Roman V Shaposhnik <ro...@shaposhnik.org>"
[unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
======================================================================
Checksums
======================================================================
md5 and sha1 are good (for both bigtop-1.2.0-project.tar.gz and
bigtop-1.2.0-project.tar.gz.asc)
Verification:
10:21 $ gsha1sum bigtop-1.2.0-project.tar.gz
f01813b17816f031d4e9dab7cc8871d6231cc610 bigtop-1.2.0-project.tar.gz
10:21 $ cat bigtop-1.2.0-project.tar.gz.sha1
f01813b17816f031d4e9dab7cc8871d6231cc610
10:21 $ gmd5sum bigtop-1.2.0-project.tar.gz
cfbf3f9efb0aef1b1f91f5bf588e8d46 bigtop-1.2.0-project.tar.gz
10:22 $ cat bigtop-1.2.0-project.tar.gz.md5
cfbf3f9efb0aef1b1f91f5bf588e8d46
10:22 $ gmd5sum bigtop-1.2.0-project.tar.gz.asc
db3ceee21aea5d6d527e561ec0bcef75 bigtop-1.2.0-project.tar.gz.asc
10:22 $ cat bigtop-1.2.0-project.tar.gz.asc.md5
db3ceee21aea5d6d527e561ec0bcef75
10:22 $ gsha1sum bigtop-1.2.0-project.tar.gz.asc
b0716f7a7c66b81fe64943fdc1113441b855de58 bigtop-1.2.0-project.tar.gz.asc
10:22 $ cat bigtop-1.2.0-project.tar.gz.asc.sha1
b0716f7a7c66b81fe64943fdc1113441b855de58
OBSERVATION: The format of the hashes is not super convenient for an
automatic comparison. Being compatible with command
line tools would be helpful.
example:
$ gsha1sum bigtop-1.2.0-project.tar.gz >
bigtop-1.2.0-project.tar.gz.sha1
$ gsha1sum --check bigtop-1.2.0-project.tar.gz.sha1
bigtop-1.2.0-project.tar.gz: OK
======================================================================
GIT TAG
======================================================================
Git tag matches src (except .git*)
commit: 5a2a1a86b17f73260229137b0b008385fd32bfae
OBSERVATION: I noticed the commit hash was not provided. I've seen
several podling votes with them. Should the hash also
been provided along with the corresponding tag?
======================================================================
Apache RAT
======================================================================
The "gradlew rat" execution passed.
OBSERVATIONS:
* Initially I ran using maven and have come to know I should use
gradle. For grins, I generated a RAT Report summary using maven
which intentionally did not have any exclusions identified.
Here is the "mvn apache-rat:check" summary which generated
a few followup observations (below):
*****************************************************
Summary
-------
Generated at: 2017-04-03T11:59:14-07:00
Notes: 97
Binaries: 9
Archives: 3
Standards: 1994
Apache Licensed: 1353
Generated Documents: 0
JavaDocs are generated, thus a license header is optional.
Generated files do not require license headers.
641 Unknown Licenses
*****************************************************
* Should the yaml files included in the release have ASF headers? It
is possible the parsers have troubles with comment ASF headers. But
then again, maybe the current parsers can handle them.
* There are three archives. Are these acceptable?
+
bigtop-packages/src/charm/giraph/layer-giraph/resources/giraph-examples-1.1.0.jar
+ bigtop-tests/test-artifacts/hadoop/src/main/resources/cachedir.jar
+
bigtop-tests/test-artifacts/hadoop/src/main/resources/test_data/test.zip
On Fri, Mar 31, 2017 at 10:39 PM, Konstantin Boudnik <co...@apache.org> wrote:
> One way of doing this is to make Weather Report of our standard CI
> process. Anyway...
>
> +1 on the release
> --
> Take care,
> Konstantin (Cos) Boudnik
> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
>
> Disclaimer: Opinions expressed in this email are those of the author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.
>
>
> On Fri, Mar 31, 2017 at 10:11 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> > On Fri, Mar 31, 2017 at 8:49 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
> >> I have deployed a trivial cluster and ran some MapReduce example and
> >> everything worked!
> >>
> >> The bad news: I found some bugs in the Ignite's deployment (or rather
> >> the discrepancies in 1.9's expectations for the configuration files).
> >> It isn't perhaps a blocker, but I would like to spend a bit of time
> >> (hopefully over the weekend) to fix it.
> >>
> >> I would be ok if we don't consider this as a blocker though.
> >
> > I'd advocate for the same here. In fact, I'd say -- lets focus on
> > core functionality working in 1.2 and once it is out focus on CI
> > to make sure things like Puppet stay functional.
> >
> > Thanks,
> > Roman.
>
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Konstantin Boudnik <co...@apache.org>.
One way of doing this is to make Weather Report of our standard CI
process. Anyway...
+1 on the release
--
Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.
On Fri, Mar 31, 2017 at 10:11 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> On Fri, Mar 31, 2017 at 8:49 PM, Konstantin Boudnik <co...@apache.org> wrote:
>> I have deployed a trivial cluster and ran some MapReduce example and
>> everything worked!
>>
>> The bad news: I found some bugs in the Ignite's deployment (or rather
>> the discrepancies in 1.9's expectations for the configuration files).
>> It isn't perhaps a blocker, but I would like to spend a bit of time
>> (hopefully over the weekend) to fix it.
>>
>> I would be ok if we don't consider this as a blocker though.
>
> I'd advocate for the same here. In fact, I'd say -- lets focus on
> core functionality working in 1.2 and once it is out focus on CI
> to make sure things like Puppet stay functional.
>
> Thanks,
> Roman.
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Mar 31, 2017 at 8:49 PM, Konstantin Boudnik <co...@apache.org> wrote:
> I have deployed a trivial cluster and ran some MapReduce example and
> everything worked!
>
> The bad news: I found some bugs in the Ignite's deployment (or rather
> the discrepancies in 1.9's expectations for the configuration files).
> It isn't perhaps a blocker, but I would like to spend a bit of time
> (hopefully over the weekend) to fix it.
>
> I would be ok if we don't consider this as a blocker though.
I'd advocate for the same here. In fact, I'd say -- lets focus on
core functionality working in 1.2 and once it is out focus on CI
to make sure things like Puppet stay functional.
Thanks,
Roman.
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Konstantin Boudnik <co...@apache.org>.
I have deployed a trivial cluster and ran some MapReduce example and
everything worked!
The bad news: I found some bugs in the Ignite's deployment (or rather
the discrepancies in 1.9's expectations for the configuration files).
It isn't perhaps a blocker, but I would like to spend a bit of time
(hopefully over the weekend) to fix it.
I would be ok if we don't consider this as a blocker though.
Cos
--
Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.
On Fri, Mar 31, 2017 at 11:16 AM, Evans Ye <ev...@apache.org> wrote:
> Roman,
>
> Sounds reasonable. I can recall that discussing thread.
> So we don't need to build arch independent component on ppc or arm.
> Instead, the deployment and testing for components on those platforms would
> be much more important than builds.
>
> Revoke my -1, but I'd like to take more time for evaluation.
> Thanks for the putting up for a RC.
>
>
> 2017-04-01 2:05 GMT+08:00 Roman Shaposhnik <ro...@shaposhnik.org>:
>
>> On Fri, Mar 31, 2017 at 11:02 AM, Olaf Flebbe <of...@oflebbe.de> wrote:
>> > Hi,
>> >
>> > That's the infamous frontend-maven-plugin, downloading and trying to
>> execute "node" for amd64 on each arch. Amir, you patched around these
>> issues in the past ?
>>
>> That's one problem -- but I'm pretty sure its not the only one.
>>
>> Like I said -- for 1.2 we're just side-stepping this and providing
>> packages built elsewhere.
>>
>> For past 1.2 we should fix it for real -- but fixing it for real will
>> require much more than
>> the workaround we currently have in do-component-builds.
>>
>> Thanks,
>> Roman.
>>
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Evans Ye <ev...@apache.org>.
Roman,
Sounds reasonable. I can recall that discussing thread.
So we don't need to build arch independent component on ppc or arm.
Instead, the deployment and testing for components on those platforms would
be much more important than builds.
Revoke my -1, but I'd like to take more time for evaluation.
Thanks for the putting up for a RC.
2017-04-01 2:05 GMT+08:00 Roman Shaposhnik <ro...@shaposhnik.org>:
> On Fri, Mar 31, 2017 at 11:02 AM, Olaf Flebbe <of...@oflebbe.de> wrote:
> > Hi,
> >
> > That's the infamous frontend-maven-plugin, downloading and trying to
> execute "node" for amd64 on each arch. Amir, you patched around these
> issues in the past ?
>
> That's one problem -- but I'm pretty sure its not the only one.
>
> Like I said -- for 1.2 we're just side-stepping this and providing
> packages built elsewhere.
>
> For past 1.2 we should fix it for real -- but fixing it for real will
> require much more than
> the workaround we currently have in do-component-builds.
>
> Thanks,
> Roman.
>
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Mar 31, 2017 at 11:02 AM, Olaf Flebbe <of...@oflebbe.de> wrote:
> Hi,
>
> That's the infamous frontend-maven-plugin, downloading and trying to execute "node" for amd64 on each arch. Amir, you patched around these issues in the past ?
That's one problem -- but I'm pretty sure its not the only one.
Like I said -- for 1.2 we're just side-stepping this and providing
packages built elsewhere.
For past 1.2 we should fix it for real -- but fixing it for real will
require much more than
the workaround we currently have in do-component-builds.
Thanks,
Roman.
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi,
That's the infamous frontend-maven-plugin, downloading and trying to execute "node" for amd64 on each arch. Amir, you patched around these issues in the past ?
Olaf
> Am 31.03.2017 um 19:55 schrieb Evans Ye <ev...@apache.org>:
>
> -1
>
> Good news:
> Binary convenient packages looks good except ppc64le
> https://ci.bigtop.apache.org/view/Releases/job/Bigtop-1.2.0/
>
> Bad news:
> Ambari 2.5 can't build on ppc64le
> https://ci.bigtop.apache.org/view/Releases/job/Bigtop-1.2.0/OS=ubuntu-16.04-ppc64le/3/console
> https://ci.bigtop.apache.org/view/Releases/job/Bigtop-1.2.0/OS=fedora-25-ppc64le/3/console
>
> Both error message looks to have something to do with
> ambari/ambari-2.5.0/ambari-web/node/with_new_path.sh
> I don't have expertise in Ambari.
> Someone has expertise can grab a hand?
>
>
> 2017-04-01 0:44 GMT+08:00 Olaf Flebbe <of...@oflebbe.de>:
>
>> +1
>>
>>
>>
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Evans Ye <ev...@apache.org>.
-1
Good news:
Binary convenient packages looks good except ppc64le
https://ci.bigtop.apache.org/view/Releases/job/Bigtop-1.2.0/
Bad news:
Ambari 2.5 can't build on ppc64le
https://ci.bigtop.apache.org/view/Releases/job/Bigtop-1.2.0/OS=ubuntu-16.04-ppc64le/3/console
https://ci.bigtop.apache.org/view/Releases/job/Bigtop-1.2.0/OS=fedora-25-ppc64le/3/console
Both error message looks to have something to do with
ambari/ambari-2.5.0/ambari-web/node/with_new_path.sh
I don't have expertise in Ambari.
Someone has expertise can grab a hand?
2017-04-01 0:44 GMT+08:00 Olaf Flebbe <of...@oflebbe.de>:
> +1
>
>
>
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Olaf Flebbe <of...@oflebbe.de>.
+1
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Thu, Mar 30, 2017 at 10:45 AM, Olaf Flebbe <of...@oflebbe.de> wrote:
> Hi Roman,
>
> thanks, for your answer. I am fine with it!
>
> Next to a bug:
>
> The release proposition does not contain a valid key: The bigtop.repo.asc file should contain the gpg key which signed the repository. It i.e. your public key, not a detached signature. (Using your public key I sucessfully installed packages ;-)
Olaf, I'm a bit confused. The key you're talking about is there at the
default location:
https://dist.apache.org/repos/dist/dev/bigtop/1.2.0-RC1/repos/GPG-KEY-bigtop
The .asc ones is there just to satisfy ASF requirements.
Am I missing something?
Thanks,
Roman.
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi Roman,
thanks, for your answer. I am fine with it!
Next to a bug:
The release proposition does not contain a valid key: The bigtop.repo.asc file should contain the gpg key which signed the repository. It i.e. your public key, not a detached signature. (Using your public key I sucessfully installed packages ;-)
Greetings
Olaf
> Am 30.03.2017 um 17:24 schrieb Roman Shaposhnik <ro...@shaposhnik.org>:
>
> On Wed, Mar 29, 2017 at 10:54 PM, Olaf Flebbe <of...@oflebbe.de> wrote:
>> Hi Roman,
>>
>> Thanks for you efforts! CI looks really good now.
>>
>> What was the consensus for the BIGTOP-2716 ?
>
> I honestly think it isn't a blocker and it seems that nobody put
> a strong argument forward to the contrary. Thus it is now pushed
> to 1.3.0.
>
>> We only support the current bigtop/slaves docker images, knowing it will
>> break if regenerated? Fine for me.
>
> That is correct. As was mentioned -- we should add it to the release notes
> once we announce the release.
>
> Does this answer your question?
>
> Thanks,
> Roman.
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Mar 29, 2017 at 10:54 PM, Olaf Flebbe <of...@oflebbe.de> wrote:
> Hi Roman,
>
> Thanks for you efforts! CI looks really good now.
>
> What was the consensus for the BIGTOP-2716 ?
I honestly think it isn't a blocker and it seems that nobody put
a strong argument forward to the contrary. Thus it is now pushed
to 1.3.0.
> We only support the current bigtop/slaves docker images, knowing it will
> break if regenerated? Fine for me.
That is correct. As was mentioned -- we should add it to the release notes
once we announce the release.
Does this answer your question?
Thanks,
Roman.
Re: [VOTE] Release Bigtop version 1.2.0
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi Roman,
Thanks for you efforts! CI looks really good now.
What was the consensus for the BIGTOP-2716 <https://issues.apache.org/jira/browse/BIGTOP-2716> ?
We only support the current bigtop/slaves docker images, knowing it will break if regenerated? Fine for me.
Greetings,
Olaf
> Am 30.03.2017 um 03:51 schrieb Roman Shaposhnik <ro...@shaposhnik.org>:
>
> This is the vote for release 1.2.0 of Apache Bigtop.
>
> It fixes the following issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311420&version=12334717
>
> The vote will close on Tuesday, April 4th, 2017 at noon PDT.
> Please download, test and vote with
>
> [ ] +1, accept RC1 as the official 1.2.0 release of Apache Bigtop
> [ ] +0, I don't care either way,
> [ ] -1, do not accept RC1 as the official 1.2.0 release of Apache
> Bigtop, because...
>
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/bigtop/1.2.0-RC1
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachebigtop-1010
>
> The git tag to be voted upon is rel/1.2.0-RC1
>
> The convenience binary artifacts are available for testing at the locations
> indicated by repo file. The easiest way to test those is to use our docker
> provisioner. E.g.
> $ cd provisioner/docker
> $ ./docker-hadoop.sh -C config_XXX.yaml -c 3
>
> Bigtop's KEYS file containing PGP keys we use to sign the release:
> https://dist.apache.org/repos/dist/release/bigtop/KEYS
>
> Thanks,
> Roman.