date:20150728


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644071#comment-14644071
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8677:


Github user wido commented on the pull request:

https://github.com/apache/cloudstack/pull/625#issuecomment-125505835
  
@DaanHoogland I will. Although I don't understand why these are happening


 Call-home functionality for CloudStack
 --

 Key: CLOUDSTACK-8677
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8677
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: Future, 4.6.0
Reporter: Wido den Hollander
Assignee: Wido den Hollander
 Fix For: 4.6.0


 A call-home feature for the CloudStack management server would send 
 anonimized reports back to the CloudStack project.
 These statistics will contain numbers and details on how CloudStack will be 
 used. It will NOT contain:
 * Hostnames
 * IP-Addresses
 * Instance names
 It will report back:
 * Hosts (Number, version, type, hypervisor)
 * Clusters (Hypervisor en Management type)
 * Primary storage (Type and provider)
 * Zones (Network type and providers)
 * Instances (Number and types)
 This gives the CloudStack project a better insight on how CloudStack is being 
 used and allows us to develop accordingly.
 It will be OPT-OUT, using the usage.report.interval users can disable usage 
 reporting. By default it will run every 7 days and send a JSON document to 
 https://call-home.cloudstack.org/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8677) Call-home functionality for CloudStack


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644078#comment-14644078
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8677:


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

https://github.com/apache/cloudstack/pull/625#discussion_r35625883
  
--- Diff: reporter/usage-report-collector.py ---
@@ -0,0 +1,64 @@
+#!/usr/bin/env python
+# 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.
+
+from flask import abort, Flask, request, Response
--- End diff --

This service will not run in the mgmt server. It is where the data is being 
send. Users will not deploy this, it will be running on call-home.cloudstack.org


 Call-home functionality for CloudStack
 --

 Key: CLOUDSTACK-8677
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8677
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: Future, 4.6.0
Reporter: Wido den Hollander
Assignee: Wido den Hollander
 Fix For: 4.6.0


 A call-home feature for the CloudStack management server would send 
 anonimized reports back to the CloudStack project.
 These statistics will contain numbers and details on how CloudStack will be 
 used. It will NOT contain:
 * Hostnames
 * IP-Addresses
 * Instance names
 It will report back:
 * Hosts (Number, version, type, hypervisor)
 * Clusters (Hypervisor en Management type)
 * Primary storage (Type and provider)
 * Zones (Network type and providers)
 * Instances (Number and types)
 This gives the CloudStack project a better insight on how CloudStack is being 
 used and allows us to develop accordingly.
 It will be OPT-OUT, using the usage.report.interval users can disable usage 
 reporting. By default it will run every 7 days and send a JSON document to 
 https://call-home.cloudstack.org/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6171) Cloudstack:KVM:: Snapshot stuck in Creating Status forever.‏

2015-07-28 Thread Wei Zhou (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644091#comment-14644091
 ] 

Wei Zhou commented on CLOUDSTACK-6171:
--

hi Rajani,
Do you mean vm snapshot is implemented for KVM, or only this issue is fixed?

 Cloudstack:KVM:: Snapshot stuck in Creating Status forever.‏
 

 Key: CLOUDSTACK-6171
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6171
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Infra, Install and Setup, KVM, Management Server
Affects Versions: 4.2.0, 4.2.1
 Environment: RHEL 6.4
Reporter: Rohit Kumar
Priority: Blocker
  Labels: newbie, test
   Original Estimate: 168h
  Remaining Estimate: 168h

 Hi,
 I am working on CloudStack infrastructure service to build our organization 
 framework.
 For this purpose, RHEL 6.4, Cloudstack 4.2.1 and KVM are being used.
 I have been working around for long to figure out the below mentioned Issue 
 but unfortunately could not.
 Issue: Snapshot gets stuck in the state Creating forever.
 Impact: Couldn't get the snapshot consequently and thus, the instance from 
 the CloudStack's UI could not be started/Stopped.
 Please see below trace from Management Server log which I think is the reason 
 behind this.
 me:ROOT-13,path:ec5692cb-7758-4618-b589-09cb71e45dba,size:21474836480,type:ROOT,storagePoolType:NetworkFilesystem,storagePoolUuid:d41d4103-a11d-3160-8a3b-6469c574a93f,deviceId:0},{id:19,name:DATA-13,path:8017ac65-b52b-450b-937f-d92178de2f34,size:21474836480,type:DATADISK,storagePoolType:NetworkFilesystem,storagePoolUuid:d41d4103-a11d-3160-8a3b-6469c574a93f,deviceId:1}],target:{id:13,snapshotName:i-2-13-VM_VS_20140225120244,type:Disk,current:false,description:new},vmName:i-2-13-VM,guestOSType:Red
  Hat Enterprise Linux 6.4 (64-bit),wait:1800}}] }
 2014-02-25 17:32:45,254 DEBUG [agent.transport.Request] 
 (AgentManager-Handler-11:null) Seq 1-2016739514: Processing:  { Ans: , 
 MgmtId: 181122461670954, via: 1, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.UnsupportedAnswer:{result:false,details:Unsupported
  command issued:com.cloud.agent.api.CreateVMSnapshotCommand.  Are you sure 
 you got the right type of server?,wait:0}}] }
 2014-02-25 17:32:45,254 DEBUG [agent.transport.Request] 
 (Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) Seq 
 1-2016739514: Received:  { Ans: , MgmtId: 181122461670954, via: 1, Ver: v1, 
 Flags: 10, { UnsupportedAnswer } }
 2014-02-25 17:32:45,254 WARN  [agent.manager.AgentManagerImpl] 
 (Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) 
 Unsupported Command: Unsupported command 
 issued:com.cloud.agent.api.CreateVMSnapshotCommand.  Are you sure you got the 
 right type of server?
 2014-02-25 17:32:45,254 ERROR [vm.snapshot.VMSnapshotManagerImpl] 
 (Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) Create vm 
 snapshot i-2-13-VM_VS_20140225120244 failed for vm: i-2-13-VM due to 
 com.cloud.agent.api.UnsupportedAnswer cannot be cast to 
 com.cloud.agent.api.CreateVMSnapshotAnswer
 2014-02-25 17:32:45,265 DEBUG [cloud.api.ApiServlet] (catalina-exec-11:null) 
 ===START===  192.168.125.241 -- GET  
 command=listOsTypesresponse=jsonsessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3D_=1393329472271
 2014-02-25 17:32:45,324 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null) 
 ===START===  192.168.125.241 -- GET  
 command=listTagsresponse=jsonsessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3DresourceId=340c69ae-f3a0-4966-aa0b-c799e944404fresourceType=UserVmlistAll=true_=1393329472305
 2014-02-25 17:32:45,330 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null) 
 ===END===  192.168.125.241 -- GET  
 command=listTagsresponse=jsonsessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3DresourceId=340c69ae-f3a0-4966-aa0b-c799e944404fresourceType=UserVmlistAll=true_=1393329472305
 2014-02-25 17:32:45,373 DEBUG [cloud.api.ApiServlet] (catalina-exec-11:null) 
 ===END===  192.168.125.241 -- GET  
 command=listOsTypesresponse=jsonsessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3D_=1393329472271
 2014-02-25 17:32:45,419 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) 
 Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.vmsnapshot.CreateVMSnapshotCmd
 com.cloud.utils.exception.CloudRuntimeException: 
 com.cloud.agent.api.UnsupportedAnswer cannot be cast to 
 com.cloud.agent.api.CreateVMSnapshotAnswer
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.createVmSnapshotInternal(VMSnapshotManagerImpl.java:406)
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.creatVMSnapshot(VMSnapshotManagerImpl.java:356)
 at

[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644165#comment-14644165
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8668:


GitHub user kishankavala opened a pull request:

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

CLOUDSTACK-8668: VR type in shared network is dhcpsrvr. Ips are being 
removed due to this issue

- VR IP config is loaded from /var/cache/cloud/cmdline
- For shared network VR type is dhcpserver in /var/cache/cloud/cmdline
- after VR refactor, merge.py is considering VR types router and 
vpcrouter only
-  Fixed by adding dhcpserver VR type

Testing:
- VR successfully started on shared network. All IPs are configured 
properly.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kishankavala/cloudstack CLOUDSTACK-8668

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/627.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #627


commit 50a6fa02dabd7df7a78a0541df6e575129e14265
Author: Kishan Kavala kis...@apache.org
Date:   2015-07-28T09:45:41Z

VR type in shared network is dhcpsrvr. Ips are being removed due to this 
issue




 VR does not start in basic zone since ip address are not being configured on 
 it
 ---

 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Wilder Rodrigues
Priority: Blocker

 VR does not start in basic zone since ip address are not being configured on 
 it
 Steps to reproduce:
 
 1.Bring up CS in basic zone with xen server cluster
 2.Try to deploy one guest vm using default cent os template
 Expected Result:
 ==
 VR should come up as part of vm deployment and vm deployment should be 
 successfull
 Actual Result:
 
 VR creation failed since the IP addresses not are getting assigned to VR's 
 guest and link local interfaces.
 Observations:
 ===
 1.During vr boot time, cloud-early-config ran successfully and VR console 
 output showed that ping to gateway was successful. However, after VR boot we 
 don't see any ip addresses on the VRs guest and link local ip address.
 2. If we run cloud-early-config manually from VR , ip addresses will be 
 assigned and persistent.
 Impact:
 =
 VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644133#comment-14644133
 ] 

Kishan Kavala commented on CLOUDSTACK-8668:
---

Issue is due to router type in cmdline. For VR in shared network type is 
dhcpsrvr and not router. I'll create a PR for this fix

 VR does not start in basic zone since ip address are not being configured on 
 it
 ---

 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Wilder Rodrigues
Priority: Blocker

 VR does not start in basic zone since ip address are not being configured on 
 it
 Steps to reproduce:
 
 1.Bring up CS in basic zone with xen server cluster
 2.Try to deploy one guest vm using default cent os template
 Expected Result:
 ==
 VR should come up as part of vm deployment and vm deployment should be 
 successfull
 Actual Result:
 
 VR creation failed since the IP addresses not are getting assigned to VR's 
 guest and link local interfaces.
 Observations:
 ===
 1.During vr boot time, cloud-early-config ran successfully and VR console 
 output showed that ping to gateway was successful. However, after VR boot we 
 don't see any ip addresses on the VRs guest and link local ip address.
 2. If we run cloud-early-config manually from VR , ip addresses will be 
 assigned and persistent.
 Impact:
 =
 VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8677) Call-home functionality for CloudStack


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644089#comment-14644089
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8677:


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

https://github.com/apache/cloudstack/pull/625#discussion_r35627322
  
