Re: [VOTE] Release Apache Storm 1.0.6 (rc3)

[P. Taylor Goetz]

This vote is now closed and passes with 3 binding +1 votes, and no 0 or -1 
votes.

Vote tally:

+1:
- Bobby Evans
- Jungtaek Lim
- P. Taylor Goetz

I will release the staged artifacts and announce the release after 24 hours.

-Taylor

> On Feb 8, 2018, at 2:22 PM, P. Taylor Goetz  wrote:
> 
> This is a call to vote on releasing Apache Storm 1.0.6 (rc3)
> 
> Full list of changes in this release:
> 
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/RELEASE_NOTES.html
> 
> The tag/commit to be voted upon is v1.0.6:
> 
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=e68365f9f947ddd1794b2edef2149fdfaa1590a2;hb=7993db01580ce62d44866dc00e0a7266984638d0
> 
> The source archive being voted upon can be found here:
> 
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/apache-storm-1.0.6-src.tar.gz
> 
> Other release files, signatures and digests can be found here:
> 
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/
> 
> The release artifacts are signed with the following key:
> 
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
> 
> The Nexus staging repository for this release is:
> 
> https://repository.apache.org/content/repositories/orgapachestorm-1060
> 
> Please vote on releasing this package as Apache Storm 1.0.6.
> 
> When voting, please list the actions taken to verify the release.
> 
> This vote will be open for at least 72 hours.
> 
> [ ] +1 Release this package as Apache Storm 1.0.6
> [ ]  0 No opinion
> [ ] -1 Do not release this package because...
> 
> Thanks to everyone who contributed to this release.
> 
> -Taylor



signature.asc
Description: Message signed with OpenPGP

Re: [VOTE] Release Apache Storm 1.0.6 (rc3)

[P. Taylor Goetz]

+1 (binding)

-Taylor

> On Feb 8, 2018, at 2:22 PM, P. Taylor Goetz  wrote:
> 
> This is a call to vote on releasing Apache Storm 1.0.6 (rc3)
> 
> Full list of changes in this release:
> 
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/RELEASE_NOTES.html
> 
> The tag/commit to be voted upon is v1.0.6:
> 
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=e68365f9f947ddd1794b2edef2149fdfaa1590a2;hb=7993db01580ce62d44866dc00e0a7266984638d0
> 
> The source archive being voted upon can be found here:
> 
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/apache-storm-1.0.6-src.tar.gz
> 
> Other release files, signatures and digests can be found here:
> 
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/
> 
> The release artifacts are signed with the following key:
> 
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
> 
> The Nexus staging repository for this release is:
> 
> https://repository.apache.org/content/repositories/orgapachestorm-1060
> 
> Please vote on releasing this package as Apache Storm 1.0.6.
> 
> When voting, please list the actions taken to verify the release.
> 
> This vote will be open for at least 72 hours.
> 
> [ ] +1 Release this package as Apache Storm 1.0.6
> [ ]  0 No opinion
> [ ] -1 Do not release this package because...
> 
> Thanks to everyone who contributed to this release.
> 
> -Taylor



signature.asc
Description: Message signed with OpenPGP

Re: [VOTE] Release Apache Storm 1.0.6 (rc3)

[Bobby Evans]

Happy to do the check.  This is something we don't want to get wrong.

On Fri, Feb 9, 2018 at 5:38 PM P. Taylor Goetz  wrote:

