[jira] [Updated] (CLOUDSTACK-7879) test_dynamic_compute_offering.py - Skip dynamic scaling on Vmware if vmware-tools are not present
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-7879: --- Status: Reviewable (was: In Progress) > test_dynamic_compute_offering.py - Skip dynamic scaling on Vmware if > vmware-tools are not present > - > > Key: CLOUDSTACK-7879 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7879 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > Vmware-tools are necessary on vmware for dynamic scaling. If tools are not > installed and running, skip the test cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7878) test_scale_vm.py - Skip test on vmware if vmware-tools are not installed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-7878: --- Status: Reviewable (was: In Progress) > test_scale_vm.py - Skip test on vmware if vmware-tools are not installed > > > Key: CLOUDSTACK-7878 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7878 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > Vmware-tools are required for scale Vm operation on VMware. Skip the test if > the tools are not installed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7823) test_snapshots.py - Remove dependency of test cases on each other
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye resolved CLOUDSTACK-7823. Resolution: Fixed > test_snapshots.py - Remove dependency of test cases on each other > - > > Key: CLOUDSTACK-7823 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7823 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > All test cases in this test suite are using the same account. > Hence it leads to failures some times. > It is necessary to remove the dependency of test cases from each other. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7866) [Automation] Fix the script "/maint/test_host_high_availability.py" - ListHosts is picking System VMs as the hosts for VM migration
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gaurav Aradhye resolved CLOUDSTACK-7866.
Resolution: Fixed
> [Automation] Fix the script "/maint/test_host_high_availability.py" -
> ListHosts is picking System VMs as the hosts for VM migration
> ---
>
> Key: CLOUDSTACK-7866
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7866
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Gaurav Aradhye
> Fix For: 4.5.0
>
>
> The following code in test_04 is picking SSVM or CPVM as the host to be
> migrated to. This code needs to be changed.
> {code}
> #Find out Non-Suitable host for VM migration
> list_hosts_response = list_hosts(
> self.apiclient,
> )
> self.assertEqual(
> isinstance(list_hosts_response, list),
> True,
> "listHosts returned invalid object in response."
> )
> self.assertNotEqual(
> len(list_hosts_response),
> 0,
> "listHosts returned empty response."
> )
> notSuitableHost = None
> for host in list_hosts_response:
> if not host.suitableformigration and host.hostid != vm.hostid:
> notSuitableHost = host
> break
> self.assertTrue(notSuitableHost is not None, "notsuitablehost should
> not be None")
> #Migrate VM to Non-Suitable host
> self.debug("Migrating VM-ID: %s to Host: %s" % (vm.id,
> notSuitableHost.id))
> cmd = migrateVirtualMachine.migrateVirtualMachineCmd()
> cmd.hostid = notSuitableHost.id
> cmd.virtualmachineid = vm.id
> self.apiclient.migrateVirtualMachine(cmd)
> {code}
> *Error Message*:
> {noformat}
> Job failed: {jobprocstatus : 0, created : u'2014-11-05T17:13:56+', cmd :
> u'org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd', userid :
> u'd9e7cf4a-649d-11e4-9ff3-ea75aeb47f80', jobstatus : 2, jobid :
> u'bc426924-e6be-4f40-91ca-1cbe13b3f09c', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 431, errortext : u'The specified
> host(s-2-VM) is not suitable to migrate the VM, please specify another one'},
> accountid : u'd9e7c22a-649d-11e4-9ff3-ea75aeb47f80'}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
> File
> "/root/cloudstack/test/integration/component/maint/test_host_high_availability.py",
> line 520, in test_04_cant_migrate_vm_to_host_with_ha_negative
> self.apiclient.migrateVirtualMachine(cmd)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 776, in migrateVirtualMachine
> response = self.connection.marvinRequest(command, response_type=response,
> method=method)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line
> 379, in marvinRequest
> raise e
> 'Job failed: {jobprocstatus : 0, created : u\'2014-11-05T17:13:56+\', cmd
> : u\'org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd\', userid :
> u\'d9e7cf4a-649d-11e4-9ff3-ea75aeb47f80\', jobstatus : 2, jobid :
> u\'bc426924-e6be-4f40-91ca-1cbe13b3f09c\', jobresultcode : 530, jobresulttype
> : u\'object\', jobresult : {errorcode : 431, errortext : u\'The specified
> host(s-2-VM) is not suitable to migrate the VM, please specify another
> one\'}, accountid : u\'d9e7c22a-649d-11e4-9ff3-ea75aeb47f80\'}\n
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7856) test_vpc_network_pf_rules.py - Check if httpd service is running or not, if not start it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye resolved CLOUDSTACK-7856. Resolution: Fixed > test_vpc_network_pf_rules.py - Check if httpd service is running or not, if > not start it > > > Key: CLOUDSTACK-7856 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7856 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > If httpd service is not running, then wget will fail. > Hence check if it is running or not, if not start it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7693) Fix pep8 issues in various test suites
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye resolved CLOUDSTACK-7693. Resolution: Fixed > Fix pep8 issues in various test suites > -- > > Key: CLOUDSTACK-7693 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7693 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > Fix all pep8 issues in various regression and BVT test suites. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7886) cs:rabbitMQ:cloudstackoperations like deployvm,deleteNW are failing if CS fail to contact rabbit mq server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207705#comment-14207705 ] ASF subversion and git services commented on CLOUDSTACK-7886: - Commit f1361796bf1fc73a65c47583dd0a5d6ef2dc3c27 in cloudstack's branch refs/heads/4.5 from [~damoder.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f136179 ] CLOUDSTACK-7886: cloudstackoperations like deployvm,deleteNW are failing if CS fail to contact rabbit mq server. This is happening in case of Async API calls. Signed-off-by: Koushik Das > cs:rabbitMQ:cloudstackoperations like deployvm,deleteNW are failing if CS > fail to contact rabbit mq server > --- > > Key: CLOUDSTACK-7886 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7886 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Damodar Reddy T >Assignee: Damodar Reddy T >Priority: Critical > Fix For: 4.5.0 > > > Enable RabbitMQ Event Bus configuration to publish events from CS. > Once management server is started stop the Rabbit MQ server which is > interacting by management server and try to do async API operations like > deployVm delete NW and these operations are failing as it is not able to > publish events to Rabbit MQ. Where as in all other cases the operations get > succeeded. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7886) cs:rabbitMQ:cloudstackoperations like deployvm,deleteNW are failing if CS fail to contact rabbit mq server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T resolved CLOUDSTACK-7886. - Resolution: Fixed > cs:rabbitMQ:cloudstackoperations like deployvm,deleteNW are failing if CS > fail to contact rabbit mq server > --- > > Key: CLOUDSTACK-7886 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7886 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Damodar Reddy T >Assignee: Damodar Reddy T >Priority: Critical > Fix For: 4.5.0 > > > Enable RabbitMQ Event Bus configuration to publish events from CS. > Once management server is started stop the Rabbit MQ server which is > interacting by management server and try to do async API operations like > deployVm delete NW and these operations are failing as it is not able to > publish events to Rabbit MQ. Where as in all other cases the operations get > succeeded. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7886) cs:rabbitMQ:cloudstackoperations like deployvm,deleteNW are failing if CS fail to contact rabbit mq server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207679#comment-14207679 ] ASF subversion and git services commented on CLOUDSTACK-7886: - Commit 50a3c0b2e30009579c3692e639d32ea608e9e8f9 in cloudstack's branch refs/heads/master from [~damoder.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=50a3c0b ] CLOUDSTACK-7886: cloudstackoperations like deployvm,deleteNW are failing if CS fail to contact rabbit mq server. This is happening in case of Async API calls. Signed-off-by: Koushik Das > cs:rabbitMQ:cloudstackoperations like deployvm,deleteNW are failing if CS > fail to contact rabbit mq server > --- > > Key: CLOUDSTACK-7886 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7886 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Damodar Reddy T >Assignee: Damodar Reddy T >Priority: Critical > Fix For: 4.5.0 > > > Enable RabbitMQ Event Bus configuration to publish events from CS. > Once management server is started stop the Rabbit MQ server which is > interacting by management server and try to do async API operations like > deployVm delete NW and these operations are failing as it is not able to > publish events to Rabbit MQ. Where as in all other cases the operations get > succeeded. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7886) cs:rabbitMQ:cloudstackoperations like deployvm,deleteNW are failing if CS fail to contact rabbit mq server
Damodar Reddy T created CLOUDSTACK-7886: --- Summary: cs:rabbitMQ:cloudstackoperations like deployvm,deleteNW are failing if CS fail to contact rabbit mq server Key: CLOUDSTACK-7886 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7886 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Damodar Reddy T Assignee: Damodar Reddy T Priority: Critical Fix For: 4.5.0 Enable RabbitMQ Event Bus configuration to publish events from CS. Once management server is started stop the Rabbit MQ server which is interacting by management server and try to do async API operations like deployVm delete NW and these operations are failing as it is not able to publish events to Rabbit MQ. Where as in all other cases the operations get succeeded. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-3383) GetHostStatsCommand fails when agent is running Ubuntu 13.04 (raring)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207074#comment-14207074
]
ASF subversion and git services commented on CLOUDSTACK-3383:
-
Commit a2a82f517b124a993d77af1e962ec7f5b5639052 in cloudstack's branch
refs/heads/4.4 from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a2a82f5 ]
CLOUDSTACK-3383 escaped "'s
> GetHostStatsCommand fails when agent is running Ubuntu 13.04 (raring)
> -
>
> Key: CLOUDSTACK-3383
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3383
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.1.0
> Environment: Ubuntu 13.04
>Reporter: Harm van Tilborg
>Assignee: Wido den Hollander
> Labels: agent, kvm, libvirt
> Attachments: ubuntu14-usage-stats.patch
>
>
> 2013-07-05 13:02:37,782 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Processing command:
> com.cloud.agent.api.GetHostStatsCommand
> 2013-07-05 13:02:37,782 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Executing: /bin/bash -c idle=$(top -b -n 1|grep
> Cpu\(s\):|cut -d% -f4|cut -d, -f2);echo $idle
> 2013-07-05 13:02:37,940 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Execution is successful.
> 2013-07-05 13:02:37,941 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-2144469000: { Ans: , MgmtId:
> 159497075554, via: 1, Ver: v1, Flags: 10,
> [{"Answer":{"result":false,"details":"empty String","wait":0}}] }
> When I check the output of Ubuntu's 13.04 top (top -v = procps-ng version
> 3.3.3), it's formatted like this:
> raring# top -b -n 1|grep Cpu\(s\):
> %Cpu(s): 0.2 us, 0.2 sy, 0.0 ni, 99.5 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0
> st
> While on Ubuntu 12.04 (top -v = procps version 3.2.8) it looks like this:
> precise# top -b -n 1|grep Cpu\(s\):
> Cpu(s): 0.3%us, 0.1%sy, 0.0%ni, 99.6%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
> So I believe it is better to split the string on a comma (,) than using the
> percentage (%).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-3383) GetHostStatsCommand fails when agent is running Ubuntu 13.04 (raring)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207026#comment-14207026
]
ASF subversion and git services commented on CLOUDSTACK-3383:
-
Commit ee8facd382b53d04e59ece7a74baddc2737d2ddd in cloudstack's branch
refs/heads/4.4 from [~widodh]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ee8facd ]
CLOUDSTACK-3383: Fetch CPU utilization more reliable.
This should fix that we can't gather CPU statistics on hypervisors
> Ubuntu 12.04
> GetHostStatsCommand fails when agent is running Ubuntu 13.04 (raring)
> -
>
> Key: CLOUDSTACK-3383
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3383
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.1.0
> Environment: Ubuntu 13.04
>Reporter: Harm van Tilborg
>Assignee: Wido den Hollander
> Labels: agent, kvm, libvirt
> Attachments: ubuntu14-usage-stats.patch
>
>
> 2013-07-05 13:02:37,782 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Processing command:
> com.cloud.agent.api.GetHostStatsCommand
> 2013-07-05 13:02:37,782 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Executing: /bin/bash -c idle=$(top -b -n 1|grep
> Cpu\(s\):|cut -d% -f4|cut -d, -f2);echo $idle
> 2013-07-05 13:02:37,940 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Execution is successful.
> 2013-07-05 13:02:37,941 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-2144469000: { Ans: , MgmtId:
> 159497075554, via: 1, Ver: v1, Flags: 10,
> [{"Answer":{"result":false,"details":"empty String","wait":0}}] }
> When I check the output of Ubuntu's 13.04 top (top -v = procps-ng version
> 3.3.3), it's formatted like this:
> raring# top -b -n 1|grep Cpu\(s\):
> %Cpu(s): 0.2 us, 0.2 sy, 0.0 ni, 99.5 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0
> st
> While on Ubuntu 12.04 (top -v = procps version 3.2.8) it looks like this:
> precise# top -b -n 1|grep Cpu\(s\):
> Cpu(s): 0.3%us, 0.1%sy, 0.0%ni, 99.6%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
> So I believe it is better to split the string on a comma (,) than using the
> percentage (%).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7885) [Automation] Fix the script "/maint/test_vpc_host_maintenance" - Router will not get automatically Started due to Host maintenance operations
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandan Purushothama updated CLOUDSTACK-7885: - Description: I see that Router is stopped consciously in the setup() method in the test suite. The test cases check if the Router is in Running state. I checked with Sheng and he mentioned that a Stopped Router will not get automatically started due Host Maintenance Use Cases. Hence stop command should be removed from the setup() Method. (was: I see that Router is stopped consciously in the setup() method in the test suite. The test cases check if the Router is in Running state. I checked with Sheng and he mentioned that a Stopped Router will not get automatically started due Host Maintenance Use Cases. Hence removed that command from the setup() Method.) > [Automation] Fix the script "/maint/test_vpc_host_maintenance" - Router will > not get automatically Started due to Host maintenance operations > - > > Key: CLOUDSTACK-7885 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7885 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Test >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Chandan Purushothama >Priority: Critical > Fix For: 4.5.0 > > > I see that Router is stopped consciously in the setup() method in the test > suite. The test cases check if the Router is in Running state. I checked with > Sheng and he mentioned that a Stopped Router will not get automatically > started due Host Maintenance Use Cases. Hence stop command should be removed > from the setup() Method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7885) [Automation] Fix the script "/maint/test_vpc_host_maintenance" - Router will not get automatically Started due to Host maintenance operations
Chandan Purushothama created CLOUDSTACK-7885: Summary: [Automation] Fix the script "/maint/test_vpc_host_maintenance" - Router will not get automatically Started due to Host maintenance operations Key: CLOUDSTACK-7885 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7885 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 I see that Router is stopped consciously in the setup() method in the test suite. The test cases check if the Router is in Running state. I checked with Sheng and he mentioned that a Stopped Router will not get automatically started due Host Maintenance Use Cases. Hence removed that command from the setup() Method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-3528) [UI]list calls are in the processing state forever with invalid name provided with Account name search filter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206938#comment-14206938 ] ASF subversion and git services commented on CLOUDSTACK-3528: - Commit 46e0a2506950063d3ed7d983f19599bb6c3c6726 in cloudstack's branch refs/heads/master from [~gabora] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=46e0a25 ] CLOUDSTACK-3528: [UI] Fix list calls on accounts page Fix List calls in the processing state forever with invalid name provided with Account name search filter -Added error handling for Events, Instances, Network, Projects, Storage pages where an advanced search by an invalid account name was making the UI to show in progress state forever. > [UI]list calls are in the processing state forever with invalid name provided > with Account name search filter > -- > > Key: CLOUDSTACK-3528 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3528 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: Sailaja Mada >Assignee: Gabor Apati-Nagy > Fix For: 4.6.0 > > Attachments: UIlistevents.png, UIlistinstances.png, UIlistvolumes.png > > > Steps: > 1. Access Instances page > 2. Click on Search Filter options > 3. Provide wrong account name and tried to search instances owned by this > account > 4. It failed with message saying no instances were found. But UI remains in > the processing state forever > This behavior is observed with other list calls , EX: List Events, List > Volumes ( All with invalid account name in the search filter) > Note: Attached snapshots. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7864) CPVM continues to be in "STOPPED' state after failure to start because of a management server restart.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-7864.
--
Resolution: Fixed
> CPVM continues to be in "STOPPED' state after failure to start because of a
> management server restart.
> --
>
> Key: CLOUDSTACK-7864
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7864
> 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
>Reporter: Min Chen
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.5.0
>
>
> CPVM continues to be in "STOPPED' state after failure to start because of a
> management server restart.
> Setup:
> Advanced zone set up with KVM hosts.
> Steps that led to the problem:
> As soon as the zone was set up and enabled , management server was restarted.
> I see that the CPVM failed to come up because there were no hosts at the time
> it was attempting to start.
> After this , even manually trying to start the CPVM does not succeed and the
> jobs are hanging.
> 2014-11-04 21:29:02,613 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-1:ctx-5e9c6a9d job-3/job-16) Unable to complete AsyncJobVO
> {id:16, userId: 1, accountId: 1, instanceType: null, instanceId: null, cmd:
> com.cloud.vm.VmWorkStart, cmdInfo:
> rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIACkoABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAABAAEAAXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwcA,
> cmdVersion: 0, status: FAILED, processStatus: 0, resultCode: 530, result:
> job cancelled because of management server restart or shutdown, initMsid:
> 235397185403991, completeMsid: null, lastUpdated: null, lastPolled: null,
> created: Tue Nov 04 21:28:01 UTC 2014}
> , job origin:3
> com.cloud.exception.InsufficientServerCapacityException: Unable to create a
> deployment for VM[ConsoleProxy|v-1-VM]Scope=interface
> com.cloud.dc.DataCenter; id=1
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:932)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5012)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5156)
> at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:101)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:540)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:47)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:497)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2014-11-04 21:29:02,620 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Work-Job-Executor-1:ctx-5e9c6a9d job-3/job-16) Complete async job-16,
> jobStatus: FAILED, resultCode: 0, result:
> rO0ABXNyABpqYXZhLmxhbmcuUnVudGltZUV4Y2VwdGlvbp5fBkcKNIPlAgAAeHIAE2phdmEubGFuZy5FeGNlcHRpb27Q_R8-GjscxAIAAHhyABNqYXZhLmxhbmcuVGhyb3dhYmx
[jira] [Commented] (CLOUDSTACK-7864) CPVM continues to be in "STOPPED' state after failure to start because of a management server restart.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206892#comment-14206892
]
ASF subversion and git services commented on CLOUDSTACK-7864:
-
Commit 0c45c96ec718edf29ba55fea7dbfda04cc3495e5 in cloudstack's branch
refs/heads/4.5 from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0c45c96 ]
CLOUDSTACK-7864: CPVM continues to be in Stopped state after a failure to start
because of a management server restart. Added optimization to purge queue items
for cancelled jobs.
> CPVM continues to be in "STOPPED' state after failure to start because of a
> management server restart.
> --
>
> Key: CLOUDSTACK-7864
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7864
> 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
>Reporter: Min Chen
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.5.0
>
>
> CPVM continues to be in "STOPPED' state after failure to start because of a
> management server restart.
> Setup:
> Advanced zone set up with KVM hosts.
> Steps that led to the problem:
> As soon as the zone was set up and enabled , management server was restarted.
> I see that the CPVM failed to come up because there were no hosts at the time
> it was attempting to start.
> After this , even manually trying to start the CPVM does not succeed and the
> jobs are hanging.
> 2014-11-04 21:29:02,613 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-1:ctx-5e9c6a9d job-3/job-16) Unable to complete AsyncJobVO
> {id:16, userId: 1, accountId: 1, instanceType: null, instanceId: null, cmd:
> com.cloud.vm.VmWorkStart, cmdInfo:
> rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIACkoABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAABAAEAAXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwcA,
> cmdVersion: 0, status: FAILED, processStatus: 0, resultCode: 530, result:
> job cancelled because of management server restart or shutdown, initMsid:
> 235397185403991, completeMsid: null, lastUpdated: null, lastPolled: null,
> created: Tue Nov 04 21:28:01 UTC 2014}
> , job origin:3
> com.cloud.exception.InsufficientServerCapacityException: Unable to create a
> deployment for VM[ConsoleProxy|v-1-VM]Scope=interface
> com.cloud.dc.DataCenter; id=1
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:932)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5012)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5156)
> at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:101)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:540)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:47)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:497)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.u
[jira] [Commented] (CLOUDSTACK-7318) [UI] processing wheel continue to spin even after error messaage during VM snapshot creation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206887#comment-14206887 ] ASF subversion and git services commented on CLOUDSTACK-7318: - Commit 6ac082b9d0396a84bb3232a0dd88ae0501cc3b39 in cloudstack's branch refs/heads/master from [~mihaelas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6ac082b ] CLOUDSTACK-7318: [UI] Add error handler for VM snapshot creation Fixes the issue where processing wheel continue to spin even after error message is displayed during VM snapshot creation > [UI] processing wheel continue to spin even after error messaage during VM > snapshot creation > > > Key: CLOUDSTACK-7318 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7318 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Mihaela Stoica > Fix For: 4.5.0 > > Attachments: processingwheel.png > > > Repro steps: > Create a LXC VM > When VM is running try to createa VM snapshot > Bug: > Notice you get message VM snapshot is not enabled for hypervisor type: LXC > but spinnign wheel continue to spin . attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7875) [UI] Wrong format check is being made on Create VPC box - DNS domain Information
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabor Apati-Nagy resolved CLOUDSTACK-7875. -- Resolution: Fixed > [UI] Wrong format check is being made on Create VPC box - DNS domain > Information > > > Key: CLOUDSTACK-7875 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7875 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Gabor Apati-Nagy >Priority: Blocker > Fix For: 4.5.0 > > Attachments: Capture5.PNG > > > Currently, We are checking the DNS name with IPV4 format which is incorrect. > DNS name needs to conform with FQDN format and not with IPV4 format. The User > is currently blocked and is not allowed to proceed forward. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7645) Many instances of "???label.*???"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206881#comment-14206881 ] Stephen Turner commented on CLOUDSTACK-7645: Thank you for your email. I am on vacation on Wednesday 12th November. For urgent questions, please contact my manager, andrew.hal...@citrix.com. Thank you very much, -- Stephen Turner Sr Manager, XenServer Citrix > Many instances of "???label.*???" > - > > Key: CLOUDSTACK-7645 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7645 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Stephen Turner >Assignee: Mihaela Stoica >Priority: Critical > Fix For: 4.5.0 > > Attachments: label.app.name.png > > > We have many instances of "\?\?\?label.*\?\?\?" in the UI, including strings > I know were correct recently. (For example, I saw it on the certificate > upload UI, which was recently rewritten). > I think something is wrong with the mechanism rather than individual > translations, so rather than creating a bug for each one, I have bundled them > together in this ticket. Individual tickets are linked from here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7831) [UI] Unlocalized string on Advanced Network -> Network tab
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206879#comment-14206879 ] ASF subversion and git services commented on CLOUDSTACK-7831: - Commit 5bac24c087c5f6afbfd454303fccad0b4bc95d90 in cloudstack's branch refs/heads/master from [~mihaelas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5bac24c ] CLOUDSTACK-7831: Fixed unlocalized string on Advanced Network -> Network tab > [UI] Unlocalized string on Advanced Network -> Network tab > -- > > Key: CLOUDSTACK-7831 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7831 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica >Priority: Minor > Attachments: screenshot-1.png > > > Advanced Network -> Network tab displays label.ipv6.cidr -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7645) Many instances of "???label.*???"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206875#comment-14206875 ] ASF subversion and git services commented on CLOUDSTACK-7645: - Commit 901c243ed1bdd5c118af65a79f33a2386543e756 in cloudstack's branch refs/heads/master from [~mihaelas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=901c243 ] CLOUDSTACK-7645: [UI] Fixed incorrect label issues caused the dictionary split In some cases the UI does not display the correct text, displaying 'label.xyz' instead of the localized string. This appears to be due to the dictionary split: entries in dictionary2.jsp are not found because the dictionary has not been extended with dictionary2 as expected. In this fix: - Instead of extending the dictionary, we leave it as it is and change the localization function to look in the dictionary first and, if the item is not found there, then look in dictionary2. - This way we are not depending on the extent() function to be called at the 'right' time; In turn, the localization function will be aware of both dictionaries. - In the future, when we add another dictionary, we will have to modify this function only. > Many instances of "???label.*???" > - > > Key: CLOUDSTACK-7645 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7645 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Stephen Turner >Assignee: Mihaela Stoica >Priority: Critical > Fix For: 4.5.0 > > Attachments: label.app.name.png > > > We have many instances of "\?\?\?label.*\?\?\?" in the UI, including strings > I know were correct recently. (For example, I saw it on the certificate > upload UI, which was recently rewritten). > I think something is wrong with the mechanism rather than individual > translations, so rather than creating a bug for each one, I have bundled them > together in this ticket. Individual tickets are linked from here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7875) [UI] Wrong format check is being made on Create VPC box - DNS domain Information
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206864#comment-14206864 ] ASF subversion and git services commented on CLOUDSTACK-7875: - Commit 0d7fa25f1df157fae5d72474cad6aa13d2fc1c05 in cloudstack's branch refs/heads/master from [~gabora] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0d7fa25 ] CLOUDSTACK-7875: [UI] - VPC - Fix validation Wrong format check is being made on Create VPC box - DNS domain Information Removing IPv4 validation from the DNS field, the original behavior is restored. (The API validates this field.) > [UI] Wrong format check is being made on Create VPC box - DNS domain > Information > > > Key: CLOUDSTACK-7875 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7875 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Gabor Apati-Nagy >Priority: Blocker > Fix For: 4.5.0 > > Attachments: Capture5.PNG > > > Currently, We are checking the DNS name with IPV4 format which is incorrect. > DNS name needs to conform with FQDN format and not with IPV4 format. The User > is currently blocked and is not allowed to proceed forward. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7864) CPVM continues to be in "STOPPED' state after failure to start because of a management server restart.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206833#comment-14206833
]
ASF subversion and git services commented on CLOUDSTACK-7864:
-
Commit 213088d7dab2286ce8394a77b8ae6b989c92a34e in cloudstack's branch
refs/heads/master from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=213088d ]
CLOUDSTACK-7864: CPVM continues to be in Stopped state after a failure to start
because of a management server restart. Added optimization to purge queue items
for cancelled jobs.
> CPVM continues to be in "STOPPED' state after failure to start because of a
> management server restart.
> --
>
> Key: CLOUDSTACK-7864
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7864
> 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
>Reporter: Min Chen
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.5.0
>
>
> CPVM continues to be in "STOPPED' state after failure to start because of a
> management server restart.
> Setup:
> Advanced zone set up with KVM hosts.
> Steps that led to the problem:
> As soon as the zone was set up and enabled , management server was restarted.
> I see that the CPVM failed to come up because there were no hosts at the time
> it was attempting to start.
> After this , even manually trying to start the CPVM does not succeed and the
> jobs are hanging.
> 2014-11-04 21:29:02,613 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-1:ctx-5e9c6a9d job-3/job-16) Unable to complete AsyncJobVO
> {id:16, userId: 1, accountId: 1, instanceType: null, instanceId: null, cmd:
> com.cloud.vm.VmWorkStart, cmdInfo:
> rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIACkoABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAABAAEAAXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwcA,
> cmdVersion: 0, status: FAILED, processStatus: 0, resultCode: 530, result:
> job cancelled because of management server restart or shutdown, initMsid:
> 235397185403991, completeMsid: null, lastUpdated: null, lastPolled: null,
> created: Tue Nov 04 21:28:01 UTC 2014}
> , job origin:3
> com.cloud.exception.InsufficientServerCapacityException: Unable to create a
> deployment for VM[ConsoleProxy|v-1-VM]Scope=interface
> com.cloud.dc.DataCenter; id=1
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:932)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5012)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5156)
> at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:101)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:540)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:47)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:497)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> jav
[jira] [Commented] (CLOUDSTACK-7151) vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206783#comment-14206783 ] David Nalley commented on CLOUDSTACK-7151: -- [~sateeshc] is this still an issue? There hasn't been movement on this bug in months. > vmware: Type of vSwitch was not detected correctly while preparing > public/guest virtual networks > > > Key: CLOUDSTACK-7151 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7151 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.3.0, 4.3.1 > Environment: VMware ESXi 5.0 > ACS 4.3.0 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi >Priority: Blocker > Fix For: 4.5.0 > > > After upgrade to 4.3.0 from 4.2.0 system vms are not able to start. > 2014-07-18 07:14:16,732 INFO [c.c.h.v.r.VmwareResource] > (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Prepare > network on vmwaresvs Public_Guest_Net with name prefix: cloud.public > 2014-07-18 07:14:16,778 ERROR [c.c.h.v.m.HypervisorHostHelper] > (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Unable to > find vSwitchPublic_Guest_Net > 2014-07-18 07:14:16,778 WARN [c.c.h.v.r.VmwareResource] > (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) StartCommand > failed due to Exception: java.lang.Exception > Message: Unable to find vSwitchPublic_Guest_Net -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7884) Cloudstack MS is not responding (happening randomly) after some restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206648#comment-14206648 ] Min Chen commented on CLOUDSTACK-7884: -- Problem: - Management server is not responding intermittently after restart. RCA: - The management server was not responding because it was not started fully and was not ready to take any requests. See the comments above for full analysis Fix: --- During Management server startup Lifecycle Handler Manager start all lifecycle handles one by one sequentially in a random order based on RUN LEVELs of the Lifecycle Handler. Id VirtualMachineManager Lifecycle Handler starts before AsyncJobManager lifecycle Handler and if there are any pending jobs to be processed then the main thread will wait till it finishes the scheduled job, but this job will never executed as asyncjob manager lifecycle handler did not start. Changed the RUN LEVEL of AsyncjobManager to make sure it gets initialised before Virtual manager life cycle handler so that there is a queue to finish the scheduled job. Notest to QA: - Make sure there are some pending virtual machine jobs before restart of the management server to test this. > Cloudstack MS is not responding (happening randomly) after some restart > --- > > Key: CLOUDSTACK-7884 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7884 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.5.0 > > > some times after the restarting the MS ,not able to see the web UI login page > (i.e not getting the response from MS when we open http://:8080/client > Page) even though MS is up and running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7884) Cloudstack MS is not responding (happening randomly) after some restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7884. -- Resolution: Fixed > Cloudstack MS is not responding (happening randomly) after some restart > --- > > Key: CLOUDSTACK-7884 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7884 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.5.0 > > > some times after the restarting the MS ,not able to see the web UI login page > (i.e not getting the response from MS when we open http://:8080/client > Page) even though MS is up and running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7884) Cloudstack MS is not responding (happening randomly) after some restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206645#comment-14206645 ] ASF subversion and git services commented on CLOUDSTACK-7884: - Commit f2cedda9efece05ef702170d5b6d3858a44de3f9 in cloudstack's branch refs/heads/4.5 from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f2cedda ] CLOUDSTACK-7884: Cloudstack MS is not responding (happening randomly) after some restart. > Cloudstack MS is not responding (happening randomly) after some restart > --- > > Key: CLOUDSTACK-7884 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7884 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.5.0 > > > some times after the restarting the MS ,not able to see the web UI login page > (i.e not getting the response from MS when we open http://:8080/client > Page) even though MS is up and running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7884) Cloudstack MS is not responding (happening randomly) after some restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206639#comment-14206639 ] ASF subversion and git services commented on CLOUDSTACK-7884: - Commit 2ef06e754b8fd41e1af1f9bce0b2f828d7fcfb95 in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2ef06e7 ] CLOUDSTACK-7884: Cloudstack MS is not responding (happening randomly) after some restart. > Cloudstack MS is not responding (happening randomly) after some restart > --- > > Key: CLOUDSTACK-7884 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7884 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.5.0 > > > some times after the restarting the MS ,not able to see the web UI login page > (i.e not getting the response from MS when we open http://:8080/client > Page) even though MS is up and running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7884) Cloudstack MS is not responding (happening randomly) after some restart
Min Chen created CLOUDSTACK-7884: Summary: Cloudstack MS is not responding (happening randomly) after some restart Key: CLOUDSTACK-7884 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7884 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 some times after the restarting the MS ,not able to see the web UI login page (i.e not getting the response from MS when we open http://:8080/client Page) even though MS is up and running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7883) Allow infrastructure to handle delete of volume from DB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206582#comment-14206582 ] ASF subversion and git services commented on CLOUDSTACK-7883: - Commit 713a3590b63dc74dc9500ec48afad8ed87ac1cbf in cloudstack's branch refs/heads/4.4 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=713a359 ] Merge remote-tracking branch 'origin/hotfix/4.4/CLOUDSTACK-7883' into 4.4 > Allow infrastructure to handle delete of volume from DB > --- > > Key: CLOUDSTACK-7883 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7883 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.4.1 > Environment: N/A >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.4.1 > > > To do this, remove this line (from SolidfirePrimaryDataStoreDriver): > _volumeDao.deleteVolumesByInstance(volumeInfo.getId()); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7883) Allow infrastructure to handle delete of volume from DB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206581#comment-14206581 ] ASF subversion and git services commented on CLOUDSTACK-7883: - Commit c58546158e2c69158364df9a0caf18ec437687b5 in cloudstack's branch refs/heads/4.4 from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c585461 ] CLOUDSTACK-7883: Allow infrastructure to handle delete of volume from DB > Allow infrastructure to handle delete of volume from DB > --- > > Key: CLOUDSTACK-7883 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7883 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.4.1 > Environment: N/A >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.4.1 > > > To do this, remove this line (from SolidfirePrimaryDataStoreDriver): > _volumeDao.deleteVolumesByInstance(volumeInfo.getId()); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7883) Allow infrastructure to handle delete of volume from DB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206577#comment-14206577 ] Mike Tutkowski commented on CLOUDSTACK-7883: I created hotfix branch hotfix/4.4/CLOUDSTACK-7883 to be put in 4.4.2. > Allow infrastructure to handle delete of volume from DB > --- > > Key: CLOUDSTACK-7883 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7883 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.4.1 > Environment: N/A >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.4.1 > > > To do this, remove this line (from SolidfirePrimaryDataStoreDriver): > _volumeDao.deleteVolumesByInstance(volumeInfo.getId()); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7883) Allow infrastructure to handle delete of volume from DB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski closed CLOUDSTACK-7883. -- > Allow infrastructure to handle delete of volume from DB > --- > > Key: CLOUDSTACK-7883 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7883 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.4.1 > Environment: N/A >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.4.1 > > > To do this, remove this line (from SolidfirePrimaryDataStoreDriver): > _volumeDao.deleteVolumesByInstance(volumeInfo.getId()); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7883) Allow infrastructure to handle delete of volume from DB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski resolved CLOUDSTACK-7883. Resolution: Fixed > Allow infrastructure to handle delete of volume from DB > --- > > Key: CLOUDSTACK-7883 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7883 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.4.1 > Environment: N/A >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.4.1 > > > To do this, remove this line (from SolidfirePrimaryDataStoreDriver): > _volumeDao.deleteVolumesByInstance(volumeInfo.getId()); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7883) Allow infrastructure to handle delete of volume from DB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206576#comment-14206576 ] ASF subversion and git services commented on CLOUDSTACK-7883: - Commit c58546158e2c69158364df9a0caf18ec437687b5 in cloudstack's branch refs/heads/hotfix/4.4/CLOUDSTACK-7883 from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c585461 ] CLOUDSTACK-7883: Allow infrastructure to handle delete of volume from DB > Allow infrastructure to handle delete of volume from DB > --- > > Key: CLOUDSTACK-7883 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7883 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.4.1 > Environment: N/A >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.4.1 > > > To do this, remove this line (from SolidfirePrimaryDataStoreDriver): > _volumeDao.deleteVolumesByInstance(volumeInfo.getId()); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7875) [UI] Wrong format check is being made on Create VPC box - DNS domain Information
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabor Apati-Nagy updated CLOUDSTACK-7875: - Status: Reviewable (was: In Progress) > [UI] Wrong format check is being made on Create VPC box - DNS domain > Information > > > Key: CLOUDSTACK-7875 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7875 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Gabor Apati-Nagy >Priority: Blocker > Fix For: 4.5.0 > > Attachments: Capture5.PNG > > > Currently, We are checking the DNS name with IPV4 format which is incorrect. > DNS name needs to conform with FQDN format and not with IPV4 format. The User > is currently blocked and is not allowed to proceed forward. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7883) Allow infrastructure to handle delete of volume from DB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski reassigned CLOUDSTACK-7883: -- Assignee: Mike Tutkowski > Allow infrastructure to handle delete of volume from DB > --- > > Key: CLOUDSTACK-7883 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7883 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.4.1 > Environment: N/A >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.4.1 > > > To do this, remove this line (from SolidfirePrimaryDataStoreDriver): > _volumeDao.deleteVolumesByInstance(volumeInfo.getId()); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7883) Allow infrastructure to handle delete of volume from DB
Mike Tutkowski created CLOUDSTACK-7883: -- Summary: Allow infrastructure to handle delete of volume from DB Key: CLOUDSTACK-7883 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7883 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.4.1 Environment: N/A Reporter: Mike Tutkowski Fix For: 4.4.1 To do this, remove this line (from SolidfirePrimaryDataStoreDriver): _volumeDao.deleteVolumesByInstance(volumeInfo.getId()); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7706) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala resolved CLOUDSTACK-7706. - Resolution: Fixed > Triage and fix Coverity defects > --- > > Key: CLOUDSTACK-7706 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7706 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Santhosh Kumar Edukulla >Assignee: Harikrishna Patnala > Fix For: 4.5.0 > > > 1. We have Coverity setup available, running as scheduled and individual > owners are assigned with analyzed bugs. > 2. As part of this bug, please triage and fix the relevant Coverity bugs > assigned. It could be a count as small as 25 bugs. > 3. First start with high impact in order to others later. > 4. We can either triage them accordingly as fix required or false positive or > not a bug accordingly. But, triage and fix accordingly wherever relevant and > applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-3383) GetHostStatsCommand fails when agent is running Ubuntu 13.04 (raring)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206570#comment-14206570
]
ASF subversion and git services commented on CLOUDSTACK-3383:
-
Commit ce7a4e2455289764779f8ebe4504125c5e9fb6a7 in cloudstack's branch
refs/heads/hotfix/3383 from [~widodh]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ce7a4e2 ]
CLOUDSTACK-3383: Fetch CPU utilization more reliable.
This should fix that we can't gather CPU statistics on hypervisors
> Ubuntu 12.04
> GetHostStatsCommand fails when agent is running Ubuntu 13.04 (raring)
> -
>
> Key: CLOUDSTACK-3383
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3383
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.1.0
> Environment: Ubuntu 13.04
>Reporter: Harm van Tilborg
>Assignee: Wido den Hollander
> Labels: agent, kvm, libvirt
> Attachments: ubuntu14-usage-stats.patch
>
>
> 2013-07-05 13:02:37,782 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Processing command:
> com.cloud.agent.api.GetHostStatsCommand
> 2013-07-05 13:02:37,782 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Executing: /bin/bash -c idle=$(top -b -n 1|grep
> Cpu\(s\):|cut -d% -f4|cut -d, -f2);echo $idle
> 2013-07-05 13:02:37,940 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Execution is successful.
> 2013-07-05 13:02:37,941 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-2144469000: { Ans: , MgmtId:
> 159497075554, via: 1, Ver: v1, Flags: 10,
> [{"Answer":{"result":false,"details":"empty String","wait":0}}] }
> When I check the output of Ubuntu's 13.04 top (top -v = procps-ng version
> 3.3.3), it's formatted like this:
> raring# top -b -n 1|grep Cpu\(s\):
> %Cpu(s): 0.2 us, 0.2 sy, 0.0 ni, 99.5 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0
> st
> While on Ubuntu 12.04 (top -v = procps version 3.2.8) it looks like this:
> precise# top -b -n 1|grep Cpu\(s\):
> Cpu(s): 0.3%us, 0.1%sy, 0.0%ni, 99.6%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
> So I believe it is better to split the string on a comma (,) than using the
> percentage (%).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7826) UI - dialog widget - dependent dropdown field (dependsOn property specified) - fix a bug that default opton in dependent dropdown field didn't trigger change event
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206571#comment-14206571 ] ASF subversion and git services commented on CLOUDSTACK-7826: - Commit 479b550d79877a57cb6369274ea1640b3f1f0b84 in cloudstack's branch refs/heads/4.4 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=479b550 ] CLOUDSTACK-7826: UI - dialog widget - dependent dropdown field (dependsOn property specified) - fix a bug that default opton in dependent dropdown field didn't trigger change event handler until another option in dependent dropdown field was selected. (cherry picked from commit 21f39577e439bd9a98bf8e9ffa0f0f7d329c5ce9) > UI - dialog widget - dependent dropdown field (dependsOn property specified) > - fix a bug that default opton in dependent dropdown field didn't trigger > change event handler until another option in dependent dropdown field was > selected. > -- > > Key: CLOUDSTACK-7826 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7826 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7716) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206569#comment-14206569 ] Devdeep Singh commented on CLOUDSTACK-7716: --- Moving the fix version to 4.6 > Triage and fix Coverity defects > --- > > Key: CLOUDSTACK-7716 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7716 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Santhosh Kumar Edukulla >Assignee: Devdeep Singh > Fix For: 4.6.0 > > > 1. We have Coverity setup available, running as scheduled and individual > owners are assigned with analyzed bugs. > 2. As part of this bug, please triage and fix the relevant Coverity bugs > assigned. It could be a count as small as 25 bugs. > 3. First start with high impact in order to others later. > 4. We can either triage them accordingly as fix required or false positive or > not a bug accordingly. But, triage and fix accordingly wherever relevant and > applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7716) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devdeep Singh updated CLOUDSTACK-7716: -- Fix Version/s: (was: 4.5.0) 4.6.0 > Triage and fix Coverity defects > --- > > Key: CLOUDSTACK-7716 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7716 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Santhosh Kumar Edukulla >Assignee: Devdeep Singh > Fix For: 4.6.0 > > > 1. We have Coverity setup available, running as scheduled and individual > owners are assigned with analyzed bugs. > 2. As part of this bug, please triage and fix the relevant Coverity bugs > assigned. It could be a count as small as 25 bugs. > 3. First start with high impact in order to others later. > 4. We can either triage them accordingly as fix required or false positive or > not a bug accordingly. But, triage and fix accordingly wherever relevant and > applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7882) SSH Keypair Creation/Selection in UI
Logan B created CLOUDSTACK-7882: --- Summary: SSH Keypair Creation/Selection in UI Key: CLOUDSTACK-7882 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7882 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.4.0 Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS Reporter: Logan B Priority: Minor Fix For: 4.5.0, 4.6.0 Currently the API allows for creating SSH keypairs, and specifying keypairs to use when deploying a VM (if the correct script is installed in the template). I would suggest adding a section in the UI (perhaps as a drop down option in the instances menu) to create SSH keypairs. I would then suggest adding an option in the Instance Wizard to select a keypair to inject into the instance upon creation. It may also be worth adding a button to the instance menu to inject a new keypair upon reboot (like we have for password resets now). This could be enabled/disabled with a template flag (e.g., "SSH Key Enabled," like the "Password Enabled" flag we have now) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7881) Allow VPN IP range to be specified when creating a VPN
Logan B created CLOUDSTACK-7881: --- Summary: Allow VPN IP range to be specified when creating a VPN Key: CLOUDSTACK-7881 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7881 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.4.0 Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS Reporter: Logan B Priority: Minor Fix For: 4.5.0, 4.6.0 Currently when creating a VPN on an Isolated Network via the UI the default VPN IP range (specified in Global Settings) is used. The API permits overriding this range during VPN creation. I would suggest adding a text box to the VPN creation form in the UI to specify an IP range that overrides the defaults. While not critical, it can be useful to the end user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7246) VM deployment failed due to wrong in script name createipalias.sh
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206555#comment-14206555 ] ASF subversion and git services commented on CLOUDSTACK-7246: - Commit 70cfbd3bb27c49c4ed8551fda7011058458373fe in cloudstack's branch refs/heads/4.4 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=70cfbd3 ] CLOUDSTACK-7246: corrected script name of createIpAlias.sh > VM deployment failed due to wrong in script name createipalias.sh > -- > > Key: CLOUDSTACK-7246 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7246 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.5.0 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Labels: DEVREV > Fix For: 4.5.0 > > > 1. added multiple ip range. > 2. deployed vm in shared network failed. > 3. createipalias failed because cloudstack referring 'createipalias.sh' but > the file in VR is 'createIpAlias.sh' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7706) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206545#comment-14206545 ] ASF subversion and git services commented on CLOUDSTACK-7706: - Commit edf1047a20b6d44fa5fc4be50d13dc833f83fe96 in cloudstack's branch refs/heads/master from [~harikrishna.patnala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=edf1047 ] CLOUDSTACK-7706: Coverity defects Signed-off-by: Santhosh Edukulla > Triage and fix Coverity defects > --- > > Key: CLOUDSTACK-7706 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7706 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Santhosh Kumar Edukulla >Assignee: Harikrishna Patnala > Fix For: 4.5.0 > > > 1. We have Coverity setup available, running as scheduled and individual > owners are assigned with analyzed bugs. > 2. As part of this bug, please triage and fix the relevant Coverity bugs > assigned. It could be a count as small as 25 bugs. > 3. First start with high impact in order to others later. > 4. We can either triage them accordingly as fix required or false positive or > not a bug accordingly. But, triage and fix accordingly wherever relevant and > applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7827) storage migration timeout, loss of data
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206542#comment-14206542 ] Tomasz Zieba commented on CLOUDSTACK-7827: -- The same situation on ACS 4.2.1 > storage migration timeout, loss of data > --- > > Key: CLOUDSTACK-7827 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7827 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.1 > Environment: CentOS 6.5, Xenserver 6.2 with latest patches, > Cloudstack 4.4.1 >Reporter: Vincent Vuong >Priority: Critical > > If a volume migration is not completed before the Cloudstack timeout is > reached, the VM cannot be started after being stopped. We have observed this > behavior with Cloudstack 4.1 – 4.4. Loss of data will occur if the admin > stops the VM before finding the new VHD chain. Here are the steps to > reproduce: > 1)Execute a storage migration on a running VM that will exceed the > Cloudstack timeout value. > 2)Storage migration will fail with Cloudstack reporting a “Host timed > out” but Xenserver continues with the volume migration. > 3)After Xenserver completes the volume migration, Xenserver deletes the > original VHD chain. The database volume “PATH” in Cloudstack is not updated > with the new VHD chain. > 4)VM cannot be started after being stopped. There is no way to find out > what the new VHD chain is if the VM has stopped. > Fix: > 1)While the VM is still running, run the following command to find the > new VHD file name: xe vbd-list vm-uuid= > 2)Stop the VM and copy the VHD chain back to the original primary storage > and update the volume “PATH” with the new VHD chain in the Cloudstack > database. > 3)Start the VM. > 2014-11-01 21:16:56,887 DEBUG [o.a.c.s.m.AncientDataMotionStrategy] > (Work-Job-Executor-3:ctx-80290066 job-174/job-175 ctx-c104adfc) copy failed > com.cloud.utils.exception.CloudRuntimeException: Failed to send command, due > to Agent:4, com.cloud.exception.OperationTimedoutException: Commands > 1959910262836298211 to Host 4 timed out after 3600 > at > org.apache.cloudstack.storage.RemoteHostEndPoint.sendMessage(RemoteHostEndPoint.java:133) > at > org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.migrateVolumeToPool(AncientDataMotionStrategy.java:383) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7246) VM deployment failed due to wrong in script name createipalias.sh
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206522#comment-14206522 ] ASF subversion and git services commented on CLOUDSTACK-7246: - Commit 987131fa9068b25275639fa335fb191fb51e9416 in cloudstack's branch refs/heads/4.4 from Jayapal [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=987131f ] CLOUDSTACK-7246: corrected script name of createipalias (cherry picked from commit 912dc15bc18a2482ff78fd2f1c19bd8e46c98bf1) Conflicts: core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java > VM deployment failed due to wrong in script name createipalias.sh > -- > > Key: CLOUDSTACK-7246 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7246 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.5.0 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Labels: DEVREV > Fix For: 4.5.0 > > > 1. added multiple ip range. > 2. deployed vm in shared network failed. > 3. createipalias failed because cloudstack referring 'createipalias.sh' but > the file in VR is 'createIpAlias.sh' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7246) VM deployment failed due to wrong in script name createipalias.sh
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206523#comment-14206523 ] ASF subversion and git services commented on CLOUDSTACK-7246: - Commit f1a714c02243d99eabb8313595feb33299ed6288 in cloudstack's branch refs/heads/4.4 from Jayapal [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f1a714c ] CLOUDSTACK-7246: corrected script name of createipalias (cherry picked from commit 1bfb1f6503167c3de2c01894b32d287a98424dbc) > VM deployment failed due to wrong in script name createipalias.sh > -- > > Key: CLOUDSTACK-7246 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7246 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.5.0 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Labels: DEVREV > Fix For: 4.5.0 > > > 1. added multiple ip range. > 2. deployed vm in shared network failed. > 3. createipalias failed because cloudstack referring 'createipalias.sh' but > the file in VR is 'createIpAlias.sh' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7348) [Automation] InvalidParameter Exception with stacktrace in MS log wile executing scale vm.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206461#comment-14206461 ] Bharat Kumar commented on CLOUDSTACK-7348: -- review request link https://reviews.apache.org/r/27868/ > [Automation] InvalidParameter Exception with stacktrace in MS log wile > executing scale vm. > -- > > Key: CLOUDSTACK-7348 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7348 > 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 >Reporter: Rayees Namathponnan >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > This issue observed during automation run, there are many InvalidParameter > Exception with stacktrace, this should be handled properly > 2014-08-14 00:18:07,480 DEBUG [c.c.a.ApiServlet] > (catalina-exec-19:ctx-5976d392 ctx-1fee54c1 ctx-1e1fed12) ===END=== > 10.223.240.194 -- GET > > jobid=2c4adb41-726e-48ec-b9d8-eb274d2f471c&apiKey=ijmmuF_StqQMPmkcUiodS09OwxhnKukISg2_Xh5l5-gbPiAQj0RKT88HroUmX-lVPNxuRUx7znDJLBe-KS1byQ& > command=queryAsyncJobResult&response=json&signature=9Y1%2F5x5XXhxLTmNVNMJi9f2xUPk%3D > 2014-08-14 00:18:07,488 ERROR [c.c.a.ApiAsyncJobDispatcher] > (API-Job-Executor-120:ctx-2a6a4c6e job-6669) Unexpected exception while > executi > ng org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin > com.cloud.exception.InvalidParameterValueException: This operation not > permitted for this hypervisor of the vm > at > com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1339) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1328) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1264) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy211.upgradeVirtualMachine(Unknown Source) > at > org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:46) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) -- This message was sent by Atlassi
[jira] [Updated] (CLOUDSTACK-7348) [Automation] InvalidParameter Exception with stacktrace in MS log wile executing scale vm.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7348: - Summary: [Automation] InvalidParameter Exception with stacktrace in MS log wile executing scale vm. (was: [Automation] ) > [Automation] InvalidParameter Exception with stacktrace in MS log wile > executing scale vm. > -- > > Key: CLOUDSTACK-7348 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7348 > 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 >Reporter: Rayees Namathponnan >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > This issue observed during automation run, there are many InvalidParameter > Exception with stacktrace, this should be handled properly > 2014-08-14 00:18:07,480 DEBUG [c.c.a.ApiServlet] > (catalina-exec-19:ctx-5976d392 ctx-1fee54c1 ctx-1e1fed12) ===END=== > 10.223.240.194 -- GET > > jobid=2c4adb41-726e-48ec-b9d8-eb274d2f471c&apiKey=ijmmuF_StqQMPmkcUiodS09OwxhnKukISg2_Xh5l5-gbPiAQj0RKT88HroUmX-lVPNxuRUx7znDJLBe-KS1byQ& > command=queryAsyncJobResult&response=json&signature=9Y1%2F5x5XXhxLTmNVNMJi9f2xUPk%3D > 2014-08-14 00:18:07,488 ERROR [c.c.a.ApiAsyncJobDispatcher] > (API-Job-Executor-120:ctx-2a6a4c6e job-6669) Unexpected exception while > executi > ng org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin > com.cloud.exception.InvalidParameterValueException: This operation not > permitted for this hypervisor of the vm > at > com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1339) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1328) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1264) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy211.upgradeVirtualMachine(Unknown Source) > at > org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:46) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) -- This message was se
[jira] [Updated] (CLOUDSTACK-7348) [Automation] InvalidParameter Exception with stacktrace in MS log wile executing scale vm.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7348: - Status: Reviewable (was: In Progress) > [Automation] InvalidParameter Exception with stacktrace in MS log wile > executing scale vm. > -- > > Key: CLOUDSTACK-7348 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7348 > 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 >Reporter: Rayees Namathponnan >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > This issue observed during automation run, there are many InvalidParameter > Exception with stacktrace, this should be handled properly > 2014-08-14 00:18:07,480 DEBUG [c.c.a.ApiServlet] > (catalina-exec-19:ctx-5976d392 ctx-1fee54c1 ctx-1e1fed12) ===END=== > 10.223.240.194 -- GET > > jobid=2c4adb41-726e-48ec-b9d8-eb274d2f471c&apiKey=ijmmuF_StqQMPmkcUiodS09OwxhnKukISg2_Xh5l5-gbPiAQj0RKT88HroUmX-lVPNxuRUx7znDJLBe-KS1byQ& > command=queryAsyncJobResult&response=json&signature=9Y1%2F5x5XXhxLTmNVNMJi9f2xUPk%3D > 2014-08-14 00:18:07,488 ERROR [c.c.a.ApiAsyncJobDispatcher] > (API-Job-Executor-120:ctx-2a6a4c6e job-6669) Unexpected exception while > executi > ng org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin > com.cloud.exception.InvalidParameterValueException: This operation not > permitted for this hypervisor of the vm > at > com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1339) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1328) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1264) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy211.upgradeVirtualMachine(Unknown Source) > at > org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:46) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7348) [Automation]
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7348: - Summary: [Automation] (was: [Automation] InvalidParameter Exception with stacktrace in MS log) > [Automation] > - > > Key: CLOUDSTACK-7348 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7348 > 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 >Reporter: Rayees Namathponnan >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > This issue observed during automation run, there are many InvalidParameter > Exception with stacktrace, this should be handled properly > 2014-08-14 00:18:07,480 DEBUG [c.c.a.ApiServlet] > (catalina-exec-19:ctx-5976d392 ctx-1fee54c1 ctx-1e1fed12) ===END=== > 10.223.240.194 -- GET > > jobid=2c4adb41-726e-48ec-b9d8-eb274d2f471c&apiKey=ijmmuF_StqQMPmkcUiodS09OwxhnKukISg2_Xh5l5-gbPiAQj0RKT88HroUmX-lVPNxuRUx7znDJLBe-KS1byQ& > command=queryAsyncJobResult&response=json&signature=9Y1%2F5x5XXhxLTmNVNMJi9f2xUPk%3D > 2014-08-14 00:18:07,488 ERROR [c.c.a.ApiAsyncJobDispatcher] > (API-Job-Executor-120:ctx-2a6a4c6e job-6669) Unexpected exception while > executi > ng org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin > com.cloud.exception.InvalidParameterValueException: This operation not > permitted for this hypervisor of the vm > at > com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1339) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1328) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1264) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy211.upgradeVirtualMachine(Unknown Source) > at > org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:46) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7865) [Automation] Fix the script "/maint/test_bugs.py" - Missing attributes used in class
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206431#comment-14206431
]
ASF subversion and git services commented on CLOUDSTACK-7865:
-
Commit 7efc4c388fc96bb76acd1dbc0c2d344ddc23f2d1 in cloudstack's branch
refs/heads/4.5 from SrikanteswaraRao Talluri
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7efc4c3 ]
CLOUDSTACK-7865: fixed pep8 errors and errors in wrong references
to the variables
> [Automation] Fix the script "/maint/test_bugs.py" - Missing attributes used
> in class
>
>
> Key: CLOUDSTACK-7865
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7865
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Srikanteswararao Talluri
>Priority: Critical
> Fix For: 4.5.0
>
>
> I see the following errors in execution of two test cases in test_bugs.py:
> *First Error*:
> {noformat}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
> File "/root/cloudstack/test/integration/component/maint/test_bugs.py", line
> 396, in test_CLOUDSTACK_6181_stoppedvm_root_resize
> virtualmachineid=self.virtual_machine.id,
> '\'Test42xBugsMgmtSvr\' object has no attribute \'virtual_machine\'\n
> {noformat}
> *Second Error*
> {noformat}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
> File "/root/cloudstack/test/integration/component/maint/test_bugs.py", line
> 464, in test_CLOUDSTACK_6181_vm_root_resize
> virtualmachineid=self.virtual_machine.id,
> '\'Test42xBugsMgmtSvr\' object has no attribute \'virtual_machine\'\n
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7865) [Automation] Fix the script "/maint/test_bugs.py" - Missing attributes used in class
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206429#comment-14206429
]
ASF subversion and git services commented on CLOUDSTACK-7865:
-
Commit 5759857ffcfb650236e4ab0c87134c95c68edc87 in cloudstack's branch
refs/heads/master from SrikanteswaraRao Talluri
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5759857 ]
CLOUDSTACK-7865: fixed pep8 errors and errors in wrong references
to the variables
> [Automation] Fix the script "/maint/test_bugs.py" - Missing attributes used
> in class
>
>
> Key: CLOUDSTACK-7865
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7865
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Srikanteswararao Talluri
>Priority: Critical
> Fix For: 4.5.0
>
>
> I see the following errors in execution of two test cases in test_bugs.py:
> *First Error*:
> {noformat}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
> File "/root/cloudstack/test/integration/component/maint/test_bugs.py", line
> 396, in test_CLOUDSTACK_6181_stoppedvm_root_resize
> virtualmachineid=self.virtual_machine.id,
> '\'Test42xBugsMgmtSvr\' object has no attribute \'virtual_machine\'\n
> {noformat}
> *Second Error*
> {noformat}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
> File "/root/cloudstack/test/integration/component/maint/test_bugs.py", line
> 464, in test_CLOUDSTACK_6181_vm_root_resize
> virtualmachineid=self.virtual_machine.id,
> '\'Test42xBugsMgmtSvr\' object has no attribute \'virtual_machine\'\n
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3383) GetHostStatsCommand fails when agent is running Ubuntu 13.04 (raring)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wido den Hollander updated CLOUDSTACK-3383:
---
Priority: Major (was: Minor)
> GetHostStatsCommand fails when agent is running Ubuntu 13.04 (raring)
> -
>
> Key: CLOUDSTACK-3383
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3383
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.1.0
> Environment: Ubuntu 13.04
>Reporter: Harm van Tilborg
>Assignee: Wido den Hollander
> Labels: agent, kvm, libvirt
> Attachments: ubuntu14-usage-stats.patch
>
>
> 2013-07-05 13:02:37,782 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Processing command:
> com.cloud.agent.api.GetHostStatsCommand
> 2013-07-05 13:02:37,782 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Executing: /bin/bash -c idle=$(top -b -n 1|grep
> Cpu\(s\):|cut -d% -f4|cut -d, -f2);echo $idle
> 2013-07-05 13:02:37,940 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Execution is successful.
> 2013-07-05 13:02:37,941 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-3:null) Seq 1-2144469000: { Ans: , MgmtId:
> 159497075554, via: 1, Ver: v1, Flags: 10,
> [{"Answer":{"result":false,"details":"empty String","wait":0}}] }
> When I check the output of Ubuntu's 13.04 top (top -v = procps-ng version
> 3.3.3), it's formatted like this:
> raring# top -b -n 1|grep Cpu\(s\):
> %Cpu(s): 0.2 us, 0.2 sy, 0.0 ni, 99.5 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0
> st
> While on Ubuntu 12.04 (top -v = procps version 3.2.8) it looks like this:
> precise# top -b -n 1|grep Cpu\(s\):
> Cpu(s): 0.3%us, 0.1%sy, 0.0%ni, 99.6%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
> So I believe it is better to split the string on a comma (,) than using the
> percentage (%).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5352) CPU cap calculated incorrectly for VMs on XenServer hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206381#comment-14206381 ] Srikanteswararao Talluri commented on CLOUDSTACK-5352: -- Verified on 4.5 1. compute offering:500MHZ CPU,1 core,CPU cap-enabled. Host speed:4 core with 2.3 GHZ. cpu cap= [(speed*vcpu*0.99)/hostspeed ]*100 cpu cap=500MHz*1*0.99/2300MHZ *100=21.5 [root@Rack1Pod1Host29 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-19-VM uuid ( RO) : b2246b3b-8eb9-f835-10a9-53d535873b6c name-label ( RW): i-2-19-VM VCPUs-params (MRW): weight: 17; cap: 20 2. compute offering:500MHZ CPU,3 core,CPU cap-enabled. Host speed:4 core with 2.3 GHZ cpu cap=500MHz*3*0.99/2300MHZ *100=64.5 [root@Rack1Pod1Host29 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-20-VM uuid ( RO) : ebc11adb-25fa-1b97-b449-f2ca8b0e6e99 name-label ( RW): i-2-20-VM VCPUs-params (MRW): weight: 17; cap: 62 > CPU cap calculated incorrectly for VMs on XenServer hosts > - > > Key: CLOUDSTACK-5352 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5352 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0, 4.3.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.3.0 > > > The CPU cap assigned to VMs on XenServer hosts (via VCPUs-params parameter) > is not calculated correctly. The assigned values are too low and can result > in performance problems. This seems related to CPU overprovisioning. The > assigned CPU cap is approximately the expected cap / CPU overprovisioning > value. The customer is using CloudStack 4.2.0 with XenServer 6.1. On the > customer environment they have several VMs that were created before upgrading > to 4.2.0 from 3.0.6 and never rebooted, and those VMs appear to have the > expected CPU cap. > I see similar results on a CS 4.2.1 setup with a XS 6.2 host with 1x E31220L > CPU – 2x physical cores / 4x logical cores (with hyperthreading) at 2.20GHz – > 8800 MHz total (confirmed in op_host_capacity), a Compute Offering with 2200 > MHz and 4 cores gives a VM with: > [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params > name-label=i-2-87-VM > uuid ( RO) : 7cd5893e-728a-a0f3-c2cf-f3464cb8b9cb > name-label ( RW): i-2-87-VM > VCPUs-params (MRW): weight: 84; cap: 131 > And with a Compute Offering with 2200 MHz and 1 core gives a VM with: > [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params > name-label=i-2-87-VM > uuid ( RO) : c17cd63a-f6d5-8f76-d7f1-eb34d574e0dd > name-label ( RW): i-2-87-VM > VCPUs-params (MRW): weight: 84; cap: 32 > The configured cap does not make sense in either example. In this > environment, cpu.overprovisioning.factor is 3 for the cluster and 1 in Global > Settings. In example 1 the cap should be: > 2200 * 0.99 * 4 / 2200 * 100 > = 396 > But it is: > 2200 * 0.99 * 4 / (3*2200) * 100 > = 132 > For example 2 it should be: > 2200 * 0.99 * 1 / 2200 * 100 > = 99 > But it is: > 2200 * 0.99 * 1 / (3*2200) * 100 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-5352) CPU cap calculated incorrectly for VMs on XenServer hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanteswararao Talluri closed CLOUDSTACK-5352. > CPU cap calculated incorrectly for VMs on XenServer hosts > - > > Key: CLOUDSTACK-5352 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5352 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0, 4.3.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.3.0 > > > The CPU cap assigned to VMs on XenServer hosts (via VCPUs-params parameter) > is not calculated correctly. The assigned values are too low and can result > in performance problems. This seems related to CPU overprovisioning. The > assigned CPU cap is approximately the expected cap / CPU overprovisioning > value. The customer is using CloudStack 4.2.0 with XenServer 6.1. On the > customer environment they have several VMs that were created before upgrading > to 4.2.0 from 3.0.6 and never rebooted, and those VMs appear to have the > expected CPU cap. > I see similar results on a CS 4.2.1 setup with a XS 6.2 host with 1x E31220L > CPU – 2x physical cores / 4x logical cores (with hyperthreading) at 2.20GHz – > 8800 MHz total (confirmed in op_host_capacity), a Compute Offering with 2200 > MHz and 4 cores gives a VM with: > [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params > name-label=i-2-87-VM > uuid ( RO) : 7cd5893e-728a-a0f3-c2cf-f3464cb8b9cb > name-label ( RW): i-2-87-VM > VCPUs-params (MRW): weight: 84; cap: 131 > And with a Compute Offering with 2200 MHz and 1 core gives a VM with: > [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params > name-label=i-2-87-VM > uuid ( RO) : c17cd63a-f6d5-8f76-d7f1-eb34d574e0dd > name-label ( RW): i-2-87-VM > VCPUs-params (MRW): weight: 84; cap: 32 > The configured cap does not make sense in either example. In this > environment, cpu.overprovisioning.factor is 3 for the cluster and 1 in Global > Settings. In example 1 the cap should be: > 2200 * 0.99 * 4 / 2200 * 100 > = 396 > But it is: > 2200 * 0.99 * 4 / (3*2200) * 100 > = 132 > For example 2 it should be: > 2200 * 0.99 * 1 / 2200 * 100 > = 99 > But it is: > 2200 * 0.99 * 1 / (3*2200) * 100 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7583) Send statistics collected by StatsCollector to optional Graphite host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander closed CLOUDSTACK-7583. -- > Send statistics collected by StatsCollector to optional Graphite host > - > > Key: CLOUDSTACK-7583 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7583 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: Future >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Fix For: 4.6.0 > > > It would be very useful if the StatsCollector inside the management server > could also send all the stats collected to a Graphite server in addition to > the usage database. > This allows for easy graph generation for CPU, Network and Disk I/O of > Instances and hosts. > Via a global setting we can configure: > * Graphite host > * Graphite port > * Key prefix > We can then send Instance and Host information, like: > cloudstack.stats.instances..cpu.num 1 > cloudstack.stats.instances..cpu.utilization 50 > cloudstack.stats.instances..network.read_kbs 4817 > cloudstack.stats.instances..network.write_kbs 672 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7583) Send statistics collected by StatsCollector to optional Graphite host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206369#comment-14206369 ] ASF subversion and git services commented on CLOUDSTACK-7583: - Commit 840c2fda852b86f51245a31e7cd91cdb0ad4bf49 in cloudstack's branch refs/heads/master from [~widodh] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=840c2fd ] CLOUDSTACK-7583: Send VmStats to Graphite host when configured This allows external processing of VmStats information without using the usage server of CloudStack Statistics are being send to Graphite using UDP and not TCP. UDP is used to prevent the management server waiting for TCP timeouts when the Graphite server is unavailable > Send statistics collected by StatsCollector to optional Graphite host > - > > Key: CLOUDSTACK-7583 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7583 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: Future >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Fix For: 4.6.0 > > > It would be very useful if the StatsCollector inside the management server > could also send all the stats collected to a Graphite server in addition to > the usage database. > This allows for easy graph generation for CPU, Network and Disk I/O of > Instances and hosts. > Via a global setting we can configure: > * Graphite host > * Graphite port > * Key prefix > We can then send Instance and Host information, like: > cloudstack.stats.instances..cpu.num 1 > cloudstack.stats.instances..cpu.utilization 50 > cloudstack.stats.instances..network.read_kbs 4817 > cloudstack.stats.instances..network.write_kbs 672 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7583) Send statistics collected by StatsCollector to optional Graphite host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander resolved CLOUDSTACK-7583. Resolution: Fixed Fix Version/s: (was: Future) 4.6.0 Merged into master with commit 840c2fda852b86f51245a31e7cd91cdb0ad4bf49 > Send statistics collected by StatsCollector to optional Graphite host > - > > Key: CLOUDSTACK-7583 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7583 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: Future >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Fix For: 4.6.0 > > > It would be very useful if the StatsCollector inside the management server > could also send all the stats collected to a Graphite server in addition to > the usage database. > This allows for easy graph generation for CPU, Network and Disk I/O of > Instances and hosts. > Via a global setting we can configure: > * Graphite host > * Graphite port > * Key prefix > We can then send Instance and Host information, like: > cloudstack.stats.instances..cpu.num 1 > cloudstack.stats.instances..cpu.utilization 50 > cloudstack.stats.instances..network.read_kbs 4817 > cloudstack.stats.instances..network.write_kbs 672 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7874) "CPU (in MHz)" does not make sense
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206359#comment-14206359 ] Ronald van Zantvoort commented on CLOUDSTACK-7874: -- I agree that it's confusing at best, especially considering that it's a relative priority; in KVM it uses which says it all. 'weight', 'share','relative priority', it's all better than 'Mhz' :) > "CPU (in MHz)" does not make sense > -- > > Key: CLOUDSTACK-7874 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7874 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, UI >Affects Versions: 4.4.1 > Environment: CentOS 6 x86_64 mgmt + HVs >Reporter: Nux > Labels: UI, cpu, cpuspeed > > Hello, > This "CPU (in MHz)" description when adding a new Service Offering does not > make much sense and is misleading. > As far as I know this is the "cpu weight" Xen feature to determine CPU > access/time priority; it should be presented as such or it should be > determined automatically based on Core count. > In my particular setup I have edited classes/resources/messages.properties > and modified it as follows: > label.cpu.mhz=CPU priority (same number as cores) > Is this something that could be changed? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7873) SSH keys larger than 1024 bytes are truncated
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206356#comment-14206356 ] ASF subversion and git services commented on CLOUDSTACK-7873: - Commit b6621428a94866be043df30d8e94e918bfcbf4bb in cloudstack's branch refs/heads/statscollector-graphite from Santhosh Edukulla [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b662142 ] CLOUDSTACK-7873 Fixed the user vm details length issue for higher key lengths > SSH keys larger than 1024 bytes are truncated > - > > Key: CLOUDSTACK-7873 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7873 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Santhosh Kumar Edukulla >Assignee: Santhosh Kumar Edukulla > > When we upload the SSH key pair with 8192 bit RSA key, however the length of > the public key in that case will be longer than 1024 bytes. In DB table > ssh_keypair the length of public_key is set to 5120 bytes which is fine. > The problematic part is the user vm. In DB table user_vm_details, the value > column be set to max 1024 bytes, this also be hard coded into the code as > well. > In case the public key length longer than 1024 bytes, the SSH.PublicKey in > user_vm_details table will be truncated, and caused the > encryptWithSSHPublicKey return "Error encrypting password" due to the > truncated RSA key is invalid. > Fixed the issue by setting the value to 5120 for key. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7583) Send statistics collected by StatsCollector to optional Graphite host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206357#comment-14206357 ] ASF subversion and git services commented on CLOUDSTACK-7583: - Commit e06a814d71d102ffb06b41400d013782210a1174 in cloudstack's branch refs/heads/statscollector-graphite from [~widodh] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e06a814 ] CLOUDSTACK-7583: Send VmStats to Graphite host when configured This allows external processing of VmStats information without using the usage server of CloudStack Statistics are being send to Graphite using UDP and not TCP. UDP is used to prevent the management server waiting for TCP timeouts when the Graphite server is unavailable > Send statistics collected by StatsCollector to optional Graphite host > - > > Key: CLOUDSTACK-7583 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7583 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: Future >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Fix For: Future > > > It would be very useful if the StatsCollector inside the management server > could also send all the stats collected to a Graphite server in addition to > the usage database. > This allows for easy graph generation for CPU, Network and Disk I/O of > Instances and hosts. > Via a global setting we can configure: > * Graphite host > * Graphite port > * Key prefix > We can then send Instance and Host information, like: > cloudstack.stats.instances..cpu.num 1 > cloudstack.stats.instances..cpu.utilization 50 > cloudstack.stats.instances..network.read_kbs 4817 > cloudstack.stats.instances..network.write_kbs 672 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7706) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala updated CLOUDSTACK-7706: Status: Reviewable (was: In Progress) > Triage and fix Coverity defects > --- > > Key: CLOUDSTACK-7706 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7706 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Santhosh Kumar Edukulla >Assignee: Harikrishna Patnala > Fix For: 4.5.0 > > > 1. We have Coverity setup available, running as scheduled and individual > owners are assigned with analyzed bugs. > 2. As part of this bug, please triage and fix the relevant Coverity bugs > assigned. It could be a count as small as 25 bugs. > 3. First start with high impact in order to others later. > 4. We can either triage them accordingly as fix required or false positive or > not a bug accordingly. But, triage and fix accordingly wherever relevant and > applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7706) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206342#comment-14206342 ] Harikrishna Patnala commented on CLOUDSTACK-7706: - patch available @ https://reviews.apache.org/r/27862/diff/# > Triage and fix Coverity defects > --- > > Key: CLOUDSTACK-7706 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7706 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Santhosh Kumar Edukulla >Assignee: Harikrishna Patnala > Fix For: 4.5.0 > > > 1. We have Coverity setup available, running as scheduled and individual > owners are assigned with analyzed bugs. > 2. As part of this bug, please triage and fix the relevant Coverity bugs > assigned. It could be a count as small as 25 bugs. > 3. First start with high impact in order to others later. > 4. We can either triage them accordingly as fix required or false positive or > not a bug accordingly. But, triage and fix accordingly wherever relevant and > applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-5700) [Vmsync] - kvm- "paused" state of Vm is not synced to CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar reassigned CLOUDSTACK-5700: Assignee: Bharat Kumar > [Vmsync] - kvm- "paused" state of Vm is not synced to CS. > - > > Key: CLOUDSTACK-5700 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5700 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Bharat Kumar > Fix For: 4.4.0, 4.5.0 > > > [Vmsync] - kvm - "paused" state of Vm is not synced to CS. > Steps to reproduce the problem: > PreReq: > Have few Vms deployed using Cloudstack. > Steps: > Outside of Cloudstack , Suspend an existing VM using the following command: > virsh suspend > Vmsync does not detect the "paused" state of a VM. CS reports the real state > of this VM as "running" > 2013-12-31 18:44:20,977 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) Found 6 VMs for host 2 > 2013-12-31 18:44:20,990 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) VM i-3-3-VM: cs state = Running and > realState = Running > 2013-12-31 18:44:20,997 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) VM i-3-3-VM: cs state = Running and > realState = Running > 2013-12-31 18:44:20,997 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) Both states are Running for > VM[User|TestVM-1] > [root@Rack3Host14 ~]# virsh list > IdName State > > 2 r-4-VM running > 5 i-3-6-VM running > 6 i-3-5-VM running > 7 s-9-VM running > 9 i-3-8-VM running > 10i-3-3-VM paused -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6575) Deploy VM failed with NPE while using custom compute offering
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sailaja Mada closed CLOUDSTACK-6575.
Its fixed. Hence closing the bug.
> Deploy VM failed with NPE while using custom compute offering
> --
>
> Key: CLOUDSTACK-6575
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6575
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.4.0
>Reporter: Sailaja Mada
>Assignee: Saksham Srivastava
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: logs.zip
>
>
> Steps:
> 1. Install and configure Adv zone using Xen 6.2.5 Hypervisor
> 2. Create Compute offering with Custom option enabled
> 3. Deploy VM using Default Cent OS template using Customer option enabled
> Compute offering with CPU=1, Memory=2000 , Speed = 500
> Observation:
> Deploy VM failed with NPE while using custom compute offering
> API call:
> 2014-05-05 16:04:23,233 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-19:ctx-b904a14a) ===START=== 10.144.6.6 -- GET
> command=deployVirtualMachine&response=json&sessionkey=TDXLIOmV8uKaEsb9Mr5o96exjw0%3D&zoneid=764d3b82-5f1f-450c-a337-6b1398c472b3&templateid=68e3978c-d1d8-11e3-9149-32588ba65dc8&hypervisor=XenServer&serviceofferingid=d04e17be-e99d-427a-95bf-ed0cbc82520d&details%5B0%5D.cpuNumber=1&details%5B0%5D.cpuSpeed=500&details%5B0%5D.memory=2000&diskofferingid=ac9d944f-6b66-4822-bd97-bde18573caae&iptonetworklist%5B0%5D.networkid=91973ed0-97f6-47bf-94ea-25751da81ae9&displayname=newcent1&name=newcent1&_=1399286122706
> 2014-05-05 16:04:23,233 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-19:ctx-b904a14a) ===START=== 10.144.6.6 -- GET
> command=deployVirtualMachine&response=json&sessionkey=TDXLIOmV8uKaEsb9Mr5o96exjw0%3D&zoneid=764d3b82-5f1f-450c-a337-6b1398c472b3&templateid=68e3978c-d1d8-11e3-9149-32588ba65dc8&hypervisor=XenServer&serviceofferingid=d04e17be-e99d-427a-95bf-ed0cbc82520d&details%5B0%5D.cpuNumber=1&details%5B0%5D.cpuSpeed=500&details%5B0%5D.memory=2000&diskofferingid=ac9d944f-6b66-4822-bd97-bde18573caae&iptonetworklist%5B0%5D.networkid=91973ed0-97f6-47bf-94ea-25751da81ae9&displayname=newcent1&name=newcent1&_=1399286122706
> 2014-05-05 16:04:23,247 DEBUG [o.a.c.a.BaseCmd]
> (catalina-exec-19:ctx-b904a14a ctx-e989ce28) Ignoring paremeter displayvm as
> the caller is not authorized to pass it in
> 2014-05-05 16:04:23,247 DEBUG [o.a.c.a.BaseCmd]
> (catalina-exec-19:ctx-b904a14a ctx-e989ce28) Ignoring paremeter
> deploymentplanner as the caller is not authorized to pass it in
> 2014-05-05 16:04:23,255 DEBUG [c.c.a.d.ParamProcessWorker]
> (catalina-exec-19:ctx-b904a14a ctx-e989ce28) Access granted to
> Acct[e412bd9a-f443-413d-941f-a2fdf1af6cf3-cdcuser1] to service offering:13 by
> RoleBasedEntityAccessChecker
> 2014-05-05 16:04:23,255 DEBUG [c.c.a.d.ParamProcessWorker]
> (catalina-exec-19:ctx-b904a14a ctx-e989ce28) Access granted to
> Acct[e412bd9a-f443-413d-941f-a2fdf1af6cf3-cdcuser1] to disk offering:4 by
> RoleBasedEntityAccessChecker
> 2014-05-05 16:04:23,295 DEBUG [c.c.u.AccountManagerImpl]
> (catalina-exec-19:ctx-b904a14a ctx-e989ce28) Access to
> {Tmpl[5-VHD-centos56-x86_64-xen} granted to
> Acct[e412bd9a-f443-413d-941f-a2fdf1af6cf3-cdcuser1] by
> RoleBasedEntityAccessChecker
> 2014-05-05 16:04:23,295 DEBUG [o.a.c.a.BaseCmd]
> (catalina-exec-19:ctx-b904a14a ctx-e989ce28) Ignoring paremeter displayvm as
> the caller is not authorized to pass it in
> 2014-05-05 16:04:23,295 DEBUG [o.a.c.a.BaseCmd]
> (catalina-exec-19:ctx-b904a14a ctx-e989ce28) Ignoring paremeter
> deploymentplanner as the caller is not authorized to pass it in
> 2014-05-05 16:04:23,335 DEBUG [c.c.u.AccountManagerImpl]
> (catalina-exec-19:ctx-b904a14a ctx-e989ce28) Access to
> {Acct[e412bd9a-f443-413d-941f-a2fdf1af6cf3-cdcuser1]} granted to
> Acct[e412bd9a-f443-413d-941f-a2fdf1af6cf3-cdcuser1] by
> RoleBasedEntityAccessChecker
> 2014-05-05 16:04:23,373 DEBUG [c.c.u.AccountManagerImpl]
> (catalina-exec-19:ctx-b904a14a ctx-e989ce28) Access to
> {Ntwk[91973ed0-97f6-47bf-94ea-25751da81ae9|Guest|8]} granted to
> Acct[e412bd9a-f443-413d-941f-a2fdf1af6cf3-cdcuser1] by
> RoleBasedEntityAccessChecker
> 2014-05-05 16:04:23,412 DEBUG [c.c.u.AccountManagerImpl]
> (catalina-exec-19:ctx-b904a14a ctx-e989ce28) Access to
> {Acct[e412bd9a-f443-413d-941f-a2fdf1af6cf3-cdcuser1]} granted to
> Acct[e412bd9a-f443-413d-941f-a2fdf1af6cf3-cdcuser1] by
> RoleBasedEntityAccessChecker
> 2014-05-05 16:04:23,437 ERROR [c.c.a.ApiServer]
> (catalina-exec-19:ctx-b904a14a ctx-e989ce28) unhandled exception executing
> api command: [Ljava.lang.String;@763f4779
> java.lang.NullPointerException
> at
> com
[jira] [Closed] (CLOUDSTACK-6414) [UI] UI is not allowing to create DomainAdmin User (ReferenceError: rootDomainId is not defined)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Mada closed CLOUDSTACK-6414. Its fixed. Hence closing the bug. > [UI] UI is not allowing to create DomainAdmin User (ReferenceError: > rootDomainId is not defined) > > > Key: CLOUDSTACK-6414 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6414 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0 >Reporter: Sailaja Mada >Assignee: Jessica Wang > Fix For: 4.4.0 > > Attachments: FailedtoaddDomainAdminUI.png > > > Steps: > 1. Install and configure Adv Zone using XenServer 6.2.5 > 2. Create domain "CDC" under "root" domain > 3. Tried to create Domain Admin user under "CDC" domain from ACS Management > Console as root admin user. > Observation: > UI is not allowing to create DomainAdmin User (ReferenceError: rootDomainId > is not defined) > createAccount API call works to create Domain Admin User. It is the failure > only in the UI. > Attached Firebug snap. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6412) [UI]Incorrect Field value added with host details page(Dedicated label.no)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Mada closed CLOUDSTACK-6412. closing as per previous comment > [UI]Incorrect Field value added with host details page(Dedicated > label.no) > -- > > Key: CLOUDSTACK-6412 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6412 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0 >Reporter: Sailaja Mada >Assignee: Jessica Wang >Priority: Minor > Fix For: 4.4.0 > > Attachments: dedicatedincorrectlabel.png > > > Setup: ACS 4.4 with XenServer 6.2.5 > Steps: > 1. Install and configure Adv zone using Xenserver 6.2.5 > 2. Go to Host Details page > Observation: > Incorrect Field value added with host details page(Dedicated label.no) > (Attached the snapshot) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6372) [UI]Incorrect Field name while adding Primary Storage (*label.path)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Mada closed CLOUDSTACK-6372. closing as per previous comment > [UI]Incorrect Field name while adding Primary Storage (*label.path) > --- > > Key: CLOUDSTACK-6372 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6372 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0 >Reporter: Sailaja Mada >Assignee: Chris Suich >Priority: Minor > Fix For: 4.4.0 > > Attachments: addPSsnap.png > > > Steps: > 1. Install and Configure Management Server > 2. Tried to add Primary Storage while configuring the Zone > Observation: > Noticed incorrect Field name while adding Primary Storage (*label.path) > (attached snap) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7880) Creating shared network results in exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das resolved CLOUDSTACK-7880. - Resolution: Fixed > Creating shared network results in exception > > > Key: CLOUDSTACK-7880 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7880 > 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 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.5.0 > > > Creating shared network gives CloudRuntimeException: NO EVENT PUBLISH CAN BE > WRAPPED WITHIN DB TRANSACTION! > Steps to Reproduce: > = > 1.Bring up CS in advanced zone with xen cluster > 2.Create one shared network using admin account > Expected Result: > = > Shared network creation should be successful without any errors/exceptions > Actual Result: > === > Shared network got created. However, got the following exception: > 2014-11-05 17:57:41,191 DEBUG [c.c.a.ApiServlet] > (catalina-exec-13:ctx-d4d8d5f9) ===START=== 10.252.193.36 -- GET > command=createNetwork&zoneId=ce166bb8-9664-4e67-9017-407fffc0715a&networkOfferingId=396f84d9-befd-4bb5-8695-51da96b7f919&physicalnetworkid=835943f8-6682-4968-9727-5eafb2e2fce0&name=shared&displayText=shared&vlan=48&acltype=domain&gateway=10.147.48.1&netmask=255.255.255.0&startip=10.147.48.200&endip=10.147.48.205&response=json&sessionkey=ollWEMxBmXyW3zKfzIoUxBuERnc%3D&_=1415171529563 > 2014-11-05 17:57:41,258 DEBUG [o.a.c.n.c.m.ContrailGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network > 2014-11-05 17:57:41,259 DEBUG [c.c.n.g.MidoNetGuestNetworkGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) design called > 2014-11-05 17:57:41,261 DEBUG [c.c.n.g.MidoNetGuestNetworkGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network, > the physical isolation type is not MIDO > 2014-11-05 17:57:41,263 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network > 2014-11-05 17:57:41,265 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network > 2014-11-05 17:57:41,267 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network > 2014-11-05 17:57:41,296 ERROR [o.a.c.f.m.MessageBusBase] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) NO EVENT PUBLISH CAN BE WRAPPED > WITHIN DB TRANSACTION! > com.cloud.utils.exception.CloudRuntimeException: NO EVENT PUBLISH CAN BE > WRAPPED WITHIN DB TRANSACTION! > at > org.apache.cloudstack.framework.messagebus.MessageBusBase.publish(MessageBusBase.java:167) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$2.doInTransactionWithoutResult(NetworkOrchestrator.java:685) > at > com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:57) > at com.cloud.utils.db.Transaction.execute(Transaction.java:45) > at com.cloud.utils.db.Transaction.execute(Transaction.java:54) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.setupNetwork(NetworkOrchestrator.java:667) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$8.doInTransaction(NetworkOrchestrator.java:1975) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$8.doInTransaction(NetworkOrchestrator.java:1936) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:57) > at com.cloud.utils.db.Transaction.execute(Transaction.java:45) > at com.cloud.utils.db.Transaction.execute(Transaction.java:54) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.createGuestNetwork(NetworkOrchestrator.java:1936) > at > com.cloud.network.NetworkServiceImpl$4.doInTransaction(NetworkServiceImpl.java:1383) > at > com.cloud.network.NetworkServiceImpl$4.doInTransaction(NetworkServiceImpl.java:1331) > at com.cloud.utils.db.Transaction.execute(Transaction.java:45) > at > com.cloud.network.NetworkServiceImpl.commitNetwork(NetworkServiceImpl.java:1331) > at > com.cloud.network.NetworkServiceImpl.createGuestNetwork(NetworkServiceImpl.java:1294) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >
[jira] [Commented] (CLOUDSTACK-7875) [UI] Wrong format check is being made on Create VPC box - DNS domain Information
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206312#comment-14206312 ] Gabor Apati-Nagy commented on CLOUDSTACK-7875: -- This is regression caused by CLOUDSTACK-7765. I am removing the IPv4 validation from the DNS field, so that the original behavior will be restored. (The API validates this field.) > [UI] Wrong format check is being made on Create VPC box - DNS domain > Information > > > Key: CLOUDSTACK-7875 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7875 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Gabor Apati-Nagy >Priority: Blocker > Fix For: 4.5.0 > > Attachments: Capture5.PNG > > > Currently, We are checking the DNS name with IPV4 format which is incorrect. > DNS name needs to conform with FQDN format and not with IPV4 format. The User > is currently blocked and is not allowed to proceed forward. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7880) Creating shared network results in exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206313#comment-14206313 ] ASF subversion and git services commented on CLOUDSTACK-7880: - Commit 2685ed36cc0b89a06d799d4d5e4235a45b8c72ec in cloudstack's branch refs/heads/master from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2685ed3 ] CLOUDSTACK-7880: Creating shared network results in exception This is due to event publish being wrapped in a transaction, moved it outside of transaction scope. > Creating shared network results in exception > > > Key: CLOUDSTACK-7880 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7880 > 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 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.5.0 > > > Creating shared network gives CloudRuntimeException: NO EVENT PUBLISH CAN BE > WRAPPED WITHIN DB TRANSACTION! > Steps to Reproduce: > = > 1.Bring up CS in advanced zone with xen cluster > 2.Create one shared network using admin account > Expected Result: > = > Shared network creation should be successful without any errors/exceptions > Actual Result: > === > Shared network got created. However, got the following exception: > 2014-11-05 17:57:41,191 DEBUG [c.c.a.ApiServlet] > (catalina-exec-13:ctx-d4d8d5f9) ===START=== 10.252.193.36 -- GET > command=createNetwork&zoneId=ce166bb8-9664-4e67-9017-407fffc0715a&networkOfferingId=396f84d9-befd-4bb5-8695-51da96b7f919&physicalnetworkid=835943f8-6682-4968-9727-5eafb2e2fce0&name=shared&displayText=shared&vlan=48&acltype=domain&gateway=10.147.48.1&netmask=255.255.255.0&startip=10.147.48.200&endip=10.147.48.205&response=json&sessionkey=ollWEMxBmXyW3zKfzIoUxBuERnc%3D&_=1415171529563 > 2014-11-05 17:57:41,258 DEBUG [o.a.c.n.c.m.ContrailGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network > 2014-11-05 17:57:41,259 DEBUG [c.c.n.g.MidoNetGuestNetworkGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) design called > 2014-11-05 17:57:41,261 DEBUG [c.c.n.g.MidoNetGuestNetworkGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network, > the physical isolation type is not MIDO > 2014-11-05 17:57:41,263 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network > 2014-11-05 17:57:41,265 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network > 2014-11-05 17:57:41,267 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network > 2014-11-05 17:57:41,296 ERROR [o.a.c.f.m.MessageBusBase] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) NO EVENT PUBLISH CAN BE WRAPPED > WITHIN DB TRANSACTION! > com.cloud.utils.exception.CloudRuntimeException: NO EVENT PUBLISH CAN BE > WRAPPED WITHIN DB TRANSACTION! > at > org.apache.cloudstack.framework.messagebus.MessageBusBase.publish(MessageBusBase.java:167) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$2.doInTransactionWithoutResult(NetworkOrchestrator.java:685) > at > com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:57) > at com.cloud.utils.db.Transaction.execute(Transaction.java:45) > at com.cloud.utils.db.Transaction.execute(Transaction.java:54) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.setupNetwork(NetworkOrchestrator.java:667) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$8.doInTransaction(NetworkOrchestrator.java:1975) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$8.doInTransaction(NetworkOrchestrator.java:1936) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:57) > at com.cloud.utils.db.Transaction.execute(Transaction.java:45) > at com.cloud.utils.db.Transaction.execute(Transaction.java:54) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.createGuestNetwork(NetworkOrchestrator.java:1936) > at > com.cloud.network.NetworkServiceImpl$4.doInTransaction(NetworkServiceImpl.java:1383) > at > com.cloud.network.NetworkServiceImpl$4.doInTransaction(NetworkServiceImpl.java:1331) > at com.cloud.utils.db.Transaction.execute(Transaction.java:45) > at > com.cloud.network.NetworkServiceImpl.commitN
[jira] [Commented] (CLOUDSTACK-7880) Creating shared network results in exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206289#comment-14206289 ] ASF subversion and git services commented on CLOUDSTACK-7880: - Commit 6d268db217a0c9dd0701a85f4d0244461c9ebd0b in cloudstack's branch refs/heads/4.5 from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6d268db ] CLOUDSTACK-7880: Creating shared network results in exception This is due to event publish being wrapped in a transaction, moved it outside of transaction scope. > Creating shared network results in exception > > > Key: CLOUDSTACK-7880 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7880 > 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 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.5.0 > > > Creating shared network gives CloudRuntimeException: NO EVENT PUBLISH CAN BE > WRAPPED WITHIN DB TRANSACTION! > Steps to Reproduce: > = > 1.Bring up CS in advanced zone with xen cluster > 2.Create one shared network using admin account > Expected Result: > = > Shared network creation should be successful without any errors/exceptions > Actual Result: > === > Shared network got created. However, got the following exception: > 2014-11-05 17:57:41,191 DEBUG [c.c.a.ApiServlet] > (catalina-exec-13:ctx-d4d8d5f9) ===START=== 10.252.193.36 -- GET > command=createNetwork&zoneId=ce166bb8-9664-4e67-9017-407fffc0715a&networkOfferingId=396f84d9-befd-4bb5-8695-51da96b7f919&physicalnetworkid=835943f8-6682-4968-9727-5eafb2e2fce0&name=shared&displayText=shared&vlan=48&acltype=domain&gateway=10.147.48.1&netmask=255.255.255.0&startip=10.147.48.200&endip=10.147.48.205&response=json&sessionkey=ollWEMxBmXyW3zKfzIoUxBuERnc%3D&_=1415171529563 > 2014-11-05 17:57:41,258 DEBUG [o.a.c.n.c.m.ContrailGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network > 2014-11-05 17:57:41,259 DEBUG [c.c.n.g.MidoNetGuestNetworkGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) design called > 2014-11-05 17:57:41,261 DEBUG [c.c.n.g.MidoNetGuestNetworkGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network, > the physical isolation type is not MIDO > 2014-11-05 17:57:41,263 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network > 2014-11-05 17:57:41,265 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network > 2014-11-05 17:57:41,267 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network > 2014-11-05 17:57:41,296 ERROR [o.a.c.f.m.MessageBusBase] > (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) NO EVENT PUBLISH CAN BE WRAPPED > WITHIN DB TRANSACTION! > com.cloud.utils.exception.CloudRuntimeException: NO EVENT PUBLISH CAN BE > WRAPPED WITHIN DB TRANSACTION! > at > org.apache.cloudstack.framework.messagebus.MessageBusBase.publish(MessageBusBase.java:167) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$2.doInTransactionWithoutResult(NetworkOrchestrator.java:685) > at > com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:57) > at com.cloud.utils.db.Transaction.execute(Transaction.java:45) > at com.cloud.utils.db.Transaction.execute(Transaction.java:54) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.setupNetwork(NetworkOrchestrator.java:667) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$8.doInTransaction(NetworkOrchestrator.java:1975) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$8.doInTransaction(NetworkOrchestrator.java:1936) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:57) > at com.cloud.utils.db.Transaction.execute(Transaction.java:45) > at com.cloud.utils.db.Transaction.execute(Transaction.java:54) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.createGuestNetwork(NetworkOrchestrator.java:1936) > at > com.cloud.network.NetworkServiceImpl$4.doInTransaction(NetworkServiceImpl.java:1383) > at > com.cloud.network.NetworkServiceImpl$4.doInTransaction(NetworkServiceImpl.java:1331) > at com.cloud.utils.db.Transaction.execute(Transaction.java:45) > at > com.cloud.network.NetworkServiceImpl.commitNetw
[jira] [Created] (CLOUDSTACK-7880) Creating shared network results in exception
Koushik Das created CLOUDSTACK-7880: --- Summary: Creating shared network results in exception Key: CLOUDSTACK-7880 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7880 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 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.5.0 Creating shared network gives CloudRuntimeException: NO EVENT PUBLISH CAN BE WRAPPED WITHIN DB TRANSACTION! Steps to Reproduce: = 1.Bring up CS in advanced zone with xen cluster 2.Create one shared network using admin account Expected Result: = Shared network creation should be successful without any errors/exceptions Actual Result: === Shared network got created. However, got the following exception: 2014-11-05 17:57:41,191 DEBUG [c.c.a.ApiServlet] (catalina-exec-13:ctx-d4d8d5f9) ===START=== 10.252.193.36 -- GET command=createNetwork&zoneId=ce166bb8-9664-4e67-9017-407fffc0715a&networkOfferingId=396f84d9-befd-4bb5-8695-51da96b7f919&physicalnetworkid=835943f8-6682-4968-9727-5eafb2e2fce0&name=shared&displayText=shared&vlan=48&acltype=domain&gateway=10.147.48.1&netmask=255.255.255.0&startip=10.147.48.200&endip=10.147.48.205&response=json&sessionkey=ollWEMxBmXyW3zKfzIoUxBuERnc%3D&_=1415171529563 2014-11-05 17:57:41,258 DEBUG [o.a.c.n.c.m.ContrailGuru] (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network 2014-11-05 17:57:41,259 DEBUG [c.c.n.g.MidoNetGuestNetworkGuru] (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) design called 2014-11-05 17:57:41,261 DEBUG [c.c.n.g.MidoNetGuestNetworkGuru] (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network, the physical isolation type is not MIDO 2014-11-05 17:57:41,263 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network 2014-11-05 17:57:41,265 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network 2014-11-05 17:57:41,267 DEBUG [c.c.n.g.OvsGuestNetworkGuru] (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) Refusing to design this network 2014-11-05 17:57:41,296 ERROR [o.a.c.f.m.MessageBusBase] (catalina-exec-13:ctx-d4d8d5f9 ctx-030f1958) NO EVENT PUBLISH CAN BE WRAPPED WITHIN DB TRANSACTION! com.cloud.utils.exception.CloudRuntimeException: NO EVENT PUBLISH CAN BE WRAPPED WITHIN DB TRANSACTION! at org.apache.cloudstack.framework.messagebus.MessageBusBase.publish(MessageBusBase.java:167) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$2.doInTransactionWithoutResult(NetworkOrchestrator.java:685) at com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25) at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:57) at com.cloud.utils.db.Transaction.execute(Transaction.java:45) at com.cloud.utils.db.Transaction.execute(Transaction.java:54) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.setupNetwork(NetworkOrchestrator.java:667) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$8.doInTransaction(NetworkOrchestrator.java:1975) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$8.doInTransaction(NetworkOrchestrator.java:1936) at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:57) at com.cloud.utils.db.Transaction.execute(Transaction.java:45) at com.cloud.utils.db.Transaction.execute(Transaction.java:54) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.createGuestNetwork(NetworkOrchestrator.java:1936) at com.cloud.network.NetworkServiceImpl$4.doInTransaction(NetworkServiceImpl.java:1383) at com.cloud.network.NetworkServiceImpl$4.doInTransaction(NetworkServiceImpl.java:1331) at com.cloud.utils.db.Transaction.execute(Transaction.java:45) at com.cloud.network.NetworkServiceImpl.commitNetwork(NetworkServiceImpl.java:1331) at com.cloud.network.NetworkServiceImpl.createGuestNetwork(NetworkServiceImpl.java:1294) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.Reflectiv
[jira] [Created] (CLOUDSTACK-7879) test_dynamic_compute_offering.py - Skip dynamic scaling on Vmware if vmware-tools are not present
Gaurav Aradhye created CLOUDSTACK-7879: -- Summary: test_dynamic_compute_offering.py - Skip dynamic scaling on Vmware if vmware-tools are not present Key: CLOUDSTACK-7879 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7879 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 Vmware-tools are necessary on vmware for dynamic scaling. If tools are not installed and running, skip the test cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6438) [Automation] Creation of Template from Volume failed due to the requested plugin could not be found.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206234#comment-14206234
]
ASF subversion and git services commented on CLOUDSTACK-6438:
-
Commit 88d222abaa4bffa09370348f1b5e143179c56781 in cloudstack's branch
refs/heads/4.3 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=88d222a ]
CLOUDSTACK-6438, CLOUDSTACK-6442: XAPI plugins must be copied to XS master first
Backported fix for 4.3 using e0e226869d83189dcdb69e3c18b24c47e2b8f1fe by:
Anthony Xu
Signed-off-by: Rohit Yadav
> [Automation] Creation of Template from Volume failed due to the requested
> plugin could not be found.
>
>
> Key: CLOUDSTACK-6438
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6438
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Management Server
>Affects Versions: 4.4.0
> Environment: Basic Zone
> XenServer
>Reporter: Chandan Purushothama
>Assignee: Anthony Xu
>Priority: Blocker
> Fix For: 4.4.0
>
> Attachments: management-server.log.2014-04-16.gz
>
>
>
> The requested plugin could not be found.
>
> 2014-04-16 15:55:43,850 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-41:job-97) Executing AsyncJobVO {id:97, userId: 2,
> accountId: 2, instanceType: Template, instanceId: 205, cmd:
> org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
> cmdInfo:
> {"cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","ispublic":"False","isextractable":"False","httpmethod":"GET","volumeid":"58a0f1da-e5fe-4cf0-8981-8a8ce848662f","domainid":"fe2a30b2-c5a8-11e3-8f55-66bc12ed7ec3","isfeatured":"False","apiKey":"MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Q","ostypeid":"feba4b70-c5a8-11e3-8f55-66bc12ed7ec3","id":"205","response":"json","name":"Cent
> OS Template-7WLKMH","passwordenabled":"False","displaytext":"Cent OS
> Template","account":"test-TestCreateTemplate-SCKX71","uuid":"2575698c-c82c-4fc3-bd51-0993e40e81cb","ctxAccountId":"2","ctxStartEventId":"291","signature":"8ILr8Hdfhc35eHAm1D0L7lkgRw4\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 112957957439171, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-04-16 15:55:43,853 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-10:ctx-a6b8fe9b) ===START=== 10.223.240.161 -- GET
> signature=vtGRmlHXmBNP%2F1rDkUstx%2BIMl4g%3D&apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Q&command=queryAsyncJobResult&response=json&jobid=51fab632-3d6f-4898-85e4-9597a8f39707
> 2014-04-16 15:55:43,877 WARN [c.c.a.d.ParamGenericValidationWorker]
> (API-Job-Executor-41:job-97 ctx-554395e3) Received unknown parameters for
> command createTemplate. Unknown parameters : isextractable account
> 2014-04-16 15:55:43,921 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-10:ctx-a6b8fe9b ctx-62916341 ctx-11cd890f) ===END===
> 10.223.240.161 -- GET
> signature=vtGRmlHXmBNP%2F1rDkUstx%2BIMl4g%3D&apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Q&command=queryAsyncJobResult&response=json&jobid=51fab632-3d6f-4898-85e4-9597a8f39707
> 2014-04-16 15:55:43,947 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl]
> (API-Job-Executor-41:job-97 ctx-554395e3) template 205 is already in store:1,
> type:Image
> 2014-04-16 15:55:43,972 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
> (API-Job-Executor-41:job-97 ctx-554395e3) copyAsync inspecting src type
> VOLUME copyAsync inspecting dest type TEMPLATE
> 2014-04-16 15:55:44,005 DEBUG [c.c.a.t.Request] (API-Job-Executor-41:job-97
> ctx-554395e3) Seq 2-7234469851417280562: Sending { Cmd , MgmtId:
> 112957957439171, via: 2(marron.lab.vmops.com), Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"58a0f1da-e5fe-4cf0-8981-8a8ce848662f","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"ac0c4b04-6b72-38b1-a72f-c7fe7163d17a","id":1,"poolType":"NetworkFilesystem","host":"nfs1-ccp.citrix.com","path":"/home/common/automation/SC_QA_AUTO7/primary4","port":2049,"url":"NetworkFilesystem://nfs1-ccp.citrix.com/home/common/automation/SC_QA_AUTO7/primary4/?ROLE=Primary&STOREUUID=ac0c4b04-6b72-38b1-a72f-c7fe7163d17a"}},"name":"ROOT-17","size":21474836480,"path":"01269023-5389-407f-8dfc-a3ab22074207","volumeId":19,"vmNam
[jira] [Commented] (CLOUDSTACK-6442) [Automation] Extraction of Volume failed due to the requested plugin could not be found.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206235#comment-14206235
]
ASF subversion and git services commented on CLOUDSTACK-6442:
-
Commit 88d222abaa4bffa09370348f1b5e143179c56781 in cloudstack's branch
refs/heads/4.3 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=88d222a ]
CLOUDSTACK-6438, CLOUDSTACK-6442: XAPI plugins must be copied to XS master first
Backported fix for 4.3 using e0e226869d83189dcdb69e3c18b24c47e2b8f1fe by:
Anthony Xu
Signed-off-by: Rohit Yadav
> [Automation] Extraction of Volume failed due to the requested plugin could
> not be found.
>
>
> Key: CLOUDSTACK-6442
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6442
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Management Server
>Affects Versions: 4.4.0
> Environment: Basic Zone
> XenServer
>Reporter: Chandan Purushothama
>Assignee: Anthony Xu
>Priority: Blocker
> Fix For: 4.4.0
>
> Attachments: management-server.log.2014-04-16.gz
>
>
> Use Case:
> Extract Volume from the Setup
>
> The requested plugin could not be found.
>
> 2014-04-16 15:59:56,332 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-1:ctx-2bcdf669) ===START=== 10.223.240.161 -- GET
> apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Q&zoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732&command=extractVolume&mode=HTTP_DOWNLOAD&signature=yuDaizmeEsZcaxZW0QEVOGL7YK0%3D&id=b5521198-97f1-4f2c-afea-fcadf70d4249&response=json
> 2014-04-16 15:59:56,335 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-20:null) SeqA 4-314: Processing Seq 4-314: { Cmd ,
> MgmtId: -1, via: 4, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":1,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-04-16 15:59:56,343 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-20:null) SeqA 4-314: Sending Seq 4-314: { Ans: ,
> MgmtId: 112957957439171, via: 4, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2014-04-16 15:59:56,369 DEBUG [c.c.u.AccountManagerImpl]
> (catalina-exec-1:ctx-2bcdf669 ctx-da1872d1 ctx-20bb4a0a) Access to
> {Vol[31|vm=null|DATADISK]} granted to
> Acct[ed7cd506-e810-496f-94ee-3e422b3a6449-test-TestVolumes-test_01_create_volume-7K52C0]
> by RoleBasedEntityAccessChecker
> 2014-04-16 15:59:56,388 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-1:ctx-2bcdf669 ctx-da1872d1 ctx-20bb4a0a) submit async
> job-169, details: AsyncJobVO {id:169, userId: 2, accountId: 2, instanceType:
> Volume, instanceId: 31, cmd:
> org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd, cmdInfo:
> {"response":"json","id":"b5521198-97f1-4f2c-afea-fcadf70d4249","cmdEventType":"VOLUME.EXTRACT","ctxUserId":"2","zoneid":"4fbc4494-e655-49b6-bda1-7ad8eb641732","httpmethod":"GET","uuid":"b5521198-97f1-4f2c-afea-fcadf70d4249","ctxAccountId":"2","ctxStartEventId":"441","apiKey":"MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Q","signature":"yuDaizmeEsZcaxZW0QEVOGL7YK0\u003d","mode":"HTTP_DOWNLOAD"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 112957957439171, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-04-16 15:59:56,389 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-1:ctx-2bcdf669 ctx-da1872d1 ctx-20bb4a0a) ===END===
> 10.223.240.161 -- GET
> apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Q&zoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732&command=extractVolume&mode=HTTP_DOWNLOAD&signature=yuDaizmeEsZcaxZW0QEVOGL7YK0%3D&id=b5521198-97f1-4f2c-afea-fcadf70d4249&response=json
> 2014-04-16 15:59:56,394 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-76:job-169) Add job-169 into job monitoring
> 2014-04-16 15:59:56,394 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-76:job-169) Executing AsyncJobVO {id:169, userId: 2,
> accountId: 2, instanceType: Volume, instanceId: 31, cmd:
> org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd, cmdInfo:
> {"response":"json","id":"b5521198-97f1-4f2c-afea-fcadf70d4249","cmdEventType":"VOLUME.EXTRACT","ctxUserId":"2","zoneid":"4fbc4494-e655-49b6-bda1-7ad8eb641732","httpmethod":"GET","uuid":"b5521198-97f1-4f2c-afea-fcadf70d4249","ctxAccountId":"2","ctxStartEventId":"441","apiKey":"MNQSBTYnkNvc4PCMgv7itBu
[jira] [Resolved] (CLOUDSTACK-7711) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-7711. Resolution: Duplicate > Triage and fix Coverity defects > --- > > Key: CLOUDSTACK-7711 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7711 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Santhosh Kumar Edukulla >Assignee: Rajesh Battala > Fix For: 4.5.0 > > > 1. We have Coverity setup available, running as scheduled and individual > owners are assigned with analyzed bugs. > 2. As part of this bug, please triage and fix the relevant Coverity bugs > assigned. It could be a count as small as 25 bugs. > 3. First start with high impact in order to others later. > 4. We can either triage them accordingly as fix required or false positive or > not a bug accordingly. But, triage and fix accordingly wherever relevant and > applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7582) Not able to remove tag from primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-7582: --- Summary: Not able to remove tag from primary storage (was: Not able to remove tag from prinmary storage) > Not able to remove tag from primary storage > --- > > Key: CLOUDSTACK-7582 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7582 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.5.0 >Reporter: prashant kumar mishra >Assignee: Rajesh Battala > Fix For: 4.5.0 > > > steps to reproduce > == > 1-update storage tags > 2-try to remove tag by passing empty value > expected: > > tags should be removed > actual > > storage tag is not getting removed > API > === > http://10.147.59.173:8096/client/api?command=updateStoragePool&id=f672eae0-b400-3767-808f-b787a5c04d5f&tags=&capacitybytes=5497558138880&response=xml > cloud-stack-version="4.5.0-SNAPSHOT">f672eae0-b400-3767-808f-b787a5c04d5fd5e96cca-0985-49fe-a777-49b257278c8amanasaprimaryVMw10.147.28.7/export/home/manasa/primaryVMw2014-09-12T11:26:37+0530NetworkFilesystem549755813888042949672962696516272128abUpZONEVMware -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7878) test_scale_vm.py - Skip test on vmware if vmware-tools are not installed
Gaurav Aradhye created CLOUDSTACK-7878: -- Summary: test_scale_vm.py - Skip test on vmware if vmware-tools are not installed Key: CLOUDSTACK-7878 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7878 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 Vmware-tools are required for scale Vm operation on VMware. Skip the test if the tools are not installed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