--- Diff: server/src/org/apache/cloudstack/report/UsageReporter.java ---
@@ -0,0 +1,487 @@
+// 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.
+package org.apache.cloudstack.report;
+
+import java.util.concurrent.Executors;
+import java.util.concurrent.ScheduledExecutorService;
+import java.util.concurrent.TimeUnit;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Map;
+import java.util.HashMap;
+import java.text.DateFormat;
+import java.text.SimpleDateFormat;
+import java.sql.Connection;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.sql.SQLException;
+import java.net.URL;
+import java.net.SocketTimeoutException;
+import java.net.MalformedURLException;
+import java.net.ProtocolException;
+import java.net.UnknownHostException;
+import java.io.OutputStreamWriter;
+import java.io.IOException;
+
+import javax.inject.Inject;
+import javax.net.ssl.HttpsURLConnection;
+
+import org.apache.log4j.Logger;
+import org.springframework.stereotype.Component;
+
+import org.apache.cloudstack.framework.config.dao.ConfigurationDao;
+import org.apache.cloudstack.managed.context.ManagedContextRunnable;
+
+import org.apache.cloudstack.storage.datastore.db.PrimaryDataStoreDao;
+import org.apache.cloudstack.storage.datastore.db.StoragePoolVO;
+
+import org.apache.commons.codec.digest.DigestUtils;
+
+import com.cloud.host.HostVO;
+import com.cloud.host.dao.HostDao;
+import com.cloud.dc.ClusterVO;
+import com.cloud.dc.dao.ClusterDao;
+import com.cloud.dc.DataCenterVO;
+import com.cloud.dc.dao.DataCenterDao;
+import com.cloud.vm.UserVmVO;
+import com.cloud.vm.dao.UserVmDao;
+import com.cloud.vm.VMInstanceVO;
+import com.cloud.vm.dao.VMInstanceDao;
+import com.cloud.utils.db.SearchCriteria;
+import com.cloud.utils.NumbersUtil;
+import com.cloud.utils.component.ManagerBase;
+import com.cloud.utils.component.ComponentMethodInterceptable;
+import com.cloud.utils.concurrency.NamedThreadFactory;
+import com.cloud.utils.db.DB;
+import com.cloud.utils.db.TransactionLegacy;
+import com.cloud.upgrade.dao.VersionDao;
+import com.cloud.upgrade.dao.VersionVO;
+import com.cloud.storage.dao.DiskOfferingDao;
+import com.cloud.storage.DiskOfferingVO;
+import com.google.gson.Gson;
+import com.google.gson.GsonBuilder;
+import com.google.common.util.concurrent.AtomicLongMap;
+
+@Component
+public class UsageReporter extends ManagerBase implements 
ComponentMethodInterceptable {
+public static final Logger s_logger = 
Logger.getLogger(UsageReporter.class.getName());
+
+/* !FIX ME! This should point to a Apache Infra host with SSL! */
+private String reportHost = https://call-home.cloudstack.org/report;;
+
+private String uniqueID = null;
+
+private static UsageReporter s_instance = null;
+
+private ScheduledExecutorService _executor = null;
+
+@Inject
+private ConfigurationDao _configDao;
+@Inject
+private HostDao _hostDao;
+@Inject
+private ClusterDao _clusterDao;
+@Inject
+private PrimaryDataStoreDao _storagePoolDao;
+@Inject
+private DataCenterDao _dataCenterDao;
+@Inject
+private UserVmDao _userVmDao;
+@Inject
+private VMInstanceDao _vmInstance;
+@Inject
+private VersionDao _versionDao;
+@Inject
+private DiskOfferingDao _diskOfferingDao;
+
+int usageReportInterval = -1;
+
+public static

[jira] [Resolved] (CLOUDSTACK-83) hitting exception when trying to take two consecutive snapshot on same volume


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi resolved CLOUDSTACK-83.
---
Resolution: Fixed

working for me. I am not able to reproduce this on 4.3 with xenserver 6.2

 hitting exception when trying to take two consecutive snapshot on same volume
 -

 Key: CLOUDSTACK-83
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-83
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Snapshot
Affects Versions: pre-4.0.0, 4.3.0
 Environment: Git Revision: 03df2fa9dd45c938f72cd1866044b09d1b0cc978
 Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git
Reporter: shweta agarwal
Assignee: Rajani Karuturi
Priority: Blocker
 Fix For: 4.6.0

 Attachments: cs-83.tar.gz, management-server.log.2012-09-12.gz


 create a VM
 Create a snapshot of its root volume
 Once the snapshot is backedup try to take one more snapshot of same volume
 Actual result:
 Gets message Failed to back up snapshot on secondary storage
 MS log shows :
 2012-09-12 15:16:47,338 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (catalina-exec-18:null) submit async job-129, details: AsyncJobVO {id:129, 
 userId: 2, accountId: 2, sessionKey: null, instanceType: Snapshot, 
 instanceId: 20, cmd: com.cloud.api.commands.CreateSnapshotCmd, cmdOriginator: 
 null, cmdInfo: 
 {id:20,response:json,sessionkey:h4CS2hXNWB/Djj6oc7EqZua14sg\u003d,ctxUserId:2,_:1347443206549,volumeid:8d62449d-b03c-4f27-8c14-9f2e1f2c1cea,ctxAccountId:2,ctxStartEventId:446},
  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
 processStatus: 0, resultCode: 0, result: null, initMsid: 59793358248320, 
 completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
 2012-09-12 15:16:47,339 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-32:job-129) Executing com.cloud.api.commands.CreateSnapshotCmd 
 for job-129
 2012-09-12 15:16:47,382 DEBUG [agent.transport.Request] 
 (Job-Executor-32:job-129) Seq 2-1053884821: Sending  { Cmd , MgmtId: 
 59793358248320, via: 2, Ver: v1, Flags: 100011, 
 [{ManageSnapshotCommand:{_commandSwitch:-c,_volumePath:5728f1d8-e898-4c27-a698-c3108fafc580,_pool:{id:200,uuid:6ce86454-a33f-3551-a1df-bf9cf191dded,host:10.147.28.7,path:/export/home/shweta/asfprimary,port:2049,type:NetworkFilesystem},_snapshotPath:8522d3f9-353a-422e-8f4c-b9e9772c47f8,_snapshotName:cent-snap_ROOT-16_20120912094647,_snapshotId:20,_vmName:i-2-16-VM,wait:0}}]
  }
 2012-09-12 15:16:47,383 DEBUG [agent.transport.Request] 
 (Job-Executor-32:job-129) Seq 2-1053884821: Executing:  { Cmd , MgmtId: 
 59793358248320, via: 2, Ver: v1, Flags: 100011, 
 [{ManageSnapshotCommand:{_commandSwitch:-c,_volumePath:5728f1d8-e898-4c27-a698-c3108fafc580,_pool:{id:200,uuid:6ce86454-a33f-3551-a1df-bf9cf191dded,host:10.147.28.7,path:/export/home/shweta/asfprimary,port:2049,type:NetworkFilesystem},_snapshotPath:8522d3f9-353a-422e-8f4c-b9e9772c47f8,_snapshotName:cent-snap_ROOT-16_20120912094647,_snapshotId:20,_vmName:i-2-16-VM,wait:0}}]
  }
 2012-09-12 15:16:47,383 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-284:null) Seq 2-1053884821: Executing request
 2012-09-12 15:16:49,425 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-284:null) Seq 2-1053884821: Response Received:
 2012-09-12 15:16:49,426 DEBUG [agent.transport.Request] 
 (DirectAgent-284:null) Seq 2-1053884821: Processing:  { Ans: , MgmtId: 
 59793358248320, via: 2, Ver: v1, Flags: 10, 
 [{ManageSnapshotAnswer:{_snapshotPath:60da197d-3de9-4eb6-8a4c-9032003c45a6,result:true,wait:0}}]
  }
 2012-09-12 15:16:49,426 DEBUG [agent.transport.Request] 
 (Job-Executor-32:job-129) Seq 2-1053884821: Received:  { Ans: , MgmtId: 
 59793358248320, via: 2, Ver: v1, Flags: 10, { ManageSnapshotAnswer } }
 2012-09-12 15:16:49,469 DEBUG [agent.transport.Request] 
 (Job-Executor-32:job-129) Seq 2-1053884822: Sending  { Cmd , MgmtId: 
 59793358248320, via: 2, Ver: v1, Flags: 100011, 
 [{BackupSnapshotCommand:{prevSnapshotUuid:8522d3f9-353a-422e-8f4c-b9e9772c47f8,prevBackupUuid:a030a6af-9663-461c-b746-8a7a814d9694,isVolumeInactive:false,vmName:i-2-16-VM,snapshotId:20,pool:{id:200,uuid:6ce86454-a33f-3551-a1df-bf9cf191dded,host:10.147.28.7,path:/export/home/shweta/asfprimary,port:2049,type:NetworkFilesystem},primaryStoragePoolNameLabel:6ce86454-a33f-3551-a1df-bf9cf191dded,snapshotUuid:60da197d-3de9-4eb6-8a4c-9032003c45a6,snapshotName:cent-snap_ROOT-16_20120912094647,secondaryStorageUrl:nfs://10.147.28.7/export/home/shweta/asfsecondary,dcId:1,accountId:2,volumeId:26,volumePath:5728f1d8-e898-4c27-a698-c3108fafc580,wait:21600}}]
  }
 2012-09-12 15:16:49,470 DEBUG [agent.transport.Request]

[jira] [Resolved] (CLOUDSTACK-8324) DHCP/DNS offload and config drive support for adv shared network

2015-07-28 Thread Jayapal Reddy (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-8324.
---
Resolution: Fixed

 DHCP/DNS offload and config drive support for adv shared network
 

 Key: CLOUDSTACK-8324
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8324
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.6.0


 1. Add support of attaching config drive to user vm.
 2. provide alternative way to pass data to user vm without depending on the 
 router.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8677) Call-home functionality for CloudStack


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644073#comment-14644073
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8677:


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

https://github.com/apache/cloudstack/pull/625#discussion_r35625751
  
--- Diff: server/src/org/apache/cloudstack/report/UsageReporter.java ---
@@ -0,0 +1,487 @@
+// 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.
+package org.apache.cloudstack.report;
+
+import java.util.concurrent.Executors;
+import java.util.concurrent.ScheduledExecutorService;
+import java.util.concurrent.TimeUnit;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Map;
+import java.util.HashMap;
+import java.text.DateFormat;
+import java.text.SimpleDateFormat;
+import java.sql.Connection;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.sql.SQLException;
+import java.net.URL;
+import java.net.SocketTimeoutException;
+import java.net.MalformedURLException;
+import java.net.ProtocolException;
+import java.net.UnknownHostException;
+import java.io.OutputStreamWriter;
+import java.io.IOException;
+
+import javax.inject.Inject;
+import javax.net.ssl.HttpsURLConnection;
+
+import org.apache.log4j.Logger;
+import org.springframework.stereotype.Component;
+
+import org.apache.cloudstack.framework.config.dao.ConfigurationDao;
+import org.apache.cloudstack.managed.context.ManagedContextRunnable;
+
+import org.apache.cloudstack.storage.datastore.db.PrimaryDataStoreDao;
+import org.apache.cloudstack.storage.datastore.db.StoragePoolVO;
+
+import org.apache.commons.codec.digest.DigestUtils;
+
+import com.cloud.host.HostVO;
+import com.cloud.host.dao.HostDao;
+import com.cloud.dc.ClusterVO;
+import com.cloud.dc.dao.ClusterDao;
+import com.cloud.dc.DataCenterVO;
+import com.cloud.dc.dao.DataCenterDao;
+import com.cloud.vm.UserVmVO;
+import com.cloud.vm.dao.UserVmDao;
+import com.cloud.vm.VMInstanceVO;
+import com.cloud.vm.dao.VMInstanceDao;
+import com.cloud.utils.db.SearchCriteria;
+import com.cloud.utils.NumbersUtil;
+import com.cloud.utils.component.ManagerBase;
+import com.cloud.utils.component.ComponentMethodInterceptable;
+import com.cloud.utils.concurrency.NamedThreadFactory;
+import com.cloud.utils.db.DB;
+import com.cloud.utils.db.TransactionLegacy;
+import com.cloud.upgrade.dao.VersionDao;
+import com.cloud.upgrade.dao.VersionVO;
+import com.cloud.storage.dao.DiskOfferingDao;
+import com.cloud.storage.DiskOfferingVO;
+import com.google.gson.Gson;
+import com.google.gson.GsonBuilder;
+import com.google.common.util.concurrent.AtomicLongMap;
+
+@Component
+public class UsageReporter extends ManagerBase implements 
ComponentMethodInterceptable {
+public static final Logger s_logger = 
Logger.getLogger(UsageReporter.class.getName());
+
+/* !FIX ME! This should point to a Apache Infra host with SSL! */
+private String reportHost = https://call-home.cloudstack.org/report;;
+
+private String uniqueID = null;
+
+private static UsageReporter s_instance = null;
+
+private ScheduledExecutorService _executor = null;
+
+@Inject
+private ConfigurationDao _configDao;
+@Inject
+private HostDao _hostDao;
+@Inject
+private ClusterDao _clusterDao;
+@Inject
+private PrimaryDataStoreDao _storagePoolDao;
+@Inject
+private DataCenterDao _dataCenterDao;
+@Inject
+private UserVmDao _userVmDao;
+@Inject
+private VMInstanceDao _vmInstance;
+@Inject
+private VersionDao _versionDao;
+@Inject
+private DiskOfferingDao _diskOfferingDao;
+
+int usageReportInterval = -1;
+
+public static UsageReporter

[jira] [Commented] (CLOUDSTACK-8677) Call-home functionality for CloudStack


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644076#comment-14644076
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8677:


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

https://github.com/apache/cloudstack/pull/625#discussion_r35625795
  
--- Diff: reporter/usage-report-collector.py ---
@@ -0,0 +1,64 @@
+#!/usr/bin/env python
+# 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.
+
+from flask import abort, Flask, request, Response
+from elasticsearch import Elasticsearch
+import json
+import time
+
+def json_response(response):
+return json.dumps(response, indent=2) + \n, 200, {'Content-Type': 
'application/json; charset=utf-8'}
+
+def generate_app(config=None):
+app = Flask(__name__)
+
+@app.route('/report/unique_id', methods=['POST'])
+def report(unique_id):
+# We expect JSON data, so if the Content-Type doesn't match JSON 
data we throw an error
+if 'Content-Type' in request.headers:
+if request.headers['Content-Type'] != 'application/json':
+abort(417, No or incorrect Content-Type header was 
supplied)
+
+index = cloudstack-%s % time.strftime(%Y.%m.%d, time.gmtime())
+timestamp = time.strftime(%Y-%m-%dT%H:%M:%SZ, time.gmtime())
+
+es = Elasticsearch()
+es.indices.create(index=index, ignore=400)
+
+report = json.loads(request.data)
--- End diff --

Good point, although Flask will catch exceptions and generate HTTP errors 
based on those


 Call-home functionality for CloudStack
 --

 Key: CLOUDSTACK-8677
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8677
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: Future, 4.6.0
Reporter: Wido den Hollander
Assignee: Wido den Hollander
 Fix For: 4.6.0


 A call-home feature for the CloudStack management server would send 
 anonimized reports back to the CloudStack project.
 These statistics will contain numbers and details on how CloudStack will be 
 used. It will NOT contain:
 * Hostnames
 * IP-Addresses
 * Instance names
 It will report back:
 * Hosts (Number, version, type, hypervisor)
 * Clusters (Hypervisor en Management type)
 * Primary storage (Type and provider)
 * Zones (Network type and providers)
 * Instances (Number and types)
 This gives the CloudStack project a better insight on how CloudStack is being 
 used and allows us to develop accordingly.
 It will be OPT-OUT, using the usage.report.interval users can disable usage 
 reporting. By default it will run every 7 days and send a JSON document to 
 https://call-home.cloudstack.org/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8677) Call-home functionality for CloudStack


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644077#comment-14644077
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8677:


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

https://github.com/apache/cloudstack/pull/625#discussion_r35625832
  
--- Diff: reporter/usage-report-collector.py ---
@@ -0,0 +1,64 @@
+#!/usr/bin/env python
+# 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.
+
+from flask import abort, Flask, request, Response
+from elasticsearch import Elasticsearch
+import json
+import time
+
+def json_response(response):
+return json.dumps(response, indent=2) + \n, 200, {'Content-Type': 
'application/json; charset=utf-8'}
+
+def generate_app(config=None):
+app = Flask(__name__)
+
+@app.route('/report/unique_id', methods=['POST'])
+def report(unique_id):
+# We expect JSON data, so if the Content-Type doesn't match JSON 
data we throw an error
+if 'Content-Type' in request.headers:
+if request.headers['Content-Type'] != 'application/json':
+abort(417, No or incorrect Content-Type header was 
supplied)
+
+index = cloudstack-%s % time.strftime(%Y.%m.%d, time.gmtime())
+timestamp = time.strftime(%Y-%m-%dT%H:%M:%SZ, time.gmtime())
+
+es = Elasticsearch()
+es.indices.create(index=index, ignore=400)
+
+report = json.loads(request.data)
+report[unique_id] = unique_id
+report[timestamp] = timestamp
+
+es.index(index=index, doc_type=usage-report, 
body=json.dumps(report), timestamp=timestamp, refresh=True)
+
+response = {}
+return json_response(response)
+
+return app
+
+
+app = generate_app()
+
+# Only run the App if this script is invoked from a Shell
+if __name__ == '__main__':
+app.debug = True
+app.run(host='0.0.0.0', port=8088)
+
+# Otherwise provide a variable called 'application' for mod_wsgi
+else:
--- End diff --

It is for mod_wsgi. It will read app and run the application from there


 Call-home functionality for CloudStack
 --

 Key: CLOUDSTACK-8677
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8677
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: Future, 4.6.0
Reporter: Wido den Hollander
Assignee: Wido den Hollander
 Fix For: 4.6.0


 A call-home feature for the CloudStack management server would send 
 anonimized reports back to the CloudStack project.
 These statistics will contain numbers and details on how CloudStack will be 
 used. It will NOT contain:
 * Hostnames
 * IP-Addresses
 * Instance names
 It will report back:
 * Hosts (Number, version, type, hypervisor)
 * Clusters (Hypervisor en Management type)
 * Primary storage (Type and provider)
 * Zones (Network type and providers)
 * Instances (Number and types)
 This gives the CloudStack project a better insight on how CloudStack is being 
 used and allows us to develop accordingly.
 It will be OPT-OUT, using the usage.report.interval users can disable usage 
 reporting. By default it will run every 7 days and send a JSON document to 
 https://call-home.cloudstack.org/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8677) Call-home functionality for CloudStack


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644087#comment-14644087
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8677:


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

https://github.com/apache/cloudstack/pull/625#discussion_r35626976
  
--- Diff: server/src/org/apache/cloudstack/report/UsageReporter.java ---
@@ -0,0 +1,487 @@
+// 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.
+package org.apache.cloudstack.report;
+
+import java.util.concurrent.Executors;
+import java.util.concurrent.ScheduledExecutorService;
+import java.util.concurrent.TimeUnit;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Map;
+import java.util.HashMap;
+import java.text.DateFormat;
+import java.text.SimpleDateFormat;
+import java.sql.Connection;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.sql.SQLException;
+import java.net.URL;
+import java.net.SocketTimeoutException;
+import java.net.MalformedURLException;
+import java.net.ProtocolException;
+import java.net.UnknownHostException;
+import java.io.OutputStreamWriter;
+import java.io.IOException;
+
+import javax.inject.Inject;
+import javax.net.ssl.HttpsURLConnection;
+
+import org.apache.log4j.Logger;
+import org.springframework.stereotype.Component;
+
+import org.apache.cloudstack.framework.config.dao.ConfigurationDao;
+import org.apache.cloudstack.managed.context.ManagedContextRunnable;
+
+import org.apache.cloudstack.storage.datastore.db.PrimaryDataStoreDao;
+import org.apache.cloudstack.storage.datastore.db.StoragePoolVO;
+
+import org.apache.commons.codec.digest.DigestUtils;
+
+import com.cloud.host.HostVO;
+import com.cloud.host.dao.HostDao;
+import com.cloud.dc.ClusterVO;
+import com.cloud.dc.dao.ClusterDao;
+import com.cloud.dc.DataCenterVO;
+import com.cloud.dc.dao.DataCenterDao;
+import com.cloud.vm.UserVmVO;
+import com.cloud.vm.dao.UserVmDao;
+import com.cloud.vm.VMInstanceVO;
+import com.cloud.vm.dao.VMInstanceDao;
+import com.cloud.utils.db.SearchCriteria;
+import com.cloud.utils.NumbersUtil;
+import com.cloud.utils.component.ManagerBase;
+import com.cloud.utils.component.ComponentMethodInterceptable;
+import com.cloud.utils.concurrency.NamedThreadFactory;
+import com.cloud.utils.db.DB;
+import com.cloud.utils.db.TransactionLegacy;
+import com.cloud.upgrade.dao.VersionDao;
+import com.cloud.upgrade.dao.VersionVO;
+import com.cloud.storage.dao.DiskOfferingDao;
+import com.cloud.storage.DiskOfferingVO;
+import com.google.gson.Gson;
+import com.google.gson.GsonBuilder;
+import com.google.common.util.concurrent.AtomicLongMap;
+
+@Component
+public class UsageReporter extends ManagerBase implements 
ComponentMethodInterceptable {
+public static final Logger s_logger = 
Logger.getLogger(UsageReporter.class.getName());
+
+/* !FIX ME! This should point to a Apache Infra host with SSL! */
+private String reportHost = https://call-home.cloudstack.org/report;;
+
+private String uniqueID = null;
+
+private static UsageReporter s_instance = null;
+
+private ScheduledExecutorService _executor = null;
+
+@Inject
+private ConfigurationDao _configDao;
+@Inject
+private HostDao _hostDao;
+@Inject
+private ClusterDao _clusterDao;
+@Inject
+private PrimaryDataStoreDao _storagePoolDao;
+@Inject
+private DataCenterDao _dataCenterDao;
+@Inject
+private UserVmDao _userVmDao;
+@Inject
+private VMInstanceDao _vmInstance;
+@Inject
+private VersionDao _versionDao;
+@Inject
+private DiskOfferingDao _diskOfferingDao;
+
+int usageReportInterval = -1;
+
+public static

[jira] [Assigned] (CLOUDSTACK-83) hitting exception when trying to take two consecutive snapshot on same volume


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi reassigned CLOUDSTACK-83:
-

Assignee: Rajani Karuturi

 hitting exception when trying to take two consecutive snapshot on same volume
 -

 Key: CLOUDSTACK-83
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-83
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Snapshot
Affects Versions: pre-4.0.0, 4.3.0
 Environment: Git Revision: 03df2fa9dd45c938f72cd1866044b09d1b0cc978
 Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git
Reporter: shweta agarwal
Assignee: Rajani Karuturi
Priority: Blocker
 Fix For: 4.6.0

 Attachments: cs-83.tar.gz, management-server.log.2012-09-12.gz


 create a VM
 Create a snapshot of its root volume
 Once the snapshot is backedup try to take one more snapshot of same volume
 Actual result:
 Gets message Failed to back up snapshot on secondary storage
 MS log shows :
 2012-09-12 15:16:47,338 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (catalina-exec-18:null) submit async job-129, details: AsyncJobVO {id:129, 
 userId: 2, accountId: 2, sessionKey: null, instanceType: Snapshot, 
 instanceId: 20, cmd: com.cloud.api.commands.CreateSnapshotCmd, cmdOriginator: 
 null, cmdInfo: 
 {id:20,response:json,sessionkey:h4CS2hXNWB/Djj6oc7EqZua14sg\u003d,ctxUserId:2,_:1347443206549,volumeid:8d62449d-b03c-4f27-8c14-9f2e1f2c1cea,ctxAccountId:2,ctxStartEventId:446},
  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
 processStatus: 0, resultCode: 0, result: null, initMsid: 59793358248320, 
 completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
 2012-09-12 15:16:47,339 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-32:job-129) Executing com.cloud.api.commands.CreateSnapshotCmd 
 for job-129
 2012-09-12 15:16:47,382 DEBUG [agent.transport.Request] 
 (Job-Executor-32:job-129) Seq 2-1053884821: Sending  { Cmd , MgmtId: 
 59793358248320, via: 2, Ver: v1, Flags: 100011, 
 [{ManageSnapshotCommand:{_commandSwitch:-c,_volumePath:5728f1d8-e898-4c27-a698-c3108fafc580,_pool:{id:200,uuid:6ce86454-a33f-3551-a1df-bf9cf191dded,host:10.147.28.7,path:/export/home/shweta/asfprimary,port:2049,type:NetworkFilesystem},_snapshotPath:8522d3f9-353a-422e-8f4c-b9e9772c47f8,_snapshotName:cent-snap_ROOT-16_20120912094647,_snapshotId:20,_vmName:i-2-16-VM,wait:0}}]
  }
 2012-09-12 15:16:47,383 DEBUG [agent.transport.Request] 
 (Job-Executor-32:job-129) Seq 2-1053884821: Executing:  { Cmd , MgmtId: 
 59793358248320, via: 2, Ver: v1, Flags: 100011, 
 [{ManageSnapshotCommand:{_commandSwitch:-c,_volumePath:5728f1d8-e898-4c27-a698-c3108fafc580,_pool:{id:200,uuid:6ce86454-a33f-3551-a1df-bf9cf191dded,host:10.147.28.7,path:/export/home/shweta/asfprimary,port:2049,type:NetworkFilesystem},_snapshotPath:8522d3f9-353a-422e-8f4c-b9e9772c47f8,_snapshotName:cent-snap_ROOT-16_20120912094647,_snapshotId:20,_vmName:i-2-16-VM,wait:0}}]
  }
 2012-09-12 15:16:47,383 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-284:null) Seq 2-1053884821: Executing request
 2012-09-12 15:16:49,425 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-284:null) Seq 2-1053884821: Response Received:
 2012-09-12 15:16:49,426 DEBUG [agent.transport.Request] 
 (DirectAgent-284:null) Seq 2-1053884821: Processing:  { Ans: , MgmtId: 
 59793358248320, via: 2, Ver: v1, Flags: 10, 
 [{ManageSnapshotAnswer:{_snapshotPath:60da197d-3de9-4eb6-8a4c-9032003c45a6,result:true,wait:0}}]
  }
 2012-09-12 15:16:49,426 DEBUG [agent.transport.Request] 
 (Job-Executor-32:job-129) Seq 2-1053884821: Received:  { Ans: , MgmtId: 
 59793358248320, via: 2, Ver: v1, Flags: 10, { ManageSnapshotAnswer } }
 2012-09-12 15:16:49,469 DEBUG [agent.transport.Request] 
 (Job-Executor-32:job-129) Seq 2-1053884822: Sending  { Cmd , MgmtId: 
 59793358248320, via: 2, Ver: v1, Flags: 100011, 
 [{BackupSnapshotCommand:{prevSnapshotUuid:8522d3f9-353a-422e-8f4c-b9e9772c47f8,prevBackupUuid:a030a6af-9663-461c-b746-8a7a814d9694,isVolumeInactive:false,vmName:i-2-16-VM,snapshotId:20,pool:{id:200,uuid:6ce86454-a33f-3551-a1df-bf9cf191dded,host:10.147.28.7,path:/export/home/shweta/asfprimary,port:2049,type:NetworkFilesystem},primaryStoragePoolNameLabel:6ce86454-a33f-3551-a1df-bf9cf191dded,snapshotUuid:60da197d-3de9-4eb6-8a4c-9032003c45a6,snapshotName:cent-snap_ROOT-16_20120912094647,secondaryStorageUrl:nfs://10.147.28.7/export/home/shweta/asfsecondary,dcId:1,accountId:2,volumeId:26,volumePath:5728f1d8-e898-4c27-a698-c3108fafc580,wait:21600}}]
  }
 2012-09-12 15:16:49,470 DEBUG [agent.transport.Request] 
 (Job-Executor-32:job-129) Seq 2-1053884822: Executing:  { Cmd , MgmtId:

[jira] [Commented] (CLOUDSTACK-8677) Call-home functionality for CloudStack


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644067#comment-14644067
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8677:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/625#issuecomment-125505270
  
@wido you are introducing two findbugs findings, can you look at those?


 Call-home functionality for CloudStack
 --

 Key: CLOUDSTACK-8677
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8677
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: Future, 4.6.0
Reporter: Wido den Hollander
Assignee: Wido den Hollander
 Fix For: 4.6.0


 A call-home feature for the CloudStack management server would send 
 anonimized reports back to the CloudStack project.
 These statistics will contain numbers and details on how CloudStack will be 
 used. It will NOT contain:
 * Hostnames
 * IP-Addresses
 * Instance names
 It will report back:
 * Hosts (Number, version, type, hypervisor)
 * Clusters (Hypervisor en Management type)
 * Primary storage (Type and provider)
 * Zones (Network type and providers)
 * Instances (Number and types)
 This gives the CloudStack project a better insight on how CloudStack is being 
 used and allows us to develop accordingly.
 It will be OPT-OUT, using the usage.report.interval users can disable usage 
 reporting. By default it will run every 7 days and send a JSON document to 
 https://call-home.cloudstack.org/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8677) Call-home functionality for CloudStack


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644081#comment-14644081
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8677:


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

https://github.com/apache/cloudstack/pull/625#discussion_r35626289
  
--- Diff: server/src/org/apache/cloudstack/report/UsageReporter.java ---
@@ -0,0 +1,487 @@
+// 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.
+package org.apache.cloudstack.report;
+
+import java.util.concurrent.Executors;
+import java.util.concurrent.ScheduledExecutorService;
+import java.util.concurrent.TimeUnit;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Map;
+import java.util.HashMap;
+import java.text.DateFormat;
+import java.text.SimpleDateFormat;
+import java.sql.Connection;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.sql.SQLException;
+import java.net.URL;
+import java.net.SocketTimeoutException;
+import java.net.MalformedURLException;
+import java.net.ProtocolException;
+import java.net.UnknownHostException;
+import java.io.OutputStreamWriter;
+import java.io.IOException;
+
+import javax.inject.Inject;
+import javax.net.ssl.HttpsURLConnection;
+
+import org.apache.log4j.Logger;
+import org.springframework.stereotype.Component;
+
+import org.apache.cloudstack.framework.config.dao.ConfigurationDao;
+import org.apache.cloudstack.managed.context.ManagedContextRunnable;
+
+import org.apache.cloudstack.storage.datastore.db.PrimaryDataStoreDao;
+import org.apache.cloudstack.storage.datastore.db.StoragePoolVO;
+
+import org.apache.commons.codec.digest.DigestUtils;
+
+import com.cloud.host.HostVO;
+import com.cloud.host.dao.HostDao;
+import com.cloud.dc.ClusterVO;
+import com.cloud.dc.dao.ClusterDao;
+import com.cloud.dc.DataCenterVO;
+import com.cloud.dc.dao.DataCenterDao;
+import com.cloud.vm.UserVmVO;
+import com.cloud.vm.dao.UserVmDao;
+import com.cloud.vm.VMInstanceVO;
+import com.cloud.vm.dao.VMInstanceDao;
+import com.cloud.utils.db.SearchCriteria;
+import com.cloud.utils.NumbersUtil;
+import com.cloud.utils.component.ManagerBase;
+import com.cloud.utils.component.ComponentMethodInterceptable;
+import com.cloud.utils.concurrency.NamedThreadFactory;
+import com.cloud.utils.db.DB;
+import com.cloud.utils.db.TransactionLegacy;
+import com.cloud.upgrade.dao.VersionDao;
+import com.cloud.upgrade.dao.VersionVO;
+import com.cloud.storage.dao.DiskOfferingDao;
+import com.cloud.storage.DiskOfferingVO;
+import com.google.gson.Gson;
+import com.google.gson.GsonBuilder;
+import com.google.common.util.concurrent.AtomicLongMap;
+
+@Component
+public class UsageReporter extends ManagerBase implements 
ComponentMethodInterceptable {
+public static final Logger s_logger = 
Logger.getLogger(UsageReporter.class.getName());
+
+/* !FIX ME! This should point to a Apache Infra host with SSL! */
+private String reportHost = https://call-home.cloudstack.org/report;;
+
+private String uniqueID = null;
+
+private static UsageReporter s_instance = null;
+
+private ScheduledExecutorService _executor = null;
+
+@Inject
+private ConfigurationDao _configDao;
+@Inject
+private HostDao _hostDao;
+@Inject
+private ClusterDao _clusterDao;
+@Inject
+private PrimaryDataStoreDao _storagePoolDao;
+@Inject
+private DataCenterDao _dataCenterDao;
+@Inject
+private UserVmDao _userVmDao;
+@Inject
+private VMInstanceDao _vmInstance;
+@Inject
+private VersionDao _versionDao;
+@Inject
+private DiskOfferingDao _diskOfferingDao;
+
+int usageReportInterval = -1;
+
+public static

[jira] [Commented] (CLOUDSTACK-8638) Cloudstack deb packages don't include update_host_passwd.sh


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644120#comment-14644120
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8638:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/626#issuecomment-125522926
  
LGTM

The thing with the line number could be done in a different PR.

Cheers,
Wilder

Sent from my iPhone

On 28 Jul 2015, at 04:38, Pierrre-Luc Dion 
notificati...@github.commailto:notificati...@github.com wrote:


  *   build .deb package job must be change for dpkg-buildpackage -uc -us 
ubuntu 14.04 enforce signature of package. CLOUDSTACK-8638

  *   @wilderrodrigueshttps://github.com/wilderrodrigues: this fix 
dependency for keepalived on building systemvm64template. Changing libnl1 by 
libnl-3-200 libnl-genl-3-200 seams resolve the build problem.

For unknown reason the default way to retrieve version mvn 
org.apache.maven.plugins:maven-help-plugin:2.1.1:evaluate 
-Dexpression=project.version | grep -v \[ does not work in package creation, 
it return a null value.


You can view, comment on, or merge this pull request online at:

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

Commit Summary

  *   fix dependency for keepalived from wheezy-backports
  *   fix release version automatically updated using pom.xml
  *   change last owner of change for pgp signature

File Changes

  *   M 
debian/changeloghttps://github.com/apache/cloudstack/pull/626/files#diff-0 (2)
  *   M 
debian/ruleshttps://github.com/apache/cloudstack/pull/626/files#diff-1 (2)
  *   M 
tools/appliance/definitions/systemvmtemplate/install_systemvm_packages.shhttps://github.com/apache/cloudstack/pull/626/files#diff-2
 (2)

Patch Links:

  *   https://github.com/apache/cloudstack/pull/626.patch
  *   https://github.com/apache/cloudstack/pull/626.diff

—
Reply to this email directly or view it on 
GitHubhttps://github.com/apache/cloudstack/pull/626.



 Cloudstack deb packages don't include update_host_passwd.sh
 ---

 Key: CLOUDSTACK-8638
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8638
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Packaging
Affects Versions: 4.6.0
Reporter: Boris Schrijver
Priority: Blocker

 When building the master; Cloudstack deb packages don't include 
 update_host_passwd.sh



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8683) Shared network VR ssh on port 3922 is blocked


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644265#comment-14644265
 ] 

Kishan Kavala commented on CLOUDSTACK-8683:
---

root@r-27-VM:~# cat /etc/iptables/router_rules.v4
# Generated by iptables-save v1.4.14 on Tue Jul 28 10:22:49 2015
*mangle
:PREROUTING ACCEPT [85:12336]
:INPUT ACCEPT [85:12336]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [78:13012]
:POSTROUTING ACCEPT [78:13012]
-A PREROUTING -m state --state RELATED,ESTABLISHED -j CONNMARK --restore-mark 
--nfmask 0x --ctmask 0x
-A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 
0x0/0x
COMMIT
# Completed on Tue Jul 28 10:22:49 2015
# Generated by iptables-save v1.4.14 on Tue Jul 28 10:22:49 2015
*filter
:INPUT ACCEPT [83:12168]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [78:13012]
:NETWORK_STATS - [0:0]
-A INPUT -j NETWORK_STATS
-A INPUT -d 224.0.0.18/32 -j ACCEPT
-A INPUT -d 225.0.0.50/32 -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A FORWARD -j NETWORK_STATS
-A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth0 -m state --state NEW -j ACCEPT
-A FORWARD -i eth2 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -j NETWORK_STATS
-A NETWORK_STATS -i eth0 -o eth2
-A NETWORK_STATS -i eth2 -o eth0
-A NETWORK_STATS ! -i eth0 -o eth2 -p tcp
-A NETWORK_STATS -i eth2 ! -o eth0 -p tcp
COMMIT
# Completed on Tue Jul 28 10:22:49 2015
# Generated by iptables-save v1.4.14 on Tue Jul 28 10:22:49 2015
*nat
:PREROUTING ACCEPT [17:1384]
:INPUT ACCEPT [15:1304]
:OUTPUT ACCEPT [4:268]
:POSTROUTING ACCEPT [4:268]
COMMIT
# Completed on Tue Jul 28 10:22:49 2015


 Shared network VR ssh on port 3922 is blocked
 -

 Key: CLOUDSTACK-8683
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8683
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Kishan Kavala
Priority: Blocker

 ssh to Shared network VR on link_local_ip @ port 3922 is blocked.
 MS is not able to program any rules on the VR due to this



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-8658) default characterset not defined


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daan Hoogland closed CLOUDSTACK-8658.
-
Resolution: Fixed

 default characterset not defined
 

 Key: CLOUDSTACK-8658
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8658
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Daan Hoogland
Assignee: Daan Hoogland
Priority: Critical

 in StringUtils the preferred platform encoding is initialized without static 
 keyword and hence only in instances.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it

2015-07-28 Thread Wilder Rodrigues (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues updated CLOUDSTACK-8668:
-
Comment: was deleted

(was: I will mark this issue as resolved, since the port problem has been 
created under another issue id.)

 VR does not start in basic zone since ip address are not being configured on 
 it
 ---

 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.6.0


 VR does not start in basic zone since ip address are not being configured on 
 it
 Steps to reproduce:
 
 1.Bring up CS in basic zone with xen server cluster
 2.Try to deploy one guest vm using default cent os template
 Expected Result:
 ==
 VR should come up as part of vm deployment and vm deployment should be 
 successfull
 Actual Result:
 
 VR creation failed since the IP addresses not are getting assigned to VR's 
 guest and link local interfaces.
 Observations:
 ===
 1.During vr boot time, cloud-early-config ran successfully and VR console 
 output showed that ping to gateway was successful. However, after VR boot we 
 don't see any ip addresses on the VRs guest and link local ip address.
 2. If we run cloud-early-config manually from VR , ip addresses will be 
 assigned and persistent.
 Impact:
 =
 VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-8640) Uploads to S3 Secondary Storage fail, stay at 0% completed

2015-07-28 Thread Wido den Hollander (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wido den Hollander updated CLOUDSTACK-8640:
---
Fix Version/s: 4.6.0

 Uploads to S3 Secondary Storage fail, stay at 0% completed
 --

 Key: CLOUDSTACK-8640
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8640
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: SystemVM
Affects Versions: Future, 4.5.1
 Environment: Ceph RADOS Gateway with Civetweb as Secondary Storage
Reporter: Wido den Hollander
Assignee: Wido den Hollander
  Labels: amazon, ceph, rados, s3, secondary_storage
 Fix For: 4.6.0


 I noticed this after upgrading to 4.5.2 (build from 4.5 branch).
 Uploads never completed when a template was downloaded en directly uploaded 
 to S3 secondary storage provided by Ceph's RADOS Gateway using Multipart.
 After searching for hours I found this: 
 http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/event/ProgressEvent.html#getBytesTransferred()
 The ProgressEvent of the returned that 0 bytes had been transferred. But when 
 using the getBytes() method it actually works.
 The upload succeeds, but we check if the amount of uploaded bytes is equal or 
 more then what we expected. If not, we say the upload failed.
 This happens inside S3TemplateDownloader (which really needs some fixes 
 btw)
 Tracing this down if it's related to Ceph or actually something in 
 S3TemplateDownloader.
 I also tried the Amazon SDK 1.9.34, but that didn't make a difference.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8677) Call-home functionality for CloudStack


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644088#comment-14644088
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8677:


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

https://github.com/apache/cloudstack/pull/625#discussion_r35627154
  
--- Diff: server/src/org/apache/cloudstack/report/UsageReporter.java ---
@@ -0,0 +1,487 @@
+// 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.
+package org.apache.cloudstack.report;
+
+import java.util.concurrent.Executors;
+import java.util.concurrent.ScheduledExecutorService;
+import java.util.concurrent.TimeUnit;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Map;
+import java.util.HashMap;
+import java.text.DateFormat;
+import java.text.SimpleDateFormat;
+import java.sql.Connection;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.sql.SQLException;
+import java.net.URL;
+import java.net.SocketTimeoutException;
+import java.net.MalformedURLException;
+import java.net.ProtocolException;
+import java.net.UnknownHostException;
+import java.io.OutputStreamWriter;
+import java.io.IOException;
+
+import javax.inject.Inject;
+import javax.net.ssl.HttpsURLConnection;
+
+import org.apache.log4j.Logger;
+import org.springframework.stereotype.Component;
+
+import org.apache.cloudstack.framework.config.dao.ConfigurationDao;
+import org.apache.cloudstack.managed.context.ManagedContextRunnable;
+
+import org.apache.cloudstack.storage.datastore.db.PrimaryDataStoreDao;
+import org.apache.cloudstack.storage.datastore.db.StoragePoolVO;
+
+import org.apache.commons.codec.digest.DigestUtils;
+
+import com.cloud.host.HostVO;
+import com.cloud.host.dao.HostDao;
+import com.cloud.dc.ClusterVO;
+import com.cloud.dc.dao.ClusterDao;
+import com.cloud.dc.DataCenterVO;
+import com.cloud.dc.dao.DataCenterDao;
+import com.cloud.vm.UserVmVO;
+import com.cloud.vm.dao.UserVmDao;
+import com.cloud.vm.VMInstanceVO;
+import com.cloud.vm.dao.VMInstanceDao;
+import com.cloud.utils.db.SearchCriteria;
+import com.cloud.utils.NumbersUtil;
+import com.cloud.utils.component.ManagerBase;
+import com.cloud.utils.component.ComponentMethodInterceptable;
+import com.cloud.utils.concurrency.NamedThreadFactory;
+import com.cloud.utils.db.DB;
+import com.cloud.utils.db.TransactionLegacy;
+import com.cloud.upgrade.dao.VersionDao;
+import com.cloud.upgrade.dao.VersionVO;
+import com.cloud.storage.dao.DiskOfferingDao;
+import com.cloud.storage.DiskOfferingVO;
+import com.google.gson.Gson;
+import com.google.gson.GsonBuilder;
+import com.google.common.util.concurrent.AtomicLongMap;
+
+@Component
+public class UsageReporter extends ManagerBase implements 
ComponentMethodInterceptable {
+public static final Logger s_logger = 
Logger.getLogger(UsageReporter.class.getName());
+
+/* !FIX ME! This should point to a Apache Infra host with SSL! */
+private String reportHost = https://call-home.cloudstack.org/report;;
+
+private String uniqueID = null;
+
+private static UsageReporter s_instance = null;
+
+private ScheduledExecutorService _executor = null;
+
+@Inject
+private ConfigurationDao _configDao;
+@Inject
+private HostDao _hostDao;
+@Inject
+private ClusterDao _clusterDao;
+@Inject
+private PrimaryDataStoreDao _storagePoolDao;
+@Inject
+private DataCenterDao _dataCenterDao;
+@Inject
+private UserVmDao _userVmDao;
+@Inject
+private VMInstanceDao _vmInstance;
+@Inject
+private VersionDao _versionDao;
+@Inject
+private DiskOfferingDao _diskOfferingDao;
+
+int usageReportInterval = -1;
+
+public static

[jira] [Commented] (CLOUDSTACK-8651) [Browser Based Upload Template] Partially uploaded templates doesn't get cleaned up after the SSVM handling it is destroyed


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644092#comment-14644092
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8651:


Github user sailajamada commented on the pull request:

https://github.com/apache/cloudstack/pull/607#issuecomment-125512446
  

Hi ,
 
I have fixed the test data file to move the browser volume/template 
specific data from configurableData” section.
 
But automation script is still pointing the data to configurableData” 
section :
 
Ex:
=
 
  84 
cls.uploadurl=cls.testdata[configurableData][browser_upload_template][cls.uploadtemplateformat][url]
  85 
cls.templatename=cls.testdata[configurableData][browser_upload_template][cls.uploadtemplateformat][templatename]
  86 
cls.md5sum=cls.testdata[configurableData][browser_upload_template][cls.uploadtemplateformat][checksum]
  87 
cls.templatedisplaytext=cls.testdata[configurableData][browser_upload_template][cls.uploadtemplateformat][displaytext]
  88 
cls.templatehypervisor=cls.testdata[configurableData][browser_upload_template][cls.uploadtemplateformat][hypervisor]
  89 
cls.templateostypeid=cls.testdata[configurableData][browser_upload_template][cls.uploadtemplateformat][ostypeid]
=
 
This needs to be fixed. I am yet to work on it. 
 
Thanks,
Sailaja.M



 [Browser Based Upload Template] Partially uploaded templates doesn't get 
 cleaned up after the SSVM handling it is destroyed
 ---

 Key: CLOUDSTACK-8651
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8651
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.6.0
Reporter: Koushik Das
Assignee: Koushik Das
 Fix For: 4.6.0


 Repro steps:
 1. Make a call to getuploadparamsfortemplate, don't start actual upload to 
 SSVM or make sure that the upload is in partially completed state.
 2. Destroy SSVM (when template state is NotUploaded or UploadInProgress).
 3. After a new SSVM comes up, these templates continue to remain in the same 
 state and cannot be removed/cleaned-up.
 The issue is happening as the original SSVM is destroyed and no longer able 
 to monitor the template. The fix is to clean-up the partially uploaded 
 templates as part of template sync-up when the new SSVM comes up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8682) Replace openswan ipsec with strongswan ipsec

2015-07-28 Thread Jayapal Reddy (JIRA)

Jayapal Reddy created CLOUDSTACK-8682:
-

 Summary: Replace openswan ipsec with strongswan ipsec
 Key: CLOUDSTACK-8682
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8682
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.0.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.6.0


Currently VR is using openswan ipsec solution. Openswan is currently not 
maintained by community.  Where as stronswan is maintained by Debian community. 
So updates are easy with the strongswan.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-8675) master branch fail to build .deb packages.

2015-07-28 Thread Pierre-Luc Dion (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre-Luc Dion closed CLOUDSTACK-8675.
---
Resolution: Fixed

 master branch fail to build .deb packages.
 --

 Key: CLOUDSTACK-8675
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8675
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Packaging
Affects Versions: 4.6.0
Reporter: Pierre-Luc Dion
Assignee: Pierre-Luc Dion
Priority: Blocker

 building .deb package fail because cloud-agent.jar not found during packaging.
 {code}
 make[1]: Leaving directory 
 `/home/jenkins/build/workspace/package-deb-master/dist/debian/cloudstack-4.6.0'
dh_auto_test
dh_testroot
dh_prep
dh_installdirs
debian/rules override_dh_auto_install
 make[1]: Entering directory 
 `/home/jenkins/build/workspace/package-deb-master/dist/debian/cloudstack-4.6.0'
 # Common packages
 mkdir -p debian/tmp//etc/cloudstack
 mkdir -p debian/tmp//etc/init.d
 mkdir -p debian/tmp/var/cache/cloudstack
 mkdir -p debian/tmp/var/log/cloudstack
 mkdir -p debian/tmp/var/lib/cloudstack
 mkdir -p debian/tmp/usr/bin
 mkdir -p debian/tmp/usr/share
 # cloudstack-agent
 mkdir debian/tmp//etc/cloudstack/agent
 mkdir debian/tmp//etc/profile.d
 mkdir debian/tmp/var/log/cloudstack/agent
 mkdir debian/tmp/usr/share/cloudstack-agent
 mkdir debian/tmp/usr/share/cloudstack-agent/plugins
 install -D agent/target/cloud-agent-.jar 
 debian/tmp/usr/share/cloudstack-agent/lib/cloudstack-agent.jar
 install: cannot stat `agent/target/cloud-agent-.jar': No such file or 
 directory
 make[1]: *** [override_dh_auto_install] Error 1
 make[1]: Leaving directory 
 `/home/jenkins/build/workspace/package-deb-master/dist/debian/cloudstack-4.6.0'
 make: *** [binary] Error 2
 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 
 2
 Build step 'Execute shell' marked build as failure
 Archiving artifacts
 Sending e-mails to: h...@apache.org
 Started calculate disk usage of build
 Finished Calculation of disk usage of build in 0 seconds
 Started calculate disk usage of workspace
 Finished Calculation of disk usage of workspace in  5 minutes
 Finished: FAILURE
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it

2015-07-28 Thread Wilder Rodrigues (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644413#comment-14644413
 ] 

Wilder Rodrigues commented on CLOUDSTACK-8668:
--

I will mark this issue as resolved, since the port problem has been created 
under another issue id.

 VR does not start in basic zone since ip address are not being configured on 
 it
 ---

 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.6.0


 VR does not start in basic zone since ip address are not being configured on 
 it
 Steps to reproduce:
 
 1.Bring up CS in basic zone with xen server cluster
 2.Try to deploy one guest vm using default cent os template
 Expected Result:
 ==
 VR should come up as part of vm deployment and vm deployment should be 
 successfull
 Actual Result:
 
 VR creation failed since the IP addresses not are getting assigned to VR's 
 guest and link local interfaces.
 Observations:
 ===
 1.During vr boot time, cloud-early-config ran successfully and VR console 
 output showed that ping to gateway was successful. However, after VR boot we 
 don't see any ip addresses on the VRs guest and link local ip address.
 2. If we run cloud-early-config manually from VR , ip addresses will be 
 assigned and persistent.
 Impact:
 =
 VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8677) Call-home functionality for CloudStack


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644390#comment-14644390
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8677:


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

https://github.com/apache/cloudstack/pull/625#discussion_r35649303
  
--- Diff: server/src/org/apache/cloudstack/report/UsageReporter.java ---
@@ -0,0 +1,490 @@
+// 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.
+package org.apache.cloudstack.report;
+
+import java.util.concurrent.Executors;
+import java.util.concurrent.ScheduledExecutorService;
+import java.util.concurrent.TimeUnit;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Map;
+import java.util.HashMap;
+import java.text.DateFormat;
+import java.text.SimpleDateFormat;
+import java.sql.Connection;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.sql.SQLException;
+import java.net.URL;
+import java.net.SocketTimeoutException;
+import java.net.MalformedURLException;
+import java.net.ProtocolException;
+import java.net.UnknownHostException;
+import java.io.OutputStreamWriter;
+import java.io.IOException;
+
+import javax.inject.Inject;
+import javax.net.ssl.HttpsURLConnection;
+
+import org.apache.log4j.Logger;
+import org.springframework.stereotype.Component;
+
+import org.apache.cloudstack.framework.config.dao.ConfigurationDao;
+import org.apache.cloudstack.managed.context.ManagedContextRunnable;
+
+import org.apache.cloudstack.storage.datastore.db.PrimaryDataStoreDao;
+import org.apache.cloudstack.storage.datastore.db.StoragePoolVO;
+
+import org.apache.commons.codec.digest.DigestUtils;
+
+import com.cloud.host.HostVO;
+import com.cloud.host.dao.HostDao;
+import com.cloud.dc.ClusterVO;
+import com.cloud.dc.dao.ClusterDao;
+import com.cloud.dc.DataCenterVO;
+import com.cloud.dc.dao.DataCenterDao;
+import com.cloud.vm.UserVmVO;
+import com.cloud.vm.dao.UserVmDao;
+import com.cloud.vm.VMInstanceVO;
+import com.cloud.vm.dao.VMInstanceDao;
+import com.cloud.utils.db.SearchCriteria;
+import com.cloud.utils.NumbersUtil;
+import com.cloud.utils.component.ManagerBase;
+import com.cloud.utils.component.ComponentMethodInterceptable;
+import com.cloud.utils.concurrency.NamedThreadFactory;
+import com.cloud.utils.db.DB;
+import com.cloud.utils.db.TransactionLegacy;
+import com.cloud.upgrade.dao.VersionDao;
+import com.cloud.upgrade.dao.VersionVO;
+import com.cloud.storage.dao.DiskOfferingDao;
+import com.cloud.storage.DiskOfferingVO;
+import com.google.gson.Gson;
+import com.google.gson.GsonBuilder;
+import com.google.common.util.concurrent.AtomicLongMap;
+
+@Component
+public class UsageReporter extends ManagerBase implements 
ComponentMethodInterceptable {
+public static final Logger s_logger = 
Logger.getLogger(UsageReporter.class.getName());
+
+/* !FIX ME! This should point to a Apache Infra host with SSL! */
+private String reportHost = https://call-home.cloudstack.org/report;;
+
+private String uniqueID = null;
+
+private static UsageReporter s_instance = null;
+
+private ScheduledExecutorService _executor = null;
+
+@Inject
+private ConfigurationDao _configDao;
+@Inject
+private HostDao _hostDao;
+@Inject
+private ClusterDao _clusterDao;
+@Inject
+private PrimaryDataStoreDao _storagePoolDao;
+@Inject
+private DataCenterDao _dataCenterDao;
+@Inject
+private UserVmDao _userVmDao;
+@Inject
+private VMInstanceDao _vmInstance;
+@Inject
+private VersionDao _versionDao;
+@Inject
+private DiskOfferingDao _diskOfferingDao;
+
+int usageReportInterval = -1;
+
+public static

[jira] [Commented] (CLOUDSTACK-8638) Cloudstack deb packages don't include update_host_passwd.sh

2015-07-28 Thread Pierre-Luc Dion (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644356#comment-14644356
 ] 

Pierre-Luc Dion commented on CLOUDSTACK-8638:
-

[~bo...@pcextreme.nl] can you confirm it is still the case on mastar branch ?

 Cloudstack deb packages don't include update_host_passwd.sh
 ---

 Key: CLOUDSTACK-8638
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8638
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Packaging
Affects Versions: 4.6.0
Reporter: Boris Schrijver
Priority: Blocker

 When building the master; Cloudstack deb packages don't include 
 update_host_passwd.sh



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8685) [VPC_VR] Default route is not configured on VPC VR

2015-07-28 Thread Sanjeev N (JIRA)

Sanjeev N created CLOUDSTACK-8685:
-

 Summary: [VPC_VR] Default route is not configured on VPC VR
 Key: CLOUDSTACK-8685
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8685
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Advanced zone with VPC. Latest build from ACS master.
Reporter: Sanjeev N
Priority: Critical


[VPC_VR] Default route is not configured on VPC VR

Steps to reproduce:

1.Bring up CS in advanced zone 
2.Create VPC and wait for the VR to come into running state
3.Connect  to VR and verify route table information

Result:
==
Default route is not configured on VPC VR.
root@r-9-VM:/var/cache/cloud# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
10.1.1.00.0.0.0 255.255.255.0   U 0  00 eth2
10.1.2.00.0.0.0 255.255.255.0   U 0  00 eth3
10.220.128.00.0.0.0 255.255.224.0   U 0  00 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0  00 eth0
root@r-9-VM:/var/cache/cloud#

Observations:
===
When vr boots up, we run cloud-early-config. This will clean if there is any 
default route exists on VR. Then we execute vpc_ipassoc.sh to configure public 
nic and default route via public nic. However, in the latest ACS master we are 
not executing vpc_ipassoc.sh.
For any configuration on VR , we are creating configuration file and applying 
it with update_config.py. 
Looks like adding default route is missing in the confguration file.

Following is the configuration file genearted on VR :
015-07-29 05:20:39,132 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-402:ctx-83549002) VR Config file 
VR-d3b73941-7b3d-489a-bcc6-47c6a777c950.cfg got created in VR, ip 169.254.0.54 
with content
#Apache CloudStack Virtual Router Config File
version
1.0
/version
file
/var/cache/cloud/ip_associations.json
{ip_address:[{public_ip:10.220.135.97,source_nat:false,add:true,one_to_one_nat:false,first_i_p:false,gateway:10.220.128.1,netmask:255.255.224.0,vif_mac_address:06:dd:e0:00:00:0e,nic_dev_id:1,new_nic:false},{public_ip:10.220.135.99,source_nat:false,add:true,one_to_one_nat:true,first_i_p:false,gateway:10.220.128.1,netmask:255.255.224.0,vif_mac_address:06:dd:e0:00:00:0e,nic_dev_id:1,new_nic:false}],type:ips}
/file
script
/opt/cloud/bin/update_config.py ip_associations.json
/script
file
/var/cache/cloud/staticnat_rules.json
{rules:[{revoke:false,source_ip_address:10.220.135.99,source_port_range:0:0,destination_ip_address:10.1.1.36}],type:staticnatrules}
/file
script
/opt/cloud/bin/update_config.py staticnat_rules.json
/script
file
/var/cache/cloud/forwarding_rules.json
{rules:[{revoke:false,protocol:tcp,source_ip_address:10.220.135.97,source_port_range:22:22,destination_ip_address:10.1.1.194,destination_port_range:22:22}],type:forwardrules}
/file
script
/opt/cloud/bin/update_config.py forwarding_rules.json
/script
file
/var/cache/cloud/network_acl.json
{device:eth2,mac_address:02:00:7c:a8:00:02,private_gateway_acl:false,nic_ip:10.1.1.1,nic_netmask:24,ingress_rules:[{type:tcp,first_port:22,last_port:22,cidr:0.0.0.0/0,allowed:true}],egress_rules:[{type:icmp,icmp_type:-1,icmp_code:-1,cidr:0.0.0.0/0,allowed:true}],type:networkacl}
/file
script
/opt/cloud/bin/update_config.py network_acl.json
/script
file
/var/cache/cloud/vm_dhcp_entry.json
{host_name:VM-403a0536-ba54-404f-a664-1b14d039497c,mac_address:02:00:10:ca:00:01,ipv4_adress:10.1.1.194,ipv6_duid:00:03:00:01:02:00:10:ca:00:01,default_gateway:10.1.1.1,default_entry:true,type:dhcpentry}
/file
script
/opt/cloud/bin/update_config.py vm_dhcp_entry.json
/script
file
/var/cache/cloud/vm_dhcp_entry.json
{host_name:VM-4c5e69ab-65dd-4315-b8fb-702f5599ede0,mac_address:02:00:0f:22:00:03,ipv4_adress:10.1.1.36,ipv6_duid:00:03:00:01:02:00:0f:22:00:03,default_gateway:10.1.1.1,default_entry:true,type:dhcpentry}
/file
script
/opt/cloud/bin/update_config.py vm_dhcp_entry.json
/script
file
/var/cache/cloud/vm_metadata.json
{vm_ip_address:10.1.1.194,vm_metadata:[[userdata,user-data,null],[metadata,service-offering,Tiny
 
Instance],[metadata,availability-zone,XenRT-Zone-0],[metadata,local-ipv4,10.1.1.194],[metadata,local-hostname,VM-403a0536-ba54-404f-a664-1b14d039497c],[metadata,public-ipv4,10.220.135.96],[metadata,public-hostname,10.220.135.96],[metadata,instance-id,403a0536-ba54-404f-a664-1b14d039497c],[metadata,vm-id,403a0536-ba54-404f-a664-1b14d039497c],[metadata,public-keys,null],[metadata,cloud-identifier,CloudStack-{5bcd0291-2ac9-4d68-9887-bda6ae6596c2}]],type:vmdata}
/file
script
/opt/cloud/bin/update_config.py vm_metadata.json
/script
file
/var/cache/cloud/vm_metadata.json

[jira] [Commented] (CLOUDSTACK-8677) Call-home functionality for CloudStack


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644470#comment-14644470
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8677:


Github user sateesh-chodapuneedi commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/625#discussion_r35655350
  
--- Diff: server/src/org/apache/cloudstack/report/UsageReporter.java ---
@@ -0,0 +1,490 @@
+// 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.
+package org.apache.cloudstack.report;
+
+import java.util.concurrent.Executors;
+import java.util.concurrent.ScheduledExecutorService;
+import java.util.concurrent.TimeUnit;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Map;
+import java.util.HashMap;
+import java.text.DateFormat;
+import java.text.SimpleDateFormat;
+import java.sql.Connection;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.sql.SQLException;
+import java.net.URL;
+import java.net.SocketTimeoutException;
+import java.net.MalformedURLException;
+import java.net.ProtocolException;
+import java.net.UnknownHostException;
+import java.io.OutputStreamWriter;
+import java.io.IOException;
+
+import javax.inject.Inject;
+import javax.net.ssl.HttpsURLConnection;
+
+import org.apache.log4j.Logger;
+import org.springframework.stereotype.Component;
+
+import org.apache.cloudstack.framework.config.dao.ConfigurationDao;
+import org.apache.cloudstack.managed.context.ManagedContextRunnable;
+
+import org.apache.cloudstack.storage.datastore.db.PrimaryDataStoreDao;
+import org.apache.cloudstack.storage.datastore.db.StoragePoolVO;
+
+import org.apache.commons.codec.digest.DigestUtils;
+
+import com.cloud.host.HostVO;
+import com.cloud.host.dao.HostDao;
+import com.cloud.dc.ClusterVO;
+import com.cloud.dc.dao.ClusterDao;
+import com.cloud.dc.DataCenterVO;
+import com.cloud.dc.dao.DataCenterDao;
+import com.cloud.vm.UserVmVO;
+import com.cloud.vm.dao.UserVmDao;
+import com.cloud.vm.VMInstanceVO;
+import com.cloud.vm.dao.VMInstanceDao;
+import com.cloud.utils.db.SearchCriteria;
+import com.cloud.utils.NumbersUtil;
+import com.cloud.utils.component.ManagerBase;
+import com.cloud.utils.component.ComponentMethodInterceptable;
+import com.cloud.utils.concurrency.NamedThreadFactory;
+import com.cloud.utils.db.DB;
+import com.cloud.utils.db.TransactionLegacy;
+import com.cloud.upgrade.dao.VersionDao;
+import com.cloud.upgrade.dao.VersionVO;
+import com.cloud.storage.dao.DiskOfferingDao;
+import com.cloud.storage.DiskOfferingVO;
+import com.google.gson.Gson;
+import com.google.gson.GsonBuilder;
+import com.google.common.util.concurrent.AtomicLongMap;
+
+@Component
+public class UsageReporter extends ManagerBase implements 
ComponentMethodInterceptable {
+public static final Logger s_logger = 
Logger.getLogger(UsageReporter.class.getName());
+
+/* !FIX ME! This should point to a Apache Infra host with SSL! */
+private String reportHost = https://call-home.cloudstack.org/report;;
+
+private String uniqueID = null;
+
+private static UsageReporter s_instance = null;
+
+private ScheduledExecutorService _executor = null;
+
+@Inject
+private ConfigurationDao _configDao;
+@Inject
+private HostDao _hostDao;
+@Inject
+private ClusterDao _clusterDao;
+@Inject
+private PrimaryDataStoreDao _storagePoolDao;
+@Inject
+private DataCenterDao _dataCenterDao;
+@Inject
+private UserVmDao _userVmDao;
+@Inject
+private VMInstanceDao _vmInstance;
+@Inject
+private VersionDao _versionDao;
+@Inject
+private DiskOfferingDao _diskOfferingDao;
+
+int usageReportInterval = -1;
+
+public

[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644486#comment-14644486
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8668:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/627#issuecomment-125639101
  
Hi @kishankavala 

Are you looking at the other problem or can I have a look into it?

I was able to reproduce here... just let me know if you need help.

Cheers,
Wilder


 VR does not start in basic zone since ip address are not being configured on 
 it
 ---

 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.6.0


 VR does not start in basic zone since ip address are not being configured on 
 it
 Steps to reproduce:
 
 1.Bring up CS in basic zone with xen server cluster
 2.Try to deploy one guest vm using default cent os template
 Expected Result:
 ==
 VR should come up as part of vm deployment and vm deployment should be 
 successfull
 Actual Result:
 
 VR creation failed since the IP addresses not are getting assigned to VR's 
 guest and link local interfaces.
 Observations:
 ===
 1.During vr boot time, cloud-early-config ran successfully and VR console 
 output showed that ping to gateway was successful. However, after VR boot we 
 don't see any ip addresses on the VRs guest and link local ip address.
 2. If we run cloud-early-config manually from VR , ip addresses will be 
 assigned and persistent.
 Impact:
 =
 VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8683) Shared network VR ssh on port 3922 is blocked

Kishan Kavala created CLOUDSTACK-8683:
-

 Summary: Shared network VR ssh on port 3922 is blocked
 Key: CLOUDSTACK-8683
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8683
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Kishan Kavala
Priority: Blocker


ssh to Shared network VR on link_local_ip @ port 3922 is blocked.
MS is not able to program any rules on the VR due to this



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644273#comment-14644273
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8668:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/627#issuecomment-125572581
  
Hi @kishankavala 

But you said you tested VR successfully started on shared network. All IPs 
are configured properly Based on that, I assumed it was working. I'm now 
building lated master in order to test it as well.

Will you look at the other problem?

Cheers,
Wilder


 VR does not start in basic zone since ip address are not being configured on 
 it
 ---

 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Wilder Rodrigues
Priority: Blocker

 VR does not start in basic zone since ip address are not being configured on 
 it
 Steps to reproduce:
 
 1.Bring up CS in basic zone with xen server cluster
 2.Try to deploy one guest vm using default cent os template
 Expected Result:
 ==
 VR should come up as part of vm deployment and vm deployment should be 
 successfull
 Actual Result:
 
 VR creation failed since the IP addresses not are getting assigned to VR's 
 guest and link local interfaces.
 Observations:
 ===
 1.During vr boot time, cloud-early-config ran successfully and VR console 
 output showed that ping to gateway was successful. However, after VR boot we 
 don't see any ip addresses on the VRs guest and link local ip address.
 2. If we run cloud-early-config manually from VR , ip addresses will be 
 assigned and persistent.
 Impact:
 =
 VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-6171) Cloudstack:KVM:: Snapshot stuck in Creating Status forever.‏


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi updated CLOUDSTACK-6171:

Priority: Critical  (was: Blocker)

 Cloudstack:KVM:: Snapshot stuck in Creating Status forever.‏
 

 Key: CLOUDSTACK-6171
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6171
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Infra, Install and Setup, KVM, Management Server
Affects Versions: 4.2.0, 4.2.1
 Environment: RHEL 6.4
Reporter: Rohit Kumar
Priority: Critical
  Labels: newbie, test
   Original Estimate: 168h
  Remaining Estimate: 168h

 Hi,
 I am working on CloudStack infrastructure service to build our organization 
 framework.
 For this purpose, RHEL 6.4, Cloudstack 4.2.1 and KVM are being used.
 I have been working around for long to figure out the below mentioned Issue 
 but unfortunately could not.
 Issue: Snapshot gets stuck in the state Creating forever.
 Impact: Couldn't get the snapshot consequently and thus, the instance from 
 the CloudStack's UI could not be started/Stopped.
 Please see below trace from Management Server log which I think is the reason 
 behind this.
 me:ROOT-13,path:ec5692cb-7758-4618-b589-09cb71e45dba,size:21474836480,type:ROOT,storagePoolType:NetworkFilesystem,storagePoolUuid:d41d4103-a11d-3160-8a3b-6469c574a93f,deviceId:0},{id:19,name:DATA-13,path:8017ac65-b52b-450b-937f-d92178de2f34,size:21474836480,type:DATADISK,storagePoolType:NetworkFilesystem,storagePoolUuid:d41d4103-a11d-3160-8a3b-6469c574a93f,deviceId:1}],target:{id:13,snapshotName:i-2-13-VM_VS_20140225120244,type:Disk,current:false,description:new},vmName:i-2-13-VM,guestOSType:Red
  Hat Enterprise Linux 6.4 (64-bit),wait:1800}}] }
 2014-02-25 17:32:45,254 DEBUG [agent.transport.Request] 
 (AgentManager-Handler-11:null) Seq 1-2016739514: Processing:  { Ans: , 
 MgmtId: 181122461670954, via: 1, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.UnsupportedAnswer:{result:false,details:Unsupported
  command issued:com.cloud.agent.api.CreateVMSnapshotCommand.  Are you sure 
 you got the right type of server?,wait:0}}] }
 2014-02-25 17:32:45,254 DEBUG [agent.transport.Request] 
 (Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) Seq 
 1-2016739514: Received:  { Ans: , MgmtId: 181122461670954, via: 1, Ver: v1, 
 Flags: 10, { UnsupportedAnswer } }
 2014-02-25 17:32:45,254 WARN  [agent.manager.AgentManagerImpl] 
 (Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) 
 Unsupported Command: Unsupported command 
 issued:com.cloud.agent.api.CreateVMSnapshotCommand.  Are you sure you got the 
 right type of server?
 2014-02-25 17:32:45,254 ERROR [vm.snapshot.VMSnapshotManagerImpl] 
 (Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) Create vm 
 snapshot i-2-13-VM_VS_20140225120244 failed for vm: i-2-13-VM due to 
 com.cloud.agent.api.UnsupportedAnswer cannot be cast to 
 com.cloud.agent.api.CreateVMSnapshotAnswer
 2014-02-25 17:32:45,265 DEBUG [cloud.api.ApiServlet] (catalina-exec-11:null) 
 ===START===  192.168.125.241 -- GET  
 command=listOsTypesresponse=jsonsessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3D_=1393329472271
 2014-02-25 17:32:45,324 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null) 
 ===START===  192.168.125.241 -- GET  
 command=listTagsresponse=jsonsessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3DresourceId=340c69ae-f3a0-4966-aa0b-c799e944404fresourceType=UserVmlistAll=true_=1393329472305
 2014-02-25 17:32:45,330 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null) 
 ===END===  192.168.125.241 -- GET  
 command=listTagsresponse=jsonsessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3DresourceId=340c69ae-f3a0-4966-aa0b-c799e944404fresourceType=UserVmlistAll=true_=1393329472305
 2014-02-25 17:32:45,373 DEBUG [cloud.api.ApiServlet] (catalina-exec-11:null) 
 ===END===  192.168.125.241 -- GET  
 command=listOsTypesresponse=jsonsessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3D_=1393329472271
 2014-02-25 17:32:45,419 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) 
 Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.vmsnapshot.CreateVMSnapshotCmd
 com.cloud.utils.exception.CloudRuntimeException: 
 com.cloud.agent.api.UnsupportedAnswer cannot be cast to 
 com.cloud.agent.api.CreateVMSnapshotAnswer
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.createVmSnapshotInternal(VMSnapshotManagerImpl.java:406)
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.creatVMSnapshot(VMSnapshotManagerImpl.java:356)
 at