> Doh! I didn’t even think consider that it was likely autogenerated by an
> IDE and likely identical to what the JDK would generate.
>
> I agree with Bobby, let’s leave it there and continue with the RC.
>
> Thanks for pointing that out Bobby.
>
> -Taylor
>
> > On Feb 9, 2018, at 4:07 PM, Bobby Evans  wrote:
> >
> > Actually it is set properly.  Do NOT change it.  It works just fine the
> way
> > it is.
> >
> > $ git checkout f6f35dd98d2492a38aa4d61da7f6caee4ec2f31a # The git version
> > right before this change on branch-1.x
> > $ mvn clean install -DskipTests
> > $ serialver -classpath ./storm-core/target/storm-core-1.1.0-SNAPSHOT.jar
> > org.apache.storm.tuple.Fields
> > org.apache.storm.tuple.Fields:private static final long
> > serialVersionUID = -3377931843059975424L;
> >
> > This is the same version that we set it to as a part of the change.
> >
> > - Bobby
> >
> > On Fri, Feb 9, 2018 at 3:00 PM Bobby Evans  wrote:
> >
> >> Fields changing will cause problems if it is serialized as part of a
> >> bolt/spout or as part of a custom grouping.  I have not checked
> explicitly,
> >> but removing that line is the wrong thing to do.  By default the
> serialVersionUID
> >> is generated from the class itself, so removing it, but leaving in the
> >> modified code would still break backwards compatibility.
> >>
> >> I'll take a look and see what you need to set it to so you don't break
> >> backwards compatibility on 1.x
> >>
> >> On Fri, Feb 9, 2018 at 10:19 AM P. Taylor Goetz 
> wrote:
> >>
> >>> What are others’ opinions on removing the serialversionUid an moving
> >>> ahead with an RC4?
> >>>
> >>> -Taylor
> >>>
>  On Feb 9, 2018, at 7:21 AM, Jungtaek Lim  wrote:
> 
>  I just went ahead verifying current RC except serialization UID issue
> in
>  Fields. I could also vote for RC4 immediately if necessary.
> 
>  +1 (binding)
> 
> > source
> 
>  - verify file (signature, MD5, SHA)
>  -- source, tar.gz : OK
>  -- source, zip : OK
> 
>  - extract file
>  -- source, tar.gz : OK
>  -- source, zip : OK
> 
>  - diff-ing extracted files between tar.gz and zip : OK
> 
>  - build source with JDK 7
>  -- source, tar.gz : OK
> 
>  - build source dist
>  -- source, tar.gz : OK
> 
>  - build binary dist
>  -- source, tar.gz : OK
> 
> > binary
> 
>  - verify file (signature, MD5, SHA)
>  -- binary, tar.gz : OK
>  -- binary, zip : OK
> 
>  - extract file
>  -- binary, tar.gz : OK
>  -- binary, zip : OK
> 
>  - diff-ing extracted files between tar.gz and zip : OK
> 
>  - launch daemons : OK
> 
>  - run RollingTopWords (local) : OK
> 
>  - run RollingTopWords (remote) : OK
>  - activate / deactivate / rebalance / kill : OK
>  - logviewer (worker dir, daemon dir) : OK
>  - change log level : OK
>  - thread dump, heap dump, restart worker : OK
>  - log search : OK
> 
>  Thanks,
>  Jungtaek Lim (HeartSaVioR)
> 
>  2018년 2월 9일 (금) 오후 6:18, Erik Weathers  >님이
> >>> 작성:
> 
> > I'm fine submitting a PR to back that line out (or any of you
> committer
> > folks could just rip it out).
> >
> > But I'd like to understand Storm a bit better as part of making this
> > decision. :-)  Am I correct in assuming it would only be a problem if
> >>> the
> > serialized Fields were stored somewhere (e.g., ZooKeeper, local
> >>> filesystem)
> > and then read back in after the Nimbus/Workers are brought back up
> >>> after
> > the upgrade?  Seems Fields is used in a *lot* of places, and I don't
> >>> know
> > precisely what is serialized for reused upon Storm Nimbus/Worker
> daemon
> > restarts.  I believe there are examples of Fields being used to
> create
> > Spout or Bolt objects that are used to create the StormTopology
> object,
> > which I believe is serialized into ZooKeeper.  But I'm not clear if
> >>> it's
> > directly the Fields object itself or some kind of translation from
> that
> > into the thrift objects that make up StormTopology.
> >
> > I also don't know exactly when kryo is applicable in Storm.  I've
> never
> > done anything with kryo directly.
> >
> > - Erik
> >
> > On Thu, Feb 8, 2018 at 10:00 PM, P. Taylor Goetz 
> > wrote:
> >
> >> *serialized* ;)
> >>
> >>> On Feb 9, 2018, at 12:48 AM, P. Taylor Goetz 
> > wrote:
> >>>
> >>> I’d have to check (can’t right now), but I think that class gets
> >> sterilized via kryo. If that’s not the case, yes, it could cause
> > problems.
> >>>
> 

Re: [VOTE] Release Apache Storm 1.0.6 (rc3)

[P. Taylor Goetz]

Doh! I didn’t even think consider that it was likely autogenerated by an IDE 
and likely identical to what the JDK would generate.

I agree with Bobby, let’s leave it there and continue with the RC.

Thanks for pointing that out Bobby.

-Taylor

> On Feb 9, 2018, at 4:07 PM, Bobby Evans  wrote:
> 
> Actually it is set properly.  Do NOT change it.  It works just fine the way
> it is.
> 
> $ git checkout f6f35dd98d2492a38aa4d61da7f6caee4ec2f31a # The git version
> right before this change on branch-1.x
> $ mvn clean install -DskipTests
> $ serialver -classpath ./storm-core/target/storm-core-1.1.0-SNAPSHOT.jar
> org.apache.storm.tuple.Fields
> org.apache.storm.tuple.Fields:private static final long
> serialVersionUID = -3377931843059975424L;
> 
> This is the same version that we set it to as a part of the change.
> 
> - Bobby
> 
> On Fri, Feb 9, 2018 at 3:00 PM Bobby Evans  wrote:
> 
>> Fields changing will cause problems if it is serialized as part of a
>> bolt/spout or as part of a custom grouping.  I have not checked explicitly,
>> but removing that line is the wrong thing to do.  By default the 
>> serialVersionUID
>> is generated from the class itself, so removing it, but leaving in the
>> modified code would still break backwards compatibility.
>> 
>> I'll take a look and see what you need to set it to so you don't break
>> backwards compatibility on 1.x
>> 
>> On Fri, Feb 9, 2018 at 10:19 AM P. Taylor Goetz  wrote:
>> 
>>> What are others’ opinions on removing the serialversionUid an moving
>>> ahead with an RC4?
>>> 
>>> -Taylor
>>> 
 On Feb 9, 2018, at 7:21 AM, Jungtaek Lim  wrote:
 
 I just went ahead verifying current RC except serialization UID issue in
 Fields. I could also vote for RC4 immediately if necessary.
 
 +1 (binding)
 
> source
 
 - verify file (signature, MD5, SHA)
 -- source, tar.gz : OK
 -- source, zip : OK
 
 - extract file
 -- source, tar.gz : OK
 -- source, zip : OK
 
 - diff-ing extracted files between tar.gz and zip : OK
 
 - build source with JDK 7
 -- source, tar.gz : OK
 
 - build source dist
 -- source, tar.gz : OK
 
 - build binary dist
 -- source, tar.gz : OK
 
> binary
 
 - verify file (signature, MD5, SHA)
 -- binary, tar.gz : OK
 -- binary, zip : OK
 
 - extract file
 -- binary, tar.gz : OK
 -- binary, zip : OK
 
 - diff-ing extracted files between tar.gz and zip : OK
 
 - launch daemons : OK
 
 - run RollingTopWords (local) : OK
 
 - run RollingTopWords (remote) : OK
 - activate / deactivate / rebalance / kill : OK
 - logviewer (worker dir, daemon dir) : OK
 - change log level : OK
 - thread dump, heap dump, restart worker : OK
 - log search : OK
 
 Thanks,
 Jungtaek Lim (HeartSaVioR)
 
 2018년 2월 9일 (금) 오후 6:18, Erik Weathers 님이
