subject:"\[4.6\] RC1 soon \?"

Re: [4.6] RC1 soon ?

2015-07-30 Thread Daan Hoogland

never mind that again, answerring to fast as I probably do one out of
two or three times :( Looking further...

On Thu, Jul 30, 2015 at 9:19 PM, Daan Hoogland daan.hoogl...@gmail.com wrote:
Mike, I am looking at the commit and it makes perfect sense as the the
prior situation was creating a prepared statement based on dynamicly
added strings. The only queer thing is that the int i = 1 is replaced
with i = 1, reusing the loop counter instead of hiding it. Maybe this
is the problem

On Thu, Jul 30, 2015 at 8:55 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
I see the problem.

The way a SQL statement was constructed was changed by commit
b84093f691ae0b09d2c525d50f2e2d200c709b2c:

https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java;h=d3c29f70d6ab56379c2436b5cafc933049200f31;hp=faf5291554a68506b14438a7e1cda61cd4c3cc0c;hb=b84093f691ae0b09d2c525d50f2e2d200c709b2c;hpb=1407033cc2e0742653d82bb0181c041b31253693

and no longer makes any sense

SELECT storage_pool.* from storage_pool LEFT JOIN storage_pool_details ON
storage_pool.id = storage_pool_details.pool_id WHERE storage_pool.removed is
null and storage_pool.status = 'Up' and storage_pool.data_center_id = 1 and
storage_pool.scope = 'ZONE' and (((storage_pool_details.name=1) AND
(storage_pool_details.value=** NOT SPECIFIED **))) GROUP BY
storage_pool_details.pool_id HAVING COUNT(storage_pool_details.name) = **
NOT SPECIFIED **

I think I'm just going to revert this commit. It was related to a change put
in at the request of FindBugs.

I've CCed the relevant participants in the commit in case they wish to
re-evaluate the FindBugs request and resubmit a fix.

On Thu, Jul 30, 2015 at 12:13 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:

FYI that I get the same error message when trying to attach a data disk
that is based on zone-wide primary storage.

On Thu, Jul 30, 2015 at 12:10 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:

I'm actually having trouble creating a VM whose root disk runs on
zone-wide primary storage.

This is definitely a blocker for 4.6. I'm just beginning to look into
this, but this is the error message I receive:

findZoneWideStoragePoolsByTags:Exception:No value specified for parameter
4

On Mon, Jul 27, 2015 at 8:51 PM, Pierre-Luc Dion pdion...@apache.org
wrote:

Hi,

I've create this jira filter[1] for the Release Manager, based on it,
there
would be only 4 maybe just 3 blockers on 4.6. Based on this, should we
consider placing a target date for RC1 somewhere like end of August ?

What's missing and to do in 4.6 as far as I know:

1. Basic documentation of new features,
2. Decide if we let it in master and freeze merge during RC ?
3. Build all job as 4.6 in jenkins ?
4. Organize a QA-party, like old time lan-party

[1] https://issues.apache.org/jira/issues/?filter=12332940

--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud™

--
Daan

Re: [4.6] RC1 soon ?

2015-07-30 Thread Mike Tutkowski

Sure, I can revert it and leave it for your leisure to find an acceptable
fix to satisfy FindBugs.

On Thu, Jul 30, 2015 at 1:42 PM, Daan Hoogland daan.hoogl...@gmail.com
wrote:

I am now thinking of how to isolate this code to write a proper test.
This is not going to be successful tonight, while the original seven
samurai is on tv. Maybe reverting is the best option and we live with
findbugs regression for a day. I will think of a way to fix this
tomorrow wit a more clear head.

On Thu, Jul 30, 2015 at 9:33 PM, Daan Hoogland daan.hoogl...@gmail.com
wrote:
But reintroduced the vulnerability that findbugs was complaining about...
I think the problem is in this bit:

int i=0;
for (Map.EntryString, String detail :
details.entrySet()) {
pstmt.setString(++i,detail.getKey());
pstmt.setString(++i,detail.getValue());
}

++i should have been i++ in both cases. I messed those in my review,
sorry

On Thu, Jul 30, 2015 at 9:24 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
No problem, Daan. :)

Just from an empirical standpoint, though, reverting the commit in my
local
repo fixed the problem.

On Thu, Jul 30, 2015 at 1:20 PM, Daan Hoogland daan.hoogl...@gmail.com

wrote:

