Re: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0 Release)

[封仲淹(纪君祥LongdaFeng)]

+1 as well.

(1) What we have been calling “0.11.0” will become the Storm 1.0 
release.[Longda] Agree.  we almost stop developing new feature after 0.11, so 
0.11 is one big version of clojure core, I prefer we give it one big milestone 
number 1.0 to this version. In fact, this version will import some big featuer.
(2) switch from "backtype.storm" to "org.apache.storm"[Longda] Agree, but what 
I concern is three point: 2.1  is the storm-compat solution can resolve all 
package name problem. Has any other system used this technology before.2.2 The 
develop speed, I wish we can finish this feature as fast as we can. 2.3 This 
will lead to a little hard to trace all file's history. Because all file will 
be rename and modify.

RegardsLongda
--From:Hugo Da 
Cruz Louro Send Time:2015年11月18日(星期三) 
07:57To:dev@storm.apache.org Subject:Re: [DISCUSS] 1.0 
Release (was Re: [DISCUSS] Initial 0.11.0 Release)
+1 as well. I support moving to the org.apache.storm package as early as 
possible and I am OK with storm-compat. My only concern with using storm-compat 
is if we are going to have to support it forever, or plan on dropping it after 
a certain release. Backwards compatibility is a valid concern but it can become 
very difficult to maintain older versions and at some point we must say that 
only topologies built after version X will run for version Y onwards (Y > X)

Hugo

> On Nov 16, 2015, at 5:23 PM, Harsha  wrote:
> 
> +1 on Bobby's suggestion on moving the packages to storm-compat and have
> it part of lib folder. 
> Moving 1.0 with org.apache.storm will make it easier in the future
> rather than wait for 2.0 release we should make 
> this change now and in 2.0 we can remove the storm-compat jar.
> 
> Thanks,
> Harsha
> 
> 
> On Thu, Nov 12, 2015, at 07:15 AM, Bobby Evans wrote:
>> I agree that having the old package names for a 1.0 release is a little
>> odd, but I also am nervous about breaking backwards compatibility for our
>> customers in a very significant way.  The upgrade for us from 0.9.x to
>> 0.10.x has gone fairly smoothly.  Most customers read the announcement
>> and recompiled their code against 0.10, but followed our instructions so
>> that their topologies could run on both 0.9.x and 0.10.x.  Having the
>> ability for a topology to run on both an old cluster and a new cluster is
>> very important for us, because of failover.  If we want to minimize
>> downtime we need to have the ability to fail a topology over from one
>> cluster to another, usually running on the other side of the
>> country/world.  For stability reasons we do not want to upgrade both
>> clusters at once, so we need to have confidence that a topology can run
>> on both clusters.  Maintaining two versions of a topology is a huge pain
>> as well.
>> Perhaps what we can do for 1.0 is to move all of the packages to
>> org.apache.storm, but provide a storm-compat package that will still have
>> the old user facing APIs in it, that are actually (for the most part)
>> subclasses/interfaces of the org.apache versions.  I am not sure this
>> will work perfectly, but I think I will give it a try.
>>  - Bobby 
>> 
>> 
>> On Thursday, November 12, 2015 9:04 AM, Aaron. Dossett
>>  wrote:
>> 
>> 
>> As a user/developer this sounds great.  The only item that gives me
>> pause
>> is #2.  Still seeing backtype.* package names would be unexpected (for
>> me)
>> for a 1.0 release.  That small reservation aside, I am +1 (non-binding).
>> 
>> On 11/11/15, 2:45 PM, "임정택"  wrote:
>> 
>>> +1
>>> 
>>> Jungtaek Lim (HeartSaVioR)
>>> 
>>> 2015-11-12 7:21 GMT+09:00 P. Taylor Goetz :
>>> 
 Changing subject in order to consolidate discussion of a 1.0 release in
 one thread (there was some additional discussion in the thread regarding
 the JStorm code merge).
 
 I just want to make sure I’m accurately capturing the sentiment of the
 community with regard to a 1.0 release. Please correct me if my summary
 seems off-base or jump in with an opinion.
 
 In summary:
 
 1. What we have been calling “0.11.0” will become the Storm 1.0 release.
 2. We will NOT be migrating package names for this release (i.e.
 “backtype.storm” —> “org.apache.storm”).
 3. Post 1.0 release we will go into feature freeze for core
 functionality
 to facilitate the JStorm merge.
 4. During the feature freeze only fixes for high priority bugs in core
 functionality will be accepted (no new features).
 5. During the feature freeze, enhancements to “external” modules can be
 accepted.
 6. We will stop using the “beta” flag in favor of purely numeric version
 numbers. Stable vs. non-stable (development) releases can be indicated
 on
 the download page.
 
 Do we all agree?
 
 -Taylor

