[GitHub] [storm] dandsager1 commented on a change in pull request #3092: STORM-3474 Large fragmented cluster scheduling time test

[GitBox]

dandsager1 commented on a change in pull request #3092: STORM-3474 Large 
fragmented cluster scheduling time test
URL: https://github.com/apache/storm/pull/3092#discussion_r309887863
 
 

 ##
 File path: 
storm-server/src/test/java/org/apache/storm/scheduler/resource/TestResourceAwareScheduler.java
 ##
 @@ -1067,6 +1068,215 @@ public void minCpuWorkerSplitFails() {
 assertFalse("Topo-1 unscheduled?", 
cluster.getAssignmentById(topo1.getId()) != null);
 }
 
+protected static class TimeBlockResult {
+List firstBlockTime;
+List lastBlockTime;
+
+TimeBlockResult() {
+firstBlockTime = new ArrayList<>();
+lastBlockTime = new ArrayList<>();
+}
+
+void append(TimeBlockResult other) {
+this.firstBlockTime.addAll(other.firstBlockTime);
+this.lastBlockTime.addAll(other.lastBlockTime);
+}
+}
+
+private long getMedianValue(List values) {
+final int numValues = values.size();
+assert(numValues % 2 == 1); // number of values must be odd to 
compute median as below
+List sortedValues = new ArrayList();
+sortedValues.addAll(values);
+Collections.sort(sortedValues);
+
+final int medianIndex = (int) Math.floor(numValues / 2);
+return sortedValues.get(medianIndex);
+}
+
+/**
+ * Check time to schedule a fragmented cluster using different strategies
+ *
+ * Simulate scheduling on a large production cluster. Find the ratio of 
time to schedule a set of topologies when
+ * the cluster is empty and when the cluster is nearly full. While the 
cluster has sufficient resources to schedule
+ * all topologies, when nearly full the cluster becomes fragmented and 
some topologies fail to schedule.
+ */
+@Test
+public void TestLargeFragmentedClusterScheduling() {
+/*
+Without fragmentation, the cluster would be able to schedule both 
topologies on each node. Let's call each node
+with both topologies scheduled as 100% scheduled.
+
+We schedule the cluster in 3 blocks of topologies, measuring the time 
to schedule the blocks. The first, middle
+and last blocks attempt to schedule the following 0-10%, 10%-90%, 
90%-100%. The last block has a number of
+scheduling failures due to cluster fragmentation and its time is 
dominated by attempting to evict topologies.
+
+Timing results for scheduling are noisy. As a result, we do multiple 
runs and use median values for FirstBlock
+and LastBlock times. (somewhere a statistician is crying). The ratio 
of LastBlock / FirstBlock remains fairly constant.
+
+
+TestLargeFragmentedClusterScheduling took 91118 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1734.0 ratio 
6.963855421686747
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1673.0 ratio 
7.78139534883721
+ConstraintSolverStrategy, FirstBlock 279.0, LastBlock 2200.0 ratio 
7.885304659498208
+
+TestLargeFragmentedClusterScheduling took 98455 ms
+DefaultResourceAwareStrategy, FirstBlock 266.0, LastBlock 1812.0 ratio 
6.81203007518797
+GenericResourceAwareStrategy, FirstBlock 235.0, LastBlock 1802.0 ratio 
7.6680851063829785
+ConstraintSolverStrategy, FirstBlock 304.0, LastBlock 2320.0 ratio 
7.631578947368421
+
+TestLargeFragmentedClusterScheduling took 97268 ms
+DefaultResourceAwareStrategy, FirstBlock 251.0, LastBlock 1826.0 ratio 
7.274900398406374
+GenericResourceAwareStrategy, FirstBlock 220.0, LastBlock 1719.0 ratio 
7.8136363636363635
+ConstraintSolverStrategy, FirstBlock 296.0, LastBlock 2469.0 ratio 
8.341216216216216
+
+TestLargeFragmentedClusterScheduling took 97963 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1788.0 ratio 
7.180722891566265
+GenericResourceAwareStrategy, FirstBlock 240.0, LastBlock 1796.0 ratio 
7.483
+ConstraintSolverStrategy, FirstBlock 328.0, LastBlock 2544.0 ratio 
7.7560975609756095
+
+TestLargeFragmentedClusterScheduling took 93106 ms
+DefaultResourceAwareStrategy, FirstBlock 258.0, LastBlock 1714.0 ratio 
6.6434108527131785
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1692.0 ratio 
7.869767441860465
+ConstraintSolverStrategy, FirstBlock 309.0, LastBlock 2342.0 ratio 
7.5792880258899675
+
+Choose the median value of the values above
+DefaultResourceAwareStrategy6.96
+GenericResourceAwareStrategy7.78
+ConstraintSolverStrategy7.75
+*/
+
+final int numNodes = 50;
+final int numRuns = 5;
+
+Map strategyToConfigs = new HashMap<>();
+strategyToConfigs.put(DefaultResourceAwareStrategy.class.getName(), 
createClusterConfig(10, 10, 0, null));
+

[GitHub] [storm] srdo commented on issue #3092: STORM-3474 Large fragmented cluster scheduling time test

[GitBox]

srdo commented on issue #3092: STORM-3474 Large fragmented cluster scheduling 
time test
URL: https://github.com/apache/storm/pull/3092#issuecomment-517442912
 
 
   +1 assuming tests pass. If the test running time becomes an issue, we can 
either try to make scheduling faster, or put it in a category of slow tests 
that aren't run by default, but do run on CI.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [storm] srdo commented on a change in pull request #3092: STORM-3474 Large fragmented cluster scheduling time test

[GitBox]

srdo commented on a change in pull request #3092: STORM-3474 Large fragmented 
cluster scheduling time test
URL: https://github.com/apache/storm/pull/3092#discussion_r309879437
 
 

 ##
 File path: 
storm-server/src/test/java/org/apache/storm/scheduler/resource/TestResourceAwareScheduler.java
 ##
 @@ -1067,6 +1068,215 @@ public void minCpuWorkerSplitFails() {
 assertFalse("Topo-1 unscheduled?", 
cluster.getAssignmentById(topo1.getId()) != null);
 }
 
+protected static class TimeBlockResult {
+List firstBlockTime;
+List lastBlockTime;
+
+TimeBlockResult() {
+firstBlockTime = new ArrayList<>();
+lastBlockTime = new ArrayList<>();
+}
+
+void append(TimeBlockResult other) {
+this.firstBlockTime.addAll(other.firstBlockTime);
+this.lastBlockTime.addAll(other.lastBlockTime);
+}
+}
+
+private long getMedianValue(List values) {
+final int numValues = values.size();
+assert(numValues % 2 == 1); // number of values must be odd to 
compute median as below
+List sortedValues = new ArrayList();
+sortedValues.addAll(values);
+Collections.sort(sortedValues);
+
+final int medianIndex = (int) Math.floor(numValues / 2);
+return sortedValues.get(medianIndex);
+}
+
+/**
+ * Check time to schedule a fragmented cluster using different strategies
+ *
+ * Simulate scheduling on a large production cluster. Find the ratio of 
time to schedule a set of topologies when
+ * the cluster is empty and when the cluster is nearly full. While the 
cluster has sufficient resources to schedule
+ * all topologies, when nearly full the cluster becomes fragmented and 
some topologies fail to schedule.
+ */
+@Test
+public void TestLargeFragmentedClusterScheduling() {
+/*
+Without fragmentation, the cluster would be able to schedule both 
topologies on each node. Let's call each node
+with both topologies scheduled as 100% scheduled.
+
+We schedule the cluster in 3 blocks of topologies, measuring the time 
to schedule the blocks. The first, middle
+and last blocks attempt to schedule the following 0-10%, 10%-90%, 
90%-100%. The last block has a number of
+scheduling failures due to cluster fragmentation and its time is 
dominated by attempting to evict topologies.
+
+Timing results for scheduling are noisy. As a result, we do multiple 
runs and use median values for FirstBlock
+and LastBlock times. (somewhere a statistician is crying). The ratio 
of LastBlock / FirstBlock remains fairly constant.
+
+
+TestLargeFragmentedClusterScheduling took 91118 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1734.0 ratio 
6.963855421686747
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1673.0 ratio 
7.78139534883721
+ConstraintSolverStrategy, FirstBlock 279.0, LastBlock 2200.0 ratio 
7.885304659498208
+
+TestLargeFragmentedClusterScheduling took 98455 ms
+DefaultResourceAwareStrategy, FirstBlock 266.0, LastBlock 1812.0 ratio 
6.81203007518797
+GenericResourceAwareStrategy, FirstBlock 235.0, LastBlock 1802.0 ratio 
7.6680851063829785
+ConstraintSolverStrategy, FirstBlock 304.0, LastBlock 2320.0 ratio 
7.631578947368421
+
+TestLargeFragmentedClusterScheduling took 97268 ms
+DefaultResourceAwareStrategy, FirstBlock 251.0, LastBlock 1826.0 ratio 
7.274900398406374
+GenericResourceAwareStrategy, FirstBlock 220.0, LastBlock 1719.0 ratio 
7.8136363636363635
+ConstraintSolverStrategy, FirstBlock 296.0, LastBlock 2469.0 ratio 
8.341216216216216
+
+TestLargeFragmentedClusterScheduling took 97963 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1788.0 ratio 
7.180722891566265
+GenericResourceAwareStrategy, FirstBlock 240.0, LastBlock 1796.0 ratio 
7.483
+ConstraintSolverStrategy, FirstBlock 328.0, LastBlock 2544.0 ratio 
7.7560975609756095
+
+TestLargeFragmentedClusterScheduling took 93106 ms
+DefaultResourceAwareStrategy, FirstBlock 258.0, LastBlock 1714.0 ratio 
6.6434108527131785
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1692.0 ratio 
7.869767441860465
+ConstraintSolverStrategy, FirstBlock 309.0, LastBlock 2342.0 ratio 
7.5792880258899675
+
+Choose the median value of the values above
+DefaultResourceAwareStrategy6.96
+GenericResourceAwareStrategy7.78
+ConstraintSolverStrategy7.75
+*/
+
+final int numNodes = 50;
+final int numRuns = 5;
+
+Map strategyToConfigs = new HashMap<>();
+strategyToConfigs.put(DefaultResourceAwareStrategy.class.getName(), 
createClusterConfig(10, 10, 0, null));
+strategyToConfigs.put(GenericResourceAwareStrategy.class.getName(), 

[GitHub] [storm] srdo commented on a change in pull request #3092: STORM-3474 Large fragmented cluster scheduling time test

[GitBox]

srdo commented on a change in pull request #3092: STORM-3474 Large fragmented 
cluster scheduling time test
URL: https://github.com/apache/storm/pull/3092#discussion_r309817930
 
 

 ##
 File path: 
storm-server/src/test/java/org/apache/storm/scheduler/resource/TestResourceAwareScheduler.java
 ##
 @@ -1067,6 +1068,208 @@ public void minCpuWorkerSplitFails() {
 assertFalse("Topo-1 unscheduled?", 
cluster.getAssignmentById(topo1.getId()) != null);
 }
 
+protected static class TimeBlockResult {
+long firstBlockTime;
+long lastBlockTime;
+}
+
+private long getMedianBlockTime(TimeBlockResult[] runResults, boolean 
firstBlock) {
+final int numRuns = runResults.length;
+assert(numRuns % 2 == 1); // number of runs must be odd to compute 
median as below
+long[] times = new long[numRuns];
+for (int i = 0; i < numRuns; ++i) {
+times[i] = firstBlock ? runResults[i].firstBlockTime : 
runResults[i].lastBlockTime;
+}
+Arrays.sort(times);
+
+final int medianIndex = (int) Math.floor(numRuns / 2);
+return times[medianIndex];
+}
+
+/**
+ * Check time to schedule a fragmented cluster using different strategies
+ *
+ * Simulate scheduling on a large production cluster. Find the ratio of 
time to schedule a set of topologies when
+ * the cluster is empty and when the cluster is nearly full. While the 
cluster has sufficient resources to schedule
+ * all topologies, when nearly full the cluster becomes fragmented and 
some topologies fail to schedule.
+ */
+@Test
+public void TestLargeFragmentedClusterScheduling() {
+/*
+Without fragmentation, the cluster would be able to schedule both 
topologies on each node. Let's call each node
+with both topologies scheduled as 100% scheduled.
+
+We schedule the cluster in 3 blocks of topologies, measuring the time 
to schedule the blocks. The first, middle
+and last blocks attempt to schedule the following 0-10%, 10%-90%, 
90%-100%. The last block has a number of
+scheduling failures due to cluster fragmentation and its time is 
dominated by attempting to evict topologies.
+
+Timing results for scheduling are noisy. As a result, we do multiple 
runs and use median values for FirstBlock
+and LastBlock times. (somewhere a statistician is crying). The ratio 
of LastBlock / FirstBlock remains fairly constant.
+
+
+TestLargeFragmentedClusterScheduling took 91118 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1734.0 ratio 
6.963855421686747
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1673.0 ratio 
7.78139534883721
+ConstraintSolverStrategy, FirstBlock 279.0, LastBlock 2200.0 ratio 
7.885304659498208
+
+TestLargeFragmentedClusterScheduling took 98455 ms
+DefaultResourceAwareStrategy, FirstBlock 266.0, LastBlock 1812.0 ratio 
6.81203007518797
+GenericResourceAwareStrategy, FirstBlock 235.0, LastBlock 1802.0 ratio 
7.6680851063829785
+ConstraintSolverStrategy, FirstBlock 304.0, LastBlock 2320.0 ratio 
7.631578947368421
+
+TestLargeFragmentedClusterScheduling took 97268 ms
+DefaultResourceAwareStrategy, FirstBlock 251.0, LastBlock 1826.0 ratio 
7.274900398406374
+GenericResourceAwareStrategy, FirstBlock 220.0, LastBlock 1719.0 ratio 
7.8136363636363635
+ConstraintSolverStrategy, FirstBlock 296.0, LastBlock 2469.0 ratio 
8.341216216216216
+
+TestLargeFragmentedClusterScheduling took 97963 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1788.0 ratio 
7.180722891566265
+GenericResourceAwareStrategy, FirstBlock 240.0, LastBlock 1796.0 ratio 
7.483
+ConstraintSolverStrategy, FirstBlock 328.0, LastBlock 2544.0 ratio 
7.7560975609756095
+
+TestLargeFragmentedClusterScheduling took 93106 ms
+DefaultResourceAwareStrategy, FirstBlock 258.0, LastBlock 1714.0 ratio 
6.6434108527131785
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1692.0 ratio 
7.869767441860465
+ConstraintSolverStrategy, FirstBlock 309.0, LastBlock 2342.0 ratio 
7.5792880258899675
+
+Choose the median value of the values above
+DefaultResourceAwareStrategy6.96
+GenericResourceAwareStrategy7.78
+ConstraintSolverStrategy7.75
+*/
+
+final int numNodes = 500;
+final String[] strategies = new String[]{
+DefaultResourceAwareStrategy.class.getName(),
+GenericResourceAwareStrategy.class.getName(),
+ConstraintSolverStrategy.class.getName()
+};
+
+final int numStrategies = strategies.length;
+final int numRuns = 5;
+TimeBlockResult testResults[][] = new 
TimeBlockResult[numStrategies][numRuns];
+
+// Get first and last block times for 

[GitHub] [storm] dandsager1 commented on issue #3092: STORM-3474 Large fragmented cluster scheduling time test

[GitBox]

dandsager1 commented on issue #3092: STORM-3474 Large fragmented cluster 
scheduling time test
URL: https://github.com/apache/storm/pull/3092#issuecomment-517365106
 
 
   The intent is to ensure that adverse changes to scheduling are not 
discovered at deploy time. It could also be used as a tool for making 
scheduling faster.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [storm] dandsager1 commented on a change in pull request #3092: STORM-3474 Large fragmented cluster scheduling time test

[GitBox]

dandsager1 commented on a change in pull request #3092: STORM-3474 Large 
fragmented cluster scheduling time test
URL: https://github.com/apache/storm/pull/3092#discussion_r309790103
 
 

 ##
 File path: 
storm-server/src/test/java/org/apache/storm/scheduler/resource/TestResourceAwareScheduler.java
 ##
 @@ -1067,6 +1068,208 @@ public void minCpuWorkerSplitFails() {
 assertFalse("Topo-1 unscheduled?", 
cluster.getAssignmentById(topo1.getId()) != null);
 }
 
+protected static class TimeBlockResult {
+long firstBlockTime;
+long lastBlockTime;
+}
+
+private long getMedianBlockTime(TimeBlockResult[] runResults, boolean 
firstBlock) {
+final int numRuns = runResults.length;
+assert(numRuns % 2 == 1); // number of runs must be odd to compute 
median as below
+long[] times = new long[numRuns];
+for (int i = 0; i < numRuns; ++i) {
+times[i] = firstBlock ? runResults[i].firstBlockTime : 
runResults[i].lastBlockTime;
+}
+Arrays.sort(times);
+
+final int medianIndex = (int) Math.floor(numRuns / 2);
+return times[medianIndex];
+}
+
+/**
+ * Check time to schedule a fragmented cluster using different strategies
+ *
+ * Simulate scheduling on a large production cluster. Find the ratio of 
time to schedule a set of topologies when
+ * the cluster is empty and when the cluster is nearly full. While the 
cluster has sufficient resources to schedule
+ * all topologies, when nearly full the cluster becomes fragmented and 
some topologies fail to schedule.
+ */
+@Test
+public void TestLargeFragmentedClusterScheduling() {
+/*
+Without fragmentation, the cluster would be able to schedule both 
topologies on each node. Let's call each node
+with both topologies scheduled as 100% scheduled.
+
+We schedule the cluster in 3 blocks of topologies, measuring the time 
to schedule the blocks. The first, middle
+and last blocks attempt to schedule the following 0-10%, 10%-90%, 
90%-100%. The last block has a number of
+scheduling failures due to cluster fragmentation and its time is 
dominated by attempting to evict topologies.
+
+Timing results for scheduling are noisy. As a result, we do multiple 
runs and use median values for FirstBlock
+and LastBlock times. (somewhere a statistician is crying). The ratio 
of LastBlock / FirstBlock remains fairly constant.
+
+
+TestLargeFragmentedClusterScheduling took 91118 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1734.0 ratio 
6.963855421686747
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1673.0 ratio 
7.78139534883721
+ConstraintSolverStrategy, FirstBlock 279.0, LastBlock 2200.0 ratio 
7.885304659498208
+
+TestLargeFragmentedClusterScheduling took 98455 ms
+DefaultResourceAwareStrategy, FirstBlock 266.0, LastBlock 1812.0 ratio 
6.81203007518797
+GenericResourceAwareStrategy, FirstBlock 235.0, LastBlock 1802.0 ratio 
7.6680851063829785
+ConstraintSolverStrategy, FirstBlock 304.0, LastBlock 2320.0 ratio 
7.631578947368421
+
+TestLargeFragmentedClusterScheduling took 97268 ms
+DefaultResourceAwareStrategy, FirstBlock 251.0, LastBlock 1826.0 ratio 
7.274900398406374
+GenericResourceAwareStrategy, FirstBlock 220.0, LastBlock 1719.0 ratio 
7.8136363636363635
+ConstraintSolverStrategy, FirstBlock 296.0, LastBlock 2469.0 ratio 
8.341216216216216
+
+TestLargeFragmentedClusterScheduling took 97963 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1788.0 ratio 
7.180722891566265
+GenericResourceAwareStrategy, FirstBlock 240.0, LastBlock 1796.0 ratio 
7.483
+ConstraintSolverStrategy, FirstBlock 328.0, LastBlock 2544.0 ratio 
7.7560975609756095
+
+TestLargeFragmentedClusterScheduling took 93106 ms
+DefaultResourceAwareStrategy, FirstBlock 258.0, LastBlock 1714.0 ratio 
6.6434108527131785
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1692.0 ratio 
7.869767441860465
+ConstraintSolverStrategy, FirstBlock 309.0, LastBlock 2342.0 ratio 
7.5792880258899675
+
+Choose the median value of the values above
+DefaultResourceAwareStrategy6.96
+GenericResourceAwareStrategy7.78
+ConstraintSolverStrategy7.75
+*/
+
+final int numNodes = 500;
+final String[] strategies = new String[]{
+DefaultResourceAwareStrategy.class.getName(),
+GenericResourceAwareStrategy.class.getName(),
+ConstraintSolverStrategy.class.getName()
+};
+
+final int numStrategies = strategies.length;
+final int numRuns = 5;
+TimeBlockResult testResults[][] = new 
TimeBlockResult[numStrategies][numRuns];
+
+// Get first and last block 

[GitHub] [storm] dandsager1 commented on a change in pull request #3092: STORM-3474 Large fragmented cluster scheduling time test

[GitBox]

dandsager1 commented on a change in pull request #3092: STORM-3474 Large 
fragmented cluster scheduling time test
URL: https://github.com/apache/storm/pull/3092#discussion_r309789628
 
 

 ##
 File path: 
storm-server/src/test/java/org/apache/storm/scheduler/resource/TestResourceAwareScheduler.java
 ##
 @@ -1067,6 +1068,208 @@ public void minCpuWorkerSplitFails() {
 assertFalse("Topo-1 unscheduled?", 
cluster.getAssignmentById(topo1.getId()) != null);
 }
 
+protected static class TimeBlockResult {
+long firstBlockTime;
+long lastBlockTime;
+}
+
+private long getMedianBlockTime(TimeBlockResult[] runResults, boolean 
firstBlock) {
+final int numRuns = runResults.length;
+assert(numRuns % 2 == 1); // number of runs must be odd to compute 
median as below
+long[] times = new long[numRuns];
+for (int i = 0; i < numRuns; ++i) {
+times[i] = firstBlock ? runResults[i].firstBlockTime : 
runResults[i].lastBlockTime;
+}
+Arrays.sort(times);
+
+final int medianIndex = (int) Math.floor(numRuns / 2);
+return times[medianIndex];
+}
+
+/**
+ * Check time to schedule a fragmented cluster using different strategies
+ *
+ * Simulate scheduling on a large production cluster. Find the ratio of 
time to schedule a set of topologies when
+ * the cluster is empty and when the cluster is nearly full. While the 
cluster has sufficient resources to schedule
+ * all topologies, when nearly full the cluster becomes fragmented and 
some topologies fail to schedule.
+ */
+@Test
+public void TestLargeFragmentedClusterScheduling() {
+/*
+Without fragmentation, the cluster would be able to schedule both 
topologies on each node. Let's call each node
+with both topologies scheduled as 100% scheduled.
+
+We schedule the cluster in 3 blocks of topologies, measuring the time 
to schedule the blocks. The first, middle
+and last blocks attempt to schedule the following 0-10%, 10%-90%, 
90%-100%. The last block has a number of
+scheduling failures due to cluster fragmentation and its time is 
dominated by attempting to evict topologies.
+
+Timing results for scheduling are noisy. As a result, we do multiple 
runs and use median values for FirstBlock
+and LastBlock times. (somewhere a statistician is crying). The ratio 
of LastBlock / FirstBlock remains fairly constant.
+
+
+TestLargeFragmentedClusterScheduling took 91118 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1734.0 ratio 
6.963855421686747
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1673.0 ratio 
7.78139534883721
+ConstraintSolverStrategy, FirstBlock 279.0, LastBlock 2200.0 ratio 
7.885304659498208
+
+TestLargeFragmentedClusterScheduling took 98455 ms
+DefaultResourceAwareStrategy, FirstBlock 266.0, LastBlock 1812.0 ratio 
6.81203007518797
+GenericResourceAwareStrategy, FirstBlock 235.0, LastBlock 1802.0 ratio 
7.6680851063829785
+ConstraintSolverStrategy, FirstBlock 304.0, LastBlock 2320.0 ratio 
7.631578947368421
+
+TestLargeFragmentedClusterScheduling took 97268 ms
+DefaultResourceAwareStrategy, FirstBlock 251.0, LastBlock 1826.0 ratio 
7.274900398406374
+GenericResourceAwareStrategy, FirstBlock 220.0, LastBlock 1719.0 ratio 
7.8136363636363635
+ConstraintSolverStrategy, FirstBlock 296.0, LastBlock 2469.0 ratio 
8.341216216216216
+
+TestLargeFragmentedClusterScheduling took 97963 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1788.0 ratio 
7.180722891566265
+GenericResourceAwareStrategy, FirstBlock 240.0, LastBlock 1796.0 ratio 
7.483
+ConstraintSolverStrategy, FirstBlock 328.0, LastBlock 2544.0 ratio 
7.7560975609756095
+
+TestLargeFragmentedClusterScheduling took 93106 ms
+DefaultResourceAwareStrategy, FirstBlock 258.0, LastBlock 1714.0 ratio 
6.6434108527131785
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1692.0 ratio 
7.869767441860465
+ConstraintSolverStrategy, FirstBlock 309.0, LastBlock 2342.0 ratio 
7.5792880258899675
+
+Choose the median value of the values above
+DefaultResourceAwareStrategy6.96
+GenericResourceAwareStrategy7.78
+ConstraintSolverStrategy7.75
+*/
+
+final int numNodes = 500;
+final String[] strategies = new String[]{
+DefaultResourceAwareStrategy.class.getName(),
+GenericResourceAwareStrategy.class.getName(),
+ConstraintSolverStrategy.class.getName()
+};
+
+final int numStrategies = strategies.length;
+final int numRuns = 5;
+TimeBlockResult testResults[][] = new 
TimeBlockResult[numStrategies][numRuns];
+
+// Get first and last block 

Re: [DISCUSS] Create a checklist for testing new Storm release

[Ethan Li]

Right. I found this 
http://www.apache.org/dev/release-distribution.html#sigs-and-sums 


In the new release, we should drop md5 checksum file. 


> On Aug 1, 2019, at 4:25 AM, Stig Rohde Døssing  wrote:
> 
> The list looks good. I think we should drop the .md5 files, the ASF have
> been telling people not to use them for a while.
> 
> I don't know that everyone needs to do it, but someone should check that
> the license files are up to date, and that we're not including any
> dependencies with incompatible licenses (
> https://apache.org/legal/resolved.html). Ideally we can automate most of
> the work.
> 
> Den man. 29. jul. 2019 kl. 23.56 skrev Ethan Li :
> 
>> 
>> Per Hugo’s suggestion, we should probably document the testings that every
>> contributors/committers should do to guarantee a stable release. It also
>> helps creating a check form or email template.
>> 
>> 
>> The testings I did for 2.0.0 release are
>> 
>> 1. Verify files such as *.asc, *.md5, *.sha512
>> 2. Build Storm source code and run unit tests; create a Storm distribution.
>> 3. Set up a standalone cluster using apache-storm-xxx.zip,
>> apache-storm-xxx.tar.gz, the Storm distribution created from step 2,
>> separately
>> 4. Launch WordCountTopology and ThroughputVsLatency topology and check
>> logs, UI metrics
>> 5. Test basic UI functionalities such as jstack, heap dump, deactivate,
>> activate, rebalance, change log level, kill topology
>> 
>> 
>> Please suggest anything that should be added so that we can document a
>> base checklist that everyone can follow to test a new Storm release.
>> 
>> 
>> Thanks,
>> Ethan

[GitHub] [storm] srdo commented on a change in pull request #3092: STORM-3474 Large fragmented cluster scheduling time test

[GitBox]

srdo commented on a change in pull request #3092: STORM-3474 Large fragmented 
cluster scheduling time test
URL: https://github.com/apache/storm/pull/3092#discussion_r309610927
 
 

 ##
 File path: 
storm-server/src/test/java/org/apache/storm/scheduler/resource/TestResourceAwareScheduler.java
 ##
 @@ -1067,6 +1068,208 @@ public void minCpuWorkerSplitFails() {
 assertFalse("Topo-1 unscheduled?", 
cluster.getAssignmentById(topo1.getId()) != null);
 }
 
+protected static class TimeBlockResult {
+long firstBlockTime;
+long lastBlockTime;
+}
+
+private long getMedianBlockTime(TimeBlockResult[] runResults, boolean 
firstBlock) {
+final int numRuns = runResults.length;
+assert(numRuns % 2 == 1); // number of runs must be odd to compute 
median as below
+long[] times = new long[numRuns];
+for (int i = 0; i < numRuns; ++i) {
+times[i] = firstBlock ? runResults[i].firstBlockTime : 
runResults[i].lastBlockTime;
+}
+Arrays.sort(times);
+
+final int medianIndex = (int) Math.floor(numRuns / 2);
+return times[medianIndex];
+}
+
+/**
+ * Check time to schedule a fragmented cluster using different strategies
+ *
+ * Simulate scheduling on a large production cluster. Find the ratio of 
time to schedule a set of topologies when
+ * the cluster is empty and when the cluster is nearly full. While the 
cluster has sufficient resources to schedule
+ * all topologies, when nearly full the cluster becomes fragmented and 
some topologies fail to schedule.
+ */
+@Test
+public void TestLargeFragmentedClusterScheduling() {
+/*
+Without fragmentation, the cluster would be able to schedule both 
topologies on each node. Let's call each node
+with both topologies scheduled as 100% scheduled.
+
+We schedule the cluster in 3 blocks of topologies, measuring the time 
to schedule the blocks. The first, middle
+and last blocks attempt to schedule the following 0-10%, 10%-90%, 
90%-100%. The last block has a number of
+scheduling failures due to cluster fragmentation and its time is 
dominated by attempting to evict topologies.
+
+Timing results for scheduling are noisy. As a result, we do multiple 
runs and use median values for FirstBlock
+and LastBlock times. (somewhere a statistician is crying). The ratio 
of LastBlock / FirstBlock remains fairly constant.
+
+
+TestLargeFragmentedClusterScheduling took 91118 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1734.0 ratio 
6.963855421686747
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1673.0 ratio 
7.78139534883721
+ConstraintSolverStrategy, FirstBlock 279.0, LastBlock 2200.0 ratio 
7.885304659498208
+
+TestLargeFragmentedClusterScheduling took 98455 ms
+DefaultResourceAwareStrategy, FirstBlock 266.0, LastBlock 1812.0 ratio 
6.81203007518797
+GenericResourceAwareStrategy, FirstBlock 235.0, LastBlock 1802.0 ratio 
7.6680851063829785
+ConstraintSolverStrategy, FirstBlock 304.0, LastBlock 2320.0 ratio 
7.631578947368421
+
+TestLargeFragmentedClusterScheduling took 97268 ms
+DefaultResourceAwareStrategy, FirstBlock 251.0, LastBlock 1826.0 ratio 
7.274900398406374
+GenericResourceAwareStrategy, FirstBlock 220.0, LastBlock 1719.0 ratio 
7.8136363636363635
+ConstraintSolverStrategy, FirstBlock 296.0, LastBlock 2469.0 ratio 
8.341216216216216
+
+TestLargeFragmentedClusterScheduling took 97963 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1788.0 ratio 
7.180722891566265
+GenericResourceAwareStrategy, FirstBlock 240.0, LastBlock 1796.0 ratio 
7.483
+ConstraintSolverStrategy, FirstBlock 328.0, LastBlock 2544.0 ratio 
7.7560975609756095
+
+TestLargeFragmentedClusterScheduling took 93106 ms
+DefaultResourceAwareStrategy, FirstBlock 258.0, LastBlock 1714.0 ratio 
6.6434108527131785
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1692.0 ratio 
7.869767441860465
+ConstraintSolverStrategy, FirstBlock 309.0, LastBlock 2342.0 ratio 
7.5792880258899675
+
+Choose the median value of the values above
+DefaultResourceAwareStrategy6.96
+GenericResourceAwareStrategy7.78
+ConstraintSolverStrategy7.75
+*/
+
+final int numNodes = 500;
+final String[] strategies = new String[]{
+DefaultResourceAwareStrategy.class.getName(),
+GenericResourceAwareStrategy.class.getName(),
+ConstraintSolverStrategy.class.getName()
+};
+
+final int numStrategies = strategies.length;
+final int numRuns = 5;
+TimeBlockResult testResults[][] = new 
TimeBlockResult[numStrategies][numRuns];
+
+// Get first and last block times for 

[GitHub] [storm] srdo commented on a change in pull request #3092: STORM-3474 Large fragmented cluster scheduling time test

[GitBox]

srdo commented on a change in pull request #3092: STORM-3474 Large fragmented 
cluster scheduling time test
URL: https://github.com/apache/storm/pull/3092#discussion_r309607164
 
 

 ##
 File path: 
storm-server/src/test/java/org/apache/storm/scheduler/resource/TestResourceAwareScheduler.java
 ##
 @@ -1067,6 +1068,208 @@ public void minCpuWorkerSplitFails() {
 assertFalse("Topo-1 unscheduled?", 
cluster.getAssignmentById(topo1.getId()) != null);
 }
 
+protected static class TimeBlockResult {
+long firstBlockTime;
+long lastBlockTime;
+}
+
+private long getMedianBlockTime(TimeBlockResult[] runResults, boolean 
firstBlock) {
+final int numRuns = runResults.length;
+assert(numRuns % 2 == 1); // number of runs must be odd to compute 
median as below
+long[] times = new long[numRuns];
+for (int i = 0; i < numRuns; ++i) {
+times[i] = firstBlock ? runResults[i].firstBlockTime : 
runResults[i].lastBlockTime;
+}
+Arrays.sort(times);
+
+final int medianIndex = (int) Math.floor(numRuns / 2);
+return times[medianIndex];
+}
+
+/**
+ * Check time to schedule a fragmented cluster using different strategies
+ *
+ * Simulate scheduling on a large production cluster. Find the ratio of 
time to schedule a set of topologies when
+ * the cluster is empty and when the cluster is nearly full. While the 
cluster has sufficient resources to schedule
+ * all topologies, when nearly full the cluster becomes fragmented and 
some topologies fail to schedule.
+ */
+@Test
+public void TestLargeFragmentedClusterScheduling() {
+/*
+Without fragmentation, the cluster would be able to schedule both 
topologies on each node. Let's call each node
+with both topologies scheduled as 100% scheduled.
+
+We schedule the cluster in 3 blocks of topologies, measuring the time 
to schedule the blocks. The first, middle
+and last blocks attempt to schedule the following 0-10%, 10%-90%, 
90%-100%. The last block has a number of
+scheduling failures due to cluster fragmentation and its time is 
dominated by attempting to evict topologies.
+
+Timing results for scheduling are noisy. As a result, we do multiple 
runs and use median values for FirstBlock
+and LastBlock times. (somewhere a statistician is crying). The ratio 
of LastBlock / FirstBlock remains fairly constant.
+
+
+TestLargeFragmentedClusterScheduling took 91118 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1734.0 ratio 
6.963855421686747
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1673.0 ratio 
7.78139534883721
+ConstraintSolverStrategy, FirstBlock 279.0, LastBlock 2200.0 ratio 
7.885304659498208
+
+TestLargeFragmentedClusterScheduling took 98455 ms
+DefaultResourceAwareStrategy, FirstBlock 266.0, LastBlock 1812.0 ratio 
6.81203007518797
+GenericResourceAwareStrategy, FirstBlock 235.0, LastBlock 1802.0 ratio 
7.6680851063829785
+ConstraintSolverStrategy, FirstBlock 304.0, LastBlock 2320.0 ratio 
7.631578947368421
+
+TestLargeFragmentedClusterScheduling took 97268 ms
+DefaultResourceAwareStrategy, FirstBlock 251.0, LastBlock 1826.0 ratio 
7.274900398406374
+GenericResourceAwareStrategy, FirstBlock 220.0, LastBlock 1719.0 ratio 
7.8136363636363635
+ConstraintSolverStrategy, FirstBlock 296.0, LastBlock 2469.0 ratio 
8.341216216216216
+
+TestLargeFragmentedClusterScheduling took 97963 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1788.0 ratio 
7.180722891566265
+GenericResourceAwareStrategy, FirstBlock 240.0, LastBlock 1796.0 ratio 
7.483
+ConstraintSolverStrategy, FirstBlock 328.0, LastBlock 2544.0 ratio 
7.7560975609756095
+
+TestLargeFragmentedClusterScheduling took 93106 ms
+DefaultResourceAwareStrategy, FirstBlock 258.0, LastBlock 1714.0 ratio 
6.6434108527131785
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1692.0 ratio 
7.869767441860465
+ConstraintSolverStrategy, FirstBlock 309.0, LastBlock 2342.0 ratio 
7.5792880258899675
+
+Choose the median value of the values above
+DefaultResourceAwareStrategy6.96
+GenericResourceAwareStrategy7.78
+ConstraintSolverStrategy7.75
+*/
+
+final int numNodes = 500;
+final String[] strategies = new String[]{
+DefaultResourceAwareStrategy.class.getName(),
+GenericResourceAwareStrategy.class.getName(),
+ConstraintSolverStrategy.class.getName()
+};
+
+final int numStrategies = strategies.length;
+final int numRuns = 5;
+TimeBlockResult testResults[][] = new 
TimeBlockResult[numStrategies][numRuns];
+
+// Get first and last block times for 

[GitHub] [storm] srdo commented on a change in pull request #3092: STORM-3474 Large fragmented cluster scheduling time test

[GitBox]

srdo commented on a change in pull request #3092: STORM-3474 Large fragmented 
cluster scheduling time test
URL: https://github.com/apache/storm/pull/3092#discussion_r309606484
 
 

 ##
 File path: 
storm-server/src/test/java/org/apache/storm/scheduler/resource/TestResourceAwareScheduler.java
 ##
 @@ -1067,6 +1068,208 @@ public void minCpuWorkerSplitFails() {
 assertFalse("Topo-1 unscheduled?", 
cluster.getAssignmentById(topo1.getId()) != null);
 }
 
+protected static class TimeBlockResult {
+long firstBlockTime;
+long lastBlockTime;
+}
+
+private long getMedianBlockTime(TimeBlockResult[] runResults, boolean 
firstBlock) {
+final int numRuns = runResults.length;
+assert(numRuns % 2 == 1); // number of runs must be odd to compute 
median as below
+long[] times = new long[numRuns];
+for (int i = 0; i < numRuns; ++i) {
+times[i] = firstBlock ? runResults[i].firstBlockTime : 
runResults[i].lastBlockTime;
+}
+Arrays.sort(times);
+
+final int medianIndex = (int) Math.floor(numRuns / 2);
+return times[medianIndex];
+}
+
+/**
+ * Check time to schedule a fragmented cluster using different strategies
+ *
+ * Simulate scheduling on a large production cluster. Find the ratio of 
time to schedule a set of topologies when
+ * the cluster is empty and when the cluster is nearly full. While the 
cluster has sufficient resources to schedule
+ * all topologies, when nearly full the cluster becomes fragmented and 
some topologies fail to schedule.
+ */
+@Test
+public void TestLargeFragmentedClusterScheduling() {
+/*
+Without fragmentation, the cluster would be able to schedule both 
topologies on each node. Let's call each node
+with both topologies scheduled as 100% scheduled.
+
+We schedule the cluster in 3 blocks of topologies, measuring the time 
to schedule the blocks. The first, middle
+and last blocks attempt to schedule the following 0-10%, 10%-90%, 
90%-100%. The last block has a number of
+scheduling failures due to cluster fragmentation and its time is 
dominated by attempting to evict topologies.
+
+Timing results for scheduling are noisy. As a result, we do multiple 
runs and use median values for FirstBlock
+and LastBlock times. (somewhere a statistician is crying). The ratio 
of LastBlock / FirstBlock remains fairly constant.
+
+
+TestLargeFragmentedClusterScheduling took 91118 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1734.0 ratio 
6.963855421686747
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1673.0 ratio 
7.78139534883721
+ConstraintSolverStrategy, FirstBlock 279.0, LastBlock 2200.0 ratio 
7.885304659498208
+
+TestLargeFragmentedClusterScheduling took 98455 ms
+DefaultResourceAwareStrategy, FirstBlock 266.0, LastBlock 1812.0 ratio 
6.81203007518797
+GenericResourceAwareStrategy, FirstBlock 235.0, LastBlock 1802.0 ratio 
7.6680851063829785
+ConstraintSolverStrategy, FirstBlock 304.0, LastBlock 2320.0 ratio 
7.631578947368421
+
+TestLargeFragmentedClusterScheduling took 97268 ms
+DefaultResourceAwareStrategy, FirstBlock 251.0, LastBlock 1826.0 ratio 
7.274900398406374
+GenericResourceAwareStrategy, FirstBlock 220.0, LastBlock 1719.0 ratio 
7.8136363636363635
+ConstraintSolverStrategy, FirstBlock 296.0, LastBlock 2469.0 ratio 
8.341216216216216
+
+TestLargeFragmentedClusterScheduling took 97963 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1788.0 ratio 
7.180722891566265
+GenericResourceAwareStrategy, FirstBlock 240.0, LastBlock 1796.0 ratio 
7.483
+ConstraintSolverStrategy, FirstBlock 328.0, LastBlock 2544.0 ratio 
7.7560975609756095
+
+TestLargeFragmentedClusterScheduling took 93106 ms
+DefaultResourceAwareStrategy, FirstBlock 258.0, LastBlock 1714.0 ratio 
6.6434108527131785
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1692.0 ratio 
7.869767441860465
+ConstraintSolverStrategy, FirstBlock 309.0, LastBlock 2342.0 ratio 
7.5792880258899675
+
+Choose the median value of the values above
+DefaultResourceAwareStrategy6.96
+GenericResourceAwareStrategy7.78
+ConstraintSolverStrategy7.75
+*/
+
+final int numNodes = 500;
+final String[] strategies = new String[]{
+DefaultResourceAwareStrategy.class.getName(),
+GenericResourceAwareStrategy.class.getName(),
+ConstraintSolverStrategy.class.getName()
+};
+
+final int numStrategies = strategies.length;
+final int numRuns = 5;
+TimeBlockResult testResults[][] = new 
TimeBlockResult[numStrategies][numRuns];
+
+// Get first and last block times for 

[GitHub] [storm] srdo commented on a change in pull request #3092: STORM-3474 Large fragmented cluster scheduling time test

[GitBox]

srdo commented on a change in pull request #3092: STORM-3474 Large fragmented 
cluster scheduling time test
URL: https://github.com/apache/storm/pull/3092#discussion_r309609442
 
 

 ##
 File path: 
storm-server/src/test/java/org/apache/storm/scheduler/resource/TestResourceAwareScheduler.java
 ##
 @@ -1067,6 +1068,208 @@ public void minCpuWorkerSplitFails() {
 assertFalse("Topo-1 unscheduled?", 
cluster.getAssignmentById(topo1.getId()) != null);
 }
 
+protected static class TimeBlockResult {
+long firstBlockTime;
+long lastBlockTime;
+}
+
+private long getMedianBlockTime(TimeBlockResult[] runResults, boolean 
firstBlock) {
+final int numRuns = runResults.length;
+assert(numRuns % 2 == 1); // number of runs must be odd to compute 
median as below
+long[] times = new long[numRuns];
+for (int i = 0; i < numRuns; ++i) {
+times[i] = firstBlock ? runResults[i].firstBlockTime : 
runResults[i].lastBlockTime;
+}
+Arrays.sort(times);
+
+final int medianIndex = (int) Math.floor(numRuns / 2);
+return times[medianIndex];
+}
+
+/**
+ * Check time to schedule a fragmented cluster using different strategies
+ *
+ * Simulate scheduling on a large production cluster. Find the ratio of 
time to schedule a set of topologies when
+ * the cluster is empty and when the cluster is nearly full. While the 
cluster has sufficient resources to schedule
+ * all topologies, when nearly full the cluster becomes fragmented and 
some topologies fail to schedule.
+ */
+@Test
+public void TestLargeFragmentedClusterScheduling() {
+/*
+Without fragmentation, the cluster would be able to schedule both 
topologies on each node. Let's call each node
+with both topologies scheduled as 100% scheduled.
+
+We schedule the cluster in 3 blocks of topologies, measuring the time 
to schedule the blocks. The first, middle
+and last blocks attempt to schedule the following 0-10%, 10%-90%, 
90%-100%. The last block has a number of
+scheduling failures due to cluster fragmentation and its time is 
dominated by attempting to evict topologies.
+
+Timing results for scheduling are noisy. As a result, we do multiple 
runs and use median values for FirstBlock
+and LastBlock times. (somewhere a statistician is crying). The ratio 
of LastBlock / FirstBlock remains fairly constant.
+
+
+TestLargeFragmentedClusterScheduling took 91118 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1734.0 ratio 
6.963855421686747
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1673.0 ratio 
7.78139534883721
+ConstraintSolverStrategy, FirstBlock 279.0, LastBlock 2200.0 ratio 
7.885304659498208
+
+TestLargeFragmentedClusterScheduling took 98455 ms
+DefaultResourceAwareStrategy, FirstBlock 266.0, LastBlock 1812.0 ratio 
6.81203007518797
+GenericResourceAwareStrategy, FirstBlock 235.0, LastBlock 1802.0 ratio 
7.6680851063829785
+ConstraintSolverStrategy, FirstBlock 304.0, LastBlock 2320.0 ratio 
7.631578947368421
+
+TestLargeFragmentedClusterScheduling took 97268 ms
+DefaultResourceAwareStrategy, FirstBlock 251.0, LastBlock 1826.0 ratio 
7.274900398406374
+GenericResourceAwareStrategy, FirstBlock 220.0, LastBlock 1719.0 ratio 
7.8136363636363635
+ConstraintSolverStrategy, FirstBlock 296.0, LastBlock 2469.0 ratio 
8.341216216216216
+
+TestLargeFragmentedClusterScheduling took 97963 ms
+DefaultResourceAwareStrategy, FirstBlock 249.0, LastBlock 1788.0 ratio 
7.180722891566265
+GenericResourceAwareStrategy, FirstBlock 240.0, LastBlock 1796.0 ratio 
7.483
+ConstraintSolverStrategy, FirstBlock 328.0, LastBlock 2544.0 ratio 
7.7560975609756095
+
+TestLargeFragmentedClusterScheduling took 93106 ms
+DefaultResourceAwareStrategy, FirstBlock 258.0, LastBlock 1714.0 ratio 
6.6434108527131785
+GenericResourceAwareStrategy, FirstBlock 215.0, LastBlock 1692.0 ratio 
7.869767441860465
+ConstraintSolverStrategy, FirstBlock 309.0, LastBlock 2342.0 ratio 
7.5792880258899675
+
+Choose the median value of the values above
+DefaultResourceAwareStrategy6.96
+GenericResourceAwareStrategy7.78
+ConstraintSolverStrategy7.75
+*/
+
+final int numNodes = 500;
+final String[] strategies = new String[]{
+DefaultResourceAwareStrategy.class.getName(),
+GenericResourceAwareStrategy.class.getName(),
+ConstraintSolverStrategy.class.getName()
+};
+
+final int numStrategies = strategies.length;
+final int numRuns = 5;
+TimeBlockResult testResults[][] = new 
TimeBlockResult[numStrategies][numRuns];
+
+// Get first and last block times for 

[GitHub] [storm] srdo commented on a change in pull request #3092: STORM-3474 Large fragmented cluster scheduling time test

[GitBox]

srdo commented on a change in pull request #3092: STORM-3474 Large fragmented 
cluster scheduling time test
URL: https://github.com/apache/storm/pull/3092#discussion_r309610071
 
 

 ##
 File path: 
storm-server/src/test/java/org/apache/storm/scheduler/resource/TestResourceAwareScheduler.java
 ##
 @@ -1067,6 +1068,208 @@ public void minCpuWorkerSplitFails() {
 assertFalse("Topo-1 unscheduled?", 
cluster.getAssignmentById(topo1.getId()) != null);
 }
 
+protected static class TimeBlockResult {
+long firstBlockTime;
+long lastBlockTime;
+}
+
+private long getMedianBlockTime(TimeBlockResult[] runResults, boolean 
firstBlock) {
 
 Review comment:
   Nit: I would probably map the firstBlock/lastBlock times to `List` and 
just pass in the list I want to find the median for, instead of passing in both 
firstBlock and lastBlock times and using a boolean to switch which we're 
looking at.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: [DISCUSS] Create a checklist for testing new Storm release

[Stig Rohde Døssing]

The list looks good. I think we should drop the .md5 files, the ASF have
been telling people not to use them for a while.

I don't know that everyone needs to do it, but someone should check that
the license files are up to date, and that we're not including any
dependencies with incompatible licenses (
https://apache.org/legal/resolved.html). Ideally we can automate most of
the work.

Den man. 29. jul. 2019 kl. 23.56 skrev Ethan Li :

>
> Per Hugo’s suggestion, we should probably document the testings that every
> contributors/committers should do to guarantee a stable release. It also
> helps creating a check form or email template.
>
>
>  The testings I did for 2.0.0 release are
>
> 1. Verify files such as *.asc, *.md5, *.sha512
> 2. Build Storm source code and run unit tests; create a Storm distribution.
> 3. Set up a standalone cluster using apache-storm-xxx.zip,
> apache-storm-xxx.tar.gz, the Storm distribution created from step 2,
> separately
> 4. Launch WordCountTopology and ThroughputVsLatency topology and check
> logs, UI metrics
> 5. Test basic UI functionalities such as jstack, heap dump, deactivate,
> activate, rebalance, change log level, kill topology
>
>
> Please suggest anything that should be added so that we can document a
> base checklist that everyone can follow to test a new Storm release.
>
>
> Thanks,
> Ethan

Re: [DISCUSS] Next 2.x release

[Stig Rohde Døssing]

Thanks Ethan, yes 2.1.0 makes sense.

Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li :

> It’s a good point. I will start a discussion thread for it.
>
>
> For the new release, I went through the list:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
> <
> https://issues.apache.org/jira/issues/?jql=project%20=%20STORM%20AND%20fixVersion%20=%202.0.1
> >
>
> We introduced some new functionalities, including
> https://issues.apache.org/jira/browse/STORM-2720 <
> https://issues.apache.org/jira/browse/STORM-2720>
> https://issues.apache.org/jira/browse/STORM-3412 <
> https://issues.apache.org/jira/browse/STORM-3412>
> https://issues.apache.org/jira/browse/STORM-3411 <
> https://issues.apache.org/jira/browse/STORM-3411>
> https://issues.apache.org/jira/browse/STORM-3442 <
> https://issues.apache.org/jira/browse/STORM-3442>
> https://issues.apache.org/jira/browse/STORM-3396 <
> https://issues.apache.org/jira/browse/STORM-3396>
> https://issues.apache.org/jira/browse/STORM-3392 <
> https://issues.apache.org/jira/browse/STORM-3392>
> https://issues.apache.org/jira/browse/STORM-3395 <
> https://issues.apache.org/jira/browse/STORM-3395>
>
> So I think we should release 2.1.0 rather than 2.0.1.
>
> There are a few pull requests we may want to review before the next
> release:
>
> https://github.com/apache/storm/pull/3094 <
> https://github.com/apache/storm/pull/3094>
> https://github.com/apache/storm/pull/2990 <
> https://github.com/apache/storm/pull/2990>
> https://github.com/apache/storm/pull/2878 <
> https://github.com/apache/storm/pull/2878>
>
>
> Thanks
> Ethan
>
>
> > On Jul 29, 2019, at 10:11 AM, Hugo Louro  wrote:
> >
> > +1
> >
> > I think it would facilitate more frequent releases to summarize in a page
> > the testing that all contributors/committers do in anticipation of the
> > release, plus any "new" testing that may become relevant for the newer
> > releases. Doing so would make it easy to create a check form or or email
> > template that what we feel should be done to guarantee a stable release.
> >
> > Thanks,
> > Hugo
> >
> > On Mon, Jul 29, 2019 at 7:15 AM Ethan Li 
> wrote:
> >
> >> Thanks Stig. I will look into it.
> >>
> >>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
> stigdoess...@gmail.com>
> >> wrote:
> >>>
> >>> I think ideally we've been trying for semver, but it's been pretty
> loose,
> >>> e.g. there were breaking changes in one of the 1.2.x releases for
> >>> storm-kafka-client. I don't know what rules we've actually been using,
> if
> >>> any.
> >>>
> >>> Semver for binary compatibility would probably be a good rule of thumb.
> >>>
> >>> Den fre. 26. jul. 2019 kl. 20.01 skrev Ethan Li <
> >> ethanopensou...@gmail.com>:
> >>>
> 
>  Stig,
> 
>  Do you know what’s the versioning standard we have been following (to
>  determine a 2.0.1 release or 2.1.0 release) ?
> 
> 
> > On Jul 26, 2019, at 12:26 PM, Stig Rohde Døssing <
> >> stigdoess...@gmail.com>
>  wrote:
> >
> > Sounds great, thanks Ethan.
> >
> > Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>  ethanopensou...@gmail.com>:
> >
> >> It’s good idea to do more frequent release. I can run the next
> >> release.
> >>
> >> I will take a look at both PRs. Other than that, I think we should
> >> also
> >> get https://github.com/apache/storm/pull/3093 <
> >> https://github.com/apache/storm/pull/3093>  in the new release.
> >>
> >>
> >>> On Jul 26, 2019, at 11:58 AM, Stig Rohde Døssing <
>  stigdoess...@gmail.com>
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I think we've talked about more frequent releases before. Releasing
> >> new
> >>> versions every few months means people don't have to wait long for
>  fixes
> >> to
> >>> get out, and smaller releases are probably also easier for users to
> >> get
> >> to
> >>> grips with (the fix list for 2.0.0 is enormous).
> >>>
> >>> With that in mind, I think we should start looking at the next 2.x
> >> release
> >>> (2.0.1 or 2.1.0?), since it's been a couple of months since 2.0.0
> >> released.
> >>> The fix list would be
> >>>
> >>
> 
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
> >>> .
> >>>
> >>> Govind and Ethan have offered to run the next release, and help
>  validate
> >>> our release process guidelines. Would one of you have time to work
> >> on a
> >>> release in the near future?
> >>>
> >>> It would be good to take a look at currently open PRs and decide
> >> which
>  we
> >>> feel need to get merged before the next release.
> >>>
> >>> I would like to see at least
> >> https://github.com/apache/storm/pull/2990
> >>> merged
> >>>
> >>> https://github.com/apache/storm/pull/2878 seems like it's close to
> >> be
> >>> mergeable too?
> 

[GitHub] [storm] srdo commented on a change in pull request #2878: [STORM-3257] 'storm kill' command line should be able to continue on error

[GitBox]

srdo commented on a change in pull request #2878: [STORM-3257] 'storm kill' 
command line should be able to continue on error
URL: https://github.com/apache/storm/pull/2878#discussion_r309601505
 
 

 ##
 File path: storm-core/src/jvm/org/apache/storm/command/KillTopology.java
 ##
 @@ -25,21 +25,49 @@
 
 public static void main(String[] args) throws Exception {
 Map cl = CLI.opt("w", "wait", null, CLI.AS_INT)
+.boolOpt("i", "ignore-errors")
 
 Review comment:
   I'm not sure how people could be depending on the old behavior, but sure it 
probably doesn't hurt to make this optional.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services