[jira] [Created] (CLOUDSTACK-9415) Update previous release documentation to point users to new location for systemvm and builtin templates
Chiradeep Vittal created CLOUDSTACK-9415: Summary: Update previous release documentation to point users to new location for systemvm and builtin templates Key: CLOUDSTACK-9415 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9415 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Chiradeep Vittal Assignee: Rajani Karuturi Since download.cloud.com is being retired and all templates have been copied over to download.apachecloudstack.net, documentation for previous releases should have a section to patch templates.sql to point to the new location. I don't know how the documentation gets built actually. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9414) Provide better and modern "built-in" templates for 4.9.0 and beyond
Chiradeep Vittal created CLOUDSTACK-9414: Summary: Provide better and modern "built-in" templates for 4.9.0 and beyond Key: CLOUDSTACK-9414 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9414 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Template Affects Versions: 4.9.0 Reporter: Chiradeep Vittal The default (builtin) templates in ACS as encoded in setup/templates.sql are outdated, too big and sometimes do not support functions such as ssh key upload, password change and userdata. For example, the set of templates available in http://dl.openvm.eu/cloudstack/ While the reliability and capacity of the dl.openvm.eu server is not guaranteed, we can copy the latest template to the current default download location (download.apachecloudstack.net) and update templates.sql appropriately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7404) Failed to start an instance when originating template has been deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14111656#comment-14111656 ] Chiradeep Vittal commented on CLOUDSTACK-7404: -- You might want to change VirtualMachineTemplate template = _entityMgr.findById(VirtualMachineTemplate.class, vm.getTemplateId()); to VirtualMachineTemplate template = _entityMgr.findByIdIncludingRemoved(VirtualMachineTemplate.class, vm.getTemplateId()); in orchestrateStart > Failed to start an instance when originating template has been deleted > -- > > Key: CLOUDSTACK-7404 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7404 > 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: Ubuntu 12.04, KVM, basic networking, Cloudstack 4.3.0 >Reporter: Loic Lambiel > > Hi, > I have an issue were I cannot start an instance that was previously stopped > when it's originating template has been deleted. > Steps to reproduce: > Deploy an instance > Stop the instance > Delete it's originating template > Wait a few minutes > Start the instance > This was working ok on CS 4.0.x > Management server log: > 2014-08-22 14:01:51,163 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped > to Starting with event: StartReques > tedvm's original host id: 48 new host id: null host id before state > transition: null > 2014-08-22 14:01:51,164 DEBUG [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to > start state for VM[User|VM-69b4c242-fcd1 > -47ec-9afa-a798c370da5d] reservation id = 7bc0e976-6ba3-4b58-aa59-1eb011c1de4e > 2014-08-22 14:01:51,167 DEBUG [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: > 1 and podId: 1 > 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) advanceStart: DeploymentPlan is > provided, using dcId:1, podId: 1, clu > sterId: 1, hostId: 48, poolId: null > 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, > clusters: null, hosts: null > 2014-08-22 14:01:51,177 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from > :Starting to Stopped with event: OperationFa > iledvm's original host id: 48 new host id: null host id before state > transition: null > 2014-08-22 14:01:51,188 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped > to Starting with event: StartReques > tedvm's original host id: 48 new host id: null host id before state > transition: null > 2014-08-22 14:01:51,189 DEBUG [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to > start state for VM[User|VM-69b4c242-fcd1 > -47ec-9afa-a798c370da5d] reservation id = 342cb1d2-fc32-4cdf-94c6-049cf16d5509 > 2014-08-22 14:01:51,191 DEBUG [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: > 1 and podId: 1 > 2014-08-22 14:01:51,192 DEBUG [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, > clusters: null, hosts: null > 2014-08-22 14:01:51,198 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from > :Starting to Stopped with event: OperationFa > iledvm's original host id: 48 new host id: null host id before state > transition: null > 2014-08-22 14:01:51,210 ERROR [cloud.api.ApiAsyncJobDispatcher] > (Job-Executor-87:ctx-17783fe6) Unexpected exception while executing > org.apache.cloudstack.api.command.user.vm.StartVMCmd > java.lang.NullPointerException > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:858) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761) > at > com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:601) > at > org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:237) > at > org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:207) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3581) > at > com.cloud.vm.UserVmManagerImpl.s
[jira] [Commented] (CLOUDSTACK-6202) Support signature version 3 in Cloudmonkey
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979098#comment-13979098 ] Chiradeep Vittal commented on CLOUDSTACK-6202: -- SignatureVersion=3 has been supported since 2011-08-10 > Support signature version 3 in Cloudmonkey > -- > > Key: CLOUDSTACK-6202 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6202 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Cloudmonkey >Reporter: Chiradeep Vittal >Assignee: Yichi Lu > > Cloudstack has signatureVersion=3 which supports an 'expires' timestamp. This > enhances security by making replay attacks less likely. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6323) GetUser API always returns admin info
Chiradeep Vittal created CLOUDSTACK-6323: Summary: GetUser API always returns admin info Key: CLOUDSTACK-6323 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6323 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0, 4.1.0, 4.0.0, 4.3.0, 4.4.0 Reporter: Chiradeep Vittal Assignee: Kishan Kavala The annotation is API_KEY for the parameter apikey which automatically gets set to the requesters api key instead of the requested API key. The annotation should be USER_API_KEY instead. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6202) Support signature version 3 in Cloudmonkey
Chiradeep Vittal created CLOUDSTACK-6202: Summary: Support signature version 3 in Cloudmonkey Key: CLOUDSTACK-6202 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6202 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Cloudmonkey Reporter: Chiradeep Vittal Cloudstack has signatureVersion=3 which supports an 'expires' timestamp. This enhances security by making replay attacks less likely. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6031) Virtual Router count not displaying in UI Infrastructure Screen
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal updated CLOUDSTACK-6031: - Environment: CloudStack 4.3.0 RC3 running on CentOS 6.5, Advanced Zone, XenServer 6.2 (was: CloudStack 4.0.3 RC3 running on CentOS 6.5, Advanced Zone, XenServer 6.2) > Virtual Router count not displaying in UI Infrastructure Screen > --- > > Key: CLOUDSTACK-6031 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6031 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 > Environment: CloudStack 4.3.0 RC3 running on CentOS 6.5, Advanced > Zone, XenServer 6.2 >Reporter: Geoff Higgibottom >Priority: Critical > Labels: 4.3.0, UI > > the Virtual Router count is not displaying in Infrastructure Screen, it is > always at ZERO, even with multiple Virtual Routers running. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6031) Virtual Router count not displaying in UI Infrastructure Screen
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal updated CLOUDSTACK-6031: - Labels: 4.3.0 UI (was: 4.0.3 UI) > Virtual Router count not displaying in UI Infrastructure Screen > --- > > Key: CLOUDSTACK-6031 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6031 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 > Environment: CloudStack 4.0.3 RC3 running on CentOS 6.5, Advanced > Zone, XenServer 6.2 >Reporter: Geoff Higgibottom >Priority: Critical > Labels: 4.3.0, UI > > the Virtual Router count is not displaying in Infrastructure Screen, it is > always at ZERO, even with multiple Virtual Routers running. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-4575) [Portable IP] disassociating a transferred public IP is failing with exception
Chiradeep Vittal created CLOUDSTACK-4575: Summary: [Portable IP] disassociating a transferred public IP is failing with exception Key: CLOUDSTACK-4575 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4575 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Reporter: Chiradeep Vittal Steps to reproduce: 1. Have latest CloudStack with at least 2 advanced zone. 2. Go to Regions -> local -> portable IP -> add an ip range like below Gateway : 10.147.33.1 startIp : 10.147.33.3 endip : 10.147.33.10 vlan : 33 subnet : 255.255.255.128 3. login as a non-ROOT admin username : dom1User1 password : password domain : dom1 4. create the following isolated networks in each zone - Network1Zone1 - Network1Zone2 5. deploy the following VMs in each network - vm1Zone1 connected to Network1Zone1 - vm1Zone2 connected to Network1Zone2 6. Acquire and associate a portable IP to Network1Zone1 7. enable staticNAT on the above portableIP and associate it to vm1Zone2 of Network1Zone2 and add firewall rule for ssh port Observations: (i) portable IP got transferred from Zone1 to Network1Zone2 successfully and able ssh to the portable IP without any issuees. 8. disassociate above portable IP from Network1Zone2. Observations: (ii) sequence of things happened as mentioned below - disassociate happened without any issues which cleaned the eth interface from router etc.., but, - it again initiated IPASSOC on its own for the same portable IP which resulted in the following error and thus this IP stuck in release state forever. (iii) above behaviour made all further IPASSOCs to fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4564) Initial zone creation wizard does not guide Guest Ip range correctly
Chiradeep Vittal created CLOUDSTACK-4564: Summary: Initial zone creation wizard does not guide Guest Ip range correctly Key: CLOUDSTACK-4564 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4564 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: Chiradeep Vittal During the wizard, it asks for Guest IP range without any guidance. The only range that will work is if the range is within the pod ip range. Any other range will lead to a lot of pain. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4563) Initial zone wizard UI label issue
Chiradeep Vittal created CLOUDSTACK-4563: Summary: Initial zone wizard UI label issue Key: CLOUDSTACK-4563 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4563 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: Chiradeep Vittal On the 'add secondary storage' wizard step, the label for the dropdown shows 'label.provider' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4559) DeployVm failure on XCP (DevCloud2)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13753828#comment-13753828 ] Chiradeep Vittal commented on CLOUDSTACK-4559: -- The root cause appears to be commit 4277bcf8f4a634f19dc41fdd8a8edd9b33c7a439 in scripts/vm/hypervisor/xenserver/xcposs/vmopsSnapshot > DeployVm failure on XCP (DevCloud2) > --- > > Key: CLOUDSTACK-4559 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4559 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XCP >Affects Versions: 4.2.0 > Environment: DevCloud2 >Reporter: Chiradeep Vittal >Assignee: edison su >Priority: Critical > > While copying the VHD from NFS secondary to primary, there is an exception. > 2013-08-28 15:29:45,585 WARN [xen.resource.XenServerStorageProcessor] > (DirectAgent-2:null) Catch Exception > com.cloud.utils.exception.CloudRuntimeException for template + due to > com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for > cmd: getVhdParent with args snapshotUuid: > 36594ef2-18a4-4b90-894e-48145ddaebda, isISCSI: false, primaryStorageSRUuid: > 9f3f9262-3f77-09cc-2df7-0d8475676260, due to There was a failure > communicating with the plugin. > com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for > cmd: getVhdParent with args snapshotUuid: > 36594ef2-18a4-4b90-894e-48145ddaebda, isISCSI: false, primaryStorageSRUuid: > 9f3f9262-3f77-09cc-2df7-0d8475676260, due to There was a failure > communicating with the plugin. > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:4188) > at > com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.getVhdParent(XenServerStorageProcessor.java:823) > at > com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copyTemplateToPrimaryStorage(XenServerStorageProcessor.java:868) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:70) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:617) > at > com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssResource.java:143) > at > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > 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.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > 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:722) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4559) DeployVm failure on XCP (DevCloud2)
Chiradeep Vittal created CLOUDSTACK-4559: Summary: DeployVm failure on XCP (DevCloud2) Key: CLOUDSTACK-4559 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4559 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: XCP Affects Versions: 4.2.0 Environment: DevCloud2 Reporter: Chiradeep Vittal Assignee: edison su Priority: Critical While copying the VHD from NFS secondary to primary, there is an exception. 2013-08-28 15:29:45,585 WARN [xen.resource.XenServerStorageProcessor] (DirectAgent-2:null) Catch Exception com.cloud.utils.exception.CloudRuntimeException for template + due to com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for cmd: getVhdParent with args snapshotUuid: 36594ef2-18a4-4b90-894e-48145ddaebda, isISCSI: false, primaryStorageSRUuid: 9f3f9262-3f77-09cc-2df7-0d8475676260, due to There was a failure communicating with the plugin. com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for cmd: getVhdParent with args snapshotUuid: 36594ef2-18a4-4b90-894e-48145ddaebda, isISCSI: false, primaryStorageSRUuid: 9f3f9262-3f77-09cc-2df7-0d8475676260, due to There was a failure communicating with the plugin. at com.cloud.hypervisor.xen.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:4188) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.getVhdParent(XenServerStorageProcessor.java:823) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copyTemplateToPrimaryStorage(XenServerStorageProcessor.java:868) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:70) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:617) at com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssResource.java:143) at com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) 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.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) 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:722) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4532) updateConfiguration fails to validate type and range of certain configuration data
Chiradeep Vittal created CLOUDSTACK-4532: Summary: updateConfiguration fails to validate type and range of certain configuration data Key: CLOUDSTACK-4532 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4532 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Chiradeep Vittal Assignee: Alex Huang Since some keys moved to ConfigDepot, updateConfiguration API is no longer able to validate the type and range of some config values -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4132) current dnsmasq config does not allow guest virtual machines(clients) to update its hostnames with a DNS server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13739020#comment-13739020 ] Chiradeep Vittal commented on CLOUDSTACK-4132: -- Looks OK to me. Here's what needs to be checked: 1. With dhcp-client-update, does dnsmasq now respond to dns requests for the windows hosts. That is, if the windows client vm hostname is "foo.cs1cloud.internal" then can dnsmasq now resolve this in a shared or isolated network? Check from another vm in the same network 2. Ditto for linux client vms > current dnsmasq config does not allow guest virtual machines(clients) to > update its hostnames with a DNS server > > > Key: CLOUDSTACK-4132 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4132 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.2.0 >Reporter: Ram Ganesh >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.2.0 > > > Current dnsmasq.conf does not have "dhcp-client-update" flag enabled thereby > preventing say Windows clients to update AD servers with its hostname. We > should enhance the config file to support this. More information about this > parameter can be found here - > http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4184) VM password reset works inconsistently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13737669#comment-13737669 ] Chiradeep Vittal commented on CLOUDSTACK-4184: -- #1. if you add fork to the TCP_LISTEN option of SOCAT, then it will fork a process for each connection, allowing more parallelism #2. There is a bug in serve_password.sh (see below) #3. You can also add 'su=nobody' to the TCP4_LISTEN option to increase the security of the procedure (after all we are blindly accepting strings from potentially untrusted vm) diff --git a/patches/systemvm/debian/config/opt/cloud/bin/passwd_server_ip b/patches/systemvm/debian/config/opt/cloud/bin/passwd_server_ip index 8d62dff..4622860 100755 --- a/patches/systemvm/debian/config/opt/cloud/bin/passwd_server_ip +++ b/patches/systemvm/debian/config/opt/cloud/bin/passwd_server_ip @@ -20,7 +20,7 @@ addr=$1; while [ "$ENABLED" == "1" ] do - socat -lf /var/log/cloud.log TCP4-LISTEN:8080,reuseaddr,crnl,bind=$addr SYSTEM:"/opt/cloud/bin/serve_password.sh \"\$SOCAT_PEERADDR\"" + socat -lf /var/log/cloud.log TCP4-LISTEN:8080,reuseaddr,su=nobody,fork,crnl,bind=$addr SYSTEM:"/opt/cloud/bin/serve_password.sh \"\$SOCAT_PEERADDR\"" rc=$? if [ $rc -ne 0 ] diff --git a/patches/systemvm/debian/config/opt/cloud/bin/serve_password.sh b/patches/systemvm/debian/config/opt/cloud/bin/serve_password.sh index b829b54..a3a2732 100755 --- a/patches/systemvm/debian/config/opt/cloud/bin/serve_password.sh +++ b/patches/systemvm/debian/config/opt/cloud/bin/serve_password.sh @@ -62,7 +62,7 @@ do break fi - request=$(echo $input | grep "DomU_Request:" | cut -d: -f2 | sed 's/^[ \t]*//') + request=$(echo "$input" | grep "DomU_Request:" | cut -d: -f2 | sed 's/^[ \t]*//') if [ "$request" != "" ] then > VM password reset works inconsistently > -- > > Key: CLOUDSTACK-4184 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4184 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.2.0 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy >Priority: Blocker > Fix For: 4.2.0 > > Attachments: cloud-set-guest-password, pass4.pcap, pass.pcap, > passwords, test.log, test.log > > > 1. When password reset fails for one vm then password reset is not working > then on. > 2. In router the password entries are made properly. > 3. serve password script is giving the password correctly but the vm did not > recieved it > Here are the logs: > === serve_password.sh debug logs > + PASSWD_FILE=/var/cache/cloud/passwords > + ip=10.1.1.143 > + logger -t cloud 'serve_password called to service a request for 10.1.1.143.' > + read input > + '[' 'GET / HTTP/1.0' == '' ']' > ++ sed 's/^[ \t]*//' > ++ cut -d: -f2 > ++ grep DomU_Request: > ++ echo GET / HTTP/1.0 > + request= > + '[' '' '!=' '' ']' > + read input > + '[' 'User-Agent: Wget/1.11.4 Red Hat modified' == '' ']' > ++ sed 's/^[ \t]*//' > ++ cut -d: -f2 > ++ grep DomU_Request: > ++ echo User-Agent: Wget/1.11.4 Red Hat modified > + request= > + '[' '' '!=' '' ']' > + read input > + '[' 'Accept: */*' == '' ']' > ++ sed 's/^[ \t]*//' > ++ cut -d: -f2 > ++ grep DomU_Request: > ++ echo Accept: redundant_router/arping_gateways.sh.templ > redundant_router/backup.sh.templ redundant_router/check_bumpup.sh > redundant_router/check_heartbeat.sh.templ > redundant_router/checkrouter.sh.templ redundant_router/conntrackd.conf.templ > redundant_router/disable_pubip.sh redundant_router/enable_pubip.sh.templ > redundant_router/fault.sh.templ redundant_router/heartbeat.sh.templ > redundant_router/keepalived.conf.templ redundant_router/master.sh.templ > redundant_router/primary-backup.sh.templ redundant_router/services.sh > + request= > + '[' '' '!=' '' ']' > + read input > + '[' 'Host: 10.1.1.1:8080' == '' ']' > ++ sed 's/^[ \t]*//' > ++ cut -d: -f2 > ++ grep DomU_Request: > ++ echo Host: 10.1.1.1:8080 > + request= > + '[' '' '!=' '' ']' > + read input > + '[' 'Connection: Keep-Alive' == '' ']' > ++ sed 's/^[ \t]*//' > ++ cut -d: -f2 > ++ grep DomU_Request: > ++ echo Connection: Keep-Alive > + request= > + '[' '' '!=' '' ']' > + read input > + '[' 'DomU_Request: send_my_password' == '' ']' > ++ sed 's/^[ \t]*//' > ++ cut -d: -f2 > ++ grep DomU_Request: > ++ echo DomU_Request: send_my_password > + request=send_my_password > + '[' send_my_password '!=' '' ']' > + break > + '[' send_my_password == send_my_password ']' > ++ get_value /var/cache/cloud/passwords 10.1.1.143 > ++ local filename=/var/cache/cloud/passwords > ++ local keyname=10.1.1.143 > ++ cut -d= -f2 > ++ grep -i 10.1.1.143= /va
[jira] [Resolved] (CLOUDSTACK-4163) QuickCloud : fix problem introduced by object store work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal resolved CLOUDSTACK-4163. -- Resolution: Fixed Fix Version/s: Future > QuickCloud : fix problem introduced by object store work > > > Key: CLOUDSTACK-4163 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4163 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 >Reporter: Chiradeep Vittal >Assignee: Donal Lafferty > Fix For: 4.2.0, Future > > > Object store work changed the semantics of the NFS <-> management server API. > MS no longer accepts 'Answer' as an Answer, but expects the specific subclass > of Answer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4163) QuickCloud : fix problem introduced by object store work
Chiradeep Vittal created CLOUDSTACK-4163: Summary: QuickCloud : fix problem introduced by object store work Key: CLOUDSTACK-4163 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4163 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: Chiradeep Vittal Assignee: Donal Lafferty Fix For: 4.2.0 Object store work changed the semantics of the NFS <-> management server API. MS no longer accepts 'Answer' as an Answer, but expects the specific subclass of Answer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2492) System VM Clock Drift
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13665418#comment-13665418 ] Chiradeep Vittal commented on CLOUDSTACK-2492: -- On the 4.2 systemvm $ dpkg --get-selections | grep ntp ntp install ps -ef | grep ntp reveals ntpd running > System VM Clock Drift > - > > Key: CLOUDSTACK-2492 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2492 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO >Affects Versions: pre-4.0.0 > Environment: devcloud/Xen >Reporter: John Burwell >Assignee: Chiradeep Vittal >Priority: Blocker > Labels: documentaion > Fix For: 4.2.0 > > > Testing of S3-backed Secondary Storage has revealed that the SSVM (and likely > all other system VMs) have no provision for clock synchronization (e.g. NTP > to dom0 for Xen, vmware-tools for VMWare, etc). In particular, the S3 > protocol is sensitive to drift between clients and S3. As an example, the > following is the stack trace caused by clock drift S3: > 2013-05-14 06:51:55,400 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) > Putting directory > /mnt/SecStorage/93fd0cb0-033b-3248-bcd0-ef6d460635ef/template/tmpl/1/5 in S3 > bucket jsb-cloudstack-templates. > 2013-05-14 06:51:55,401 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) > Creating S3 client with configuration: [protocol: https, connectionTimeOut: > 5, maxErrorRetry: 3, socketTimeout: 5] > 2013-05-14 06:51:55,403 DEBUG [storage.resource.NfsSecondaryStorageResource] > (agentRequest-Handler-3:) Determining key using account id 1 and template id 5 > 2013-05-14 06:51:55,403 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) > Putting file > /mnt/SecStorage/93fd0cb0-033b-3248-bcd0-ef6d460635ef/template/tmpl/1/5/template.properties > into bucket jsb-cloudstack-templates with key > template/tmpl/1/5/template.properties. > 2013-05-14 06:51:55,578 ERROR [storage.resource.NfsSecondaryStorageResource] > (agentRequest-Handler-3:) Failed to upload template id 5 > Status Code: 403, AWS Service: Amazon S3, AWS Request ID: 970A274E132A9ACB, > AWS Error Code: RequestTimeTooSkewed, AWS Error Message: The difference > between the request time and the current time is too large., S3 Extended > Request ID: 9w8a6YBxTn+WlBg96s9stxWuuP8oQ7ksZtg6++wVRHJfE2qmucrilhoEJVetJui4 > at > com.amazonaws.http.AmazonHttpClient.handleErrorResponse(AmazonHttpClient.java:609) > at > com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:309) > at > com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:164) > at > com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:2863) > at > com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:1100) > at > com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:963) > at com.cloud.utils.S3Utils.putDirectory(S3Utils.java:282) > at > com.cloud.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:414) > at > com.cloud.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:212) > at com.cloud.agent.Agent.processRequest(Agent.java:525) > at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852) > at com.cloud.utils.nio.Task.run(Task.java:83) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > In addition to impacting S3, this clock drift also makes log correlation > between the management server and system VMs very difficult, if not, > impossible. Finally, there are suspicions that the clock drift could also > impact operation of console proxy and virtual router VMs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2492) System VM Clock Drift
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal resolved CLOUDSTACK-2492. -- Resolution: Fixed On the 4.2 systemvm $ dpkg --get-selections | grep ntp ntp install ps -ef | grep ntp reveals ntpd running > System VM Clock Drift > - > > Key: CLOUDSTACK-2492 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2492 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO >Affects Versions: pre-4.0.0 > Environment: devcloud/Xen >Reporter: John Burwell >Assignee: Chiradeep Vittal >Priority: Blocker > Labels: documentaion > Fix For: 4.2.0 > > > Testing of S3-backed Secondary Storage has revealed that the SSVM (and likely > all other system VMs) have no provision for clock synchronization (e.g. NTP > to dom0 for Xen, vmware-tools for VMWare, etc). In particular, the S3 > protocol is sensitive to drift between clients and S3. As an example, the > following is the stack trace caused by clock drift S3: > 2013-05-14 06:51:55,400 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) > Putting directory > /mnt/SecStorage/93fd0cb0-033b-3248-bcd0-ef6d460635ef/template/tmpl/1/5 in S3 > bucket jsb-cloudstack-templates. > 2013-05-14 06:51:55,401 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) > Creating S3 client with configuration: [protocol: https, connectionTimeOut: > 5, maxErrorRetry: 3, socketTimeout: 5] > 2013-05-14 06:51:55,403 DEBUG [storage.resource.NfsSecondaryStorageResource] > (agentRequest-Handler-3:) Determining key using account id 1 and template id 5 > 2013-05-14 06:51:55,403 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) > Putting file > /mnt/SecStorage/93fd0cb0-033b-3248-bcd0-ef6d460635ef/template/tmpl/1/5/template.properties > into bucket jsb-cloudstack-templates with key > template/tmpl/1/5/template.properties. > 2013-05-14 06:51:55,578 ERROR [storage.resource.NfsSecondaryStorageResource] > (agentRequest-Handler-3:) Failed to upload template id 5 > Status Code: 403, AWS Service: Amazon S3, AWS Request ID: 970A274E132A9ACB, > AWS Error Code: RequestTimeTooSkewed, AWS Error Message: The difference > between the request time and the current time is too large., S3 Extended > Request ID: 9w8a6YBxTn+WlBg96s9stxWuuP8oQ7ksZtg6++wVRHJfE2qmucrilhoEJVetJui4 > at > com.amazonaws.http.AmazonHttpClient.handleErrorResponse(AmazonHttpClient.java:609) > at > com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:309) > at > com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:164) > at > com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:2863) > at > com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:1100) > at > com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:963) > at com.cloud.utils.S3Utils.putDirectory(S3Utils.java:282) > at > com.cloud.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:414) > at > com.cloud.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:212) > at com.cloud.agent.Agent.processRequest(Agent.java:525) > at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852) > at com.cloud.utils.nio.Task.run(Task.java:83) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > In addition to impacting S3, this clock drift also makes log correlation > between the management server and system VMs very difficult, if not, > impossible. Finally, there are suspicions that the clock drift could also > impact operation of console proxy and virtual router VMs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-1813) QuickCloud - faster cloud startup
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chiradeep Vittal resolved CLOUDSTACK-1813.
--
Resolution: Fixed
Commits are
bf56403d828aa50c0650cc41cdc51aae79b1c19e
2e6c65fd34dc5f4f885c12a4e5469b505975685d
271d232d620f27c6b8b10bc85f849563c528e3ae
778a59fbf6bc8957771718123079bd8a2707affa
5ff8bcaa2e16035197c6d58bb212ba1696411dce
936973aff7ba372abe442a7a40e112219fba7570
c5b11df6b78dd755acc4141dc2063608e581996d
a806ce43d32e8d5ac064b79dd623c01be4489126
1d70b9ea77fd1e9fce98f7d9cd5fd92cfe444c39
21b4635948152710935ba420cee50b823fd7a2b4
3d78019e571677f1b2ac87acebe6192f2a4fa96c
790d2ce82ef6b1ac910124c8c9ab519e2431e622
16790446e51645dc3e2623ebf57f88e0cfe2c89c
e7983b2569abe0304a0b8d720c4c85c4561a
> QuickCloud - faster cloud startup
> -
>
> Key: CLOUDSTACK-1813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1813
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller, Storage Controller
>Reporter: Chiradeep Vittal
>Assignee: Chiradeep Vittal
> Fix For: 4.2.0
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/QuickCloud
> To enable a cloud to "boot" with services managed and running on
> non-cloudstack-managed servers
> To enable a development environment based on DevCloud ("QuickCloud") that
> eschews the use of system vms
> To allow the cloud administrator to choose to provide these services the
> "old" way after booting in the QuickCloud fashion
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-2521) System template build failed in Jenkins.cloudstack.org
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal closed CLOUDSTACK-2521. Resolution: Fixed Fix Version/s: 4.2.0 see above > System template build failed in Jenkins.cloudstack.org > -- > > Key: CLOUDSTACK-2521 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2521 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Projects >Affects Versions: 4.2.0 >Reporter: Rayees Namathponnan >Priority: Critical > Fix For: 4.2.0 > > > System template build failed in Jenkins.cloudstack.org more than 2 weeks, > We dont have any template after below fix > https://issues.apache.org/jira/browse/CLOUDSTACK-2324 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-2324) [XenServer][SystemVM] [Automation] haproxy is not running on the virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal closed CLOUDSTACK-2324. Resolution: Fixed see commit log above > [XenServer][SystemVM] [Automation] haproxy is not running on the virtual > router > --- > > Key: CLOUDSTACK-2324 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2324 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 > Environment: commit # 09af15035b9febe6f55e73a1389f950ab042564f >Reporter: venkata swamybabu budumuru >Priority: Blocker > Fix For: 4.2.0 > > Attachments: logs.tgz > > > Steps to reproduce : > 1. Have at least one advanced zone with Xen cluster > 2. Have a latest systemVM template > version I used here is : > Cloudstack Release 4.2.0 Wed Apr 10 07:46:46 UTC 2013 > 3. deploy a VM connected to isolated network (which will automatically spin a > virtual router) > 4. verify whether haproxy is running on the virtual router or not > Observations: > (i) > root@r-28-VM:~# ps -aef | grep -i haproxy > root 7689 7457 0 14:21 pts/100:00:00 grep -i haproxy > (ii) > find / -name *haproxy* > /etc/haproxy > /etc/haproxy/haproxy.cfg.new > /etc/haproxy/haproxy.cfg > /etc/logrotate.d/haproxy > /var/lib/haproxy > /var/log/haproxy.log > (iii) here is the snippet from /var/log/messages of virtual router > May 3 12:40:10 r-28-VM cloud: Starting ssh > May 3 12:40:10 r-28-VM cloud: Starting haproxy > May 3 12:40:10 r-28-VM cloud: Starting apache2 > May 3 12:40:10 r-28-VM cloud: Starting dnsmasq > May 3 12:40:10 r-28-VM cloud: Starting cloud-passwd-srvr > May 3 12:40:10 r-28-VM cloud: Stopping cloud > May 3 12:40:11 r-28-VM cloud: Stopping nfs-common > May 3 12:40:11 r-28-VM cloud: Stopping portmap > May 3 12:40:11 r-28-VM cloud: Stopping keepalived > May 3 12:40:11 r-28-VM cloud: Stopping conntrackd > (iv) > snippet from /var/log/cloud.log > Fri May 3 12:38:50 UTC 2013 Enable service dnsmasq = 1 > Fri May 3 12:38:50 UTC 2013 Enable service haproxy = 1 > Attaching the /var/log folder from router VM and mgmt server logs to the bug. > (vi) Because of the above issue, unable to create LB rules. when tried it > throws the following error in the SMlog of the xenserver. > Here is the snippet from /var/log/SMLog on the xenserver. > + local cfg=/tmp/169_254_2_213.cfg > + scp -P 3922 -q -o StrictHostKeyChecking=no -i /root/.ssh/id_rsa.cloud > /tmp/169_254_2_213.cfg root@169.254.2.213:/etc/haproxy/haproxy.cfg.new > + return 0 > + '[' 0 -gt 0 ']' > + ssh -p 3922 -q -o StrictHostKeyChecking=no -i /root/.ssh/id_rsa.cloud > root@169.254.2.213 '/root/loadbalancer.sh -i 169.254.2.213 -f > /tmp/169_254_2_213.cfg -a 10.147.44.61:22:, -s 10.147.44.64:8081:0/0:,,' > mv: cannot stat `/var/run/haproxy.pid': No such file or directory > cat: /var/run/haproxy.pid.old: No such file or directory > kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or > kill -l [sigspec] > /root/reconfigLB.sh: line 28: haproxy: command not found > cat: /var/run/haproxy.pid.old: No such file or directory > kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or > kill -l [sigspec] > mv: cannot stat `/var/run/haproxy.pid.old': No such file or directory > + exit 1 > ' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-1994) [SSVM] Unable to start agent: Resource class not found: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource due to: java.lang.ClassNotFoundException: o
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal closed CLOUDSTACK-1994. Resolution: Fixed commit f35272b6c585f85c5c0f1e92f99b8224feceb29e Author: Kelven Yang Date: Thu Apr 11 11:41:10 2013 -0700 Fix the systemvm packaging issue > [SSVM] Unable to start agent: Resource class not found: > org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource due to: > java.lang.ClassNotFoundException: > org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource > --- > > Key: CLOUDSTACK-1994 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1994 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 > Environment: commit 97c2f7d0c4b330f3456e8c1b5236e280b9931197 >Reporter: venkata swamybabu budumuru >Priority: Blocker > Fix For: 4.2.0 > > Attachments: logs.tgz > > > Steps to reproduce : > 1. Have the latest master and deploy an advanced zone with Xen Cluster > 2. use system vm template "systemvmtemplate-2013-03-27-master-xen.vhd.bz2" > from http://jenkins.cloudstack.org > 3. verify whether system vms come up fine or not > Observations : > (i) both v-2-VM and s-1-VM are shown in running state > (ii) cloud.host table doesn't show the SSVM but, shows the console proxy in > host table. > (iii) default centos template download doesn't happen. New template > registration as well fails to download > (iv) Here is the snippet from SSVM:/var/log/cloud/cloud.out > log4j:WARN No appenders could be found for logger > (org.apache.commons.httpclient.params.DefaultHttpParams). > log4j:WARN Please initialize the log4j system properly. > log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more > info. > 08:15:40,493 ERROR AgentShell:610 - Unable to start agent: Resource class not > found: org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource due > to: java.lang.ClassNotFoundException: > org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource > Unable to start agent: Resource class not found: > org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource due to: > java.lang.ClassNotFoundException: > org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource > (v) Based on the above log, it looks like agent on the ssvm is failing to > start. ps -aef | grep -i java doesn't show up an process. > Attaching all the required logs to bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-524) http proxy used by ssvm (secstorage.proxy) NOT working
[
https://issues.apache.org/jira/browse/CLOUDSTACK-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chiradeep Vittal closed CLOUDSTACK-524.
---
Resolution: Fixed
Assignee: Chiradeep Vittal (was: Prasanna Santhanam)
in some cases (especially the built-in CentOS template), the template
downloader does not use the configured http proxy The DownloadProgress command
is used to restart failed or stuck download jobs -- It would not include the
proxy information, unlike the DownloadCommand which always did
ref 67a99cb
> http proxy used by ssvm (secstorage.proxy) NOT working
> --
>
> Key: CLOUDSTACK-524
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-524
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Install and Setup
>Affects Versions: 4.0.0
> Environment: Ubuntu 12.04 - package installation
>Reporter: Dimitri Desmidt
>Assignee: Chiradeep Vittal
>Priority: Critical
> Fix For: 4.2.0
>
>
> In my lab, the SSVM has access to Internet ONLY via a Proxy.
> I configured for that the Global Setting secstorage.proxy with the value
> "http://proxy.xyz.com:3128"; (without the quotes "").
> Then I restarted the cloud management and destroyed the SSVM.
> The new SSVM tries to download again
> "http://download.cloud.com/templates/builtin/centos56-x86_64.vhd.bz2";.
> This still fails and when I look at the Management Log, it looks like there
> is still no Proxy used:
> 2012-11-20 06:44:31,438 DEBUG [agent.transport.Request] (Timer-4:null) Seq
> 18-550436874: Sending { Cmd , MgmtId: 345051959742, via: 18, Ver: v1, Flags:
> 100011,
> [{"storage.DownloadProgressCommand":{"jobId":"38d18cba-470a-46da-821d-37cfacd2bb40","request":"GET_STATUS","hvm":false,"description":"CentOS
> 5.6(64-bit) no GUI
> (XenServer)","checksum":"905cec879afd9c9d22ecc8036131a180","maxDownloadSizeInBytes":53687091200,"id":5,"resourceType":"TEMPLATE","url":"http://download.cloud.com/templates/builtin/centos56-x86_64.vhd.bz2","format":"VHD","accountId":1,"name":"centos56-x86_64-xen","secUrl":"nfs://10.30.1.3/export/secondary","wait":0}}]
> }
> 2012-11-20 06:44:31,485 DEBUG [agent.transport.Request]
> (AgentManager-Handler-2:null) Seq 18-550436874: Processing: { Ans: , MgmtId:
> 345051959742, via: 18, Ver: v1, Flags: 10,
> [{"storage.DownloadAnswer":{"jobId":"38d18cba-470a-46da-821d-37cfacd2bb40","downloadPct":0,"errorString":"
>
> ","downloadStatus":"NOT_DOWNLOADED","downloadPath":"/mnt/SecStorage/ff53ffad-7c5d-382f-942c-e527528c5699/template/tmpl/1/5/dnld5122201514511320578tmp_","templateSize":0,"templatePhySicalSize":0,"checkSum":"905cec879afd9c9d22ecc8036131a180","result":false,"details":"
> ","wait":0}}] }
> Conclusion;
> Looks like the Global Setting information is NOT applied :-(
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-1955) Packaging: package cloudstack-sysdaemons
Chiradeep Vittal created CLOUDSTACK-1955: Summary: Packaging: package cloudstack-sysdaemons Key: CLOUDSTACK-1955 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1955 Project: CloudStack Issue Type: Sub-task Security Level: Public (Anyone can view this level - this is the default.) Reporter: Chiradeep Vittal Copying systemvm.zip around and starting daemons without some kind of init script isn't ideal. Probably have a meta-package (perhaps the root cloudstack package) that would require cloudstack-sysdaemons. A person would still be able to 'yum install cloudstack-server and not get those dameons, but the 'default' install (yum install cloudstack) would have SS/CP as a dependency and thus have it installed and started. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-524) http proxy used by ssvm (secstorage.proxy) NOT working
[
https://issues.apache.org/jira/browse/CLOUDSTACK-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13622736#comment-13622736
]
Chiradeep Vittal commented on CLOUDSTACK-524:
-
Sounds counter-intuitive, but you should be able to initiate download of *new*
template - you can give the same URL of the original "built-in" template and it
should use the proxy.
> http proxy used by ssvm (secstorage.proxy) NOT working
> --
>
> Key: CLOUDSTACK-524
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-524
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Install and Setup
>Affects Versions: 4.0.0
> Environment: Ubuntu 12.04 - package installation
>Reporter: Dimitri Desmidt
>Assignee: Prasanna Santhanam
>Priority: Critical
> Fix For: 4.2.0
>
>
> In my lab, the SSVM has access to Internet ONLY via a Proxy.
> I configured for that the Global Setting secstorage.proxy with the value
> "http://proxy.xyz.com:3128"; (without the quotes "").
> Then I restarted the cloud management and destroyed the SSVM.
> The new SSVM tries to download again
> "http://download.cloud.com/templates/builtin/centos56-x86_64.vhd.bz2";.
> This still fails and when I look at the Management Log, it looks like there
> is still no Proxy used:
> 2012-11-20 06:44:31,438 DEBUG [agent.transport.Request] (Timer-4:null) Seq
> 18-550436874: Sending { Cmd , MgmtId: 345051959742, via: 18, Ver: v1, Flags:
> 100011,
> [{"storage.DownloadProgressCommand":{"jobId":"38d18cba-470a-46da-821d-37cfacd2bb40","request":"GET_STATUS","hvm":false,"description":"CentOS
> 5.6(64-bit) no GUI
> (XenServer)","checksum":"905cec879afd9c9d22ecc8036131a180","maxDownloadSizeInBytes":53687091200,"id":5,"resourceType":"TEMPLATE","url":"http://download.cloud.com/templates/builtin/centos56-x86_64.vhd.bz2","format":"VHD","accountId":1,"name":"centos56-x86_64-xen","secUrl":"nfs://10.30.1.3/export/secondary","wait":0}}]
> }
> 2012-11-20 06:44:31,485 DEBUG [agent.transport.Request]
> (AgentManager-Handler-2:null) Seq 18-550436874: Processing: { Ans: , MgmtId:
> 345051959742, via: 18, Ver: v1, Flags: 10,
> [{"storage.DownloadAnswer":{"jobId":"38d18cba-470a-46da-821d-37cfacd2bb40","downloadPct":0,"errorString":"
>
> ","downloadStatus":"NOT_DOWNLOADED","downloadPath":"/mnt/SecStorage/ff53ffad-7c5d-382f-942c-e527528c5699/template/tmpl/1/5/dnld5122201514511320578tmp_","templateSize":0,"templatePhySicalSize":0,"checkSum":"905cec879afd9c9d22ecc8036131a180","result":false,"details":"
> ","wait":0}}] }
> Conclusion;
> Looks like the Global Setting information is NOT applied :-(
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CLOUDSTACK-1389) Interactive Password Prompts during Management Server Startup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal reopened CLOUDSTACK-1389: -- This is still a problem. Let's fix in 4.2 > Interactive Password Prompts during Management Server Startup > - > > Key: CLOUDSTACK-1389 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1389 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 > Environment: devcloud >Reporter: John Burwell >Assignee: Abhinandan Prateek > Labels: security > Fix For: 4.2.0 > > > When starting the management with no SSL certificate present, the system > attempts to run a shell script that requires interactive password entry. > Executing the following steps with a user that is either non-sudoer or a > sudoer that requires a password authentication to perform sudo actions (and > who has not already authenticated to sudo), execute the following commands > from root directory of a cloudstack/4.1 checkout: >1. mvn -P developer clean install >2. mvn -pl :cloud-client-ui jetty:run > During the startup process, the management server will not find the > cloud.keystore in the the > client/target/cloud-client-ui-4.1-SNAPSHOT/WEB-INF/classes directory, and > attempt to generate an SSL certificate using the following shell scripts: >sudo keytool -genkey -keystore > /Users/jburwell/Documents/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore > -store > pass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname > cn="Cloudstack User",ou="0.8.31",o="0.8.31",c="Unknown" > The following is a capture of the script timeout error from the vmops.log: >2013-02-27 09:52:17,157 INFO [cloud.server.ConfigurationServerImpl] > (Timer-2:null) SSL keystore located at /Users/jburwell/Docum > ents/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore > 2013-02-27 09:52:17,176 DEBUG [utils.script.Script] (Timer-2:null) Executing: > sudo keytool -genkey -keystore /Users/jburwell/Docu > ments/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore > -store > pass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname > cn="Cloudstack User",ou="0.8.31",o="0.8.31",c="Unknown" > 2013-02-27 09:52:22,188 WARN [utils.script.Script] (Script-1:null) > Interrupting script. > 2013-02-27 09:52:22,190 WARN [utils.script.Script] (Timer-2:null) Timed out: > sudo keytool -genkey -keystore /Users/jburwell/Docu > ments/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore > -store > pass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname > cn="Cloudstack User",ou="0.8.31",o="0.8.31",c="Unknown" . Ou > tput is: dyld: DYLD_ environment variables being ignored because main > executable (/usr/bin/sudo) is setuid or setgid > 2013-02-27 09:52:22,191 WARN [cloud.server.ConfigurationServerImpl] > (Timer-2:null) Would use fail-safe keystore to continue. > java.io.IOException: Fail to generate certificate!: timeout > at > com.cloud.server.ConfigurationServerImpl.generateDefaultKeystore(ConfigurationServerImpl.java:490) > at > com.cloud.server.ConfigurationServerImpl.updateSSLKeystore(ConfigurationServerImpl.java:511) > at > com.cloud.server.ConfigurationServerImpl.persistDefaultValues(ConfigurationServerImpl.java:272) > at > com.cloud.server.ConfigurationServerImpl.configure(ConfigurationServerImpl.java:144) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:319) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:8 > 0) > at > com.cloud.utils.db.TransactionContextBuilder.AroundAnyMethod(TransactionContextBuilder.java:37) > at sun.reflect.GeneratedMethodAccessor35.invo
[jira] [Updated] (CLOUDSTACK-1389) Interactive Password Prompts during Management Server Startup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chiradeep Vittal updated CLOUDSTACK-1389: - Fix Version/s: (was: 4.1.0) 4.2.0 > Interactive Password Prompts during Management Server Startup > - > > Key: CLOUDSTACK-1389 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1389 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 > Environment: devcloud >Reporter: John Burwell >Assignee: Abhinandan Prateek > Labels: security > Fix For: 4.2.0 > > > When starting the management with no SSL certificate present, the system > attempts to run a shell script that requires interactive password entry. > Executing the following steps with a user that is either non-sudoer or a > sudoer that requires a password authentication to perform sudo actions (and > who has not already authenticated to sudo), execute the following commands > from root directory of a cloudstack/4.1 checkout: >1. mvn -P developer clean install >2. mvn -pl :cloud-client-ui jetty:run > During the startup process, the management server will not find the > cloud.keystore in the the > client/target/cloud-client-ui-4.1-SNAPSHOT/WEB-INF/classes directory, and > attempt to generate an SSL certificate using the following shell scripts: >sudo keytool -genkey -keystore > /Users/jburwell/Documents/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore > -store > pass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname > cn="Cloudstack User",ou="0.8.31",o="0.8.31",c="Unknown" > The following is a capture of the script timeout error from the vmops.log: >2013-02-27 09:52:17,157 INFO [cloud.server.ConfigurationServerImpl] > (Timer-2:null) SSL keystore located at /Users/jburwell/Docum > ents/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore > 2013-02-27 09:52:17,176 DEBUG [utils.script.Script] (Timer-2:null) Executing: > sudo keytool -genkey -keystore /Users/jburwell/Docu > ments/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore > -store > pass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname > cn="Cloudstack User",ou="0.8.31",o="0.8.31",c="Unknown" > 2013-02-27 09:52:22,188 WARN [utils.script.Script] (Script-1:null) > Interrupting script. > 2013-02-27 09:52:22,190 WARN [utils.script.Script] (Timer-2:null) Timed out: > sudo keytool -genkey -keystore /Users/jburwell/Docu > ments/projects/cloudstack/src/cloudstack-basho/client/target/cloud-client-ui-4.1.0-SNAPSHOT/WEB-INF/classes/cloud.keystore > -store > pass vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname > cn="Cloudstack User",ou="0.8.31",o="0.8.31",c="Unknown" . Ou > tput is: dyld: DYLD_ environment variables being ignored because main > executable (/usr/bin/sudo) is setuid or setgid > 2013-02-27 09:52:22,191 WARN [cloud.server.ConfigurationServerImpl] > (Timer-2:null) Would use fail-safe keystore to continue. > java.io.IOException: Fail to generate certificate!: timeout > at > com.cloud.server.ConfigurationServerImpl.generateDefaultKeystore(ConfigurationServerImpl.java:490) > at > com.cloud.server.ConfigurationServerImpl.updateSSLKeystore(ConfigurationServerImpl.java:511) > at > com.cloud.server.ConfigurationServerImpl.persistDefaultValues(ConfigurationServerImpl.java:272) > at > com.cloud.server.ConfigurationServerImpl.configure(ConfigurationServerImpl.java:144) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:319) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:8 > 0) > at > com.cloud.utils.db.TransactionContextBuilder.AroundAnyMethod(TransactionContextBuilder.java:37) > at sun.reflect.GeneratedMethodAccessor35.
[jira] [Updated] (CLOUDSTACK-1896) S3-backed NFS secondary storage uses Db-based lock when DB is not available
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chiradeep Vittal updated CLOUDSTACK-1896:
-
Description:
While perusing NfsSecondaryStorageResource.java, I came across:
public Answer execute(final DownloadSnapshotFromS3Command cmd) {
...
try {
executeWithNoWaitLock(determineSnapshotLockId(accountId, volumeId),
new Callable() {
@Override
public Void call() throws Exception {
}
}
The executeWithNoWaitLock utility uses the management server database, which is
not available inside the secondary storage vm. So, my conclusion is that there
is no way this code works.
This also affects the method deleteSnapshotBackupfromS3
was:
While perusing NfsSecondaryStorageResource.java, I came across:
public Answer execute(final DownloadSnapshotFromS3Command cmd) {
...
try {
executeWithNoWaitLock(determineSnapshotLockId(accountId, volumeId),
new Callable() {
@Override
public Void call() throws Exception {
}
}
The executeWithNoWaitLock utility uses the management server database, which is
not available inside the secondary storage vm. So, my conclusion is that there
is no way this code works.
Unfortunately the same code has been added to the Swift-backed code as well and
will therefore break that as well.
Summary: S3-backed NFS secondary storage uses Db-based lock when DB is
not available (was: S3 and Swift-backed NFS secondary storage uses Db-based
lock when DB is not available)
> S3-backed NFS secondary storage uses Db-based lock when DB is not available
> ---
>
> Key: CLOUDSTACK-1896
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1896
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller
>Affects Versions: 4.1.0, 4.2.0
>Reporter: Chiradeep Vittal
>Assignee: John Burwell
>
> While perusing NfsSecondaryStorageResource.java, I came across:
> public Answer execute(final DownloadSnapshotFromS3Command cmd) {
>...
> try {
> executeWithNoWaitLock(determineSnapshotLockId(accountId,
> volumeId),
> new Callable() {
> @Override
> public Void call() throws Exception {
>
> }
>}
> The executeWithNoWaitLock utility uses the management server database, which
> is not available inside the secondary storage vm. So, my conclusion is that
> there is no way this code works.
> This also affects the method deleteSnapshotBackupfromS3
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-1896) S3 and Swift-backed NFS secondary storage uses Db-based lock when DB is not available
Chiradeep Vittal created CLOUDSTACK-1896:
Summary: S3 and Swift-backed NFS secondary storage uses Db-based
lock when DB is not available
Key: CLOUDSTACK-1896
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1896
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Storage Controller
Affects Versions: 4.1.0, 4.2.0
Reporter: Chiradeep Vittal
Assignee: John Burwell
While perusing NfsSecondaryStorageResource.java, I came across:
public Answer execute(final DownloadSnapshotFromS3Command cmd) {
...
try {
executeWithNoWaitLock(determineSnapshotLockId(accountId, volumeId),
new Callable() {
@Override
public Void call() throws Exception {
}
}
The executeWithNoWaitLock utility uses the management server database, which is
not available inside the secondary storage vm. So, my conclusion is that there
is no way this code works.
Unfortunately the same code has been added to the Swift-backed code as well and
will therefore break that as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-1821) AWS S3 API -Get bucket by name - ACLs do not give user the required permission
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619233#comment-13619233 ] Chiradeep Vittal commented on CLOUDSTACK-1821: -- http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGET.html You have to make sure your request is signed. If you do this http://:7080/awsapi/rest/AmazonS3/test12323 then it is an anonymous request and unless the bucket ACL / policy is set to read by 'ALL', and you won't be able to read it http://docs.aws.amazon.com/AmazonS3/latest/dev/ACLOverview.html > AWS S3 API -Get bucket by name - ACLs do not give user the required permission > -- > > Key: CLOUDSTACK-1821 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1821 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: AWSAPI >Affects Versions: 4.0.0 > Environment: Software platform >Reporter: Asmita Vagyani > Fix For: 4.0.0 > > > Now the bucket gets created in mount point folder, but the owner of folder is > nobody user. > Now when I use: http://:7080/awsapi/rest/AmazonS3/test12323 > This should give me details abt the bucket. > I get following error on IE browser: Access denied - > com.cloud.bridge.service.exception.PermissionDeniedException: Access Denied - > ACLs do not give user the required permission > This is a bug. > Logs show- > com.cloud.bridge.service.exception.PermissionDeniedException: Access Denied - > ACLs do not give user the required permission > at > com.cloud.bridge.service.core.s3.S3Engine.accessAllowed(S3Engine.java:1762) > at > com.cloud.bridge.service.core.s3.S3Engine.verifyAccess(S3Engine.java:1729) > at > com.cloud.bridge.service.core.s3.S3Engine.listBucketContents(S3Engine.java:362) > at > com.cloud.bridge.service.controller.s3.S3BucketAction.executeGetBucket(S3BucketAction.java:578) > at > com.cloud.bridge.service.controller.s3.S3BucketAction.execute(S3BucketAction.java:202) > at > com.cloud.bridge.service.S3RestServlet.processRequest(S3RestServlet.java:181) > at com.cloud.bridge.service.S3RestServlet.doGet(S3RestServlet.java:84) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) > at > org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) > at > org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2268) > 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:722) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-1807) CS4 AWS S3 support - List all buckets AWS API doesnot return correct response if not buckets are created on NFS mount
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616729#comment-13616729 ] Chiradeep Vittal commented on CLOUDSTACK-1807: -- This follows the Amazon S3 behavior, I believe. If you do not specify a bucket, the S3 API endpoint doesn't know what you are trying to -- list a bucket, list an ACL, etc. > CS4 AWS S3 support - List all buckets AWS API doesnot return correct response > if not buckets are created on NFS mount > - > > Key: CLOUDSTACK-1807 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1807 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: AWSAPI >Affects Versions: 4.0.0 > Environment: CS 4.0.0. dfeployed on RHEL 6.3 >Reporter: Asmita Vagyani > > There is no bucket created on my NFS mount. > When I use this url > http://torvm-cloudstack-mgmt.sigmasys.net:7080/awsapi/rest/AmazonS3 > In the IE browser, it gives 400-Bad request error. > When I give url as > http://torvm-cloudstack-mgmt.sigmasys.net:7080/awsapi/rest/AmazonS3/test2342 > It gives error like : > > NoSuchBucket > The specified bucket does not exist > test2342 1DEADBEEF9 > abCdeFgHiJ1k2LmN3op4q56r7st89 > > This is a normal behavior. > Same behavior I should get when I don’t pass any name of bucket. > Please check if this is a bug in CS4. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-1821) AWS S3 API -Get bucket by name - ACLs do not give user the required permission
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616725#comment-13616725 ] Chiradeep Vittal commented on CLOUDSTACK-1821: -- When you create a bucket you have to specify ACLs on it so that it is publicly viewable. > AWS S3 API -Get bucket by name - ACLs do not give user the required permission > -- > > Key: CLOUDSTACK-1821 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1821 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: AWSAPI >Affects Versions: 4.0.0 > Environment: Software platform >Reporter: Asmita Vagyani > Fix For: 4.0.0 > > > Now the bucket gets created in mount point folder, but the owner of folder is > nobody user. > Now when I use: http://:7080/awsapi/rest/AmazonS3/test12323 > This should give me details abt the bucket. > I get following error on IE browser: Access denied - > com.cloud.bridge.service.exception.PermissionDeniedException: Access Denied - > ACLs do not give user the required permission > This is a bug. > Logs show- > com.cloud.bridge.service.exception.PermissionDeniedException: Access Denied - > ACLs do not give user the required permission > at > com.cloud.bridge.service.core.s3.S3Engine.accessAllowed(S3Engine.java:1762) > at > com.cloud.bridge.service.core.s3.S3Engine.verifyAccess(S3Engine.java:1729) > at > com.cloud.bridge.service.core.s3.S3Engine.listBucketContents(S3Engine.java:362) > at > com.cloud.bridge.service.controller.s3.S3BucketAction.executeGetBucket(S3BucketAction.java:578) > at > com.cloud.bridge.service.controller.s3.S3BucketAction.execute(S3BucketAction.java:202) > at > com.cloud.bridge.service.S3RestServlet.processRequest(S3RestServlet.java:181) > at com.cloud.bridge.service.S3RestServlet.doGet(S3RestServlet.java:84) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) > at > org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) > at > org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2268) > 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:722) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1813) QuickCloud - faster cloud startup
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chiradeep Vittal updated CLOUDSTACK-1813:
-
Fix Version/s: 4.2.0
Assignee: Chiradeep Vittal
Description:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/QuickCloud
To enable a cloud to "boot" with services managed and running on
non-cloudstack-managed servers
To enable a development environment based on DevCloud ("QuickCloud") that
eschews the use of system vms
To allow the cloud administrator to choose to provide these services the "old"
way after booting in the QuickCloud fashion
> QuickCloud - faster cloud startup
> -
>
> Key: CLOUDSTACK-1813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1813
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller, Storage Controller
>Reporter: Chiradeep Vittal
>Assignee: Chiradeep Vittal
> Fix For: 4.2.0
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/QuickCloud
> To enable a cloud to "boot" with services managed and running on
> non-cloudstack-managed servers
> To enable a development environment based on DevCloud ("QuickCloud") that
> eschews the use of system vms
> To allow the cloud administrator to choose to provide these services the
> "old" way after booting in the QuickCloud fashion
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-1813) QuickCloud - faster cloud startup
Chiradeep Vittal created CLOUDSTACK-1813: Summary: QuickCloud - faster cloud startup Key: CLOUDSTACK-1813 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1813 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller, Storage Controller Reporter: Chiradeep Vittal -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
