[jira] [Commented] (CLOUDSTACK-6801) Public IP not assigned to eth1 on VR in VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643880#comment-14643880 ] Rajani Karuturi commented on CLOUDSTACK-6801: - [~andrija], can you test on any of the recent versions and close it if its working? (reducing the priority to critical) Public IP not assigned to eth1 on VR in VPC --- Key: CLOUDSTACK-6801 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6801 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Environment: CentOS, KVM. Reporter: Andrija Panic Priority: Blocker Labels: publicip, virtualrouter, vpc Hi, after upgrade from 4.2.1 to 4.3.0, Public IP on eth1 is missing on VR when creating new (and on existing) VPCs, although eth1 seems present per /proc/net/dev. Mangement logs are fine, eth1 plugged in correct bridge, etc. Manually adding IP on eth1 and starting eth1 does work. From /var/log/messages inside VR: May 28 18:27:36 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 0 seconds May 28 18:27:37 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 1 seconds May 28 18:27:38 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 2 seconds May 28 18:27:39 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 3 seconds May 28 18:27:40 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 4 seconds May 28 18:27:41 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 5 seconds May 28 18:27:42 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 6 seconds May 28 18:27:43 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 7 seconds May 28 18:27:44 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 8 seconds May 28 18:27:45 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 9 seconds May 28 18:27:46 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 10 seconds May 28 18:27:47 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 11 seconds May 28 18:27:48 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 12 seconds May 28 18:27:49 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 13 seconds May 28 18:27:50 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 14 seconds May 28 18:27:51 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 15 seconds May 28 18:27:52 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 16 seconds May 28 18:27:53 r-799-VM cloud: vpc_ipassoc.sh:interface ethnull never appeared May 28 18:27:53 r-799-VM cloud: vpc_ipassoc.sh:Adding ip 46.232.x.246 on interface ethnull May 28 18:27:53 r-799-VM cloud: vpc_ipassoc.sh:Add routing 46.232.x.246 on interface ethnull May 28 18:27:53 r-799-VM cloud: vpc_privateGateway.sh:Added SourceNAT 46.232.x.246 on interface ethnull May 28 18:27:53 r-799-VM cloud: vpc_snat.sh:Added SourceNAT 46.232.x.246 on interface eth1 May 28 18:27:54 r-799-VM cloud: vpc_guestnw.sh: Create network on interface eth2, gateway 10.0.1.1, network 10.0.1.1/24 May 28 18:27:59 r-799-VM cloud: Setting up apache web server for eth2 May 28 18:27:59 r-799-VM cloud: Setting up password service for network 10.0.1.1/24, eth eth2 May 28 18:27:59 r-799-VM cloud: vpc_guestnw.sh: Create network on interface eth3, gateway 10.0.3.1, network 10.0.3.1/24 May 28 18:28:04 r-799-VM cloud: Setting up apache web server for eth3 May 28 18:28:06 r-799-VM cloud: Setting up password service for network 10.0.3.1/24, eth eth3 May 28 18:28:06 r-799-VM cloud: vpc_guestnw.sh: Create network on interface eth4, gateway 10.0.4.1, network 10.0.4.1/24 May 28 18:28:11 r-799-VM cloud: Setting up apache web server for eth4 May 28 18:28:12 r-799-VM cloud: Setting up password service for network 10.0.4.1/24, eth eth4 May 28 18:28:13 r-799-VM cloud: vpc_guestnw.sh: Create network on interface eth5, gateway 10.0.6.1, network 10.0.6.1/24 May 28 18:28:18 r-799-VM cloud: Setting up apache web server for eth5 May 28 18:28:19 r-799-VM cloud: Setting up password service for network 10.0.6.1/24, eth eth5 Nothing else usefull in other logs... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (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 resolved CLOUDSTACK-6171.
-
Resolution: Fixed
resolving as it works on recent versions. Please reopen if you are able to
reproduce in any of the recent versions
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] [Updated] (CLOUDSTACK-6801) Public IP not assigned to eth1 on VR in VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-6801: Priority: Critical (was: Blocker) Public IP not assigned to eth1 on VR in VPC --- Key: CLOUDSTACK-6801 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6801 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Environment: CentOS, KVM. Reporter: Andrija Panic Priority: Critical Labels: publicip, virtualrouter, vpc Hi, after upgrade from 4.2.1 to 4.3.0, Public IP on eth1 is missing on VR when creating new (and on existing) VPCs, although eth1 seems present per /proc/net/dev. Mangement logs are fine, eth1 plugged in correct bridge, etc. Manually adding IP on eth1 and starting eth1 does work. From /var/log/messages inside VR: May 28 18:27:36 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 0 seconds May 28 18:27:37 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 1 seconds May 28 18:27:38 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 2 seconds May 28 18:27:39 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 3 seconds May 28 18:27:40 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 4 seconds May 28 18:27:41 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 5 seconds May 28 18:27:42 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 6 seconds May 28 18:27:43 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 7 seconds May 28 18:27:44 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 8 seconds May 28 18:27:45 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 9 seconds May 28 18:27:46 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 10 seconds May 28 18:27:47 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 11 seconds May 28 18:27:48 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 12 seconds May 28 18:27:49 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 13 seconds May 28 18:27:50 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 14 seconds May 28 18:27:51 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 15 seconds May 28 18:27:52 r-799-VM cloud: vpc_ipassoc.sh:Waiting for interface ethnull to appear, 16 seconds May 28 18:27:53 r-799-VM cloud: vpc_ipassoc.sh:interface ethnull never appeared May 28 18:27:53 r-799-VM cloud: vpc_ipassoc.sh:Adding ip 46.232.x.246 on interface ethnull May 28 18:27:53 r-799-VM cloud: vpc_ipassoc.sh:Add routing 46.232.x.246 on interface ethnull May 28 18:27:53 r-799-VM cloud: vpc_privateGateway.sh:Added SourceNAT 46.232.x.246 on interface ethnull May 28 18:27:53 r-799-VM cloud: vpc_snat.sh:Added SourceNAT 46.232.x.246 on interface eth1 May 28 18:27:54 r-799-VM cloud: vpc_guestnw.sh: Create network on interface eth2, gateway 10.0.1.1, network 10.0.1.1/24 May 28 18:27:59 r-799-VM cloud: Setting up apache web server for eth2 May 28 18:27:59 r-799-VM cloud: Setting up password service for network 10.0.1.1/24, eth eth2 May 28 18:27:59 r-799-VM cloud: vpc_guestnw.sh: Create network on interface eth3, gateway 10.0.3.1, network 10.0.3.1/24 May 28 18:28:04 r-799-VM cloud: Setting up apache web server for eth3 May 28 18:28:06 r-799-VM cloud: Setting up password service for network 10.0.3.1/24, eth eth3 May 28 18:28:06 r-799-VM cloud: vpc_guestnw.sh: Create network on interface eth4, gateway 10.0.4.1, network 10.0.4.1/24 May 28 18:28:11 r-799-VM cloud: Setting up apache web server for eth4 May 28 18:28:12 r-799-VM cloud: Setting up password service for network 10.0.4.1/24, eth eth4 May 28 18:28:13 r-799-VM cloud: vpc_guestnw.sh: Create network on interface eth5, gateway 10.0.6.1, network 10.0.6.1/24 May 28 18:28:18 r-799-VM cloud: Setting up apache web server for eth5 May 28 18:28:19 r-799-VM cloud: Setting up password service for network 10.0.6.1/24, eth eth5 Nothing else usefull in other logs... -- 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:
Priority: Critical (was: Blocker)
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
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] [Assigned] (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 reassigned CLOUDSTACK-8192:
---
Assignee: 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: Rajani Karuturi
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] [Resolved] (CLOUDSTACK-8604) devcloud installation crashes on chef step
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajani Karuturi resolved CLOUDSTACK-8604.
-
Resolution: Fixed
resolving based on the comments from [~pdion]. Please reopen if you are able to
reproduce on master
devcloud installation crashes on chef step
--
Key: CLOUDSTACK-8604
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8604
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: DevCloud
Affects Versions: 4.3.0, 4.5.1
Environment: Ubuntu 14.04, VirtualBox 4.3, ChefDK 0.6.2, Vagrant 1.7.2
Reporter: Fabio Da Soghe
Priority: Blocker
Followed instruction for DevCloud4, as described here:
https://github.com/apache/cloudstack/tree/master/tools/devcloud4
In binary-installation-basic issued command:
bq. vagrant up
Virtual machines get created, then the procedure halts on this:
{code}
== management: [2015-07-01T11:03:22+00:00] INFO:
template[/etc/sysconfig/nfs] sending restart action to service[portmap]
(immediate)
== management:
== management:
== management: Error executing action `restart` on resource
'service[portmap]'
== management:
== management:
== management:
== management: NoMethodError
== management: -
== management: undefined method `action=' for Chef::Resource::Service
== management:
== management:
== management: Resource Declaration:
== management: -
== management: # In
/tmp/vagrant-chef/617db32fe644a3d75932d34ec1e052f9/cookbooks/nfs/recipes/_common.rb
== management:
== management:
== management:
== management: 43: service component do
== management:
== management: 44: service_name node['nfs']['service'][component]
== management:
== management: 45: pattern node['nfs']['service'][component]
== management:
== management: 46: provider node['nfs']['service_provider'][component]
== management:
== management: 47: action [:start, :enable]
== management:
== management: 48: supports :status = true
== management:
== management: 49: end
== management:
== management: 50: end
== management:
== management:
== management:
== management: Compiled Resource:
== management: --
== management: # Declared in
/tmp/vagrant-chef/617db32fe644a3d75932d34ec1e052f9/cookbooks/nfs/recipes/_common.rb:43:in
`block in from_file'
== management:
== management:
== management:
== management: service(portmap) do
== management:
== management: provider Chef::Resource::Service
== management: action [:start, :enable]
== management: supports {:status=true}
== management: retries 0
== management: retry_delay 2
== management: guard_interpreter :default
== management: service_name rpcbind
== management: pattern rpcbind
== management: cookbook_name :nfs
== management: recipe_name _common
== management: end
== management:
== management: [2015-07-01T11:03:22+00:00] INFO: Running queued delayed
notifications before re-raising exception
== management: [2015-07-01T11:03:22+00:00] ERROR: Running exception handlers
== management: [2015-07-01T11:03:22+00:00] ERROR: Exception handlers complete
== management: [2015-07-01T11:03:22+00:00] FATAL: Stacktrace dumped to
/var/chef/cache/chef-stacktrace.out
== management: [2015-07-01T11:03:22+00:00] ERROR: service[portmap]
(nfs::_common line 43) had an error: NoMethodError: undefined method
`action=' for Chef::Resource::Service
== management: [2015-07-01T11:03:22+00:00] FATAL:
Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully
(exit code 1)
{code}
Besides last version (4.5.1), tried also with master branch, with CloudStack
4.3 git tag, with different (previous) versions of ChefDK, with
binary-installation-advanced, nothing changes.
As it is, DevCloud4 appears broken. Any help is greatly appreciated, thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8633) Cannot login due to an error in starting 'cloudStackLifeCycle' bean
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8633. - Resolution: Fixed resolving as the pull request is closed. Cannot login due to an error in starting 'cloudStackLifeCycle' bean --- Key: CLOUDSTACK-8633 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8633 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.6.0 Reporter: Raja Pullela Priority: Blocker Using Master builds, MS logs shows following error – “management-server.log:org.springframework.context.ApplicationContextException: Failed to start bean 'cloudStackLifeCycle'; nested exception is com.cloud.utils.exception.CloudRuntimeException: Failed to inject generated public key into systemvm iso sudo: /etc/sudoers.d/cloudstack-management is mode 0755, should be 0440sudo: sorry, you must have a tty to run sudo” After modifying the permissions – MS works fine. Apparently, this is related to a check that was done some time back… commit 870e1898eb28039fafaaeb8e50a7039f626f912c https://github.com/apache/cloudstack/commit/870e1898eb28039fafaaeb8e50a7039f626f912c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8642) SSO Method not allowed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8642. - Resolution: Fixed resolving as the pull request is accepted and closed SSO Method not allowed -- Key: CLOUDSTACK-8642 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8642 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.2 Reporter: Boris Schrijver Priority: Blocker Fix For: 4.5.2 When trying to authenticate using SSO with the login url, you will get an Method not Allowed. Reason: CLOUDSTACK-8505: Don't allow non-POST requests for default login API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8666) Put host in Alert state only after alert.wait timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643891#comment-14643891 ] ASF subversion and git services commented on CLOUDSTACK-8666: - Commit 6c3c9ea915b486722c6d41491338531254335272 in cloudstack's branch refs/heads/master from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6c3c9ea ] Unit tests for HA manager investigate method. Refer to CLOUDSTACK-8666 for the code chenges Put host in Alert state only after alert.wait timeout - Key: CLOUDSTACK-8666 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8666 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0, 4.6.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 When there is a ping timeout on a host, investigators try to determine the state of a host. If none of the investigators are able to determine the host state then the process is repeated after some time. This works most of the time except some boundary scenarios. For e.g. if last host or all host in a XS cluster are brought down then the investigators are not able to determine the host state and the investigation process never completes. In such scenarios host state always remain as Up. In order to fix these boundary scenarios, a fix was made (refer to commit 4a13f81485c0f0664c60acafe534946e7428f080) to immediately put the host in Alert state if investigators are not able to determine the state after ping timeout. The fix solved the boundary scenarios but introduced a new issue. Suppose there is a XS cluster with 2 hosts and the master host is brought down. In this case XS elects a new master for the cluster. Since master is down, investigators won't able to determine host state until a new master is elected. If this master election takes more than ping timeout to complete then the host is put to Alert based on the above fix. Once this happens, the host continues to remain in Alert state and no actions are taken on the VMs on this host. In this case if the investigators were allowed to run for 1 or 2 more times, possibly the new master election would have completed and host state correctly determined. In order to fix both these issues, instead of putting the host to Alert state immediately, the investigators should be allowed to run for some time based on alert.wait global config. At the end of this interval if the host state still cannot be determined then put the host in Alert. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3682) NPE in BridgeVifDriver causing systemvm startup failure in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajani Karuturi updated CLOUDSTACK-3682:
Fix Version/s: (was: Future)
4.6.0
NPE in BridgeVifDriver causing systemvm startup failure in KVM
--
Key: CLOUDSTACK-3682
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3682
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Install and Setup, KVM
Reporter: Prasanna Santhanam
Assignee: Toshiaki Hatano
Priority: Blocker
Fix For: 4.6.0
KVM start up of systemVMs is broken on master with the following exception
found in the management server logs
Running against master (88c84d91092f7f77bf7766a5164de90ac703bdc9)
Management Server:
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com local0: 2013-07-20
04:32:55,858 DEBUG [agent.manager.AgentAttache] (secstorage-1:null) Request
seq: 1368719379
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com local0: 2013-07-20
04:32:55,859 DEBUG [agent.transport.Request] (AgentManager-Handler-3:null)
Seq 2-1785069582: Processing: { Ans: , MgmtId: 200973787296321, via: 2, Ver:
v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:false,details:java.lang.NullPointerException\n\tat
com.cloud.hypervisor.kvm.resource.BridgeVifDriver.plug(BridgeVifDriver.java:118)\n\tat
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.createVif(LibvirtComputingResource.java:3504)\n\tat
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.createVifs(LibvirtComputingResource.java:3266)\n\tat
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(L...
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com
...ibvirtComputingResource.java: 3291)\n\tat
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1223)\n\tat
com.cloud.agent.Agent.processRequest(Agent.java:499)\n\tat
com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:807)\n\tat
com.cloud.utils.nio.Task.run(Task.java:83)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)\n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat
java.lang.Thread.run(Thread.java:679)\n,wait:0}},{com.cloud.agent.api.Answer:{result:false,details:Stopped
by previous failure,wait:0}}] }
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com local0: 2013-07-20
04:32:55,862 DEBUG [agent.transport.Request] (consoleproxy-1:null) Seq
2-1785069582: Received: { Ans: , MgmtId: 200973787296321, via: 2, Ver: v1,
Flags: 10, { Answer, Answer } }
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com local0: 2013-07-20
04:32:55,864 DEBUG [agent.manager.AgentAttache] (secstorage-1:null) waiting
to send 1368719379
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com local0: 2013-07-20
04:32:55,864 DEBUG [agent.manager.AgentAttache] (secstorage-1:null) entering
synchronize block for sending 1368719379
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com local0: 2013-07-20
04:32:55,867 ERROR [cloud.vm.VirtualMachineManagerImpl] (consoleproxy-1:null)
Failed to start instance VM[ConsoleProxy|v-2-VM]
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com
com.cloud.utils.exception.CloudRuntimeException: Unable to get answer that is
of class com.cloud.agent.api.StartAnswer
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com at
com.cloud.agent.manager.Commands.getAnswer(Commands.java:80)
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:939)
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:614)
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:607)
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:555)
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:927)
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1641)
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:156)
Jul 19 21:32:55 cloudstack-centos63.fmt.vmops.com at
com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111)
Jul 19 21:32:55
[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=14642638#comment-14642638 ] ASF GitHub Bot commented on CLOUDSTACK-8651: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/607#issuecomment-125183196 never mind that last bot-comment, i found a working config its running. will get results in a minute. if impatient and a hero, go with your own result ;) [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-8677) Call-home functionality for CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642700#comment-14642700 ] ASF GitHub Bot commented on CLOUDSTACK-8677: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/625#issuecomment-125199454 any way to verify this? 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=14642681#comment-14642681 ] ASF GitHub Bot commented on CLOUDSTACK-8677: GitHub user wido opened a pull request: https://github.com/apache/cloudstack/pull/625 CLOUDSTACK-8677: Call-home functionality for CloudStack With this commit the Management Server will be default generate a anonymous Usage report every 7 (seven) days and submit this information back to the Apache CloudStack project. These anonymous reports do NOT contain any information about Instance names, subnets, etc. It only contains numbers about how CloudStack is being used. This information is vital for the project to gain more insight in how CloudStack is being used. Users can turn the reporting off by setting usage.report.interval to 0 (zero) You can merge this pull request into a Git repository by running: $ git pull https://github.com/wido/cloudstack CLOUDSTACK-8677 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/625.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 #625 commit 1c61afb7b93313743e9df1d10242415f838e660b Author: Wido den Hollander w...@widodh.nl Date: 2015-07-08T19:17:30Z CLOUDSTACK-8677: Call-home functionality for CloudStack With this commit the Management Server will be default generate a anonymous Usage report every 7 (seven) days and submit this information back to the Apache CloudStack project. These anonymous reports do NOT contain any information about Instance names, subnets, etc. It only contains numbers about how CloudStack is being used. This information is vital for the project to gain more insight in how CloudStack is being used. Users can turn the reporting off by setting usage.report.interval to 0 (zero) 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=14642722#comment-14642722
]
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_r35535873
--- Diff: server/src/org/apache/cloudstack/report/UsageReporter.java ---
@@ -0,0 +1,473 @@
+// 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] [Resolved] (CLOUDSTACK-8551) Findbugs warning in LdapCreateAccountCmd.java and LdapImportUsersCmd.java
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8551. - Resolution: Fixed Findbugs warning in LdapCreateAccountCmd.java and LdapImportUsersCmd.java - Key: CLOUDSTACK-8551 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8551 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.5.1 Reporter: Rajani Karuturi Assignee: Rajani Karuturi Labels: ldap Fix For: 4.6.0 LdapCreateAccountCmd.java:146, DMI_INVOKING_TOSTRING_ON_ARRAY, Priority: High Invocation of toString on org.bouncycastle.util.encoders.Base64.encode(byte[]) in org.apache.cloudstack.api.command.LdapCreateAccountCmd.generatePassword() The code invokes toString on an array, which will generate a fairly useless result such as [C@16f0472. Consider using Arrays.toString to convert the array into a readable String that gives the contents of the array. See Programming Puzzlers, chapter 3, puzzle 12. LdapImportUsersCmd.java:231, DM_DEFAULT_ENCODING, Priority: High Found reliance on default encoding in org.apache.cloudstack.api.command.LdapImportUsersCmd.generatePassword(): new String(byte[]) Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable. This will cause the application behaviour to vary between platforms. Use an alternative API and specify a charset name or Charset object explicitly. -- 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=14642698#comment-14642698 ] 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_r35532842 --- Diff: setup/db/db/schema-452to460.sql --- @@ -398,3 +398,5 @@ CREATE TABLE `cloud`.`external_bigswitch_bcf_devices` ( CONSTRAINT `fk_external_bigswitch_bcf_devices__host_id` FOREIGN KEY (`host_id`) REFERENCES `host`(`id`) ON DELETE CASCADE, CONSTRAINT `fk_external_bigswitch_bcf_devices__physical_network_id` FOREIGN KEY (`physical_network_id`) REFERENCES `physical_network`(`id`) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8; + +INSERT IGNORE INTO `cloud`.`configuration` VALUES (Advanced, 'DEFAULT', 'management-server', usage.report.interval, 7, Interval (days) between sending anonymous Usage Reports back to the CloudStack project, , NULL, NULL, 0); --- End diff -- with the new style config (ConfigKeyT), this isn't needed is it? It should insert the default if it doesn't find the value. 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=14642710#comment-14642710 ] 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_r35533953 --- Diff: setup/db/db/schema-452to460.sql --- @@ -398,3 +398,5 @@ CREATE TABLE `cloud`.`external_bigswitch_bcf_devices` ( CONSTRAINT `fk_external_bigswitch_bcf_devices__host_id` FOREIGN KEY (`host_id`) REFERENCES `host`(`id`) ON DELETE CASCADE, CONSTRAINT `fk_external_bigswitch_bcf_devices__physical_network_id` FOREIGN KEY (`physical_network_id`) REFERENCES `physical_network`(`id`) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8; + +INSERT IGNORE INTO `cloud`.`configuration` VALUES (Advanced, 'DEFAULT', 'management-server', usage.report.interval, 7, Interval (days) between sending anonymous Usage Reports back to the CloudStack project, , NULL, NULL, 0); --- End diff -- Hmm, I don't know. I wrote this code in 2014 and was that in there by now? I'm just doing this because I assumed it was still required. Maybe @bhaisaab knows? 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=14642711#comment-14642711
]
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_r35534192
--- Diff: server/src/org/apache/cloudstack/report/UsageReporter.java ---
@@ -0,0 +1,473 @@
+// 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-8677) Call-home functionality for CloudStack
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642712#comment-14642712
]
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_r35534267
--- Diff: server/src/org/apache/cloudstack/report/UsageReporter.java ---
@@ -0,0 +1,473 @@
+// 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-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=14643096#comment-14643096
]
Wilder Rodrigues commented on CLOUDSTACK-8668:
--
Few things I got from the logs when creating a VM:
2015-07-27 13:28:20,921 DEBUG [c.c.h.x.r.w.x.CitrixStartCommandWrapper]
(DirectAgent-28:ctx-b81b9e66) 1. The VM r-4-VM is in Starting state.
2015-07-27 13:28:20,950 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-28:ctx-b81b9e66) Created VM d42abe6d-d225-c738-d905-a303883cb093
for r-4-VM
2015-07-27 13:28:20,958 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-28:ctx-b81b9e66) PV args are -- quiet
console=hvc0%template=domP%name=r-4-VM%eth0ip=192.168.22.66%eth0mask=255.255.255.0%gateway=192.168.22.1%domain=cs1cloud%cidrsize=24%dhcprange=192.168.22.1%eth1i
p=169.254.2.146%eth1mask=255.255.0.0%type=dhcpsrvr%disable_rp_filter=true%dns1=8.8.8.8%dns2=8.8.4.4%baremetalnotificationsecuritykey=aon4dbRYnNESI4PY3PDh64PgJKAx6H11OfLVwZAWE-4uJWV-iJrg7fcgdTHDVVjOP81TS0UBxKMmY53r0y88bw%baremetalnotificationapikey=CAC7caUw4uF9wfLNrSObdj-h
VkVSo9MQzEMIjN4rIfSjOAu8TJxVnHaFEU8W5utTWuuDJqHiqtXgTJT7T-Cm4w%host=192.168.22.61%port=8080
2015-07-27 13:28:21,006 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-28:ctx-b81b9e66) VBD 6c7a704f-6043-d09e-ecbb-27e8b6378597 created
for com.cloud.agent.api.to.DiskTO@ad357be
2015-07-27 13:28:21,024 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-28:ctx-b81b9e66) Creating VIF for r-4-VM on nic
[Nic:Guest-192.168.22.66-vlan://untagged]
2015-07-27 13:28:21,048 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-28:ctx-b81b9e66) Created a vif
8db43efe-bac2-8b6e-d20f-b2f25445e6c1 on 0
2015-07-27 13:28:21,048 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-28:ctx-b81b9e66) Creating VIF for r-4-VM on nic
[Nic:Control-169.254.2.146-null]
2015-07-27 13:28:21,099 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-28:ctx-b81b9e66) already have a vif on dom0 for link local network
2015-07-27 13:28:21,284 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-28:ctx-b81b9e66) Created a vif
dbe914ad-eed8-c79c-0162-4cb7118ab701 on 1
2015-07-27 13:31:55,197 DEBUG [c.c.c.ClusterManagerImpl]
(Cluster-Heartbeat-1:ctx-4fe9ccf7) Management server heartbeat takes too long
to finish. profiler: Done. Duration: 5ms, profilerHeartbeatUpdate: Done.
Duration: 4ms, profilerPeerScan: Done. Duration: 1ms
2015-07-27 13:31:55,580 ERROR [c.c.u.s.SshHelper] (DirectAgent-28:ctx-b81b9e66)
Timed out in waiting SSH execution result
2015-07-27 13:31:55,581 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-28:ctx-b81b9e66) Seq 1-7644297417507995698: Response Received:
2015-07-27 13:31:55,583 DEBUG [c.c.a.t.Request] (DirectAgent-28:ctx-b81b9e66)
Seq 1-7644297417507995698: Processing: { Ans: , MgmtId: 3232241213, via: 1,
Ver: v1, Flags: 10,
[{com.cloud.agent.api.StartAnswer:{vm:{id:4,name:r-4-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-4-VM eth0ip=192.168.22.66
eth0mask=255.255.255.0 gateway=192.168.22.1 domain=cs1cloud cidrsize=24
dhcprange=192.168.22.1 eth1ip=169.254.2.146 eth1mask=255.255.0.0 type=dhcpsrvr
disable_rp_filter=true dns1=8.8.8.8 dns2=8.8.4.4
baremetalnotificationsecuritykey=aon4dbRYnNESI4PY3PDh64PgJKAx6H11OfLVwZAWE-4uJWV-iJrg7fcgdTHDVVjOP81TS0UBxKMmY53r0y88bw
baremetalnotificationapikey=CAC7caUw4uF9wfLNrSObdj-hVkVSo9MQzEMIjN4rIfSjOAu8TJxVnHaFEU8W5utTWuuDJqHiqtXgTJT7T-Cm4w
host=192.168.22.61
[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 ] Wilder Rodrigues updated CLOUDSTACK-8668: - Assignee: 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: 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=14643075#comment-14643075 ] Wilder Rodrigues commented on CLOUDSTACK-8668: -- I'm testing it with 2 xenserver (cluster), shared storage and basic zone 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] [Created] (CLOUDSTACK-8678) OOM Kills Guests
Josh Harshman created CLOUDSTACK-8678: - Summary: 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-8678) OOM Kills Guests
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643525#comment-14643525 ] Daan Hoogland commented on CLOUDSTACK-8678: --- Josh, this seems more a user question then a bug report;) It could well be or become one though. What you are looking for is the overprovisioning ratio, i think. set it to 0.9 or some other value below 1. I am not sure that ACS honours it correctly but it is worth a shot. look for overprovisioning in the global settings (or zone/pod/cluster settings) 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] [Updated] (CLOUDSTACK-8679) Changes to RabbitMQ events notification framework not documented anywhere
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yiping Zhang updated CLOUDSTACK-8679: - Summary: Changes to RabbitMQ events notification framework not documented anywhere (was: problem parsing RabbitMQ events) Changes to RabbitMQ events notification framework not documented anywhere - Key: CLOUDSTACK-8679 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8679 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.5.1 Reporter: Yiping Zhang There seems to be some quite major changes in RabbitMQ events generated by CloudStack between 4.3.x and 4.5.1 . However, there are no documentations mentioning such changes in either release notes or admin guide. Such changes break any and all integrations with external apps which happen to use affected CloudStack events. For me, I only use VM.CREATE and VM.DESTROY events and both are changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8680) problem parsing RabbitMQ events
Yiping Zhang created CLOUDSTACK-8680:
Summary: problem parsing RabbitMQ events
Key: CLOUDSTACK-8680
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8680
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.5.1
Reporter: Yiping Zhang
RabbitMQ event message for VM.CREATE and VM.DESTROY events can't be parsed
cleanly. Here is an example:
{
cmdInfo:
{\response\:\json\,\id\:\b780c229-7064-47e5-97d0-a8b4590b36b8\,\sessionkey\:\WY6E5WuM8SbqMw4bCumnVgGsgEQ\\u003d\,\ctxDetails\:\{\\\com.cloud.vm.VirtualMachine\\\:\\\b780c229-7064-47e5-97d0-a8b4590b36b8\\\}\,\cmdEventType\:\VM.DESTROY\,\ctxUserId\:\2\,\httpmethod\:\GET\,\_\:\1438027779033\,\uuid\:\b780c229-7064-47e5-97d0-a8b4590b36b8\,\ctxAccountId\:\2\,\ctxStartEventId\:\6282\},
instanceType: VirtualMachine,
instanceUuid: b780c229-7064-47e5-97d0-a8b4590b36b8,
jobId: 61a62e5d-61ee-41eb-b947-0f8ef5d857c3,
status: SUCCEEDED,
processStatus: 0,
commandEventType: VM.DESTROY,
resultCode: 0,
command: org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin,
jobResult:
org.apache.cloudstack.api.response.UserVmResponse/virtualmachine/{\id\:\b780c229-7064-47e5-97d0-a8b4590b36b8\,\name\:\yz-x1\,\displayname\:\yz-x1\,\account\:\admin\,\domainid\:\994ff03e-bb8f-11e4-b7d5-36d1d14da5e9\,\domain\:\ROOT\,\created\:\2015-07-27T12:01:12-0500\,\state\:\Destroyed\,\haenable\:false,\zoneid\:\1b0b4859-7b8a-41dd-8522-4dbf24345509\,\zonename\:\sjlab\,\templateid\:\e6fa410f-4bf0-4b3c-9982-9d60e7ffc07e\,\templatename\:\Base\,\templatedisplaytext\:\Base
with 32 GB root and
cloud-init\,\passwordenabled\:false,\serviceofferingid\:\11a5e901-bc78-45c6-8b81-a2a9e3530164\,\serviceofferingname\:\1CPU@1.0Ghz@1.5GB\,\cpunumber\:1,\cpuspeed\:1000,\memory\:1536,\cpuused\:\0.56%\,\networkkbsread\:0,\networkkbswrite\:2,\diskkbsread\:2670,\diskkbswrite\:163,\diskioread\:0,\diskiowrite\:0,\guestosid\:\a0c75a5b-bb8f-11e4-b7d5-36d1d14da5e9\,\rootdeviceid\:0,\rootdevicetype\:\ROOT\,\securitygroup\:[{\id\:\ad13aa78-bb8f-11e4-b7d5-36d1d14da5e9\,\name\:\default\,\description\:\Default
Security
Group\,\account\:\admin\,\ingressrule\:[],\egressrule\:[],\tags\:[]}],\nic\:[{\id\:\1c87d7e1-f8c9-425e-809d-7edd1a30c3a6\,\networkid\:\abe603fe-1d8b-4b23-9aa2-0234f18de686\,\networkname\:\vlan106\,\netmask\:\255.255.255.0\,\gateway\:\10.0.106.1\,\ipaddress\:\10.0.106.170\,\isolationuri\:\vlan://106\,\broadcasturi\:\vlan://106\,\traffictype\:\Guest\,\type\:\Shared\,\isdefault\:true,\macaddress\:\06:d9:2e:00:03:f6\}],\hypervisor\:\XenServer\,\instancename\:\i-2-346-VM\,\tags\:[],\details\:{\hypervisortoolsversion\:\xenserver56\},\affinitygroup\:[],\displayvm\:true,\isdynamicallyscalable\:true,\ostypeid\:206,\jobid\:\61a62e5d-61ee-41eb-b947-0f8ef5d857c3\,\jobstatus\:0},
account: ad11bb05-bb8f-11e4-b7d5-36d1d14da5e9,
user: ad129c91-bb8f-11e4-b7d5-36d1d14da5e9
}
There are two problems for above example:
1. The nested data structures are not parsed properly. As you can see, values
for both “cmdInfo” and “jobResult” are strings instead of nested hash. I have
to make additional calls to JSON parser on those values to parse them.
2. The string
org.apache.cloudstack.api.response.UserVmResponse/virtualmachine/“ at the
beginning of the value for “jobResult” makes this value invalid to be parsed as
JSON object at all.
--
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=14643612#comment-14643612 ] Josh Harshman commented on CLOUDSTACK-8678: --- Daan, Thanks for the quick reply. It does kinda sound like a user question :P. But I wouldn't have submitted an issue unless I had already explored other avenues. Cloudstack doesn't appear to like setting the overprovisioning factor to any value less than one (at least through the GUI). Unless you can force it through the cli? Error Message: mem.overprovisioning.factor should be greater than or equal to 1 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-8652) drop old upgrade code
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643613#comment-14643613 ] ASF GitHub Bot commented on CLOUDSTACK-8652: Github user pdion891 commented on the pull request: https://github.com/apache/cloudstack/pull/608#issuecomment-125378707 +1 for the concept, we need to get rid of old crappy stuff, none of those upgrade path are tested during RC and dev a release. Some of them have been removed from 4.5 release notes because they were not tested. Although, some upgrade path should remain, maybe from 4.3.x. also, I wouldn't add this in 4.6 but maybe the next one 4.7 or 5.0? Out of curiosity, where the database structure get created/updated from removed code? In theory if someone want's to upgrade from something as old a 3.x to 4.6, he would probably need to do some intermediary upgrade, which is fairly standard in the firmware world and anyway, he wouldn't have just cloudstack to upgrade but far probably the hypervisor stack too. My 2 cents ;) I'm more in favor of a much more solid app confirmed by coverity then outdated upgrade path to a so-so version. drop old upgrade code - Key: CLOUDSTACK-8652 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8652 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Reporter: Daan Hoogland Assignee: Daan Hoogland old upgrade code contains a lot of resource leaks. users still below version 4.0 can upgrade to any version between 4.0.0 and 4.5.x and then move on. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8679) problem parsing RabbitMQ events
Yiping Zhang created CLOUDSTACK-8679: Summary: problem parsing RabbitMQ events Key: CLOUDSTACK-8679 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8679 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.5.1 Reporter: Yiping Zhang There seems to be some quite major changes in RabbitMQ events generated by CloudStack between 4.3.x and 4.5.1 . However, there are no documentations mentioning such changes in either release notes or admin guide. Such changes break any and all integrations with external apps which happen to use affected CloudStack events. For me, I only use VM.CREATE and VM.DESTROY events and both are changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8680) problem parsing RabbitMQ events
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yiping Zhang updated CLOUDSTACK-8680:
-
Description:
RabbitMQ event message for VM.CREATE and VM.DESTROY events can't be parsed
cleanly. Here is an example:
{code}
{
cmdInfo:
{\response\:\json\,\id\:\b780c229-7064-47e5-97d0-a8b4590b36b8\,\sessionkey\:\WY6E5WuM8SbqMw4bCumnVgGsgEQ\\u003d\,\ctxDetails\:\{\\\com.cloud.vm.VirtualMachine\\\:\\\b780c229-7064-47e5-97d0-a8b4590b36b8\\\}\,\cmdEventType\:\VM.DESTROY\,\ctxUserId\:\2\,\httpmethod\:\GET\,\_\:\1438027779033\,\uuid\:\b780c229-7064-47e5-97d0-a8b4590b36b8\,\ctxAccountId\:\2\,\ctxStartEventId\:\6282\},
instanceType: VirtualMachine,
instanceUuid: b780c229-7064-47e5-97d0-a8b4590b36b8,
jobId: 61a62e5d-61ee-41eb-b947-0f8ef5d857c3,
status: SUCCEEDED,
processStatus: 0,
commandEventType: VM.DESTROY,
resultCode: 0,
command: org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin,
jobResult:
org.apache.cloudstack.api.response.UserVmResponse/virtualmachine/{\id\:\b780c229-7064-47e5-97d0-a8b4590b36b8\,\name\:\yz-x1\,\displayname\:\yz-x1\,\account\:\admin\,\domainid\:\994ff03e-bb8f-11e4-b7d5-36d1d14da5e9\,\domain\:\ROOT\,\created\:\2015-07-27T12:01:12-0500\,\state\:\Destroyed\,\haenable\:false,\zoneid\:\1b0b4859-7b8a-41dd-8522-4dbf24345509\,\zonename\:\sjlab\,\templateid\:\e6fa410f-4bf0-4b3c-9982-9d60e7ffc07e\,\templatename\:\Base\,\templatedisplaytext\:\Base
with 32 GB root and
cloud-init\,\passwordenabled\:false,\serviceofferingid\:\11a5e901-bc78-45c6-8b81-a2a9e3530164\,\serviceofferingname\:\1CPU@1.0Ghz@1.5GB\,\cpunumber\:1,\cpuspeed\:1000,\memory\:1536,\cpuused\:\0.56%\,\networkkbsread\:0,\networkkbswrite\:2,\diskkbsread\:2670,\diskkbswrite\:163,\diskioread\:0,\diskiowrite\:0,\guestosid\:\a0c75a5b-bb8f-11e4-b7d5-36d1d14da5e9\,\rootdeviceid\:0,\rootdevicetype\:\ROOT\,\securitygroup\:[{\id\:\ad13aa78-bb8f-11e4-b7d5-36d1d14da5e9\,\name\:\default\,\description\:\Default
Security
Group\,\account\:\admin\,\ingressrule\:[],\egressrule\:[],\tags\:[]}],\nic\:[{\id\:\1c87d7e1-f8c9-425e-809d-7edd1a30c3a6\,\networkid\:\abe603fe-1d8b-4b23-9aa2-0234f18de686\,\networkname\:\vlan106\,\netmask\:\255.255.255.0\,\gateway\:\10.0.106.1\,\ipaddress\:\10.0.106.170\,\isolationuri\:\vlan://106\,\broadcasturi\:\vlan://106\,\traffictype\:\Guest\,\type\:\Shared\,\isdefault\:true,\macaddress\:\06:d9:2e:00:03:f6\}],\hypervisor\:\XenServer\,\instancename\:\i-2-346-VM\,\tags\:[],\details\:{\hypervisortoolsversion\:\xenserver56\},\affinitygroup\:[],\displayvm\:true,\isdynamicallyscalable\:true,\ostypeid\:206,\jobid\:\61a62e5d-61ee-41eb-b947-0f8ef5d857c3\,\jobstatus\:0},
account: ad11bb05-bb8f-11e4-b7d5-36d1d14da5e9,
user: ad129c91-bb8f-11e4-b7d5-36d1d14da5e9
}
{code}
There are two problems for above example:
1. The nested data structures are not parsed properly. As you can see, values
for both “cmdInfo” and “jobResult” are strings instead of nested hash. I have
to make additional calls to JSON parser on those values to parse them.
2. The string
org.apache.cloudstack.api.response.UserVmResponse/virtualmachine/“ at the
beginning of the value for “jobResult” makes this value invalid to be parsed as
JSON object at all.
was:
RabbitMQ event message for VM.CREATE and VM.DESTROY events can't be parsed
cleanly. Here is an example:
{
cmdInfo:
{\response\:\json\,\id\:\b780c229-7064-47e5-97d0-a8b4590b36b8\,\sessionkey\:\WY6E5WuM8SbqMw4bCumnVgGsgEQ\\u003d\,\ctxDetails\:\{\\\com.cloud.vm.VirtualMachine\\\:\\\b780c229-7064-47e5-97d0-a8b4590b36b8\\\}\,\cmdEventType\:\VM.DESTROY\,\ctxUserId\:\2\,\httpmethod\:\GET\,\_\:\1438027779033\,\uuid\:\b780c229-7064-47e5-97d0-a8b4590b36b8\,\ctxAccountId\:\2\,\ctxStartEventId\:\6282\},
instanceType: VirtualMachine,
instanceUuid: b780c229-7064-47e5-97d0-a8b4590b36b8,
jobId: 61a62e5d-61ee-41eb-b947-0f8ef5d857c3,
status: SUCCEEDED,
processStatus: 0,
commandEventType: VM.DESTROY,
resultCode: 0,
command: org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin,
jobResult:
org.apache.cloudstack.api.response.UserVmResponse/virtualmachine/{\id\:\b780c229-7064-47e5-97d0-a8b4590b36b8\,\name\:\yz-x1\,\displayname\:\yz-x1\,\account\:\admin\,\domainid\:\994ff03e-bb8f-11e4-b7d5-36d1d14da5e9\,\domain\:\ROOT\,\created\:\2015-07-27T12:01:12-0500\,\state\:\Destroyed\,\haenable\:false,\zoneid\:\1b0b4859-7b8a-41dd-8522-4dbf24345509\,\zonename\:\sjlab\,\templateid\:\e6fa410f-4bf0-4b3c-9982-9d60e7ffc07e\,\templatename\:\Base\,\templatedisplaytext\:\Base
with 32 GB root and
[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=14643706#comment-14643706
]
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_r35605766
--- 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 --
May be we wanted to add a small check to see report is None and proceed.
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=14643705#comment-14643705
]
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_r35605705
--- 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-8677) Call-home functionality for CloudStack
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643717#comment-14643717
]
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_r35606107
--- 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-8675) master branch fail to build .deb packages.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre-Luc Dion reassigned CLOUDSTACK-8675:
---
Assignee: Pierre-Luc Dion
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=14643707#comment-14643707
]
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_r35605790
--- 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 --
Where is this application var used? Its not global var as well?
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=14643708#comment-14643708 ] 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_r35605842 --- 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 is good work i would say, but just add some comments on this service purpose, may be for people seeing it later can understand it easily. Any reason to have this service written in python and other usage code to run along with cs in java? 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-8610) [VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642526#comment-14642526
]
ASF GitHub Bot commented on CLOUDSTACK-8610:
Github user wilderrodrigues commented on the pull request:
https://github.com/apache/cloudstack/pull/554#issuecomment-125155019
+1 for @DaanHoogland's comments: please add unit tests to cover the changes.
[VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance
--
Key: CLOUDSTACK-8610
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8610
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Fix For: 4.6.0
+Steps to reproduce+
1. Set global config vmware.root.disk.controller to 'osdefault'.
2. Deploy a VM and attach 6 disks to the VM.
3. Try to attach a 7th disk to the VM.
Step 3 will fail with the below error
{noformat}
2015-06-22 11:03:22,673 ERROR [c.c.s.r.VmwareStorageProcessor]
(DirectAgent-636:ctx-8e72c2d9 s1p-z1-esxic-001.es.local, job-9286/job-9287,
cmd: AttachCommand) (logid:6372e940) Failed to attach volume: Failed to add
disk scsi0:7.
java.lang.RuntimeException: Failed to add disk scsi0:7.
at
com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:336)
at
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.attachDisk(VirtualMachineMO.java:1206)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8666) Put host in Alert state only after alert.wait timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642531#comment-14642531 ] ASF GitHub Bot commented on CLOUDSTACK-8666: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/621#issuecomment-12513 Hi @koushik-das Perhaps refactoring the code in a way that its design is improved could make easy to add tests for it. Put host in Alert state only after alert.wait timeout - Key: CLOUDSTACK-8666 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8666 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0, 4.6.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 When there is a ping timeout on a host, investigators try to determine the state of a host. If none of the investigators are able to determine the host state then the process is repeated after some time. This works most of the time except some boundary scenarios. For e.g. if last host or all host in a XS cluster are brought down then the investigators are not able to determine the host state and the investigation process never completes. In such scenarios host state always remain as Up. In order to fix these boundary scenarios, a fix was made (refer to commit 4a13f81485c0f0664c60acafe534946e7428f080) to immediately put the host in Alert state if investigators are not able to determine the state after ping timeout. The fix solved the boundary scenarios but introduced a new issue. Suppose there is a XS cluster with 2 hosts and the master host is brought down. In this case XS elects a new master for the cluster. Since master is down, investigators won't able to determine host state until a new master is elected. If this master election takes more than ping timeout to complete then the host is put to Alert based on the above fix. Once this happens, the host continues to remain in Alert state and no actions are taken on the VMs on this host. In this case if the investigators were allowed to run for 1 or 2 more times, possibly the new master election would have completed and host state correctly determined. In order to fix both these issues, instead of putting the host to Alert state immediately, the investigators should be allowed to run for some time based on alert.wait global config. At the end of this interval if the host state still cannot be determined then put the host in Alert. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8666) Put host in Alert state only after alert.wait timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642537#comment-14642537 ] ASF GitHub Bot commented on CLOUDSTACK-8666: Github user koushik-das commented on the pull request: https://github.com/apache/cloudstack/pull/621#issuecomment-125156829 @wilderrodrigues Agree that refactoring the code might help with the tests. But that will be a bigger effort. Put host in Alert state only after alert.wait timeout - Key: CLOUDSTACK-8666 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8666 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0, 4.6.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 When there is a ping timeout on a host, investigators try to determine the state of a host. If none of the investigators are able to determine the host state then the process is repeated after some time. This works most of the time except some boundary scenarios. For e.g. if last host or all host in a XS cluster are brought down then the investigators are not able to determine the host state and the investigation process never completes. In such scenarios host state always remain as Up. In order to fix these boundary scenarios, a fix was made (refer to commit 4a13f81485c0f0664c60acafe534946e7428f080) to immediately put the host in Alert state if investigators are not able to determine the state after ping timeout. The fix solved the boundary scenarios but introduced a new issue. Suppose there is a XS cluster with 2 hosts and the master host is brought down. In this case XS elects a new master for the cluster. Since master is down, investigators won't able to determine host state until a new master is elected. If this master election takes more than ping timeout to complete then the host is put to Alert based on the above fix. Once this happens, the host continues to remain in Alert state and no actions are taken on the VMs on this host. In this case if the investigators were allowed to run for 1 or 2 more times, possibly the new master election would have completed and host state correctly determined. In order to fix both these issues, instead of putting the host to Alert state immediately, the investigators should be allowed to run for some time based on alert.wait global config. At the end of this interval if the host state still cannot be determined then put the host in Alert. -- 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=14642538#comment-14642538 ] ASF GitHub Bot commented on CLOUDSTACK-8651: Github user koushik-das commented on the pull request: https://github.com/apache/cloudstack/pull/607#issuecomment-125157246 @DaanHoogland Are you running some private simulator test? If so is it done? [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] [Updated] (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 updated CLOUDSTACK-83:
--
Fix Version/s: (was: pre-4.0.0)
4.6.0
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
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] [Updated] (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 updated CLOUDSTACK-4442: Fix Version/s: (was: Future) 4.6.0 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: Murali Reddy 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] [Resolved] (CLOUDSTACK-5211) Need Support for the OVM for the Report sockets CS-4908
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-5211. - Resolution: Fixed Need Support for the OVM for the Report sockets CS-4908 --- Key: CLOUDSTACK-5211 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5211 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kiran Koneti Priority: Blocker For the report sockets feature we need to provide support for the OVM hypervisor.The support is not yet added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-4419) Marvin needs versioning and a remote pypi repository to fetch latest
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-4419: Priority: Critical (was: Blocker) Marvin needs versioning and a remote pypi repository to fetch latest Key: CLOUDSTACK-4419 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4419 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Assignee: Prasanna Santhanam Priority: Critical It is very unweildy to update marvin from the development environment. And since whenever an API definition changes QA needs to update marvin libraries it is harder to do a simple update. 1. Create a pypi repo for marvin-latest from where the latest builds with latest APIs can be installed/upgraded using $pip install cloudstack-marvin-latest 2. Versioning marvin alongside CloudStack releases. -latest will have minor version numbers 3. Make the sync functionality more robust to update against a given management server all the API libraries. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-5397) Starting VM fails if VM snapshot is created
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-5397. - Resolution: Fixed resolving as it works on higher version. Please reopen if you are able to reproduce in any of the recent versions Starting VM fails if VM snapshot is created --- Key: CLOUDSTACK-5397 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5397 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Antonio Petrocelli Priority: Blocker Hello, i configured CS 4.2 with a basic network zone and local disk. Configuration is one zone, one pod, one cluster, one host, one primary storage ( local ), one secondary storage ( nfs ). I am using VMware 5.1 If i create an instance everything works. If i take a VM snapshot, after stop and start vm i obtain same error discussed here: https://issues.apache.org/jira/browse/CLOUDSTACK-3234 On issues website it said it was fixed ( at least for advanced network ) but i still receive same error. VM does not start and on CS log i see following lines: 2013-12-05 17:48:04,372 INFO [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-27:job-72 = [ 48e7c5c4-c2f0-4ea1-8e8e-045332c5f9db ]) Unable to start VM on Host[-4-Routing] due to StartCommand failed due to Exception: java.lang.RuntimeException Message: Invalid configuration for device '0'. If i delete VM snapshot everything works. Waiting for your reply Best regards -- 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:
Issue Type: Bug (was: Task)
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-5717) Unable to start new instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-5717. - Resolution: Fixed resolving as it works on recent versions. Please reopen if you are able to reproduce in any of the recent versions Unable to start new instance Key: CLOUDSTACK-5717 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5717 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: ISO, Management Server, VMware Affects Versions: 4.2.0 Environment: Management Server - Cloudstack 4.2.0, CentOS6.4 Secondary Storage - NFS Server VMware vCenter 5.1.0 build 799731 Hypervisors - ESXi 5.1.0 build 838463 Reporter: Alex Rybchenko Priority: Blocker Attachments: management-serverl.log We have created few projects and already started migration of our production and successfully migrated few. But now we are not able to start new instances from ISO In cloudstack GUI we have error: Unable to create a deployment for VM In vmware logs: Invalid configuration for device 0 in management server: exception Invalid configuration for device 0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=14643786#comment-14643786 ] ASF GitHub Bot commented on CLOUDSTACK-8638: GitHub user pdion891 opened a pull request: https://github.com/apache/cloudstack/pull/626 fix systemvm64template build, fix .deb package creation. - build .deb package job must be change for ``dpkg-buildpackage -uc -us`` ubuntu 14.04 enforce signature of package. CLOUDSTACK-8638 - @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 merge this pull request into a Git repository by running: $ git pull https://github.com/pdion891/cloudstack 8675 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/626.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 #626 commit 6a01f48e1bb55826790af354686d150b5d440e02 Author: Pierre-Luc Dion pdion...@apache.org Date: 2015-07-28T00:49:40Z fix dependency for keepalived from wheezy-backports commit a3319b76ba04f64f3121470a976799c44a58d53b Author: Pierre-Luc Dion pdion...@apache.org Date: 2015-07-28T01:16:30Z fix release version automatically updated using pom.xml commit d4bfca6330a3fbe50156e9e249a2535e80be9cda Author: Pierre-Luc Dion pdion...@apache.org Date: 2015-07-28T01:20:48Z change last owner of change for pgp signature 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-8664) Verify if queryAsyncJobResult api return jobinstanceid
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642322#comment-14642322 ] ASF GitHub Bot commented on CLOUDSTACK-8664: Github user sanju1010 commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/619#discussion_r35507858 --- Diff: test/integration/testpaths/testpath_queryAsyncJobResult.py --- @@ -0,0 +1,133 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# License); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + Test case to check if queryAsyncJobResult returns jobinstanceid + +from nose.plugins.attrib import attr +from marvin.cloudstackTestCase import cloudstackTestCase +from marvin.lib.utils import (cleanup_resources) +from marvin.lib.base import (Account, + ServiceOffering, + VirtualMachine, + ) +from marvin.lib.common import (get_domain, + get_zone, + get_template, + ) + +from marvin.cloudstackAPI import queryAsyncJobResult + +class TestJobinstanceid(cloudstackTestCase): + +@classmethod +def setUpClass(cls): +testClient = super(TestJobinstanceid, cls).getClsTestClient() +cls.apiclient = testClient.getApiClient() +cls.testdata = testClient.getParsedTestDataConfig() + +cls.hypervisor = cls.testClient.getHypervisorInfo() +# Get Zone, Domain and templates +cls.domain = get_domain(cls.apiclient) +cls.zone = get_zone(cls.apiclient, testClient.getZoneForTests()) + +cls.template = get_template( +cls.apiclient, +cls.zone.id, +cls.testdata[ostype]) + +cls._cleanup = [] + +try: + +# Create an account +cls.account = Account.create( +cls.apiclient, +cls.testdata[account], +domainid=cls.domain.id +) +# Create user api client of the account +cls.userapiclient = testClient.getUserApiClient( +UserName=cls.account.name, +DomainName=cls.account.domain +) + + # Create Service offering +cls.service_offering = ServiceOffering.create( +cls.apiclient, +cls.testdata[service_offering], +) + +cls._cleanup = [ +cls.account, +cls.service_offering, +] +except Exception as e: +cls.tearDownClass() +raise e +return + + +@classmethod +def tearDownClass(cls): +try: +cleanup_resources(cls.apiclient, cls._cleanup) +except Exception as e: +raise Exception(Warning: Exception during cleanup : %s % e) + +def setUp(self): +self.apiclient = self.testClient.getApiClient() +self.dbclient = self.testClient.getDbConnection() +self.cleanup = [] + +def tearDown(self): +try: +cleanup_resources(self.apiclient, self.cleanup) +except Exception as e: +raise Exception(Warning: Exception during cleanup : %s % e) +return + +@attr(tags=[advanced, basic], required_hardware=false) +def test_queryAsyncJobResult_jobinstanceid(self): + Test queryAsyncJobResult api return jobinstanceid + +# 1. Deploy a VM +# 2. Call queryAsyncJobResult API with jobid of previous step +# 3. Verify that queryAsyncJobResult returns jobinstanceid + + +# Step 1 + --- End diff -- Please fix pep8 issues Verify if queryAsyncJobResult api return jobinstanceid
[jira] [Commented] (CLOUDSTACK-8664) Verify if queryAsyncJobResult api return jobinstanceid
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642349#comment-14642349 ] ASF GitHub Bot commented on CLOUDSTACK-8664: Github user pritisarap12 commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/619#discussion_r35508814 --- Diff: test/integration/testpaths/testpath_queryAsyncJobResult.py --- @@ -0,0 +1,133 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# License); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + Test case to check if queryAsyncJobResult returns jobinstanceid + +from nose.plugins.attrib import attr +from marvin.cloudstackTestCase import cloudstackTestCase +from marvin.lib.utils import (cleanup_resources) +from marvin.lib.base import (Account, + ServiceOffering, + VirtualMachine, + ) +from marvin.lib.common import (get_domain, + get_zone, + get_template, + ) + +from marvin.cloudstackAPI import queryAsyncJobResult + +class TestJobinstanceid(cloudstackTestCase): + +@classmethod +def setUpClass(cls): +testClient = super(TestJobinstanceid, cls).getClsTestClient() +cls.apiclient = testClient.getApiClient() +cls.testdata = testClient.getParsedTestDataConfig() + +cls.hypervisor = cls.testClient.getHypervisorInfo() +# Get Zone, Domain and templates +cls.domain = get_domain(cls.apiclient) +cls.zone = get_zone(cls.apiclient, testClient.getZoneForTests()) + +cls.template = get_template( +cls.apiclient, +cls.zone.id, +cls.testdata[ostype]) + +cls._cleanup = [] + +try: + +# Create an account +cls.account = Account.create( +cls.apiclient, +cls.testdata[account], +domainid=cls.domain.id +) +# Create user api client of the account +cls.userapiclient = testClient.getUserApiClient( +UserName=cls.account.name, +DomainName=cls.account.domain +) + + # Create Service offering +cls.service_offering = ServiceOffering.create( +cls.apiclient, +cls.testdata[service_offering], +) + +cls._cleanup = [ +cls.account, +cls.service_offering, +] +except Exception as e: +cls.tearDownClass() +raise e +return + + +@classmethod +def tearDownClass(cls): +try: +cleanup_resources(cls.apiclient, cls._cleanup) +except Exception as e: +raise Exception(Warning: Exception during cleanup : %s % e) + +def setUp(self): +self.apiclient = self.testClient.getApiClient() +self.dbclient = self.testClient.getDbConnection() +self.cleanup = [] + +def tearDown(self): +try: +cleanup_resources(self.apiclient, self.cleanup) +except Exception as e: +raise Exception(Warning: Exception during cleanup : %s % e) +return + +@attr(tags=[advanced, basic], required_hardware=false) +def test_queryAsyncJobResult_jobinstanceid(self): + Test queryAsyncJobResult api return jobinstanceid + +# 1. Deploy a VM +# 2. Call queryAsyncJobResult API with jobid of previous step +# 3. Verify that queryAsyncJobResult returns jobinstanceid + + +# Step 1 + --- End diff -- Fixed pep8 issues. Verify if queryAsyncJobResult api return jobinstanceid
[jira] [Updated] (CLOUDSTACK-8676) Deploy user instance from vm snapshot for VMware hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-8676: - Description: Currently, ACS provides the ability to deploy a VM from a template or ISO. However, ACS does not provide the ability to deploy a VM(s) directly from a VM snapshot. VM snapshots are stored in the primary storage and have a hierarchical or parent/child relationship. The requirement would be to provide the ability to deploy user instances from selected VM snapshots. Additionally, any VM snapshot in the hierarchy can be deployed concurrently. Even though this can be supported and applicable to all hypervisors, to start with this feature is supported only for VMware hypervisor. Feature specification is at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Deploy+instance+from+VM+snapshot was: Currently, ACS provides the ability to deploy a VM from a template or ISO. However, ACS does not provide the ability to deploy a VM(s) directly from a VM snapshot. VM snapshots are stored in the primary storage and have a hierarchical or parent/child relationship. The requirement would be to provide the ability to deploy user instances from selected VM snapshots. Additionally, any VM snapshot in the hierarchy can be deployed concurrently. Even though this can be supported and applicable to all hypervisors, to start with this feature is supported only for VMware hypervisor. Deploy user instance from vm snapshot for VMware hypervisor --- Key: CLOUDSTACK-8676 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8676 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, VMware Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 Currently, ACS provides the ability to deploy a VM from a template or ISO. However, ACS does not provide the ability to deploy a VM(s) directly from a VM snapshot. VM snapshots are stored in the primary storage and have a hierarchical or parent/child relationship. The requirement would be to provide the ability to deploy user instances from selected VM snapshots. Additionally, any VM snapshot in the hierarchy can be deployed concurrently. Even though this can be supported and applicable to all hypervisors, to start with this feature is supported only for VMware hypervisor. Feature specification is at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Deploy+instance+from+VM+snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8664) Verify if queryAsyncJobResult api return jobinstanceid
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642371#comment-14642371 ] ASF GitHub Bot commented on CLOUDSTACK-8664: Github user nitt10prashant commented on the pull request: https://github.com/apache/cloudstack/pull/619#issuecomment-125107406 LGTM Verify if queryAsyncJobResult api return jobinstanceid -- Key: CLOUDSTACK-8664 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8664 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.2.1 Reporter: Priti Sarap Fix For: 4.2.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8677) Call-home functionality for CloudStack
Wido den Hollander created CLOUDSTACK-8677: -- Summary: 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-8664) Verify if queryAsyncJobResult api return jobinstanceid
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642373#comment-14642373 ] ASF subversion and git services commented on CLOUDSTACK-8664: - Commit 9c9e902e5ca6e5f5ac5fcb186d28963d5571eb3e in cloudstack's branch refs/heads/master from [~pritisarap12] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9c9e902 ] CLOUDSTACK-8664: Verify if queryAsyncJobResult api return jobinstanceid This closes #619 Verify if queryAsyncJobResult api return jobinstanceid -- Key: CLOUDSTACK-8664 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8664 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.2.1 Reporter: Priti Sarap Fix For: 4.2.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8664) Verify if queryAsyncJobResult api return jobinstanceid
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642374#comment-14642374 ] ASF GitHub Bot commented on CLOUDSTACK-8664: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/619 Verify if queryAsyncJobResult api return jobinstanceid -- Key: CLOUDSTACK-8664 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8664 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.2.1 Reporter: Priti Sarap Fix For: 4.2.1 -- 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=14642430#comment-14642430 ] Wido den Hollander commented on CLOUDSTACK-8677: We need a VM on Apache Infra to send these statistics to 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-8634) Make changes to test_security_group.py test suite to support EIP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642451#comment-14642451 ] ASF subversion and git services commented on CLOUDSTACK-8634: - Commit 7f7026ace59d96e7d38270ec4a2fe1a7076d0e87 in cloudstack's branch refs/heads/reporter from sanjeev [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7f7026a ] CLOUDSTACK-8634: Made changes to test_security_group.py test suite to support EIP Signed-off-by: Pierre-Luc Dion pdion...@apache.org Make changes to test_security_group.py test suite to support EIP Key: CLOUDSTACK-8634 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8634 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sanjeev N Assignee: Sanjeev N Make changes to test_security_group.py test suite to support EIP 1. In case of a basic zone with EIP/ELB capability vm will have two ip addresses one from public ip range and another one from guest ip range. vm creation method in base.py returns vm ip address which is part of guest ip range as the vm.ssh.ipaddress if we don't pass mode to it. So access to vms with that ip address would not be successful. Made changes to handle this 2.vm public address is associated with Netscaler. So even if we don't allow ping traffic in security groups applied to vm, ping will be successful. Skipping ping test in case the zone is enabled with EIP/ELB 3.Removing default rules from security groups except what is needed for that test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8664) Verify if queryAsyncJobResult api return jobinstanceid
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642452#comment-14642452 ] ASF subversion and git services commented on CLOUDSTACK-8664: - Commit 9c9e902e5ca6e5f5ac5fcb186d28963d5571eb3e in cloudstack's branch refs/heads/reporter from [~pritisarap12] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9c9e902 ] CLOUDSTACK-8664: Verify if queryAsyncJobResult api return jobinstanceid This closes #619 Verify if queryAsyncJobResult api return jobinstanceid -- Key: CLOUDSTACK-8664 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8664 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.2.1 Reporter: Priti Sarap Fix For: 4.2.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8483) Private template not visible in project
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642450#comment-14642450 ] ASF subversion and git services commented on CLOUDSTACK-8483: - Commit fd17e47e152f161d4d5a66b102dc8832c8858607 in cloudstack's branch refs/heads/reporter from Sudhansu [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fd17e47 ] BUG-ID: CLOUDSTACK-8483 - Private template not visible in project added new 'projectId' parameter in createTemplate command and based current user, account and projectid decide the owner of the template. Signed-off-by: Pierre-Luc Dion pdion...@apache.org Private template not visible in project --- Key: CLOUDSTACK-8483 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8483 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Projects Affects Versions: 4.5.0 Reporter: Sudhansu Sahu Assignee: Sudhansu Sahu Private template get created outside the project context. These templates are not visible in project view. STEPS TO REPRODUCE: 1 Select a project view, and go into volumes view 2 Create a template from a Volume and wait until the process is complete 3 The template cannot be found in the project 4 Navigate back to the Default view The template can be found in the templates screen in this view -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8659) Verify presentation of volume id in description of events table for 'SNAPSHOT.CREATE' type.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642459#comment-14642459 ] ASF GitHub Bot commented on CLOUDSTACK-8659: Github user wido commented on the pull request: https://github.com/apache/cloudstack/pull/613#issuecomment-125133196 LGTM Verify presentation of volume id in description of events table for 'SNAPSHOT.CREATE' type. --- Key: CLOUDSTACK-8659 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8659 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.2.1 Reporter: Priti Sarap Labels: snapshot Fix For: 4.2.1 Verify if events table records UUID of the volume instead of volume ID from which snapshot is created for 'SNAPSHOT.CREATE' type . -- 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=14642461#comment-14642461 ] ASF GitHub Bot commented on CLOUDSTACK-8651: Github user wido commented on the pull request: https://github.com/apache/cloudstack/pull/607#issuecomment-125133501 I think this one can be merged after simulator is done, right? [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-8659) Verify presentation of volume id in description of events table for 'SNAPSHOT.CREATE' type.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642491#comment-14642491 ] ASF subversion and git services commented on CLOUDSTACK-8659: - Commit 66f5163426c5df86414d0b63d526015a683a892a in cloudstack's branch refs/heads/master from [~pritisarap12] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=66f5163 ] CLOUDSTACK-8659: Verify presentation of volume id in description of events table for 'SNAPSHOT.CREATE' type This closes #613 Verify presentation of volume id in description of events table for 'SNAPSHOT.CREATE' type. --- Key: CLOUDSTACK-8659 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8659 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.2.1 Reporter: Priti Sarap Labels: snapshot Fix For: 4.2.1 Verify if events table records UUID of the volume instead of volume ID from which snapshot is created for 'SNAPSHOT.CREATE' type . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8659) Verify presentation of volume id in description of events table for 'SNAPSHOT.CREATE' type.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642492#comment-14642492 ] ASF GitHub Bot commented on CLOUDSTACK-8659: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/613 Verify presentation of volume id in description of events table for 'SNAPSHOT.CREATE' type. --- Key: CLOUDSTACK-8659 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8659 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.2.1 Reporter: Priti Sarap Labels: snapshot Fix For: 4.2.1 Verify if events table records UUID of the volume instead of volume ID from which snapshot is created for 'SNAPSHOT.CREATE' type . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8666) Put host in Alert state only after alert.wait timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642521#comment-14642521 ] ASF GitHub Bot commented on CLOUDSTACK-8666: Github user koushik-das commented on the pull request: https://github.com/apache/cloudstack/pull/621#issuecomment-125152445 @DaanHoogland Writing an unit test for changes in AgentManagerImpl.java is hard due to the way the method gets invoked. Let me know if you have any suggestion. Fot the HighAvailabilityManagerImpl.java changes I have written a unit test, will send out the PR for that. Put host in Alert state only after alert.wait timeout - Key: CLOUDSTACK-8666 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8666 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0, 4.6.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 When there is a ping timeout on a host, investigators try to determine the state of a host. If none of the investigators are able to determine the host state then the process is repeated after some time. This works most of the time except some boundary scenarios. For e.g. if last host or all host in a XS cluster are brought down then the investigators are not able to determine the host state and the investigation process never completes. In such scenarios host state always remain as Up. In order to fix these boundary scenarios, a fix was made (refer to commit 4a13f81485c0f0664c60acafe534946e7428f080) to immediately put the host in Alert state if investigators are not able to determine the state after ping timeout. The fix solved the boundary scenarios but introduced a new issue. Suppose there is a XS cluster with 2 hosts and the master host is brought down. In this case XS elects a new master for the cluster. Since master is down, investigators won't able to determine host state until a new master is elected. If this master election takes more than ping timeout to complete then the host is put to Alert based on the above fix. Once this happens, the host continues to remain in Alert state and no actions are taken on the VMs on this host. In this case if the investigators were allowed to run for 1 or 2 more times, possibly the new master election would have completed and host state correctly determined. In order to fix both these issues, instead of putting the host to Alert state immediately, the investigators should be allowed to run for some time based on alert.wait global config. At the end of this interval if the host state still cannot be determined then put the host in Alert. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