Re: [Discusson] Storm System Tests

[封仲淹(纪君祥LongdaFeng)]

+1
By the way, Tong(王桐) can work for this. Tong is responsible for the 
automatically daily JStorm test, the only problem is that the automatically 
daily JStorm test is basing on Alibaba testing framework. Some of the 
components can't run on outside.
But we can share the test cases firstly. Then we will try to port the old test 
cases to the storm tests.

regardsLongda
--From:P. 
Taylor Goetz Send Time:2015年11月6日(星期五) 
12:12To:dev@storm.apache.org Subject:Re: [Discusson] 
Storm System Tests
+1
I think we should experiment with this. If it can serve us well, and we all 
agree, then we should consider adopting it.

From what I see:

* Icense is compatible
* fairly well documented.

What potentially worries me:

* Maintenance. Can we count on updates? Is the ducktape community open to 
accepting patches from us? If so, what would be the turnaround time for 
acceptance?

-Taylor

> On Nov 5, 2015, at 8:54 PM, Harsha  wrote:
> 
> The reason for suggesting ducktape not just used in apache kafka but
> also its getting security services integration like kdc and already has
> zookeeper. This framework can work with vagrant vms or amazon ec2 etc..
> 
>> On Thu, Nov 5, 2015, at 11:49 AM, Hugo Da Cruz Louro wrote:
>> Great, will make this a priority. Created a
>> JIRA ticket and
>> assigned it to me.
>> 
>> https://issues.apache.org/jira/browse/STORM-1179
>> 
>> 
>> On Nov 5, 2015, at 11:40 AM, Bobby Evans
>> > wrote:
>> 
>> Hugo,
>> 
>> I would love to see that happen.  It has been on my list for a while, but
>> I have never found the time to do it. I personally am +1 on this,
>> hopefully we can do this quickly in preparation for a 0.11.0 release.
>> 
>> - Bobby
>> 
>> 
>> 
>> On Thursday, November 5, 2015 1:37 PM, Hugo Da Cruz Louro
>> > wrote:
>> 
>> 
>> I a agree with these three levels of testing, and that at the very least
>> we should keep unit tests separated from the system/integration tests.
>> One huge advantage would be to quickly run unit tests that hopefully are
>> more predictable, and thus avoid intermittent test fails.
>> 
>> Bobby just mentioned but I had already in mind that it would be useful to
>> create different maven profiles for integration and unit tests. I have
>> done something similar in a different project and it works really well.
>> If we agree that it is something we want to implement here, I will create
>> a JIRA ticket for this and get it done. Please let me know.
>> 
>> Thanks,
>> Hugo
>> 
>>> On Nov 5, 2015, at 11:23 AM, Bobby Evans 
>>>> wrote:
>>> 
>>> I totally agree.  Too many of our "unit" tests are integration tests and 
>>>end up spinning up an entire local-mode cluster.
>>> I personally would like to see three levels of testing.
>>> 1) true unit tests.  They only touch the code under test and very little 
>>>else.  The should be what you get when you run mvn test2) integration tests. 
>>> These should spin up local mode clusters and modify configs/etc to get a 
>>>decent set of more white box tests.  The should run as a part of trivis-ci, 
>>>and probably should run by enabling a special profile.3) Sanity Integration 
>>>Tests.  ducktape looks like a great fit here.  I would love to see us spin 
>>>up an few different scenarios for testing, with/without security.  Talking 
>>>to Kafka, Hadoop(HBase, HDFS, Hive), redis, elastasearch, etc.
>>> These would be run frequently but not necessarily a part of CI initially.
>>> - Bobby
>>> 
>>> 
>>>   On Wednesday, November 4, 2015 7:21 PM, Harsha 
>>>> wrote:
>>> 
>>> 
>>> Hi All,
>>> As community we are growing and adding new and exciting
>>> features to Storm and also we've ever growing connector which
>>> only helps in storm adoption. One thing we've severely lacking
>>> is system tests. There are unit tests which acts as
>>> integration tests to storm-core but there are no system wide
>>> integration tests that can spin up kafka nodes and storm ,
>>> hbase and run a topology that can make sure the data is
>>> getting into hbase.
>>>   We at Hortonworks use our test topologies run some of these
>>>   tests but this integration code to spin up vms or nodes is hard
>>>   to share. In apache kafka we are using ducktape to write system
>>>   tests so far its working out good. If there are any other
>>>   frameworks you've in mind we can definitely take a look. But as
>>>   a community we need start looking at
>>>   https://github.com/confluentinc/ducktape or similar frameworks
>>>   to start writing systems tests. Ducktape makes it  easy to run
>>>   in a vm or