>>> 작성:
 
> I'm fine submitting a PR to back that line out (or any of you committer
> folks could just rip it out).
> 
> But I'd like to understand Storm a bit better as part of making this
> decision. :-)  Am I correct in assuming it would only be a problem if
>>> the
> serialized Fields were stored somewhere (e.g., ZooKeeper, local
>>> filesystem)
> and then read back in after the Nimbus/Workers are brought back up
>>> after
> the upgrade?  Seems Fields is used in a *lot* of places, and I don't
>>> know
> precisely what is serialized for reused upon Storm Nimbus/Worker daemon
> restarts.  I believe there are examples of Fields being used to create
> Spout or Bolt objects that are used to create the StormTopology object,
> which I believe is serialized into ZooKeeper.  But I'm not clear if
>>> it's
> directly the Fields object itself or some kind of translation from that
> into the thrift objects that make up StormTopology.
> 
> I also don't know exactly when kryo is applicable in Storm.  I've never
> done anything with kryo directly.
> 
> - Erik
> 
> On Thu, Feb 8, 2018 at 10:00 PM, P. Taylor Goetz 
> wrote:
> 
>> *serialized* ;)
>> 
>>> On Feb 9, 2018, at 12:48 AM, P. Taylor Goetz 
> wrote:
>>> 
>>> I’d have to check (can’t right now), but I think that class gets
>> sterilized via kryo. If that’s not the case, yes, it could cause
> problems.
>>> 
>>> I think the safest option would be to remove the serialversionuid.
>>> 
>>> -Taylor
>>> 
 On Feb 8, 2018, at 5:36 PM, Erik Weathers
> 
>> wrote:
 
 Something I just realized -- in the storm-kafka-client stomping into
 1.0.x-branch PR, I backported a change to Fields.java which added a
 serialVersionUID.

Re: [VOTE] Release Apache Storm 1.0.6 (rc3)

[Bobby Evans]

Actually it is set properly.  Do NOT change it.  It works just fine the way
it is.

$ git checkout f6f35dd98d2492a38aa4d61da7f6caee4ec2f31a # The git version
right before this change on branch-1.x
$ mvn clean install -DskipTests
$ serialver -classpath ./storm-core/target/storm-core-1.1.0-SNAPSHOT.jar
org.apache.storm.tuple.Fields
org.apache.storm.tuple.Fields:private static final long
serialVersionUID = -3377931843059975424L;

This is the same version that we set it to as a part of the change.

- Bobby

On Fri, Feb 9, 2018 at 3:00 PM Bobby Evans  wrote:

> Fields changing will cause problems if it is serialized as part of a
> bolt/spout or as part of a custom grouping.  I have not checked explicitly,
> but removing that line is the wrong thing to do.  By default the 
> serialVersionUID
> is generated from the class itself, so removing it, but leaving in the
> modified code would still break backwards compatibility.
>
> I'll take a look and see what you need to set it to so you don't break
> backwards compatibility on 1.x
>
> On Fri, Feb 9, 2018 at 10:19 AM P. Taylor Goetz  wrote:
>
>> What are others’ opinions on removing the serialversionUid an moving
>> ahead with an RC4?
>>
>> -Taylor
>>
>> > On Feb 9, 2018, at 7:21 AM, Jungtaek Lim  wrote:
>> >
>> > I just went ahead verifying current RC except serialization UID issue in
>> > Fields. I could also vote for RC4 immediately if necessary.
>> >
>> > +1 (binding)
>> >
>> >> source
>> >
>> > - verify file (signature, MD5, SHA)
>> > -- source, tar.gz : OK
>> > -- source, zip : OK
>> >
>> > - extract file
>> > -- source, tar.gz : OK
>> > -- source, zip : OK
>> >
>> > - diff-ing extracted files between tar.gz and zip : OK
>> >
>> > - build source with JDK 7
>> > -- source, tar.gz : OK
>> >
>> > - build source dist
>> > -- source, tar.gz : OK
>> >
>> > - build binary dist
>> > -- source, tar.gz : OK
>> >
>> >> binary
>> >
>> > - verify file (signature, MD5, SHA)
>> > -- binary, tar.gz : OK
>> > -- binary, zip : OK
>> >
>> > - extract file
>> > -- binary, tar.gz : OK
>> > -- binary, zip : OK
>> >
>> > - diff-ing extracted files between tar.gz and zip : OK
>> >
>> > - launch daemons : OK
>> >
>> > - run RollingTopWords (local) : OK
>> >
>> > - run RollingTopWords (remote) : OK
>> >  - activate / deactivate / rebalance / kill : OK
>> >  - logviewer (worker dir, daemon dir) : OK
>> >  - change log level : OK
>> >  - thread dump, heap dump, restart worker : OK
>> >  - log search : OK
>> >
>> > Thanks,
>> > Jungtaek Lim (HeartSaVioR)
>> >
>> > 2018년 2월 9일 (금) 오후 6:18, Erik Weathers 님이
>> 작성:
>> >
>> >> I'm fine submitting a PR to back that line out (or any of you committer
>> >> folks could just rip it out).
>> >>
>> >> But I'd like to understand Storm a bit better as part of making this
>> >> decision. :-)  Am I correct in assuming it would only be a problem if
>> the
>> >> serialized Fields were stored somewhere (e.g., ZooKeeper, local
>> filesystem)
>> >> and then read back in after the Nimbus/Workers are brought back up
>> after
>> >> the upgrade?  Seems Fields is used in a *lot* of places, and I don't
>> know
>> >> precisely what is serialized for reused upon Storm Nimbus/Worker daemon
>> >> restarts.  I believe there are examples of Fields being used to create
>> >> Spout or Bolt objects that are used to create the StormTopology object,
>> >> which I believe is serialized into ZooKeeper.  But I'm not clear if
>> it's
>> >> directly the Fields object itself or some kind of translation from that
>> >> into the thrift objects that make up StormTopology.
>> >>
>> >> I also don't know exactly when kryo is applicable in Storm.  I've never
>> >> done anything with kryo directly.
>> >>
>> >> - Erik
>> >>
>> >> On Thu, Feb 8, 2018 at 10:00 PM, P. Taylor Goetz 
>> >> wrote:
>> >>
>> >>> *serialized* ;)
>> >>>
>>  On Feb 9, 2018, at 12:48 AM, P. Taylor Goetz 
>> >> wrote:
>> 
>>  I’d have to check (can’t right now), but I think that class gets
>> >>> sterilized via kryo. If that’s not the case, yes, it could cause
>> >> problems.
>> 
>>  I think the safest option would be to remove the serialversionuid.
>> 
>>  -Taylor
>> 
>> > On Feb 8, 2018, at 5:36 PM, Erik Weathers
>> >> 
>> >>> wrote:
>> >
>> > Something I just realized -- in the storm-kafka-client stomping into
>> > 1.0.x-branch PR, I backported a change to Fields.java which added a
>> > serialVersionUID.
>> > Could that potentially break topologies when you upgrade storm-core
>> on
>> >>> the
>> > servers (nimbus, workers) from 1.0.{1..5} to 1.0.6?   I'm not super
>> > familiar with the serialization that occurs in Storm and whether
>> that
>> >>> could
>> > break people.
>> >
>> > https://github.com/apache/storm/pull/2550/files#diff-71a428d
>> >>> 508c4f5af0bfe3cc186e8edcf
>> >
>> 