never mind that again, answerring to fast as I probably do one out of
two or three times :( Looking further...

On Thu, Jul 30, 2015 at 9:19 PM, Daan Hoogland
daan.hoogl...@gmail.com
wrote:
Mike, I am looking at the commit and it makes perfect sense as the
the
prior situation was creating a prepared statement based on dynamicly
added strings. The only queer thing is that the int i = 1 is replaced
with i = 1, reusing the loop counter instead of hiding it. Maybe this
is the problem

On Thu, Jul 30, 2015 at 8:55 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
I see the problem.

The way a SQL statement was constructed was changed by commit
b84093f691ae0b09d2c525d50f2e2d200c709b2c:

and no longer makes any sense

SELECT storage_pool.* from storage_pool LEFT JOIN
storage_pool_details
ON
storage_pool.id = storage_pool_details.pool_id WHERE
storage_pool.removed is
null and storage_pool.status = 'Up' and storage_pool.data_center_id
= 1
and
storage_pool.scope = 'ZONE' and (((storage_pool_details.name=1) AND
(storage_pool_details.value=** NOT SPECIFIED **))) GROUP BY
storage_pool_details.pool_id HAVING COUNT(storage_pool_details.name)
=
**
NOT SPECIFIED **

I think I'm just going to revert this commit. It was related to a
change put
in at the request of FindBugs.

I've CCed the relevant participants in the commit in case they wish
to
re-evaluate the FindBugs request and resubmit a fix.

On Thu, Jul 30, 2015 at 12:13 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:

FYI that I get the same error message when trying to attach a data
disk
that is based on zone-wide primary storage.

On Thu, Jul 30, 2015 at 12:10 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:

I'm actually having trouble creating a VM whose root disk runs on
zone-wide primary storage.

This is definitely a blocker for 4.6. I'm just beginning to look
into
this, but this is the error message I receive:

findZoneWideStoragePoolsByTags:Exception:No value specified for
parameter
4

On Mon, Jul 27, 2015 at 8:51 PM, Pierre-Luc Dion
pdion...@apache.org
wrote:

Hi,

I've create this jira filter[1] for the Release Manager, based on
it,
there
would be only 4 maybe just 3 blockers on 4.6. Based on this,
should
we
consider placing a target date for RC1 somewhere like end of
August
?

What's missing and to do in 4.6 as far as I know:

1. Basic documentation of new features,
2. Decide if we let it in master and freeze merge during RC ?
3. Build all job as 4.6 in jenkins ?
4. Organize a QA-party, like old time lan-party

[1] https://issues.apache.org/jira/issues/?filter=12332940

--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud™

--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkow...@solidfire.com
o: 303.746.7302

Re: [4.6] RC1 soon ?

2015-07-30 Thread Mike Tutkowski

No problem, Daan. :)

Just from an empirical standpoint, though, reverting the commit in my local
repo fixed the problem.

