date:20150730

[GitHub] cloudstack pull request: Cloudstack 8656 adding messages to empty ...

2015-07-30 Thread DaanHoogland

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/637#issuecomment-126331708
  
So I will amend the interrupted to be level debug and then merge. next I 
will create a new PR for any remaining empty catch blocks, @koushik-das.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [Blocker] Default ip table rules on VR

2015-07-30 Thread Daan Hoogland

Guys, I see votes here but no arguments. Why is it a blocker?

 From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com]
 Sent: 30 July 2015 02:07 PM
 To: dev@cloudstack.apache.org dev@cloudstack.apache.org
 Subject: Re: [Blocker] Default ip table rules on VR

 I see VR ingress traffic is blocked by default from iptables mangle table.
So, ...

 But on the guest interface all the traffic is accepted.
this is behind the VR.

 Also egress firewall rule will break because of FORWARD policy.

On Thu, Jul 30, 2015 at 2:35 PM, Wilder Rodrigues
wrodrig...@schubergphilis.com wrote:
 Hi,

 We discussed that one yesterday and I already assigned the issue to myself on 
 Jira. I will fix it.

 Cheers,
 WIlder

 On 30 Jul 2015, at 14:09, Sanjeev N sanj...@apache.org wrote:

 Agree with Kishan Kavala and Jayapal.

 On Thu, Jul 30, 2015 at 2:13 PM, Kishan Kavala kishan.kav...@citrix.com
 wrote:

 This is a security issue with high impact.
 We should treat it as a blocker.

 -Original Message-
 From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com]
 Sent: 30 July 2015 02:07 PM
 To: dev@cloudstack.apache.org dev@cloudstack.apache.org
 Subject: Re: [Blocker] Default ip table rules on VR

 I see VR ingress traffic is blocked by default from iptables mangle table.
 But on the guest interface all the traffic is accepted.
 Also egress firewall rule will break because of FORWARD policy.

 Thanks,
 Jayapal

 On 30-Jul-2015, at 12:53 PM, Jayapal Reddy Uradi 
 jayapalreddy.ur...@citrix.com wrote:

 It is security concern on the VR. All the ingress traffic onto the VR is
 accepted.
 Let it be blocker.

 Thanks,
 Jayapal

 On 30-Jul-2015, at 12:28 PM, Daan Hoogland daan.hoogl...@gmail.com
 wrote:

 I changed it to critical. It is only a blocker if we agree on this
 list that it is.

 On Thu, Jul 30, 2015 at 6:44 AM, Sanjeev N sanj...@apache.org wrote:
 Hi,

 In latest ACS builds, the ip table rules in VR have ACCEPT as the
 default policy in INPUT and FORWARD chains, instead of DROP.

 Created a blocker bug for this issue
 https://issues.apache.org/jira/browse/CLOUDSTACK-8688

 Can somebody please fix it?

 Thanks,
 Sanjeev

 --
 Daan

-- 
Daan

[GitHub] cloudstack pull request: CLOUDSTACK-8689: Verify effect of changin...

2015-07-30 Thread pritisarap12

Github user pritisarap12 commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/638#discussion_r35862152
  