Re: [VOTE] Release Apache Storm 1.0.6 (rc3)

[P. Taylor Goetz]

What are others’ opinions on removing the serialversionUid an moving ahead with 
an RC4?

-Taylor

> On Feb 9, 2018, at 7:21 AM, Jungtaek Lim  wrote:
> 
> I just went ahead verifying current RC except serialization UID issue in
> Fields. I could also vote for RC4 immediately if necessary.
> 
> +1 (binding)
> 
>> source
> 
> - verify file (signature, MD5, SHA)
> -- source, tar.gz : OK
> -- source, zip : OK
> 
> - extract file
> -- source, tar.gz : OK
> -- source, zip : OK
> 
> - diff-ing extracted files between tar.gz and zip : OK
> 
> - build source with JDK 7
> -- source, tar.gz : OK
> 
> - build source dist
> -- source, tar.gz : OK
> 
> - build binary dist
> -- source, tar.gz : OK
> 
>> binary
> 
> - verify file (signature, MD5, SHA)
> -- binary, tar.gz : OK
> -- binary, zip : OK
> 
> - extract file
> -- binary, tar.gz : OK
> -- binary, zip : OK
> 
> - diff-ing extracted files between tar.gz and zip : OK
> 
> - launch daemons : OK
> 
> - run RollingTopWords (local) : OK
> 
> - run RollingTopWords (remote) : OK
>  - activate / deactivate / rebalance / kill : OK
>  - logviewer (worker dir, daemon dir) : OK
>  - change log level : OK
>  - thread dump, heap dump, restart worker : OK
>  - log search : OK
> 
> Thanks,
> Jungtaek Lim (HeartSaVioR)
> 
> 2018년 2월 9일 (금) 오후 6:18, Erik Weathers 님이 작성:
> 
>> I'm fine submitting a PR to back that line out (or any of you committer
>> folks could just rip it out).
>> 
>> But I'd like to understand Storm a bit better as part of making this
>> decision. :-)  Am I correct in assuming it would only be a problem if the
>> serialized Fields were stored somewhere (e.g., ZooKeeper, local filesystem)
>> and then read back in after the Nimbus/Workers are brought back up after
>> the upgrade?  Seems Fields is used in a *lot* of places, and I don't know
>> precisely what is serialized for reused upon Storm Nimbus/Worker daemon
>> restarts.  I believe there are examples of Fields being used to create
>> Spout or Bolt objects that are used to create the StormTopology object,
>> which I believe is serialized into ZooKeeper.  But I'm not clear if it's
>> directly the Fields object itself or some kind of translation from that
>> into the thrift objects that make up StormTopology.
>> 
>> I also don't know exactly when kryo is applicable in Storm.  I've never
>> done anything with kryo directly.
>> 
>> - Erik
>> 
>> On Thu, Feb 8, 2018 at 10:00 PM, P. Taylor Goetz 
>> wrote:
>> 
>>> *serialized* ;)
>>> 
 On Feb 9, 2018, at 12:48 AM, P. Taylor Goetz 
>> wrote:
 
 I’d have to check (can’t right now), but I think that class gets
>>> sterilized via kryo. If that’s not the case, yes, it could cause
>> problems.
 
 I think the safest option would be to remove the serialversionuid.
 
 -Taylor
 