[jira] [Updated] (CLOUDSTACK-6171) Cloudstack:KVM:: Snapshot stuck in Creating Status forever.‏


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi updated CLOUDSTACK-6171:

Issue Type: Improvement  (was: Bug)

 Cloudstack:KVM:: Snapshot stuck in Creating Status forever.‏
 

 Key: CLOUDSTACK-6171
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6171
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Infra, Install and Setup, KVM, Management Server
Affects Versions: 4.2.0, 4.2.1
 Environment: RHEL 6.4
Reporter: Rohit Kumar
Priority: Blocker
  Labels: newbie, test
   Original Estimate: 168h
  Remaining Estimate: 168h

 Hi,
 I am working on CloudStack infrastructure service to build our organization 
 framework.
 For this purpose, RHEL 6.4, Cloudstack 4.2.1 and KVM are being used.
 I have been working around for long to figure out the below mentioned Issue 
 but unfortunately could not.
 Issue: Snapshot gets stuck in the state Creating forever.
 Impact: Couldn't get the snapshot consequently and thus, the instance from 
 the CloudStack's UI could not be started/Stopped.
 Please see below trace from Management Server log which I think is the reason 
 behind this.
 me:ROOT-13,path:ec5692cb-7758-4618-b589-09cb71e45dba,size:21474836480,type:ROOT,storagePoolType:NetworkFilesystem,storagePoolUuid:d41d4103-a11d-3160-8a3b-6469c574a93f,deviceId:0},{id:19,name:DATA-13,path:8017ac65-b52b-450b-937f-d92178de2f34,size:21474836480,type:DATADISK,storagePoolType:NetworkFilesystem,storagePoolUuid:d41d4103-a11d-3160-8a3b-6469c574a93f,deviceId:1}],target:{id:13,snapshotName:i-2-13-VM_VS_20140225120244,type:Disk,current:false,description:new},vmName:i-2-13-VM,guestOSType:Red
  Hat Enterprise Linux 6.4 (64-bit),wait:1800}}] }
 2014-02-25 17:32:45,254 DEBUG [agent.transport.Request] 
 (AgentManager-Handler-11:null) Seq 1-2016739514: Processing:  { Ans: , 
 MgmtId: 181122461670954, via: 1, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.UnsupportedAnswer:{result:false,details:Unsupported
  command issued:com.cloud.agent.api.CreateVMSnapshotCommand.  Are you sure 
 you got the right type of server?,wait:0}}] }
 2014-02-25 17:32:45,254 DEBUG [agent.transport.Request] 
 (Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) Seq 
 1-2016739514: Received:  { Ans: , MgmtId: 181122461670954, via: 1, Ver: v1, 
 Flags: 10, { UnsupportedAnswer } }
 2014-02-25 17:32:45,254 WARN  [agent.manager.AgentManagerImpl] 
 (Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) 
 Unsupported Command: Unsupported command 
 issued:com.cloud.agent.api.CreateVMSnapshotCommand.  Are you sure you got the 
 right type of server?
 2014-02-25 17:32:45,254 ERROR [vm.snapshot.VMSnapshotManagerImpl] 
 (Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) Create vm 
 snapshot i-2-13-VM_VS_20140225120244 failed for vm: i-2-13-VM due to 
 com.cloud.agent.api.UnsupportedAnswer cannot be cast to 
 com.cloud.agent.api.CreateVMSnapshotAnswer
 2014-02-25 17:32:45,265 DEBUG [cloud.api.ApiServlet] (catalina-exec-11:null) 
 ===START===  192.168.125.241 -- GET  
 command=listOsTypesresponse=jsonsessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3D_=1393329472271
 2014-02-25 17:32:45,324 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null) 
 ===START===  192.168.125.241 -- GET  
 command=listTagsresponse=jsonsessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3DresourceId=340c69ae-f3a0-4966-aa0b-c799e944404fresourceType=UserVmlistAll=true_=1393329472305
 2014-02-25 17:32:45,330 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null) 
 ===END===  192.168.125.241 -- GET  
 command=listTagsresponse=jsonsessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3DresourceId=340c69ae-f3a0-4966-aa0b-c799e944404fresourceType=UserVmlistAll=true_=1393329472305
 2014-02-25 17:32:45,373 DEBUG [cloud.api.ApiServlet] (catalina-exec-11:null) 
 ===END===  192.168.125.241 -- GET  
 command=listOsTypesresponse=jsonsessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3D_=1393329472271
 2014-02-25 17:32:45,419 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) 
 Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.vmsnapshot.CreateVMSnapshotCmd
 com.cloud.utils.exception.CloudRuntimeException: 
 com.cloud.agent.api.UnsupportedAnswer cannot be cast to 
 com.cloud.agent.api.CreateVMSnapshotAnswer
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.createVmSnapshotInternal(VMSnapshotManagerImpl.java:406)
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.creatVMSnapshot(VMSnapshotManagerImpl.java:356)
 at