--- Diff: test/integration/testpaths/testpath_hypervisor_limit.py ---
@@ -0,0 +1,191 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# License); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+
+ Test cases to Verify effect of changing value of XenServer
+Max guest limit on previously added hosts
+
+
+from nose.plugins.attrib import attr
+from marvin.cloudstackTestCase import cloudstackTestCase
+from marvin.lib.utils import (cleanup_resources,
+validateList)
+from marvin.lib.base import (Account,
+ ServiceOffering,
+ VirtualMachine,
+ Host
+ )
+from marvin.lib.common import (get_domain,
+   get_zone,
+   get_template,
+  )
+
+
+from marvin.cloudstackAPI import (updateHypervisorCapabilities,
+  listHypervisorCapabilities)
+
+from marvin.codes import PASS
+
+
+
+class TestMaxHyperviosrLimit(cloudstackTestCase):
+
+@classmethod
+def setUpClass(cls):
+testClient = super(TestMaxHyperviosrLimit, cls).getClsTestClient()
+cls.apiclient = testClient.getApiClient()
+cls.testdata = testClient.getParsedTestDataConfig()
+
+cls.hypervisor = cls.testClient.getHypervisorInfo()
+# Get Zone, Domain and templates
+cls.domain = get_domain(cls.apiclient)
+cls.zone = get_zone(cls.apiclient, testClient.getZoneForTests())
+
+cls.template = get_template(
+cls.apiclient,
+cls.zone.id,
+cls.testdata[ostype])
+
+cls._cleanup = []
+hostList = Host.list(cls.apiclient, zoneid=cls.zone.id, 
type=Routing)
+cls.host = Host(hostList[0].__dict__)
+try:
+
+cls.skiptest = False
+if cls.hypervisor.lower() not in ['xenserver']:
+cls.skiptest = True
+return
+# Create an account
+cls.account = Account.create(
+cls.apiclient,
+cls.testdata[account],
+domainid=cls.domain.id
+)
+
+# Create user api client of the account
+cls.userapiclient = testClient.getUserApiClient(
+UserName=cls.account.name,
+DomainName=cls.account.domain
+)
+# Create Service offering
+cls.service_offering = ServiceOffering.create(
+cls.apiclient,
+cls.testdata[service_offering],
+)
+
+cls._cleanup = [
+cls.account,
+cls.service_offering,
+]
+except Exception as e:
+cls.tearDownClass()
+raise e
+return
+
+@classmethod
+def tearDownClass(cls):
+try:
+cleanup_resources(cls.apiclient, cls._cleanup)
+except Exception as e:
+raise Exception(Warning: Exception during cleanup : %s % e)
+
+def setUp(self):
+self.cleanup = []
+if self.skiptest:
+self.skipTest(This test is to be checked on xenserver \
+only  Hence, skip for %s  % self.hypervisor)
+
+self.apiclient = self.testClient.getApiClient()
+self.dbclient = self.testClient.getDbConnection()
+
+def tearDown(self):
+try:
+
+cmd = 
updateHypervisorCapabilities.updateHypervisorCapabilitiesCmd()
+cmd.id = self.hostCapId
+cmd.maxguestslimit = self.originalLimit
+self.apiclient.updateHypervisorCapabilities(cmd)

[GitHub] cloudstack pull request: Coverity Issue: Resource Leak fixed

2015-07-30 Thread kansal

Github user kansal commented on the pull request:

https://github.com/apache/cloudstack/pull/643#issuecomment-126301540
  
@DaanHoogland It was the issue that was reported by our internal coverity. 
The issue reported is:

noescape: Resource 'in' is not closed or saved in readObject.
CID 17897: Resource leak (RESOURCE_LEAK). leaked_resource: Variable in 
going out of scope leaks the resource it refers to.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Coverity Issue: Resource Leak fixed

2015-07-30 Thread DaanHoogland

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/643#issuecomment-126319443
  
-1 on this. I cannot track any internal tracking system of another company. 
please if the public coverity doesn't have this make a jira ticket describve 
the problem and put the ticket id in hte commit message.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Coverity Issue: Resource Leak fixed

2015-07-30 Thread miguelaferreira

Github user miguelaferreira commented on the pull request:

https://github.com/apache/cloudstack/pull/643#issuecomment-126319900
  
Hi @kansal 

If this issue was caught by your internal Coverity scan, wouldn't it also 
have been cough by the public Coverity scan? Or are these configured 
differently?

It would be great to use the public IDs all-around, otherwise it will be 
very confusing. I can imagine many people have their own internal ticketing 
systems (for example), and if people would just start to use IDs form those 
internal systems it would be extremely hard to backtrack. Don't you think? 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8687: Prepare template only on...

2015-07-30 Thread kishankavala

Github user kishankavala commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/635#discussion_r35862098
  