> On Feb 8, 2018, at 5:36 PM, Erik Weathers
>> 
>>> wrote:
> 
> Something I just realized -- in the storm-kafka-client stomping into
> 1.0.x-branch PR, I backported a change to Fields.java which added a
> serialVersionUID.
> Could that potentially break topologies when you upgrade storm-core on
>>> the
> servers (nimbus, workers) from 1.0.{1..5} to 1.0.6?   I'm not super
> familiar with the serialization that occurs in Storm and whether that
>>> could
> break people.
> 
> https://github.com/apache/storm/pull/2550/files#diff-71a428d
>>> 508c4f5af0bfe3cc186e8edcf
> 
> - Erik
> 
>> On Thu, Feb 8, 2018 at 1:25 PM, Bobby Evans 
>>> wrote:
>> 
>> +1 I built the code from the git tag, ran all the unit tests (which
>>> passed
>> the first time), and ran some tests on a single node cluster.
>> 
>> It all looked good.
>> 
>> - Bobby
>> 
>>> On Thu, Feb 8, 2018 at 1:22 PM P. Taylor Goetz 
>>> wrote:
>>> 
>>> This is a call to vote on releasing Apache Storm 1.0.6 (rc3)
>>> 
>>> Full list of changes in this release:
>>> 
>>> 
>>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.
>> 0.6-rc3/RELEASE_NOTES.html
>>> 
>>> The tag/commit to be voted upon is v1.0.6:
>>> 
>>> 
>>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=
>> e68365f9f947ddd1794b2edef2149fdfaa1590a2;hb=7993db01580ce62d
>>> 44866dc00e0a72
>> 66984638d0
>>> 
>>> The source archive being voted upon can be found here:
>>> 
>>> 
>>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.
>> 0.6-rc3/apache-storm-1.0.6-src.tar.gz
>>> 
>>> Other release files, signatures and digests can be found here:
>>> 
>>> 
>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/
>>> 
>>> The release artifacts are signed with the following key:
>>> 
>>> 
>>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_
>> 

Re: [VOTE] Release Apache Storm 1.0.6 (rc3)

[Jungtaek Lim]

I just went ahead verifying current RC except serialization UID issue in
Fields. I could also vote for RC4 immediately if necessary.

+1 (binding)

> source

- verify file (signature, MD5, SHA)
-- source, tar.gz : OK
-- source, zip : OK

- extract file
-- source, tar.gz : OK
-- source, zip : OK

- diff-ing extracted files between tar.gz and zip : OK

- build source with JDK 7
-- source, tar.gz : OK

- build source dist
-- source, tar.gz : OK

- build binary dist
-- source, tar.gz : OK

> binary

- verify file (signature, MD5, SHA)
-- binary, tar.gz : OK
-- binary, zip : OK

- extract file
-- binary, tar.gz : OK
-- binary, zip : OK

- diff-ing extracted files between tar.gz and zip : OK

- launch daemons : OK

- run RollingTopWords (local) : OK

- run RollingTopWords (remote) : OK
  - activate / deactivate / rebalance / kill : OK
  - logviewer (worker dir, daemon dir) : OK
  - change log level : OK
  - thread dump, heap dump, restart worker : OK
  - log search : OK

Thanks,
Jungtaek Lim (HeartSaVioR)

2018년 2월 9일 (금) 오후 6:18, Erik Weathers 님이 작성:

> I'm fine submitting a PR to back that line out (or any of you committer
> folks could just rip it out).
>
> But I'd like to understand Storm a bit better as part of making this
> decision. :-)  Am I correct in assuming it would only be a problem if the
> serialized Fields were stored somewhere (e.g., ZooKeeper, local filesystem)
> and then read back in after the Nimbus/Workers are brought back up after
> the upgrade?  Seems Fields is used in a *lot* of places, and I don't know
> precisely what is serialized for reused upon Storm Nimbus/Worker daemon
> restarts.  I believe there are examples of Fields being used to create
> Spout or Bolt objects that are used to create the StormTopology object,
> which I believe is serialized into ZooKeeper.  But I'm not clear if it's
> directly the Fields object itself or some kind of translation from that
> into the thrift objects that make up StormTopology.
>
> I also don't know exactly when kryo is applicable in Storm.  I've never
> done anything with kryo directly.
>
> - Erik
>
> On Thu, Feb 8, 2018 at 10:00 PM, P. Taylor Goetz 
> wrote:
>
> > *serialized* ;)
> >
> > > On Feb 9, 2018, at 12:48 AM, P. Taylor Goetz 
> wrote:
> > >
> > > I’d have to check (can’t right now), but I think that class gets
> > sterilized via kryo. If that’s not the case, yes, it could cause
> problems.
> > >
> > > I think the safest option would be to remove the serialversionuid.
> > >
> > > -Taylor
> > >
> > >> On Feb 8, 2018, at 5:36 PM, Erik Weathers
> 
> > wrote:
> > >>
> > >> Something I just realized -- in the storm-kafka-client stomping into
> > >> 1.0.x-branch PR, I backported a change to Fields.java which added a
> > >> serialVersionUID.
> > >> Could that potentially break topologies when you upgrade storm-core on
> > the
> > >> servers (nimbus, workers) from 1.0.{1..5} to 1.0.6?   I'm not super
> > >> familiar with the serialization that occurs in Storm and whether that
> > could
> > >> break people.
> > >>
> > >> https://github.com/apache/storm/pull/2550/files#diff-71a428d
> > 508c4f5af0bfe3cc186e8edcf
> > >>
> > >> - Erik
> > >>
> > >>> On Thu, Feb 8, 2018 at 1:25 PM, Bobby Evans 
> > wrote:
> > >>>
> > >>> +1 I built the code from the git tag, ran all the unit tests (which
> > passed
> > >>> the first time), and ran some tests on a single node cluster.
> > >>>
> > >>> It all looked good.
> > >>>
> > >>> - Bobby
> > >>>
> >  On Thu, Feb 8, 2018 at 1:22 PM P. Taylor Goetz 
> > wrote:
> > 
> >  This is a call to vote on releasing Apache Storm 1.0.6 (rc3)
> > 
> >  Full list of changes in this release:
> > 
> > 
> >  https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.
> > >>> 0.6-rc3/RELEASE_NOTES.html
> > 
> >  The tag/commit to be voted upon is v1.0.6:
> > 
> > 
> >  https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=
> > >>> e68365f9f947ddd1794b2edef2149fdfaa1590a2;hb=7993db01580ce62d
> > 44866dc00e0a72
> > >>> 66984638d0
> > 
> >  The source archive being voted upon can be found here:
> > 
> > 
> >  https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.
> > >>> 0.6-rc3/apache-storm-1.0.6-src.tar.gz
> > 
> >  Other release files, signatures and digests can be found here:
> > 
> > 
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/
> > 
> >  The release artifacts are signed with the following key:
> > 
> > 
> >  https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_
> > >>> plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
> > 
> >  The Nexus staging repository for this release is:
> > 
> >  https://repository.apache.org/content/repositories/orgapache
> > storm-1060
> > 
> >  Please vote on releasing this 