On Thu, Jul 30, 2015 at 1:20 PM, Daan Hoogland daan.hoogl...@gmail.com
wrote:

 never mind that again, answerring to fast as I probably do one out of
 two or three times :( Looking further...

 On Thu, Jul 30, 2015 at 9:19 PM, Daan Hoogland daan.hoogl...@gmail.com
 wrote:
  Mike, I am looking at the commit and it makes perfect sense as the the
  prior situation was creating a prepared statement based on dynamicly
  added strings. The only queer thing is that the int i = 1 is replaced
  with i = 1, reusing the loop counter instead of hiding it. Maybe this
  is the problem
 
  On Thu, Jul 30, 2015 at 8:55 PM, Mike Tutkowski
  mike.tutkow...@solidfire.com wrote:
  I see the problem.
 
  The way a SQL statement was constructed was changed by commit
  b84093f691ae0b09d2c525d50f2e2d200c709b2c:
 
 
 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java;h=d3c29f70d6ab56379c2436b5cafc933049200f31;hp=faf5291554a68506b14438a7e1cda61cd4c3cc0c;hb=b84093f691ae0b09d2c525d50f2e2d200c709b2c;hpb=1407033cc2e0742653d82bb0181c041b31253693
 
  and no longer makes any sense
 
  SELECT storage_pool.* from storage_pool LEFT JOIN storage_pool_details
 ON
  storage_pool.id = storage_pool_details.pool_id WHERE
 storage_pool.removed is
  null and storage_pool.status = 'Up' and storage_pool.data_center_id = 1
 and
  storage_pool.scope = 'ZONE' and (((storage_pool_details.name=1) AND
  (storage_pool_details.value=** NOT SPECIFIED **))) GROUP BY
  storage_pool_details.pool_id HAVING COUNT(storage_pool_details.name)
 = **
  NOT SPECIFIED **
 
  I think I'm just going to revert this commit. It was related to a
 change put
  in at the request of FindBugs.
 
  I've CCed the relevant participants in the commit in case they wish to
  re-evaluate the FindBugs request and resubmit a fix.
 
 
  On Thu, Jul 30, 2015 at 12:13 PM, Mike Tutkowski
  mike.tutkow...@solidfire.com wrote:
 
  FYI that I get the same error message when trying to attach a data disk
  that is based on zone-wide primary storage.
 
  On Thu, Jul 30, 2015 at 12:10 PM, Mike Tutkowski
  mike.tutkow...@solidfire.com wrote:
 
  I'm actually having trouble creating a VM whose root disk runs on
  zone-wide primary storage.
 
  This is definitely a blocker for 4.6. I'm just beginning to look into
  this, but this is the error message I receive:
 
  findZoneWideStoragePoolsByTags:Exception:No value specified for
 parameter
  4
 
  On Mon, Jul 27, 2015 at 8:51 PM, Pierre-Luc Dion pdion...@apache.org
 
  wrote:
 
  Hi,
 
  I've create this jira filter[1] for the Release Manager, based on it,
  there
  would be only 4 maybe just 3 blockers on 4.6. Based on this, should
 we
  consider placing a target date for RC1 somewhere like end of August ?
 
  What's missing and to do in 4.6 as far as I know:
 
  1. Basic documentation of new features,
  2. Decide if we let it in master and freeze merge during RC ?
  3. Build all job as 4.6 in jenkins ?
  4. Organize a QA-party, like old time lan-party
 
  [1] https://issues.apache.org/jira/issues/?filter=12332940
 
 
 
 
  --
  Mike Tutkowski
  Senior CloudStack Developer, SolidFire Inc.
  e: mike.tutkow...@solidfire.com
  o: 303.746.7302
  Advancing the way the world uses the cloud™
 
 
 
 
  --
  Mike Tutkowski
  Senior CloudStack Developer, SolidFire Inc.
  e: mike.tutkow...@solidfire.com
  o: 303.746.7302
  Advancing the way the world uses the cloud™
 
 
 
 
  --
  Mike Tutkowski
  Senior CloudStack Developer, SolidFire Inc.
  e: mike.tutkow...@solidfire.com
  o: 303.746.7302
  Advancing the way the world uses the cloud™
 
 
 
  --
  Daan



 --
 Daan




-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
http://solidfire.com/solution/overview/?video=play*™*

Re: [4.6] RC1 soon ?

2015-07-30 Thread Daan Hoogland

But reintroduced the vulnerability that findbugs was complaining about...
I think the problem is in this bit:

int i=0;
for (Map.EntryString, String detail : details.entrySet()) {
pstmt.setString(++i,detail.getKey());
pstmt.setString(++i,detail.getValue());
}

++i should have been i++ in both cases. I messed those in my review, sorry

On Thu, Jul 30, 2015 at 9:24 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
No problem, Daan. :)

Just from an empirical standpoint, though, reverting the commit in my local
repo fixed the problem.

On Thu, Jul 30, 2015 at 1:20 PM, Daan Hoogland daan.hoogl...@gmail.com
wrote:

never mind that again, answerring to fast as I probably do one out of
two or three times :( Looking further...

On Thu, Jul 30, 2015 at 9:19 PM, Daan Hoogland daan.hoogl...@gmail.com
wrote:
Mike, I am looking at the commit and it makes perfect sense as the the
prior situation was creating a prepared statement based on dynamicly
added strings. The only queer thing is that the int i = 1 is replaced
with i = 1, reusing the loop counter instead of hiding it. Maybe this
is the problem

On Thu, Jul 30, 2015 at 8:55 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
I see the problem.

The way a SQL statement was constructed was changed by commit
b84093f691ae0b09d2c525d50f2e2d200c709b2c:

and no longer makes any sense

SELECT storage_pool.* from storage_pool LEFT JOIN storage_pool_details
ON
storage_pool.id = storage_pool_details.pool_id WHERE
storage_pool.removed is
null and storage_pool.status = 'Up' and storage_pool.data_center_id = 1
and
storage_pool.scope = 'ZONE' and (((storage_pool_details.name=1) AND
(storage_pool_details.value=** NOT SPECIFIED **))) GROUP BY
storage_pool_details.pool_id HAVING COUNT(storage_pool_details.name) =
**
NOT SPECIFIED **