--- Diff: 
api/src/org/apache/cloudstack/api/command/admin/template/PrepareTemplateCmd.java
 ---
@@ -60,6 +61,15 @@
description = template ID of the template to be prepared 
in primary storage(s).)
 private Long templateId;
 
+@ACL(accessType = AccessType.OperateEntry)
+@Parameter(name = ApiConstants.STORAGE_ID,
+type = CommandType.UUID,
+entityType = StoragePoolResponse.class,
+required = false,
+description = storage pool ID of the primary storage pool to 
which the template should be prepared. If it is not provided the template +
+ is prepared on all the available primary storage 
pools.)
+private Long storageId;
--- End diff --

@devdeep  LGTM if storageId is consistent across APIs


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [Blocker] Default ip table rules on VR

2015-07-30 Thread Wilder Rodrigues

Hi,

We discussed that one yesterday and I already assigned the issue to myself on 
Jira. I will fix it.

Cheers,
WIlder



 On 30 Jul 2015, at 14:09, Sanjeev N sanj...@apache.org wrote:
 
 Agree with Kishan Kavala and Jayapal.
 
 On Thu, Jul 30, 2015 at 2:13 PM, Kishan Kavala kishan.kav...@citrix.com
 wrote:
 
 This is a security issue with high impact.
 We should treat it as a blocker.
 
 -Original Message-
 From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com]
 Sent: 30 July 2015 02:07 PM
 To: dev@cloudstack.apache.org dev@cloudstack.apache.org
 Subject: Re: [Blocker] Default ip table rules on VR
 
 I see VR ingress traffic is blocked by default from iptables mangle table.
 But on the guest interface all the traffic is accepted.
 Also egress firewall rule will break because of FORWARD policy.
 
 Thanks,
 Jayapal
 
 On 30-Jul-2015, at 12:53 PM, Jayapal Reddy Uradi 
 jayapalreddy.ur...@citrix.com wrote:
 
 
 It is security concern on the VR. All the ingress traffic onto the VR is
 accepted.
 Let it be blocker.
 
 Thanks,
 Jayapal
 
 On 30-Jul-2015, at 12:28 PM, Daan Hoogland daan.hoogl...@gmail.com
 wrote:
 
 I changed it to critical. It is only a blocker if we agree on this
 list that it is.
 
 On Thu, Jul 30, 2015 at 6:44 AM, Sanjeev N sanj...@apache.org wrote:
 Hi,
 
 In latest ACS builds, the ip table rules in VR have ACCEPT as the
 default policy in INPUT and FORWARD chains, instead of DROP.
 
 Created a blocker bug for this issue
 https://issues.apache.org/jira/browse/CLOUDSTACK-8688
 
 Can somebody please fix it?
 
 Thanks,
 Sanjeev
 
 
 
 --
 Daan

Build failed in Jenkins: simulator-4.5-singlerun #256

2015-07-30 Thread jenkins

See http://jenkins.buildacloud.org/job/simulator-4.5-singlerun/256/

--
Started by upstream project build-4.5-simulator build number 311
originally caused by:
 Started by upstream project build-4.5 build number 503
 originally caused by:
  Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on simulator in workspace 
http://jenkins.buildacloud.org/job/simulator-4.5-singlerun/ws/
  /usr/bin/git rev-parse --is-inside-work-tree # timeout=400
Fetching changes from the remote Git repository
  /usr/bin/git config remote.origin.url 
  https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=400
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
  /usr/bin/git --version # timeout=400
  /usr/bin/git fetch --tags --progress 
  https://git-wip-us.apache.org/repos/asf/cloudstack.git 
  +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:735)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:983)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1016)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1258)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528)