Re: [VOTE] Release Apache Storm 1.0.6 (rc3)

[Erik Weathers]

I'm fine submitting a PR to back that line out (or any of you committer
folks could just rip it out).

But I'd like to understand Storm a bit better as part of making this
decision. :-)  Am I correct in assuming it would only be a problem if the
serialized Fields were stored somewhere (e.g., ZooKeeper, local filesystem)
and then read back in after the Nimbus/Workers are brought back up after
the upgrade?  Seems Fields is used in a *lot* of places, and I don't know
precisely what is serialized for reused upon Storm Nimbus/Worker daemon
restarts.  I believe there are examples of Fields being used to create
Spout or Bolt objects that are used to create the StormTopology object,
which I believe is serialized into ZooKeeper.  But I'm not clear if it's
directly the Fields object itself or some kind of translation from that
into the thrift objects that make up StormTopology.

I also don't know exactly when kryo is applicable in Storm.  I've never
done anything with kryo directly.

- Erik

On Thu, Feb 8, 2018 at 10:00 PM, P. Taylor Goetz  wrote:

> *serialized* ;)
>
> > On Feb 9, 2018, at 12:48 AM, P. Taylor Goetz  wrote:
> >
> > I’d have to check (can’t right now), but I think that class gets
> sterilized via kryo. If that’s not the case, yes, it could cause problems.
> >
> > I think the safest option would be to remove the serialversionuid.
> >
> > -Taylor
> >
> >> On Feb 8, 2018, at 5:36 PM, Erik Weathers 
> wrote:
> >>
> >> Something I just realized -- in the storm-kafka-client stomping into
> >> 1.0.x-branch PR, I backported a change to Fields.java which added a
> >> serialVersionUID.
> >> Could that potentially break topologies when you upgrade storm-core on
> the
> >> servers (nimbus, workers) from 1.0.{1..5} to 1.0.6?   I'm not super
> >> familiar with the serialization that occurs in Storm and whether that
> could
> >> break people.
> >>
> >> https://github.com/apache/storm/pull/2550/files#diff-71a428d
> 508c4f5af0bfe3cc186e8edcf
> >>
> >> - Erik
> >>
> >>> On Thu, Feb 8, 2018 at 1:25 PM, Bobby Evans 
> wrote:
> >>>
> >>> +1 I built the code from the git tag, ran all the unit tests (which
> passed
> >>> the first time), and ran some tests on a single node cluster.
> >>>
> >>> It all looked good.
> >>>
> >>> - Bobby
> >>>
>  On Thu, Feb 8, 2018 at 1:22 PM P. Taylor Goetz 
> wrote:
> 
>  This is a call to vote on releasing Apache Storm 1.0.6 (rc3)
> 
>  Full list of changes in this release:
> 
> 
>  https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.
> >>> 0.6-rc3/RELEASE_NOTES.html
> 
>  The tag/commit to be voted upon is v1.0.6:
> 
> 
>  https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=
> >>> e68365f9f947ddd1794b2edef2149fdfaa1590a2;hb=7993db01580ce62d
> 44866dc00e0a72
> >>> 66984638d0
> 
>  The source archive being voted upon can be found here:
> 
> 
>  https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.
> >>> 0.6-rc3/apache-storm-1.0.6-src.tar.gz
> 
>  Other release files, signatures and digests can be found here:
> 
>  https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/
> 
>  The release artifacts are signed with the following key:
> 
> 
>  https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_
> >>> plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
> 
>  The Nexus staging repository for this release is:
> 
>  https://repository.apache.org/content/repositories/orgapache
> storm-1060
> 
>  Please vote on releasing this package as Apache Storm 1.0.6.
> 
>  When voting, please list the actions taken to verify the release.
> 
>  This vote will be open for at least 72 hours.
> 
>  [ ] +1 Release this package as Apache Storm 1.0.6
>  [ ]  0 No opinion
>  [ ] -1 Do not release this package because...
> 
>  Thanks to everyone who contributed to this release.
> 
>  -Taylor
> >>>
>

Re: [VOTE] Release Apache Storm 1.0.6 (rc3)

[P. Taylor Goetz]

*serialized* ;)