[jira] [Commented] (CLOUDSTACK-6171) Cloudstack:KVM:: Snapshot stuck in Creating Status forever.‏


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644245#comment-14644245
 ] 

Rajani Karuturi commented on CLOUDSTACK-6171:
-

I misread it as volume snapshot. 

 Cloudstack:KVM:: Snapshot stuck in Creating Status forever.‏
 

 Key: CLOUDSTACK-6171
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6171
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Infra, Install and Setup, KVM, Management Server
Affects Versions: 4.2.0, 4.2.1
 Environment: RHEL 6.4
Reporter: Rohit Kumar
Priority: Blocker
  Labels: newbie, test
   Original Estimate: 168h
  Remaining Estimate: 168h

 Hi,
 I am working on CloudStack infrastructure service to build our organization 
 framework.
 For this purpose, RHEL 6.4, Cloudstack 4.2.1 and KVM are being used.
 I have been working around for long to figure out the below mentioned Issue 
 but unfortunately could not.
 Issue: Snapshot gets stuck in the state Creating forever.
 Impact: Couldn't get the snapshot consequently and thus, the instance from 
 the CloudStack's UI could not be started/Stopped.
 Please see below trace from Management Server log which I think is the reason 
 behind this.
 me:ROOT-13,path:ec5692cb-7758-4618-b589-09cb71e45dba,size:21474836480,type:ROOT,storagePoolType:NetworkFilesystem,storagePoolUuid:d41d4103-a11d-3160-8a3b-6469c574a93f,deviceId:0},{id:19,name:DATA-13,path:8017ac65-b52b-450b-937f-d92178de2f34,size:21474836480,type:DATADISK,storagePoolType:NetworkFilesystem,storagePoolUuid:d41d4103-a11d-3160-8a3b-6469c574a93f,deviceId:1}],target:{id:13,snapshotName:i-2-13-VM_VS_20140225120244,type:Disk,current:false,description:new},vmName:i-2-13-VM,guestOSType:Red
  Hat Enterprise Linux 6.4 (64-bit),wait:1800}}] }
 2014-02-25 17:32:45,254 DEBUG [agent.transport.Request] 
 (AgentManager-Handler-11:null) Seq 1-2016739514: Processing:  { Ans: , 
 MgmtId: 181122461670954, via: 1, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.UnsupportedAnswer:{result:false,details:Unsupported
  command issued:com.cloud.agent.api.CreateVMSnapshotCommand.  Are you sure 
 you got the right type of server?,wait:0}}] }
 2014-02-25 17:32:45,254 DEBUG [agent.transport.Request] 
 (Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) Seq 
 1-2016739514: Received:  { Ans: , MgmtId: 181122461670954, via: 1, Ver: v1, 
 Flags: 10, { UnsupportedAnswer } }
 2014-02-25 17:32:45,254 WARN  [agent.manager.AgentManagerImpl] 
 (Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) 
 Unsupported Command: Unsupported command 
 issued:com.cloud.agent.api.CreateVMSnapshotCommand.  Are you sure you got the 
 right type of server?
 2014-02-25 17:32:45,254 ERROR [vm.snapshot.VMSnapshotManagerImpl] 
 (Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) Create vm 
 snapshot i-2-13-VM_VS_20140225120244 failed for vm: i-2-13-VM due to 
 com.cloud.agent.api.UnsupportedAnswer cannot be cast to 
 com.cloud.agent.api.CreateVMSnapshotAnswer
 2014-02-25 17:32:45,265 DEBUG [cloud.api.ApiServlet] (catalina-exec-11:null) 
 ===START===  192.168.125.241 -- GET  
 command=listOsTypesresponse=jsonsessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3D_=1393329472271
 2014-02-25 17:32:45,324 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null) 
 ===START===  192.168.125.241 -- GET  
 command=listTagsresponse=jsonsessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3DresourceId=340c69ae-f3a0-4966-aa0b-c799e944404fresourceType=UserVmlistAll=true_=1393329472305
 2014-02-25 17:32:45,330 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null) 
 ===END===  192.168.125.241 -- GET  
 command=listTagsresponse=jsonsessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3DresourceId=340c69ae-f3a0-4966-aa0b-c799e944404fresourceType=UserVmlistAll=true_=1393329472305
 2014-02-25 17:32:45,373 DEBUG [cloud.api.ApiServlet] (catalina-exec-11:null) 
 ===END===  192.168.125.241 -- GET  
 command=listOsTypesresponse=jsonsessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3D_=1393329472271
 2014-02-25 17:32:45,419 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) 
 Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.vmsnapshot.CreateVMSnapshotCmd
 com.cloud.utils.exception.CloudRuntimeException: 
 com.cloud.agent.api.UnsupportedAnswer cannot be cast to 
 com.cloud.agent.api.CreateVMSnapshotAnswer
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.createVmSnapshotInternal(VMSnapshotManagerImpl.java:406)
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.creatVMSnapshot(VMSnapshotManagerImpl.java:356)
 at

