I'm doing other testing locally anyways. If you happen to find a fix, then
I won't bother to revert. I can just try it again with your fix. I'll wait
until tonight MST to revert.
On Thu, Jul 30, 2015 at 1:51 PM, Daan Hoogland <daan.hoogl...@gmail.com>
wrote:
> leasure time is on
>
> On Thu, Jul 30, 2015 at 9:44 PM, Mike Tutkowski
> <mike.tutkow...@solidfire.com> wrote:
> > 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.Entry<String, 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:
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> 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™
> >> >
> >> >
> >> >
> >> > --
> >> > 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™
>
>
>
> --
> 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>*™*