> On Feb 9, 2018, at 12:48 AM, P. Taylor Goetz  wrote:
> 
> I’d have to check (can’t right now), but I think that class gets sterilized 
> via kryo. If that’s not the case, yes, it could cause problems.
> 
> I think the safest option would be to remove the serialversionuid.
> 
> -Taylor
> 
>> On Feb 8, 2018, at 5:36 PM, Erik Weathers  
>> wrote:
>> 
>> Something I just realized -- in the storm-kafka-client stomping into
>> 1.0.x-branch PR, I backported a change to Fields.java which added a
>> serialVersionUID.
>> Could that potentially break topologies when you upgrade storm-core on the
>> servers (nimbus, workers) from 1.0.{1..5} to 1.0.6?   I'm not super
>> familiar with the serialization that occurs in Storm and whether that could
>> break people.
>> 
>> https://github.com/apache/storm/pull/2550/files#diff-71a428d508c4f5af0bfe3cc186e8edcf
>> 
>> - Erik
>> 
>>> On Thu, Feb 8, 2018 at 1:25 PM, Bobby Evans  wrote:
>>> 
>>> +1 I built the code from the git tag, ran all the unit tests (which passed
>>> the first time), and ran some tests on a single node cluster.
>>> 
>>> It all looked good.
>>> 
>>> - Bobby
>>> 
 On Thu, Feb 8, 2018 at 1:22 PM P. Taylor Goetz  wrote:
 
 This is a call to vote on releasing Apache Storm 1.0.6 (rc3)
 
 Full list of changes in this release:
 
 
 https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.
>>> 0.6-rc3/RELEASE_NOTES.html
 
 The tag/commit to be voted upon is v1.0.6:
 
 
 https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=
>>> e68365f9f947ddd1794b2edef2149fdfaa1590a2;hb=7993db01580ce62d44866dc00e0a72
>>> 66984638d0
 
 The source archive being voted upon can be found here:
 
 
 https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.
>>> 0.6-rc3/apache-storm-1.0.6-src.tar.gz
 
 Other release files, signatures and digests can be found here:
 
 https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/
 
 The release artifacts are signed with the following key:
 
 
 https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_
>>> plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
 
 The Nexus staging repository for this release is:
 
 https://repository.apache.org/content/repositories/orgapachestorm-1060
 
 Please vote on releasing this package as Apache Storm 1.0.6.
 
 When voting, please list the actions taken to verify the release.
 
 This vote will be open for at least 72 hours.
 
 [ ] +1 Release this package as Apache Storm 1.0.6
 [ ]  0 No opinion
 [ ] -1 Do not release this package because...
 
 Thanks to everyone who contributed to this release.
 
 -Taylor
>>> 

Re: [VOTE] Release Apache Storm 1.0.6 (rc3)

[P. Taylor Goetz]

I’d have to check (can’t right now), but I think that class gets sterilized via 
kryo. If that’s not the case, yes, it could cause problems.

I think the safest option would be to remove the serialversionuid.

-Taylor

> On Feb 8, 2018, at 5:36 PM, Erik Weathers  
> wrote:
> 
> Something I just realized -- in the storm-kafka-client stomping into
> 1.0.x-branch PR, I backported a change to Fields.java which added a
> serialVersionUID.
> Could that potentially break topologies when you upgrade storm-core on the
> servers (nimbus, workers) from 1.0.{1..5} to 1.0.6?   I'm not super
> familiar with the serialization that occurs in Storm and whether that could
> break people.
> 
> https://github.com/apache/storm/pull/2550/files#diff-71a428d508c4f5af0bfe3cc186e8edcf
> 
> - Erik
> 
>> On Thu, Feb 8, 2018 at 1:25 PM, Bobby Evans  wrote:
>> 
>> +1 I built the code from the git tag, ran all the unit tests (which passed
>> the first time), and ran some tests on a single node cluster.
>> 
>> It all looked good.
>> 
>> - Bobby
>> 
>>> On Thu, Feb 8, 2018 at 1:22 PM P. Taylor Goetz  wrote:
>>> 
>>> This is a call to vote on releasing Apache Storm 1.0.6 (rc3)
>>> 
>>> Full list of changes in this release:
>>> 
>>> 
>>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.
>> 0.6-rc3/RELEASE_NOTES.html
>>> 
>>> The tag/commit to be voted upon is v1.0.6:
>>> 
>>> 
>>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=
>> e68365f9f947ddd1794b2edef2149fdfaa1590a2;hb=7993db01580ce62d44866dc00e0a72
>> 66984638d0
>>> 
>>> The source archive being voted upon can be found here:
>>> 
>>> 
>>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.
>> 0.6-rc3/apache-storm-1.0.6-src.tar.gz
>>> 
>>> Other release files, signatures and digests can be found here:
>>> 
>>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/
>>> 
>>> The release artifacts are signed with the following key:
>>> 
>>> 
>>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_
>> plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
>>> 
>>> The Nexus staging repository for this release is:
>>> 
>>> https://repository.apache.org/content/repositories/orgapachestorm-1060
>>> 
>>> Please vote on releasing this package as Apache Storm 1.0.6.
>>> 
>>> When voting, please list the actions taken to verify the release.
>>> 
>>> This vote will be open for at least 72 hours.
>>> 
>>> [ ] +1 Release this package as Apache Storm 1.0.6
>>> [ ]  0 No opinion
>>> [ ] -1 Do not release this package because...
>>> 
>>> Thanks to everyone who contributed to this release.
>>> 
>>> -Taylor
>> 

Re: [VOTE] Release Apache Storm 1.0.6 (rc3)

[Jungtaek Lim]

I'm not 100% sure either, but I assume Storm serializes topology
information into thrift structure (at least Grouping.fields() takes
List instead of Fields), so unless nodes are using different
versions of Storm (which we never support), that would be safe. If it's not
safe, we already broke rolling upgrade from under 1.1.0 to 1.1.0 since same
modification was done from 1.1.0.

2018년 2월 9일 (금) 오전 7:37, Erik Weathers 님이 작성:

> Something I just realized -- in the storm-kafka-client stomping into
> 1.0.x-branch PR, I backported a change to Fields.java which added a
> serialVersionUID.
> Could that potentially break topologies when you upgrade storm-core on the
> servers (nimbus, workers) from 1.0.{1..5} to 1.0.6?   I'm not super
> familiar with the serialization that occurs in Storm and whether that could
> break people.
>
>
> https://github.com/apache/storm/pull/2550/files#diff-71a428d508c4f5af0bfe3cc186e8edcf
>
> - Erik
>
> On Thu, Feb 8, 2018 at 1:25 PM, Bobby Evans 
> wrote:
>
> > +1 I built the code from the git tag, ran all the unit tests (which
> passed
> > the first time), and ran some tests on a single node cluster.
> >
> > It all looked good.
> >
> > - Bobby
> >
> > On Thu, Feb 8, 2018 at 1:22 PM P. Taylor Goetz 
> wrote:
> >
> > > This is a call to vote on releasing Apache Storm 1.0.6 (rc3)
> > >
> > > Full list of changes in this release:
> > >
> > >
> > > https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.
> > 0.6-rc3/RELEASE_NOTES.html
> > >
> > > The tag/commit to be voted upon is v1.0.6:
> > >
> > >
> > > https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=
> >
> e68365f9f947ddd1794b2edef2149fdfaa1590a2;hb=7993db01580ce62d44866dc00e0a72
> > 66984638d0
> > >
> > > The source archive being voted upon can be found here:
> > >
> > >
> > > https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.
> > 0.6-rc3/apache-storm-1.0.6-src.tar.gz
> > >
> > > Other release files, signatures and digests can be found here:
> > >
> > > https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/
> > >
> > > The release artifacts are signed with the following key:
> > >
> > >
> > > https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_
> > plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
> > >
> > > The Nexus staging repository for this release is:
> > >
> > > https://repository.apache.org/content/repositories/orgapachestorm-1060
> > >
> > > Please vote on releasing this package as Apache Storm 1.0.6.
> > >
> > > When voting, please list the actions taken to verify the release.
> > >
> > > This vote will be open for at least 72 hours.
> > >
> > > [ ] +1 Release this package as Apache Storm 1.0.6
> > > [ ]  0 No opinion
> > > [ ] -1 Do not release this package because...
> > >
> > > Thanks to everyone who contributed to this release.
> > >
> > > -Taylor
> > >
> >
>

Re: [VOTE] Release Apache Storm 1.0.6 (rc3)

[Erik Weathers]

Something I just realized -- in the storm-kafka-client stomping into
1.0.x-branch PR, I backported a change to Fields.java which added a
serialVersionUID.
Could that potentially break topologies when you upgrade storm-core on the
servers (nimbus, workers) from 1.0.{1..5} to 1.0.6?   I'm not super
familiar with the serialization that occurs in Storm and whether that could
break people.

https://github.com/apache/storm/pull/2550/files#diff-71a428d508c4f5af0bfe3cc186e8edcf

- Erik

On Thu, Feb 8, 2018 at 1:25 PM, Bobby Evans  wrote:

> +1 I built the code from the git tag, ran all the unit tests (which passed
> the first time), and ran some tests on a single node cluster.
>
> It all looked good.
>
> - Bobby
>
> On Thu, Feb 8, 2018 at 1:22 PM P. Taylor Goetz  wrote:
>
> > This is a call to vote on releasing Apache Storm 1.0.6 (rc3)
> >
> > Full list of changes in this release:
> >
> >
> > https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.
> 0.6-rc3/RELEASE_NOTES.html
> >
> > The tag/commit to be voted upon is v1.0.6:
> >
> >
> > https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=
> e68365f9f947ddd1794b2edef2149fdfaa1590a2;hb=7993db01580ce62d44866dc00e0a72
> 66984638d0
> >
> > The source archive being voted upon can be found here:
> >
> >
> > https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.
> 0.6-rc3/apache-storm-1.0.6-src.tar.gz
> >
> > Other release files, signatures and digests can be found here:
> >
> > https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/
> >
> > The release artifacts are signed with the following key:
> >
> >
> > https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_
> plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
> >
> > The Nexus staging repository for this release is:
> >
> > https://repository.apache.org/content/repositories/orgapachestorm-1060
> >
> > Please vote on releasing this package as Apache Storm 1.0.6.
> >
> > When voting, please list the actions taken to verify the release.
> >
> > This vote will be open for at least 72 hours.
> >
> > [ ] +1 Release this package as Apache Storm 1.0.6
> > [ ]  0 No opinion
> > [ ] -1 Do not release this package because...
> >
> > Thanks to everyone who contributed to this release.
> >
> > -Taylor
> >
>

Re: [VOTE] Release Apache Storm 1.0.6 (rc3)

[Bobby Evans]

+1 I built the code from the git tag, ran all the unit tests (which passed
the first time), and ran some tests on a single node cluster.

It all looked good.

- Bobby

On Thu, Feb 8, 2018 at 1:22 PM P. Taylor Goetz  wrote:

> This is a call to vote on releasing Apache Storm 1.0.6 (rc3)
>
> Full list of changes in this release:
>
>
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/RELEASE_NOTES.html
>
> The tag/commit to be voted upon is v1.0.6:
>
>
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=e68365f9f947ddd1794b2edef2149fdfaa1590a2;hb=7993db01580ce62d44866dc00e0a7266984638d0
>
> The source archive being voted upon can be found here:
>
>
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/apache-storm-1.0.6-src.tar.gz
>
> Other release files, signatures and digests can be found here:
>
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/
>
> The release artifacts are signed with the following key:
>
>
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
>
> The Nexus staging repository for this release is:
>
> https://repository.apache.org/content/repositories/orgapachestorm-1060
>
> Please vote on releasing this package as Apache Storm 1.0.6.
>
> When voting, please list the actions taken to verify the release.
>
> This vote will be open for at least 72 hours.
>
> [ ] +1 Release this package as Apache Storm 1.0.6
> [ ]  0 No opinion
> [ ] -1 Do not release this package because...
>
> Thanks to everyone who contributed to this release.
>
> -Taylor
>