[jira] [Resolved] (CLOUDSTACK-7539) [S3] Parallel deployment makes reference count of a cache in nfs secondary staging store negative(-1)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daan Hoogland resolved CLOUDSTACK-7539.
---
Resolution: Fixed

resolving for now as neither 4.5.2 nor 4.6.0 are out and user hasn't verified.

 [S3] Parallel deployment makes reference count of a cache in nfs secondary 
 staging store negative(-1)
 -

 Key: CLOUDSTACK-7539
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7539
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Storage Controller, Template
Affects Versions: Future, 4.3.0, 4.4.0, 4.5.0
 Environment: OS: CentOS 6.5, CloudStack Version: 4.3.0,  Hypervisor: 
 KVM,  Primary Storage: Local Storage,  Secondary Storage:   S3(RADOS),  Zone: 
  Advanced
Reporter: Hiroki Ohashi
Assignee: Daan Hoogland
Priority: Critical
 Fix For: 4.6.0, 4.5.2


 When we create some instances in parallel in an environment shown above, an 
 exception like ([#2]) happens. After that, reference count of a cache in NFS 
 Secondary Staging Store(SSS) becomes negative([#3]).
 In this situcation, we can't use a template used for creating the instances 
 because negative reference count will cause another
 exception([#4]). Furthermore, template caches in NFS SSS aren't cleaned up.
 I think this is related to CLOUDSTACK-6236. I'm using CloudStack 4.3.0 
 branch. The code was applied a patch of CLOUDSTACK-6236 to and also fixed 
 about volume reference count setter problem by myself. But the reference 
 count problem still happens.
 Conditions to trigger
   - A cache of a template isn't on NFS SSS.
   - Choose compute offering that occupies all resources in a host.(ex. Use 
 all cores and almost all memory)
   - Create multiple instances ([#1]).
 Other behaviors
   - Management server inserts multiple entries for template cache(ImageCache) 
 to cloud.template_store_ref.
   - SSVM probably downloads same template from S3 and creates multiple caches 
 to NFS SSS concurrently. Sometimes, SSVM retries download  and cache creation.
 (1)
 {anchor:1}
 {noformat}
 #! /bin/bash
 COMPUTE_OFFERING=b6fc0598-6903-48cc-b894-ead3bb0e39f5
 TEMPLATE=ef1d5a8e-5951-4036-a236-fe2d47224fe4
 ZONE=23156857-4722-4fc4-86d4-a12ca1028197
 NETWORK=4ba56179-f7b9-4560-a00e-80c946856ff8
 KEYPAIR=mykey
 NAME1=test-template-error-0003
 NAME2=test-template-error-0004
 cloudmonkey deploy virtualmachine serviceofferingid=${COMPUTE_OFFERING} 
 templateid=${TEMPLATE} zoneid=${ZONE} networkids=${NETWORK} 
 displayname=${NAME1} name=${NAME1} keypair=${KEYPAIR}
 sleep 1
 cloudmonkey deploy virtualmachine serviceofferingid=${COMPUTE_OFFERING} 
 templateid=${TEMPLATE} zoneid=${ZONE} networkids=${NETWORK} 
 displayname=${NAME2} name=${NAME2} keypair=${KEYPAIR}
 {noformat}
 (2)
 {anchor:2}
 {noformat}
 2014-09-10 17:22:51,249 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null) 
 Seq 171-1789133096: Processing:  { Ans: , MgmtId: 98532524288, via: 171, Ver: 
 v1, Flags: 10, 
 [{org.apache.cloudstack.storage.command.CopyCmdAnswer:{newData:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/3/330/22e69a40-0916-4d11-a07a-63d38e76887f.qcow2,id:0,accountId:0,hvm:false,name:22e69a40-0916-4d11-a07a-63d38e76887f.qcow2,size:14340259840,physicalSize:14340259840}},result:true,wait:0}}]
  }
 2014-09-10 17:22:51,249 DEBUG [c.c.a.t.Request] 
 (Job-Executor-162:ctx-4a2eb345 ctx-fbf59f27) Seq 171-1789133096: Received:  { 
 Ans: , MgmtId: 98532524288, via: 171, Ver: v1, Flags: 10, { CopyCmdAnswer } }
 2014-09-10 17:22:51,257 DEBUG [o.a.c.s.i.s.TemplateObject] 
 (Job-Executor-162:ctx-4a2eb345 ctx-fbf59f27) failed to update state
 com.cloud.utils.fsm.NoTransitionException: Unable to transition to a new 
 state from Allocated via OperationSuccessed
 at 
 com.cloud.utils.fsm.StateMachine2.getNextState(StateMachine2.java:83)
 at com.cloud.utils.fsm.StateMachine2.transitTo(StateMachine2.java:100)
 at 
 org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.update(ObjectInDataStoreManagerImpl.java:297)
 at 
 org.apache.cloudstack.storage.image.store.TemplateObject.processEvent(TemplateObject.java:225)
 at 
 org.apache.cloudstack.storage.cache.manager.StorageCacheManagerImpl.createCacheObject(StorageCacheManagerImpl.java:240)
 at 
 org.apache.cloudstack.storage.cache.manager.StorageCacheManagerImpl.createCacheObject(StorageCacheManagerImpl.java:267)
 at 
 org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyObject(AncientDataMotionStrategy.java:165)
 at 
 org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:428)

[jira] [Commented] (CLOUDSTACK-8683) Shared network VR ssh on port 3922 is blocked


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644263#comment-14644263
 ] 

Kishan Kavala commented on CLOUDSTACK-8683:
---

VR started successfully:
2015-07-28 14:59:19,348 DEBUG [c.c.a.t.Request] (DirectAgent-77:ctx-f7624550) 
Seq 3-4390446686732812409: Processing:  { Ans: , MgmtId: 233845178473044, via: 
3, Ver: v1, Flags: 10, 
[{com.cloud.agent.api.StartAnswer:{vm:{id:27,name:r-27-VM,bootloader:PyGrub,type:DomainRouter,cpus:1,minSpeed:500,maxSpeed:500,minRam:268435456,maxRam:268435456,arch:x86_64,os:Debian
 GNU/Linux 7(64-bit),platformEmulator:Debian Wheezy 7.0 
(64-bit),bootArgs: template=domP name=r-27-VM eth0ip=10.147.52.121 
eth0mask=255.255.255.0 gateway=10.147.52.1 domain=cs1cloud.internal cidrsize=24 
dhcprange=10.147.52.1 eth1ip=169.254.0.180 eth1mask=255.255.0.0 type=dhcpsrvr 
disable_rp_filter=true dns1=4.2.2.2 
baremetalnotificationsecuritykey=s67s-w0ooifUaTiCWhF24OUfj8JSRhTKTs6N-2rlWY2tkkPo-F0nZOv1lKTIyXXs0ir4vv0hatiUHFaddZxiDw
 
baremetalnotificationapikey=c9SUcsu8zctnSQmy43yhQB0HJM2HTDsRjEXd85s9IJOobOBRLaGZBa22vDH4IozJpIW8PHXVAFWu_W9qtdvYIA
 host=10.147.28.47 
port=8080,enableHA:true,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:NgZKb896siNBSaMS6m9y8A,params:{},uuid:2d2cc793-7ddc-49be-811c-86e859c31b11,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:206adec6-37e6-4596-a052-4a2e38d62d1e,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:4edf56a8-1f93-513a-4bb7-e859915dfa15,id:1,poolType:LVM,host:10.147.28.44,path:lvm,port:0,url:LVM://10.147.28.44/lvm/?ROLE=PrimarySTOREUUID=4edf56a8-1f93-513a-4bb7-e859915dfa15}},name:ROOT-27,size:3145728000,path:fe290765-5d3a-4547-84c6-14acb8a03f71,volumeId:27,vmName:r-27-VM,accountId:1,format:VHD,provisioningType:THIN,id:27,deviceId:0,hypervisorType:XenServer}},diskSeq:0,path:fe290765-5d3a-4547-84c6-14acb8a03f71,type:ROOT,_details:{managed:false,storagePort:0,storageHost:10.147.28.44,volumeSize:3145728000}}],nics:[{deviceId:0,networkRateMbps:200,defaultNic:true,pxeDisable:true,nicUuid:1ab3d3d9-008c-4c20-a34d-a15978a00fac,uuid:09c5c631-7164-42f6-a5ad-30826734305c,ip:10.147.52.121,netmask:255.255.255.0,gateway:10.147.52.1,mac:06:27:98:00:00:16,dns1:4.2.2.2,broadcastType:Vlan,type:Guest,broadcastUri:vlan://52,isolationUri:vlan://52,isSecurityGroupEnabled:false},{deviceId:1,networkRateMbps:-1,defaultNic:false,pxeDisable:true,nicUuid:b63b0fa9-de99-47d8-a913-f66215ef2e06,uuid:4c825977-669f-4777-9a44-a312952321c8,ip:169.254.0.180,netmask:255.255.0.0,gateway:169.254.0.1,mac:0e:00:a9:fe:00:b4,broadcastType:LinkLocal,type:Control,isSecurityGroupEnabled:false}]},_iqnToPath:{},result:true,wait:0}},{com.cloud.agent.api.check.CheckSshAnswer:{result:true,wait:0}},{com.cloud.agent.api.GetDomRVersionAnswer:{templateVersion:Cloudstack
 Release 4.6.0 Sun Jul 26 22:08:05 UTC 
2015,scriptsVersion:34389714eff6bb4cbfd2c8cc1cbaac85\n,result:true,details:Cloudstack
 Release 4.6.0 Sun Jul 26 22:08:05 UTC 
201534389714eff6bb4cbfd2c8cc1cbaac85\n,wait:0}},{com.cloud.agent.api.NetworkUsageAnswer:{routerName:r-27-VM,bytesSent:0,bytesReceived:0,result:true,details:,wait:0}},{com.cloud.agent.api.Answer:{result:true,details:Command
 aggregation 
started,wait:0}},{com.cloud.agent.api.Answer:{result:true,wait:0}},{com.cloud.agent.api.Answer:{result:true,wait:0}},{com.cloud.agent.api.Answer:{result:true,wait:0}},{com.cloud.agent.api.Answer:{result:true,wait:0}},{com.cloud.agent.api.Answer:{result:true,wait:0}},{com.cloud.agent.api.Answer:{result:true,details:Command
 aggregation finished,wait:0}}] }
2015-07-28 14:59:19,348 DEBUG [c.c.a.t.Request] 
(Work-Job-Executor-8:ctx-1de01f8b job-209/job-210 ctx-d40f9c75) Seq 
3-4390446686732812409: Received:  { Ans: , MgmtId: 233845178473044, via: 3, 
Ver: v1, Flags: 10, { StartAnswer, CheckSshAnswer, GetDomRVersionAnswer, 
NetworkUsageAnswer, Answer, Answer, Answer, Answer, Answer, Answer, Answer } }

SSH timed out while adding DHCP entry:
2015-07-28 15:01:27,099 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-81:ctx-6421786c) VR Config file vm_dhcp_entry.json got created in 
VR, ip 169.254.0.180 with content
{host_name:VM-b2364fd7-92ce-4ccc-89bc-842aabaa9a6e,mac_address:06:df:8a:00:00:18,ipv4_adress:10.147.52.123,ipv6_duid:00:03:00:01:06:df:8a:00:00:18,dns_adresses:10.147.52.120,default_gateway:10.147.52.1,default_entry:true,type:dhcpentry}
2015-07-28 15:01:27,099 DEBUG [c.c.a.r.v.VirtualRoutingResource] 
(DirectAgent-81:ctx-6421786c) Processing FileConfigItem, copying 266 characters 
to vm_dhcp_entry.json took 127595ms
2015-07-28 15:01:27,099 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-81:ctx-6421786c) Executing command in VR: 
/opt/cloud/bin/router_proxy.sh update_config.py 169.254.0.180 vm_dhcp_entry.json
2015-07-28 15:03:27,204 ERROR [c.c.u.s.SshHelper] (DirectAgent-81:ctx-6421786c) 
Timed out in waiting SSH execution result

[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644264#comment-14644264
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8668:


Github user asfgit closed the pull request at:

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


 VR does not start in basic zone since ip address are not being configured on 
 it
 ---

 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Wilder Rodrigues
Priority: Blocker

 VR does not start in basic zone since ip address are not being configured on 
 it
 Steps to reproduce:
 
 1.Bring up CS in basic zone with xen server cluster
 2.Try to deploy one guest vm using default cent os template
 Expected Result:
 ==
 VR should come up as part of vm deployment and vm deployment should be 
 successfull
 Actual Result:
 
 VR creation failed since the IP addresses not are getting assigned to VR's 
 guest and link local interfaces.
 Observations:
 ===
 1.During vr boot time, cloud-early-config ran successfully and VR console 
 output showed that ping to gateway was successful. However, after VR boot we 
 don't see any ip addresses on the VRs guest and link local ip address.
 2. If we run cloud-early-config manually from VR , ip addresses will be 
 assigned and persistent.
 Impact:
 =
 VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8651) [Browser Based Upload Template] Partially uploaded templates doesn't get cleaned up after the SSVM handling it is destroyed

[
https://issues.apache.org/jira/browse/CLOUDSTACK-8651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644274#comment-14644274
]

ASF GitHub Bot commented on CLOUDSTACK-8651:

Github user koushik-das commented on the pull request:

https://github.com/apache/cloudstack/pull/607#issuecomment-125573161

@DaanHoogland I will create a separate test file with new the test case for
now. Once the issues in test_browse_templates.py are fixed, will merge it back
later on.

[Browser Based Upload Template] Partially uploaded templates doesn't get
cleaned up after the SSVM handling it is destroyed
---

Key: CLOUDSTACK-8651
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8651
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.6.0
Reporter: Koushik Das
Assignee: Koushik Das
Fix For: 4.6.0

Repro steps:
1. Make a call to getuploadparamsfortemplate, don't start actual upload to
SSVM or make sure that the upload is in partially completed state.
2. Destroy SSVM (when template state is NotUploaded or UploadInProgress).
3. After a new SSVM comes up, these templates continue to remain in the same
state and cannot be removed/cleaned-up.
The issue is happening as the original SSVM is destroyed and no longer able
to monitor the template. The fix is to clean-up the partially uploaded
templates as part of template sync-up when the new SSVM comes up.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8675) master branch fail to build .deb packages.


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644292#comment-14644292
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8675:


Github user asfgit closed the pull request at:

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


 master branch fail to build .deb packages.
 --

 Key: CLOUDSTACK-8675
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8675
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Packaging
Affects Versions: 4.6.0
Reporter: Pierre-Luc Dion
Assignee: Pierre-Luc Dion
Priority: Blocker

 building .deb package fail because cloud-agent.jar not found during packaging.
 {code}
 make[1]: Leaving directory 
 `/home/jenkins/build/workspace/package-deb-master/dist/debian/cloudstack-4.6.0'
dh_auto_test
dh_testroot
dh_prep
dh_installdirs
debian/rules override_dh_auto_install
 make[1]: Entering directory 
 `/home/jenkins/build/workspace/package-deb-master/dist/debian/cloudstack-4.6.0'
 # Common packages
 mkdir -p debian/tmp//etc/cloudstack
 mkdir -p debian/tmp//etc/init.d
 mkdir -p debian/tmp/var/cache/cloudstack
 mkdir -p debian/tmp/var/log/cloudstack
 mkdir -p debian/tmp/var/lib/cloudstack
 mkdir -p debian/tmp/usr/bin
 mkdir -p debian/tmp/usr/share
 # cloudstack-agent
 mkdir debian/tmp//etc/cloudstack/agent
 mkdir debian/tmp//etc/profile.d
 mkdir debian/tmp/var/log/cloudstack/agent
 mkdir debian/tmp/usr/share/cloudstack-agent
 mkdir debian/tmp/usr/share/cloudstack-agent/plugins
 install -D agent/target/cloud-agent-.jar 
 debian/tmp/usr/share/cloudstack-agent/lib/cloudstack-agent.jar
 install: cannot stat `agent/target/cloud-agent-.jar': No such file or 
 directory
 make[1]: *** [override_dh_auto_install] Error 1
 make[1]: Leaving directory 
 `/home/jenkins/build/workspace/package-deb-master/dist/debian/cloudstack-4.6.0'
 make: *** [binary] Error 2
 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 
 2
 Build step 'Execute shell' marked build as failure
 Archiving artifacts
 Sending e-mails to: h...@apache.org
 Started calculate disk usage of build
 Finished Calculation of disk usage of build in 0 seconds
 Started calculate disk usage of workspace
 Finished Calculation of disk usage of workspace in  5 minutes
 Finished: FAILURE
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8677) Call-home functionality for CloudStack


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644194#comment-14644194
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8677:


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