at hudson.model.Run.execute(Run.java:1759)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
Caused by: hudson.plugins.git.GitException: Command /usr/bin/git fetch --tags 
--progress https://git-wip-us.apache.org/repos/asf/cloudstack.git 
+refs/heads/*:refs/remotes/origin/* returned status code 128:
stdout: 
stderr: error:  while accessing 
https://git-wip-us.apache.org/repos/asf/cloudstack.git/info/refs

fatal: HTTP request failed

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1591)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1379)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:86)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:324)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:121)
at hudson.remoting.UserRequest.perform(UserRequest.java:49)
at hudson.remoting.Request$2.run(Request.java:324)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
at ..remote call to simulator(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:221)
at hudson.remoting.Channel.call(Channel.java:752)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor375.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at sun.proxy.$Proxy46.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:733)
... 11 more
ERROR: Error fetching remote repo 'origin'
[xUnit] [INFO] - Starting to record.
[xUnit] [INFO] - Processing JUnit
[xUnit] [INFO] - [JUnit] - No test report file(s) were found with the pattern 
'xunit.xml' relative to 
'http://jenkins.buildacloud.org/job/simulator-4.5-singlerun/ws/' for the 
testing framework 'JUnit'.  Did you enter a pattern relative to the correct 
directory?  Did you generate the result report(s) for 'JUnit'?
[xUnit] [ERROR] - No test reports found for the metric 'JUnit' with the 
resolved pattern 'xunit.xml'. Configuration error?.
[xUnit] [INFO] - Failing BUILD.
[xUnit] [INFO] - There are errors

[GitHub] cloudstack pull request: Update NiciraNvpGuestNetworkGuru.java

2015-07-30 Thread kishankavala

Github user kishankavala commented on the pull request:

https://github.com/apache/cloudstack/pull/636#issuecomment-126288404
  
@sspans 
Since Test case is updated to cover VXLAN also, LGTM. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Update NiciraNvpGuestNetworkGuru.java

2015-07-30 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/636


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Update L10N resource files on master bran...

2015-07-30 Thread DaanHoogland

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/640#issuecomment-126307227
  
Bruno, please find two LGTM before merging, thanks. Can you still advertise 
and find some?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Update L10N resource files on master bran...

2015-07-30 Thread milamberspace

Github user milamberspace commented on the pull request:

https://github.com/apache/cloudstack/pull/640#issuecomment-126315563
  
Sorry, I already merged on apache repo. I will better the next time.

Howto find the rules before merging ? (2 LGTM, How many 
asfbot/cloudstack-pull process?)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [Blocker] Default ip table rules on VR

2015-07-30 Thread Sanjeev N

Agree with Kishan Kavala and Jayapal.

On Thu, Jul 30, 2015 at 2:13 PM, Kishan Kavala kishan.kav...@citrix.com
wrote:

 This is a security issue with high impact.
 We should treat it as a blocker.

 -Original Message-
 From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com]
 Sent: 30 July 2015 02:07 PM
 To: dev@cloudstack.apache.org dev@cloudstack.apache.org
 Subject: Re: [Blocker] Default ip table rules on VR

 I see VR ingress traffic is blocked by default from iptables mangle table.
 But on the guest interface all the traffic is accepted.
 Also egress firewall rule will break because of FORWARD policy.

 Thanks,
 Jayapal

 On 30-Jul-2015, at 12:53 PM, Jayapal Reddy Uradi 
 jayapalreddy.ur...@citrix.com wrote:

 
  It is security concern on the VR. All the ingress traffic onto the VR is
 accepted.
  Let it be blocker.
 
  Thanks,
  Jayapal
 
  On 30-Jul-2015, at 12:28 PM, Daan Hoogland daan.hoogl...@gmail.com
  wrote:
 
  I changed it to critical. It is only a blocker if we agree on this
  list that it is.
 
  On Thu, Jul 30, 2015 at 6:44 AM, Sanjeev N sanj...@apache.org wrote:
  Hi,
 
  In latest ACS builds, the ip table rules in VR have ACCEPT as the
  default policy in INPUT and FORWARD chains, instead of DROP.
 
  Created a blocker bug for this issue
  https://issues.apache.org/jira/browse/CLOUDSTACK-8688
 
  Can somebody please fix it?
 
  Thanks,
  Sanjeev
 
 
 
  --
  Daan

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 **