https://github.com/apache/cloudstack/pull/625#discussion_r35633526
  
--- Diff: server/src/org/apache/cloudstack/report/UsageReporter.java ---
@@ -0,0 +1,487 @@
+// 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.
+package org.apache.cloudstack.report;
+
+import java.util.concurrent.Executors;
+import java.util.concurrent.ScheduledExecutorService;
+import java.util.concurrent.TimeUnit;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Map;
+import java.util.HashMap;
+import java.text.DateFormat;
+import java.text.SimpleDateFormat;
+import java.sql.Connection;
+import java.sql.PreparedStatement;
+import java.sql.ResultSet;
+import java.sql.SQLException;
+import java.net.URL;
+import java.net.SocketTimeoutException;
+import java.net.MalformedURLException;
+import java.net.ProtocolException;
+import java.net.UnknownHostException;
+import java.io.OutputStreamWriter;
+import java.io.IOException;
+
+import javax.inject.Inject;
+import javax.net.ssl.HttpsURLConnection;
+
+import org.apache.log4j.Logger;
+import org.springframework.stereotype.Component;
+
+import org.apache.cloudstack.framework.config.dao.ConfigurationDao;
+import org.apache.cloudstack.managed.context.ManagedContextRunnable;
+
+import org.apache.cloudstack.storage.datastore.db.PrimaryDataStoreDao;
+import org.apache.cloudstack.storage.datastore.db.StoragePoolVO;
+
+import org.apache.commons.codec.digest.DigestUtils;
+
+import com.cloud.host.HostVO;
+import com.cloud.host.dao.HostDao;
+import com.cloud.dc.ClusterVO;
+import com.cloud.dc.dao.ClusterDao;
+import com.cloud.dc.DataCenterVO;
+import com.cloud.dc.dao.DataCenterDao;
+import com.cloud.vm.UserVmVO;
+import com.cloud.vm.dao.UserVmDao;
+import com.cloud.vm.VMInstanceVO;
+import com.cloud.vm.dao.VMInstanceDao;
+import com.cloud.utils.db.SearchCriteria;
+import com.cloud.utils.NumbersUtil;
+import com.cloud.utils.component.ManagerBase;
+import com.cloud.utils.component.ComponentMethodInterceptable;
+import com.cloud.utils.concurrency.NamedThreadFactory;
+import com.cloud.utils.db.DB;
+import com.cloud.utils.db.TransactionLegacy;
+import com.cloud.upgrade.dao.VersionDao;
+import com.cloud.upgrade.dao.VersionVO;
+import com.cloud.storage.dao.DiskOfferingDao;
+import com.cloud.storage.DiskOfferingVO;
+import com.google.gson.Gson;
+import com.google.gson.GsonBuilder;
+import com.google.common.util.concurrent.AtomicLongMap;
+
+@Component
+public class UsageReporter extends ManagerBase implements 
ComponentMethodInterceptable {
+public static final Logger s_logger = 
Logger.getLogger(UsageReporter.class.getName());
+
+/* !FIX ME! This should point to a Apache Infra host with SSL! */
+private String reportHost = https://call-home.cloudstack.org/report;;
+
+private String uniqueID = null;
+
+private static UsageReporter s_instance = null;
+
+private ScheduledExecutorService _executor = null;
+
+@Inject
+private ConfigurationDao _configDao;
+@Inject
+private HostDao _hostDao;
+@Inject
+private ClusterDao _clusterDao;
+@Inject
+private PrimaryDataStoreDao _storagePoolDao;
+@Inject
+private DataCenterDao _dataCenterDao;
+@Inject
+private UserVmDao _userVmDao;
+@Inject
+private VMInstanceDao _vmInstance;
+@Inject
+private VersionDao _versionDao;
+@Inject
+private DiskOfferingDao _diskOfferingDao;
+
+int usageReportInterval = -1;
+
+public static

[jira] [Updated] (CLOUDSTACK-7539) [S3] Parallel deployment makes reference count of a cache in nfs secondary staging store negative(-1)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daan Hoogland updated CLOUDSTACK-7539:
--
Fix Version/s: 4.6.0

 [S3] Parallel deployment makes reference count of a cache in nfs secondary 
 staging store negative(-1)
 -

 Key: CLOUDSTACK-7539
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7539
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Storage Controller, Template
Affects Versions: Future, 4.3.0, 4.4.0, 4.5.0
 Environment: OS: CentOS 6.5, CloudStack Version: 4.3.0,  Hypervisor: 
 KVM,  Primary Storage: Local Storage,  Secondary Storage:   S3(RADOS),  Zone: 
  Advanced
Reporter: Hiroki Ohashi
Assignee: Daan Hoogland
Priority: Critical
 Fix For: 4.6.0, 4.5.2


 When we create some instances in parallel in an environment shown above, an 
 exception like ([#2]) happens. After that, reference count of a cache in NFS 
 Secondary Staging Store(SSS) becomes negative([#3]).
 In this situcation, we can't use a template used for creating the instances 
 because negative reference count will cause another
 exception([#4]). Furthermore, template caches in NFS SSS aren't cleaned up.
 I think this is related to CLOUDSTACK-6236. I'm using CloudStack 4.3.0 
 branch. The code was applied a patch of CLOUDSTACK-6236 to and also fixed 
 about volume reference count setter problem by myself. But the reference 
 count problem still happens.
 Conditions to trigger
   - A cache of a template isn't on NFS SSS.
   - Choose compute offering that occupies all resources in a host.(ex. Use 
 all cores and almost all memory)
   - Create multiple instances ([#1]).
 Other behaviors
   - Management server inserts multiple entries for template cache(ImageCache) 
 to cloud.template_store_ref.
   - SSVM probably downloads same template from S3 and creates multiple caches 
 to NFS SSS concurrently. Sometimes, SSVM retries download  and cache creation.
 (1)
 {anchor:1}
 {noformat}
 #! /bin/bash
 COMPUTE_OFFERING=b6fc0598-6903-48cc-b894-ead3bb0e39f5
 TEMPLATE=ef1d5a8e-5951-4036-a236-fe2d47224fe4
 ZONE=23156857-4722-4fc4-86d4-a12ca1028197
 NETWORK=4ba56179-f7b9-4560-a00e-80c946856ff8
 KEYPAIR=mykey
 NAME1=test-template-error-0003
 NAME2=test-template-error-0004
 cloudmonkey deploy virtualmachine serviceofferingid=${COMPUTE_OFFERING} 
 templateid=${TEMPLATE} zoneid=${ZONE} networkids=${NETWORK} 
 displayname=${NAME1} name=${NAME1} keypair=${KEYPAIR}
 sleep 1
 cloudmonkey deploy virtualmachine serviceofferingid=${COMPUTE_OFFERING} 
 templateid=${TEMPLATE} zoneid=${ZONE} networkids=${NETWORK} 
 displayname=${NAME2} name=${NAME2} keypair=${KEYPAIR}
 {noformat}
 (2)
 {anchor:2}
 {noformat}
 2014-09-10 17:22:51,249 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null) 
 Seq 171-1789133096: Processing:  { Ans: , MgmtId: 98532524288, via: 171, Ver: 
 v1, Flags: 10, 
 [{org.apache.cloudstack.storage.command.CopyCmdAnswer:{newData:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/3/330/22e69a40-0916-4d11-a07a-63d38e76887f.qcow2,id:0,accountId:0,hvm:false,name:22e69a40-0916-4d11-a07a-63d38e76887f.qcow2,size:14340259840,physicalSize:14340259840}},result:true,wait:0}}]
  }
 2014-09-10 17:22:51,249 DEBUG [c.c.a.t.Request] 
 (Job-Executor-162:ctx-4a2eb345 ctx-fbf59f27) Seq 171-1789133096: Received:  { 
 Ans: , MgmtId: 98532524288, via: 171, Ver: v1, Flags: 10, { CopyCmdAnswer } }
 2014-09-10 17:22:51,257 DEBUG [o.a.c.s.i.s.TemplateObject] 
 (Job-Executor-162:ctx-4a2eb345 ctx-fbf59f27) failed to update state
 com.cloud.utils.fsm.NoTransitionException: Unable to transition to a new 
 state from Allocated via OperationSuccessed
 at 
 com.cloud.utils.fsm.StateMachine2.getNextState(StateMachine2.java:83)
 at com.cloud.utils.fsm.StateMachine2.transitTo(StateMachine2.java:100)
 at 
 org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.update(ObjectInDataStoreManagerImpl.java:297)
 at 
 org.apache.cloudstack.storage.image.store.TemplateObject.processEvent(TemplateObject.java:225)
 at 
 org.apache.cloudstack.storage.cache.manager.StorageCacheManagerImpl.createCacheObject(StorageCacheManagerImpl.java:240)
 at 
 org.apache.cloudstack.storage.cache.manager.StorageCacheManagerImpl.createCacheObject(StorageCacheManagerImpl.java:267)
 at 
 org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyObject(AncientDataMotionStrategy.java:165)
 at 
 org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:428)
 at

[jira] [Closed] (CLOUDSTACK-8585) refactor non-transitive equals implementations for objects.equals(String other) usage


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daan Hoogland closed CLOUDSTACK-8585.
-
Resolution: Fixed

this was addressed with findbugs refs instead of refs to this ticket

 refactor non-transitive equals implementations for objects.equals(String 
 other) usage
 -

 Key: CLOUDSTACK-8585
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8585
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Daan Hoogland
Assignee: Daan Hoogland

 findbugs reported several instances of 
 EQ_CHECK_FOR_OPERAND_NOT_COMPATIBLE_WITH_THIS in ACS. Research the usage of 
 those implementations and factor them out of the suystem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it

[
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644291#comment-14644291
]

ASF GitHub Bot commented on CLOUDSTACK-8668:

Github user kishankavala commented on the pull request:

https://github.com/apache/cloudstack/pull/627#issuecomment-125580306

Yes @wilderrodrigues VR started successfully . But port 3922 is not open.
Once I add iptables rule to allow 3922, MS is able to program rules.
I'm looking at CLOUDSTACK-8683, but might take a while for me to find the
root cause.

VR does not start in basic zone since ip address are not being configured on
it
---

Key: CLOUDSTACK-8668
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.6.0
Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Wilder Rodrigues
Priority: Blocker

VR does not start in basic zone since ip address are not being configured on
it
Steps to reproduce:

1.Bring up CS in basic zone with xen server cluster
2.Try to deploy one guest vm using default cent os template
Expected Result:
==
VR should come up as part of vm deployment and vm deployment should be
successfull
Actual Result:

VR creation failed since the IP addresses not are getting assigned to VR's
guest and link local interfaces.
Observations:
===
1.During vr boot time, cloud-early-config ran successfully and VR console
output showed that ping to gateway was successful. However, after VR boot we
don't see any ip addresses on the VRs guest and link local ip address.
2. If we run cloud-early-config manually from VR , ip addresses will be
assigned and persistent.
Impact:
=
VM deployments will fail since VR remains in stopped state.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kishan Kavala updated CLOUDSTACK-8668:
--
Fix Version/s: 4.6.0

 VR does not start in basic zone since ip address are not being configured on 
 it
 ---

 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.6.0


 VR does not start in basic zone since ip address are not being configured on 
 it
 Steps to reproduce:
 
 1.Bring up CS in basic zone with xen server cluster
 2.Try to deploy one guest vm using default cent os template
 Expected Result:
 ==
 VR should come up as part of vm deployment and vm deployment should be 
 successfull
 Actual Result:
 
 VR creation failed since the IP addresses not are getting assigned to VR's 
 guest and link local interfaces.
 Observations:
 ===
 1.During vr boot time, cloud-early-config ran successfully and VR console 
 output showed that ping to gateway was successful. However, after VR boot we 
 don't see any ip addresses on the VRs guest and link local ip address.
 2. If we run cloud-early-config manually from VR , ip addresses will be 
 assigned and persistent.
 Impact:
 =
 VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kishan Kavala resolved CLOUDSTACK-8668.
---
Resolution: Fixed

 VR does not start in basic zone since ip address are not being configured on 
 it
 ---

 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Kishan Kavala
Priority: Blocker

 VR does not start in basic zone since ip address are not being configured on 
 it
 Steps to reproduce:
 
 1.Bring up CS in basic zone with xen server cluster
 2.Try to deploy one guest vm using default cent os template
 Expected Result:
 ==
 VR should come up as part of vm deployment and vm deployment should be 
 successfull
 Actual Result:
 
 VR creation failed since the IP addresses not are getting assigned to VR's 
 guest and link local interfaces.
 Observations:
 ===
 1.During vr boot time, cloud-early-config ran successfully and VR console 
 output showed that ping to gateway was successful. However, after VR boot we 
 don't see any ip addresses on the VRs guest and link local ip address.
 2. If we run cloud-early-config manually from VR , ip addresses will be 
 assigned and persistent.
 Impact:
 =
 VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8651) [Browser Based Upload Template] Partially uploaded templates doesn't get cleaned up after the SSVM handling it is destroyed

[
https://issues.apache.org/jira/browse/CLOUDSTACK-8651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644198#comment-14644198
]

ASF GitHub Bot commented on CLOUDSTACK-8651:

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/607#issuecomment-125546704

I would like to see the test run pass but don't think it is fair that this
should be blocked by an older error in test code. @koushik-das please comment
on how you executed the test and you have my lgtm

[Browser Based Upload Template] Partially uploaded templates doesn't get
cleaned up after the SSVM handling it is destroyed
---

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it

[
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644290#comment-14644290
]

Kishan Kavala commented on CLOUDSTACK-8668:
---

Yes Wilder VR started successfully . But port 3922 is not open. Once I add
iptables rule to allow 3922, MS is able to program rules.
I'm looking at CLOUDSTACK-8683, but might take a while for me to find the root
cause.

VR does not start in basic zone since ip address are not being configured on
it
---

VR does not start in basic zone since ip address are not being configured on
it
Steps to reproduce:

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kishan Kavala updated CLOUDSTACK-8668:
--
Comment: was deleted

(was: Yes Wilder VR started successfully . But port 3922 is not open. Once I 
add iptables rule to allow 3922, MS is able to program rules.
I'm looking at CLOUDSTACK-8683, but might take a while for me to find the root 
cause.)

 VR does not start in basic zone since ip address are not being configured on 
 it
 ---

 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Wilder Rodrigues
Priority: Blocker

 VR does not start in basic zone since ip address are not being configured on 
 it
 Steps to reproduce:
 
 1.Bring up CS in basic zone with xen server cluster
 2.Try to deploy one guest vm using default cent os template
 Expected Result:
 ==
 VR should come up as part of vm deployment and vm deployment should be 
 successfull
 Actual Result:
 
 VR creation failed since the IP addresses not are getting assigned to VR's 
 guest and link local interfaces.
 Observations:
 ===
 1.During vr boot time, cloud-early-config ran successfully and VR console 
 output showed that ping to gateway was successful. However, after VR boot we 
 don't see any ip addresses on the VRs guest and link local ip address.
 2. If we run cloud-early-config manually from VR , ip addresses will be 
 assigned and persistent.
 Impact:
 =
 VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644251#comment-14644251
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8668:


Github user jayapalu commented on the pull request:

https://github.com/apache/cloudstack/pull/627#issuecomment-125565419
  
LGTM


 VR does not start in basic zone since ip address are not being configured on 
 it
 ---

 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Wilder Rodrigues
Priority: Blocker

 VR does not start in basic zone since ip address are not being configured on 
 it
 Steps to reproduce:
 
 1.Bring up CS in basic zone with xen server cluster
 2.Try to deploy one guest vm using default cent os template
 Expected Result:
 ==
 VR should come up as part of vm deployment and vm deployment should be 
 successfull
 Actual Result:
 
 VR creation failed since the IP addresses not are getting assigned to VR's 
 guest and link local interfaces.
 Observations:
 ===
 1.During vr boot time, cloud-early-config ran successfully and VR console 
 output showed that ping to gateway was successful. However, after VR boot we 
 don't see any ip addresses on the VRs guest and link local ip address.
 2. If we run cloud-early-config manually from VR , ip addresses will be 
 assigned and persistent.
 Impact:
 =
 VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644254#comment-14644254
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8668:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/627#issuecomment-125566567
  
Thanks for the PR, @kishankavala !

It LGTM :+1:  and I will also test it

Cheers,
Wilder


 VR does not start in basic zone since ip address are not being configured on 
 it
 ---

 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Wilder Rodrigues
Priority: Blocker

 VR does not start in basic zone since ip address are not being configured on 
 it
 Steps to reproduce:
 
 1.Bring up CS in basic zone with xen server cluster
 2.Try to deploy one guest vm using default cent os template
 Expected Result:
 ==
 VR should come up as part of vm deployment and vm deployment should be 
 successfull
 Actual Result:
 
 VR creation failed since the IP addresses not are getting assigned to VR's 
 guest and link local interfaces.
 Observations:
 ===
 1.During vr boot time, cloud-early-config ran successfully and VR console 
 output showed that ping to gateway was successful. However, after VR boot we 
 don't see any ip addresses on the VRs guest and link local ip address.
 2. If we run cloud-early-config manually from VR , ip addresses will be 
 assigned and persistent.
 Impact:
 =
 VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8678) OOM Kills Guests

[
https://issues.apache.org/jira/browse/CLOUDSTACK-8678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644256#comment-14644256
]

Daan Hoogland commented on CLOUDSTACK-8678:
---

clear. there are some other knobs to turn: vm.memballoon.disable in the
agent.properties file on the host(s) and
cluster.memory.allocated.capacity.notificationthreshold and
cluster.memory.allocated.capacity.disablethreshold. I had some chats about them
and came to the conclusion that these might help you to some extend, Let's use
this ticket to come to additional functional demands.

OOM Kills Guests

Key: CLOUDSTACK-8678
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8678
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, KVM
Affects Versions: 4.4.2
Environment: Intel Xeon Quad Core CPU L5520 @ 2.27GHz
98 GB RAM
Ubuntu 14.04
Running Cloustack 4.4.2
Reporter: Josh Harshman
Priority: Critical

We have several KVM nodes running Cloudstack 4.4.2. Sometimes an instance
with X amount of RAM provisioned will be started on a host that has X+a small
amount of RAM free. The kernel OOM killer will eventually kill off the
instance. Has anyone else seen this behavior, is there a way to reserve RAM
for use by the host instead of by Cloudstack? Looking at the numbers in the
database and the logs, Cloudstack is trying to use 100% of the RAM on the
host.
Any thoughts would be appreciated.
Thank you,

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644270#comment-14644270
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8668:


Github user kishankavala commented on the pull request:

https://github.com/apache/cloudstack/pull/627#issuecomment-125571871
  
Thanks @wilderrodrigues for merging.
Ran into another blocker after VR came up: 
https://issues.apache.org/jira/browse/CLOUDSTACK-8683


 VR does not start in basic zone since ip address are not being configured on 
 it
 ---

 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Wilder Rodrigues
Priority: Blocker

 VR does not start in basic zone since ip address are not being configured on 
 it
 Steps to reproduce:
 
 1.Bring up CS in basic zone with xen server cluster
 2.Try to deploy one guest vm using default cent os template
 Expected Result:
 ==
 VR should come up as part of vm deployment and vm deployment should be 
 successfull
 Actual Result:
 
 VR creation failed since the IP addresses not are getting assigned to VR's 
 guest and link local interfaces.
 Observations:
 ===
 1.During vr boot time, cloud-early-config ran successfully and VR console 
 output showed that ping to gateway was successful. However, after VR boot we 
 don't see any ip addresses on the VRs guest and link local ip address.
 2. If we run cloud-early-config manually from VR , ip addresses will be 
 assigned and persistent.
 Impact:
 =
 VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-8586) findbugs report on null return for Boolean


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daan Hoogland closed CLOUDSTACK-8586.
-
Resolution: Fixed

further investigation in the use of null as return values is needed. 
Inconsistency in the semantics of methods arise from the use of null quite 
easily. the issues mentioned are fixed.

 findbugs report on null return for Boolean
 --

 Key: CLOUDSTACK-8586
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8586
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Daan Hoogland
Assignee: Daan Hoogland

 NP_BOOLEAN_RETURN_NULL says that returning null in a Boolean function is bad 
 practice. It makes sense as it might be used in an if statement and lead to 
 NPE. The functions reported on are isThisOrThat() functions and a possible 
 solution is renaming them to getThisOrThat().
 A small further investigation of the solution and the semantics of the 
 present implementation is required.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kishan Kavala updated CLOUDSTACK-8668:
--
Assignee: Kishan Kavala  (was: Wilder Rodrigues)

 VR does not start in basic zone since ip address are not being configured on 
 it
 ---

 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.6.0


 VR does not start in basic zone since ip address are not being configured on 
 it
 Steps to reproduce:
 
 1.Bring up CS in basic zone with xen server cluster
 2.Try to deploy one guest vm using default cent os template
 Expected Result:
 ==
 VR should come up as part of vm deployment and vm deployment should be 
 successfull
 Actual Result:
 
 VR creation failed since the IP addresses not are getting assigned to VR's 
 guest and link local interfaces.
 Observations:
 ===
 1.During vr boot time, cloud-early-config ran successfully and VR console 
 output showed that ping to gateway was successful. However, after VR boot we 
 don't see any ip addresses on the VRs guest and link local ip address.
 2. If we run cloud-early-config manually from VR , ip addresses will be 
 assigned and persistent.
 Impact:
 =
 VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14645467#comment-14645467
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8668:


Github user kishankavala commented on the pull request:

https://github.com/apache/cloudstack/pull/627#issuecomment-125846995
  
Hi @wilderrodrigues 
Please look into CLOUDSTACK-8683 when possible


 VR does not start in basic zone since ip address are not being configured on 
 it
 ---

 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.6.0


 VR does not start in basic zone since ip address are not being configured on 
 it
 Steps to reproduce:
 
 1.Bring up CS in basic zone with xen server cluster
 2.Try to deploy one guest vm using default cent os template
 Expected Result:
 ==
 VR should come up as part of vm deployment and vm deployment should be 
 successfull
 Actual Result:
 
 VR creation failed since the IP addresses not are getting assigned to VR's 
 guest and link local interfaces.
 Observations:
 ===
 1.During vr boot time, cloud-early-config ran successfully and VR console 
 output showed that ping to gateway was successful. However, after VR boot we 
 don't see any ip addresses on the VRs guest and link local ip address.
 2. If we run cloud-early-config manually from VR , ip addresses will be 
 assigned and persistent.
 Impact:
 =
 VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8651) [Browser Based Upload Template] Partially uploaded templates doesn't get cleaned up after the SSVM handling it is destroyed

[
https://issues.apache.org/jira/browse/CLOUDSTACK-8651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14645479#comment-14645479
]

ASF GitHub Bot commented on CLOUDSTACK-8651:

Github user koushik-das commented on the pull request:

https://github.com/apache/cloudstack/pull/607#issuecomment-125849581

Moved the test to a new file test_browse_templates2.py. This is the command
to run it

nosetests-2.7 --with-marvin --marvin-config=setup/dev/advanced.cfg
--with-xunit --xunit-file=test_output.xml
test/integration/component/test_browse_templates2.py -a required_hardware=false
--zone=Sandbox-simulator --hypervisor=simulator

[Browser Based Upload Template] Partially uploaded templates doesn't get
cleaned up after the SSVM handling it is destroyed
---

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-4442) Source NAT not applied when network starts up


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi reassigned CLOUDSTACK-4442:
---

Assignee: (was: Murali Reddy)

 Source NAT not applied when network starts up
 -

 Key: CLOUDSTACK-4442
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4442
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Reporter: Dave Cahill
Priority: Blocker
 Fix For: 4.6.0


 Create a network with Source NAT but no static NAT, and no firewall rules 
 applied.
 Observed behavior:
 Source NAT is not applied when the first VM is launched (when network is 
 implemented)
 Expected:
 Source NAT enabled at network implement time
 Network devices:
 Should affect all network devices; verified in 2 separate environments, one 
 with Virtual Router only, one MidoNet only
 Further information:
 This bug seems to be a result of this change:
 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=server/src/com/cloud/network/NetworkManagerImpl.java;h=2b53565297dc7bd96c6102cdc1c90cb166e9e704;hp=dac6a3a42e75324a963997e17e076f4020a7103e;hb=fe568fe;hpb=c7f26583a26eb7e4f15feafc292ec9576df61a8d
 The above change was made as a fix for CLOUDSTACK-234.
 If the user enables Static NAT, Source NAT will be applied as a side effect.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-8685) [VPC_VR] Default route is not configured on VPC VR

2015-07-28 Thread Sanjeev N (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-8685:
--
Attachment: management-server.zip

 [VPC_VR] Default route is not configured on VPC VR
 --

 Key: CLOUDSTACK-8685
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8685
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Advanced zone with VPC. Latest build from ACS master.
Reporter: Sanjeev N
Priority: Critical
 Attachments: management-server.zip


 [VPC_VR] Default route is not configured on VPC VR
 Steps to reproduce:
 
 1.Bring up CS in advanced zone 
 2.Create VPC and wait for the VR to come into running state
 3.Connect  to VR and verify route table information
 Result:
 ==
 Default route is not configured on VPC VR.
 root@r-9-VM:/var/cache/cloud# route -n
 Kernel IP routing table
 Destination Gateway Genmask Flags Metric RefUse Iface
 10.1.1.00.0.0.0 255.255.255.0   U 0  00 eth2
 10.1.2.00.0.0.0 255.255.255.0   U 0  00 eth3
 10.220.128.00.0.0.0 255.255.224.0   U 0  00 eth1
 169.254.0.0 0.0.0.0 255.255.0.0 U 0  00 eth0
 root@r-9-VM:/var/cache/cloud#
 Observations:
 ===
 When vr boots up, we run cloud-early-config. This will clean if there is any 
 default route exists on VR. Then we execute vpc_ipassoc.sh to configure 
 public nic and default route via public nic. However, in the latest ACS 
 master we are not executing vpc_ipassoc.sh.
 For any configuration on VR , we are creating configuration file and applying 
 it with update_config.py. 
 Looks like adding default route is missing in the confguration file.
 Following is the configuration file genearted on VR :
 015-07-29 05:20:39,132 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-402:ctx-83549002) VR Config file 
 VR-d3b73941-7b3d-489a-bcc6-47c6a777c950.cfg got created in VR, ip 
 169.254.0.54 with content
 #Apache CloudStack Virtual Router Config File
 version
 1.0
 /version
 file
 /var/cache/cloud/ip_associations.json
 {ip_address:[{public_ip:10.220.135.97,source_nat:false,add:true,one_to_one_nat:false,first_i_p:false,gateway:10.220.128.1,netmask:255.255.224.0,vif_mac_address:06:dd:e0:00:00:0e,nic_dev_id:1,new_nic:false},{public_ip:10.220.135.99,source_nat:false,add:true,one_to_one_nat:true,first_i_p:false,gateway:10.220.128.1,netmask:255.255.224.0,vif_mac_address:06:dd:e0:00:00:0e,nic_dev_id:1,new_nic:false}],type:ips}
 /file
 script
 /opt/cloud/bin/update_config.py ip_associations.json
 /script
 file
 /var/cache/cloud/staticnat_rules.json
 {rules:[{revoke:false,source_ip_address:10.220.135.99,source_port_range:0:0,destination_ip_address:10.1.1.36}],type:staticnatrules}
 /file
 script
 /opt/cloud/bin/update_config.py staticnat_rules.json
 /script
 file
 /var/cache/cloud/forwarding_rules.json
 {rules:[{revoke:false,protocol:tcp,source_ip_address:10.220.135.97,source_port_range:22:22,destination_ip_address:10.1.1.194,destination_port_range:22:22}],type:forwardrules}
 /file
 script
 /opt/cloud/bin/update_config.py forwarding_rules.json
 /script
 file
 /var/cache/cloud/network_acl.json
 {device:eth2,mac_address:02:00:7c:a8:00:02,private_gateway_acl:false,nic_ip:10.1.1.1,nic_netmask:24,ingress_rules:[{type:tcp,first_port:22,last_port:22,cidr:0.0.0.0/0,allowed:true}],egress_rules:[{type:icmp,icmp_type:-1,icmp_code:-1,cidr:0.0.0.0/0,allowed:true}],type:networkacl}
 /file
 script
 /opt/cloud/bin/update_config.py network_acl.json
 /script
 file
 /var/cache/cloud/vm_dhcp_entry.json
 {host_name:VM-403a0536-ba54-404f-a664-1b14d039497c,mac_address:02:00:10:ca:00:01,ipv4_adress:10.1.1.194,ipv6_duid:00:03:00:01:02:00:10:ca:00:01,default_gateway:10.1.1.1,default_entry:true,type:dhcpentry}
 /file
 script
 /opt/cloud/bin/update_config.py vm_dhcp_entry.json
 /script
 file
 /var/cache/cloud/vm_dhcp_entry.json
 {host_name:VM-4c5e69ab-65dd-4315-b8fb-702f5599ede0,mac_address:02:00:0f:22:00:03,ipv4_adress:10.1.1.36,ipv6_duid:00:03:00:01:02:00:0f:22:00:03,default_gateway:10.1.1.1,default_entry:true,type:dhcpentry}
 /file
 script
 /opt/cloud/bin/update_config.py vm_dhcp_entry.json
 /script
 file
 /var/cache/cloud/vm_metadata.json
 {vm_ip_address:10.1.1.194,vm_metadata:[[userdata,user-data,null],[metadata,service-offering,Tiny

[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14645486#comment-14645486
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8668:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/627#issuecomment-125850427
  
Hi @kishankavala 

I'm on it.

Cheers,
Wilder


 VR does not start in basic zone since ip address are not being configured on 
 it
 ---

 Key: CLOUDSTACK-8668
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.6.0
 Environment: Latest build from ACS master
Reporter: Sanjeev N
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.6.0


 VR does not start in basic zone since ip address are not being configured on 
 it
 Steps to reproduce:
 
 1.Bring up CS in basic zone with xen server cluster
 2.Try to deploy one guest vm using default cent os template
 Expected Result:
 ==
 VR should come up as part of vm deployment and vm deployment should be 
 successfull
 Actual Result:
 
 VR creation failed since the IP addresses not are getting assigned to VR's 
 guest and link local interfaces.
 Observations:
 ===
 1.During vr boot time, cloud-early-config ran successfully and VR console 
 output showed that ping to gateway was successful. However, after VR boot we 
 don't see any ip addresses on the VRs guest and link local ip address.
 2. If we run cloud-early-config manually from VR , ip addresses will be 
 assigned and persistent.
 Impact:
 =
 VM deployments will fail since VR remains in stopped state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-4442) Source NAT not applied when network starts up


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi reassigned CLOUDSTACK-4442:
---

Assignee: Rajani Karuturi

 Source NAT not applied when network starts up
 -

 Key: CLOUDSTACK-4442
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4442
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Reporter: Dave Cahill
Assignee: Rajani Karuturi
Priority: Blocker
 Fix For: 4.6.0


 Create a network with Source NAT but no static NAT, and no firewall rules 
 applied.
 Observed behavior:
 Source NAT is not applied when the first VM is launched (when network is 
 implemented)
 Expected:
 Source NAT enabled at network implement time
 Network devices:
 Should affect all network devices; verified in 2 separate environments, one 
 with Virtual Router only, one MidoNet only
 Further information:
 This bug seems to be a result of this change:
 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=server/src/com/cloud/network/NetworkManagerImpl.java;h=2b53565297dc7bd96c6102cdc1c90cb166e9e704;hp=dac6a3a42e75324a963997e17e076f4020a7103e;hb=fe568fe;hpb=c7f26583a26eb7e4f15feafc292ec9576df61a8d
 The above change was made as a fix for CLOUDSTACK-234.
 If the user enables Static NAT, Source NAT will be applied as a side effect.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8684) Upgrade from 4.3.1 to 4.5.1 does not update resource for existing XenServer 6.0.2 hosts

2015-07-28 Thread Carlos Reategui (JIRA)

Carlos Reategui created CLOUDSTACK-8684:
---

 Summary: Upgrade from 4.3.1 to 4.5.1 does not update resource for 
existing XenServer 6.0.2 hosts
 Key: CLOUDSTACK-8684
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8684
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Upgrade
Affects Versions: 4.5.1
 Environment: I was upgrading from ACS 4.3.1 to 4.5.1.  Hosts are 
running XenServer 6.0.2
Reporter: Carlos Reategui


4.5.1 got rid of the specific XS 6.0.2 resource since it was the same as the 
6.0 one.  However the upgrade script does not update the resource column in the 
host table for pre-existing entries that still point to the old 602 resource.

Change was done here: 
https://github.com/apache/cloudstack/commit/81c5e184ba998a6ccd75dfffad32cbe5dbc8c2ec

The error I got after upgrade was:
2015-07-28 00:00:43,097 WARN  [c.c.r.DiscovererBase] (ClusteredAgentManager 
Timer:ctx-ac79289c) Unable to find class 
com.cloud.hypervisor.xenserver.resource.XenServer602Resource
java.lang.ClassNotFoundException: 
com.cloud.hypervisor.xenserver.resource.XenServer602Resource




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-8192) Wrong ID being returned in the createEgressFirewallRule end-point response


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi updated CLOUDSTACK-8192:

Assignee: Maneesha  (was: Rajani Karuturi)

 Wrong ID being returned in the createEgressFirewallRule end-point response
 --

 Key: CLOUDSTACK-8192
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8192
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
 Environment: Issue was found on cloudstack version 4.2.1
Reporter: Diogo Monteiro
Assignee: Maneesha
Priority: Critical

 Instead of returning the rule UUID, the endpoint is returning the database 
 primary key. This causes an issue since most third party applications expect 
 async endpoints to return the asyncJobId and the resource UUID as part of the 
 response
 Steps to reproduce:
 #1 Make a request to the createEgressFirewallRule endPoint
 http://cs42.dev.cloud:8096?action=ALLOWapiKey=j-DKJIkURhA2G4H0vg3Tba-a75SasolsL8sRZbEAxKlq-AihyVElV7dhaAMjf-jOTOwzu8zEoKb-2krJjr8r3Qcidrlist=0.0.0.0%2F0command=createEgressFirewallRuleendport=81networkid=e5a1cb87-b6da-4e41-b6c2-2bc686713d0fnumber=1003protocol=TCPresponse=jsonstartport=81traffictype=INGRESSsignature=aT8dtBE%2FTb34205sfKHckXXPGcQ%3D
 Results
 Response object return primary key instead of UUID:
 createegressfirewallruleresponse: {
   id: 78,
   jobid: 05626600-fb64-4558-b5ce-675294e9f48f
 }
 Expected Results:
 createegressfirewallruleresponse object should contain the rule UUID



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CLOUDSTACK-8678) OOM Kills Guests

[
https://issues.apache.org/jira/browse/CLOUDSTACK-8678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644256#comment-14644256
]

Daan Hoogland edited comment on CLOUDSTACK-8678 at 7/28/15 9:13 PM:

was (Author: dahn):
clear. there are some other knobs to turn: vm.memballoon.disable in the
agent.properties file on the host(s) and
cluster.memory.allocated.capacity.notificationthreshold and
cluster.memory.allocated.capacity.disablethreshold. I had some chats about them
and came to the conclusion that these might help you to some extend, Let's use
this ticket to come to additional functional demands.

OOM Kills Guests

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-8678) OOM Kills Guests