[jira] [Resolved] (CLOUDSTACK-6354) In com.cloud.utils.crypt.EncryptionSecretKeyChecker the key file paths are hard coded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T resolved CLOUDSTACK-6354. - Resolution: Fixed In com.cloud.utils.crypt.EncryptionSecretKeyChecker the key file paths are hard coded - Key: CLOUDSTACK-6354 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6354 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: Damodar Reddy T Assignee: Damodar Reddy T Fix For: Future In com.cloud.utils.crypt.EncryptionSecretKeyChecker the key file paths are hard coded to /etc/cloudstack/management/key which will cause issue if key generation path gets changes during installation time. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6410) [Windows] Integrate Windows wix tool to maven
Damodar Reddy T created CLOUDSTACK-6410: --- Summary: [Windows] Integrate Windows wix tool to maven Key: CLOUDSTACK-6410 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6410 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: Future Reporter: Damodar Reddy T Assignee: Damodar Reddy T Fix For: Future Try to integrate Wix tool set with maven build process so that no manual steps are required to create windows msi installer file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6385) Can`t update systemvm.iso and authorized_keys on host after upgrade from 4.2 to 4.3
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Artemyev updated CLOUDSTACK-6385: Affects Version/s: 4.0.0 4.0.1 4.0.2 4.1.0 4.2.0 Can`t update systemvm.iso and authorized_keys on host after upgrade from 4.2 to 4.3 --- Key: CLOUDSTACK-6385 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6385 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, SystemVM, XenServer Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.2.0, 4.3.0 Reporter: Andrew Artemyev when I upgrade managment the server from 4.2 to 4.3. new ssh key-pair generated and intergate to systemvm.iso, but neither new publickey no systemvm.iso not upload to hypervisor host as result upgraded systemvm started but down by hypervisor which can`t access to it. clean install of CS not have this problem -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6242) Potential bugs and improvements for exception handlers
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969296#comment-13969296
]
ASF subversion and git services commented on CLOUDSTACK-6242:
-
Commit c031eb7d38200d680da85ef57367b21df3483c41 in cloudstack's branch
refs/heads/master from [~d.yuan]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c031eb7 ]
CLOUDSTACK-6242: exception handling improvements
Signed-off-by: Daan Hoogland d...@onecht.net
Potential bugs and improvements for exception handlers
--
Key: CLOUDSTACK-6242
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6242
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Projects, Storage Controller
Affects Versions: 4.2.0
Reporter: Ding Yuan
Attachments: CLOUDSTACK-6242.patch
Hi Cloudstack developers,
I'm reporting a few cases where the exception handling logic could be
improved. In particular, there are a few cases where the caught exception is
too general (over-catch), and/or missing log messages. Attaching a patch for
review.
There are a few cases where it looks suspicious but I do not know how to fix
right now (all filenames and line numbers are based on version 4.2.1):
=
Case 1:
Line: 375, File: com/cloud/network/ovs/OvsTunnelManagerImpl.java
{noformat}
326: try {
327: String myIp = getGreEndpointIP(dest.getHost(), nw);
.. .. ..
373:} catch (Exception e) {
374:// I really thing we should do a better handling of these
exceptions
375:s_logger.warn(Ovs Tunnel network created tunnel failed, e);
376:}
{noformat}
Comment seems to suggest for a better handling.
=
=
Case 2:
Line: 2295, File: com/cloud/resource/ResourceManagerImpl.java
{noformat}
2284: try {
2285: /*
2286: * FIXME: this is a buggy logic, check with alex.
Shouldn't
2287: * return if propagation return non null
2288: */
2289: Boolean result =
_clusterMgr.propagateResourceEvent(h.getId(),
ResourceState.Event.UpdatePassword);
2290: if (result != null) {
2291: return result;
2292: }
2293:
2294: doUpdateHostPassword(h.getId());
2295: } catch (AgentUnavailableException e) {
2296: }
{noformat}
Seem from the comment the logic should be fixed.
A similar code snipeet is at:
Line: 2276, File: com/cloud/resource/ResourceManagerImpl.java
=
=
Case 3:
Line: 184, File:
org/apache/cloudstack/api/command/user/autoscale/CreateAutoScaleVmGroupCmd.java
{noformat}
174: try
175: {
176: success = _autoScaleService.configureAutoScaleVmGroup(this);
177: if (success) {
178: vmGroup = _entityMgr.findById(AutoScaleVmGroup.class,
getEntityId());
179: AutoScaleVmGroupResponse responseObject =
_responseGenerator.createAutoScaleVmGroupResponse(vmGroup);
180: setResponseObject(responseObject);
181: responseObject.setResponseName(getCommandName());
182: }
183: } catch (Exception ex) {
184: // TODO what will happen if Resource Layer fails in a step
inbetween
185: s_logger.warn(Failed to create autoscale vm group, ex);
186: }
{noformat}
The comment, TODO, seems to suggest for better handling.
=
=
Case 4:
Line: 222, File: com/cloud/api/ApiDispatcher.java
This snippet is moved to ParamProcessWorker.java in the trunk.
{noformat}
203: try {
204: setFieldValue(field, cmd, paramObj, parameterAnnotation);
.. ..
220: } catch (CloudRuntimeException cloudEx) {
221:s_logger.error(CloudRuntimeException, cloudEx);
222: // FIXME: Better error message? This only happens if the
API command is not executable, which typically
223: //means
224: // there was
225: // and IllegalAccessException setting one of the
parameters.
226: throw new
ServerApiException(ApiErrorCode.INTERNAL_ERROR, Internal error executing API
command + cmd.getCommandName().substring(0, cmd.getCommandName().length() -
8));
227: }
{noformat}
The FIXME comment seems to suggest for getter error message.
=
--
This
[jira] [Commented] (CLOUDSTACK-6400) [Hyper-V][VMSync]Occasionally VM is not deleted from back-end when it is stopped from Hyper-V manager and then destroyed-expunged from CS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969304#comment-13969304 ] ASF subversion and git services commented on CLOUDSTACK-6400: - Commit d45ee3ef21fd55c8a1cf1373225cab81389ad8c7 in cloudstack's branch refs/heads/4.4 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d45ee3e ] CLOUDSTACK-6400: [hyper-v] [vmsync] fixed occasionally VM is not deleted from back-end when it is stopped from Hyper-V manager and then destroyed-expunged from CS and returning only power VMs for vmsync [Hyper-V][VMSync]Occasionally VM is not deleted from back-end when it is stopped from Hyper-V manager and then destroyed-expunged from CS - Key: CLOUDSTACK-6400 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6400 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar [Hyper-V][VMSync]Occasionally VM is not deleted from back-end when it is stopped from Hyper-V manager and then destroyed-expunged from CS -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6401) [Hyper-v] Host state is always shown as down when agent is down even when it is up
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969305#comment-13969305 ] ASF subversion and git services commented on CLOUDSTACK-6401: - Commit b78aee8f117f9e89a533afba86b3ff91da19744e in cloudstack's branch refs/heads/4.4 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b78aee8 ] CLOUDSTACK-6401: [hyper-v] fixed correct host state, if host is up and hyper-v agent is down then the host state will be shown as up(actual host state) in cloudstack [Hyper-v] Host state is always shown as down when agent is down even when it is up -- Key: CLOUDSTACK-6401 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6401 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar [Hyper-v] Host state is always shown as down when agent is down even when it is up -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6398) [Hyper-V] [VMSync] Change auto shutdown and startup actions of VMs to shutdown and nothing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969303#comment-13969303 ] ASF subversion and git services commented on CLOUDSTACK-6398: - Commit 36103633c2764fe33374f5cbfb1ac0d5bf24ed1b in cloudstack's branch refs/heads/4.4 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3610363 ] CLOUDSTACK-6398:[hyper-v] changed auto shutdown and startup actions of VMs to shutdown and nothingauto shutdown and startup actions of VMs to shutdown and nothing so that they are consistent with cloudstack auto shudown and startup behavior [Hyper-V] [VMSync] Change auto shutdown and startup actions of VMs to shutdown and nothing -- Key: CLOUDSTACK-6398 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6398 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Change auto shutdown and startup actions to shutdown and nothing so that they are consistent with Cloudstack auto shutdown and startup behavior -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6411) [hyper-v] some files are not loading in visual studio due to license header at top making them unparsable
Anshul Gangwar created CLOUDSTACK-6411: -- Summary: [hyper-v] some files are not loading in visual studio due to license header at top making them unparsable Key: CLOUDSTACK-6411 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6411 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar [hyper-v] some files are not loading in visual studio due to license header at top making them unparsable -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5907) KVM/CLVM volumes are shown as Ovm hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969323#comment-13969323 ] Nux commented on CLOUDSTACK-5907: - Thanks, I'll bug some people so we hopefully get this validated incorporated. KVM/CLVM volumes are shown as Ovm hypervisor Key: CLOUDSTACK-5907 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5907 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, KVM, Oracle VM (OVM), Storage Controller, UI Affects Versions: 4.2.1, 4.3.0 Environment: KVM, CLVM Reporter: Nux Labels: clvm, kvm, ovm, storage Attachments: storage1.png, storage2.png It looks like ACS is showing KVM volumes on CLVM primary storage as being for Oracle hypervisor. http://i.imgur.com/E4InCV2.png The API shows the same so it's not a UI glitch. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (CLOUDSTACK-5907) KVM/CLVM volumes are shown as Ovm hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nux reopened CLOUDSTACK-5907: - KVM/CLVM volumes are shown as Ovm hypervisor Key: CLOUDSTACK-5907 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5907 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, KVM, Oracle VM (OVM), Storage Controller, UI Affects Versions: 4.2.1, 4.3.0 Environment: KVM, CLVM Reporter: Nux Labels: clvm, kvm, ovm, storage Attachments: storage1.png, storage2.png It looks like ACS is showing KVM volumes on CLVM primary storage as being for Oracle hypervisor. http://i.imgur.com/E4InCV2.png The API shows the same so it's not a UI glitch. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6412) [UI]Incorrect Field value added with host details page(Dedicated label.no)
Sailaja Mada created CLOUDSTACK-6412: Summary: [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 Priority: Minor 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(Dedicatedlabel.no) (Attached the snapshot) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (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 updated CLOUDSTACK-6412: - Fix Version/s: 4.4.0 [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 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.2#6252)
[jira] [Updated] (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 updated CLOUDSTACK-6412: - Attachment: dedicatedincorrectlabel.png [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 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.2#6252)
[jira] [Resolved] (CLOUDSTACK-6404) Download template URL is broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nux resolved CLOUDSTACK-6404. - Resolution: Fixed Download template URL is broken --- Key: CLOUDSTACK-6404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6404 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Management Server Affects Versions: 4.3.0 Environment: CentOS 6.5/KVM Xenserver Reporter: Nux Labels: template When I click on download template button in a template's window I get an incorrect url. Instead of getting https://1-2-3-4.domain.tld/userdata/b851ca5f-f108-4294-bb31-26c8b2e9707a.qcow2 which is the SS VM, I get https://domain.tld/userdata/b851ca5f-f108-4294-bb31-26c8b2e9707a.qcow2 which is a totally different site. I'm running under my own domain and wildcard cert, but this happens also when realhostip.com is in use. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6404) Download template URL is broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nux closed CLOUDSTACK-6404. --- Download template URL is broken --- Key: CLOUDSTACK-6404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6404 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Management Server Affects Versions: 4.3.0 Environment: CentOS 6.5/KVM Xenserver Reporter: Nux Labels: template When I click on download template button in a template's window I get an incorrect url. Instead of getting https://1-2-3-4.domain.tld/userdata/b851ca5f-f108-4294-bb31-26c8b2e9707a.qcow2 which is the SS VM, I get https://domain.tld/userdata/b851ca5f-f108-4294-bb31-26c8b2e9707a.qcow2 which is a totally different site. I'm running under my own domain and wildcard cert, but this happens also when realhostip.com is in use. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6401) [Hyper-v] Host state is always shown as down when agent is down even when it is up
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969373#comment-13969373 ] ASF subversion and git services commented on CLOUDSTACK-6401: - Commit 55f53e13e82179c2cbde3f667869495ec944f496 in cloudstack's branch refs/heads/master from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=55f53e1 ] CLOUDSTACK-6401: [hyper-v] fixed correct host state, if host is up and hyper-v agent is down then the host state will be shown as up(actual host state) in cloudstack [Hyper-v] Host state is always shown as down when agent is down even when it is up -- Key: CLOUDSTACK-6401 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6401 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar [Hyper-v] Host state is always shown as down when agent is down even when it is up -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6398) [Hyper-V] [VMSync] Change auto shutdown and startup actions of VMs to shutdown and nothing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969371#comment-13969371 ] ASF subversion and git services commented on CLOUDSTACK-6398: - Commit 0aa6cc60c73698a7be960d2503a5abceaf16d8c7 in cloudstack's branch refs/heads/master from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0aa6cc6 ] CLOUDSTACK-6398:[hyper-v] changed auto shutdown and startup actions of VMs to shutdown and nothingauto shutdown and startup actions of VMs to shutdown and nothing so that they are consistent with cloudstack auto shudown and startup behavior [Hyper-V] [VMSync] Change auto shutdown and startup actions of VMs to shutdown and nothing -- Key: CLOUDSTACK-6398 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6398 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Change auto shutdown and startup actions to shutdown and nothing so that they are consistent with Cloudstack auto shutdown and startup behavior -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6400) [Hyper-V][VMSync]Occasionally VM is not deleted from back-end when it is stopped from Hyper-V manager and then destroyed-expunged from CS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969372#comment-13969372 ] ASF subversion and git services commented on CLOUDSTACK-6400: - Commit 3ec7497e1ebcaa65a8cbd24c27326356355ac8cc in cloudstack's branch refs/heads/master from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3ec7497 ] CLOUDSTACK-6400: [hyper-v] [vmsync] fixed occasionally VM is not deleted from back-end when it is stopped from Hyper-V manager and then destroyed-expunged from CS and returning only power VMs for vmsync [Hyper-V][VMSync]Occasionally VM is not deleted from back-end when it is stopped from Hyper-V manager and then destroyed-expunged from CS - Key: CLOUDSTACK-6400 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6400 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar [Hyper-V][VMSync]Occasionally VM is not deleted from back-end when it is stopped from Hyper-V manager and then destroyed-expunged from CS -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6400) [Hyper-V][VMSync]Occasionally VM is not deleted from back-end when it is stopped from Hyper-V manager and then destroyed-expunged from CS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-6400. Resolution: Fixed [Hyper-V][VMSync]Occasionally VM is not deleted from back-end when it is stopped from Hyper-V manager and then destroyed-expunged from CS - Key: CLOUDSTACK-6400 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6400 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar [Hyper-V][VMSync]Occasionally VM is not deleted from back-end when it is stopped from Hyper-V manager and then destroyed-expunged from CS -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6401) [Hyper-v] Host state is always shown as down when agent is down even when it is up
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-6401. Resolution: Fixed [Hyper-v] Host state is always shown as down when agent is down even when it is up -- Key: CLOUDSTACK-6401 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6401 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar [Hyper-v] Host state is always shown as down when agent is down even when it is up -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6398) [Hyper-V] [VMSync] Change auto shutdown and startup actions of VMs to shutdown and nothing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-6398. Resolution: Fixed [Hyper-V] [VMSync] Change auto shutdown and startup actions of VMs to shutdown and nothing -- Key: CLOUDSTACK-6398 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6398 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Change auto shutdown and startup actions to shutdown and nothing so that they are consistent with Cloudstack auto shutdown and startup behavior -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6413) Cutom Disk Offering VirtualRouter Disk
Keerthiraja created CLOUDSTACK-6413: --- Summary: Cutom Disk Offering VirtualRouter Disk Key: CLOUDSTACK-6413 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6413 Project: CloudStack Issue Type: New Feature Components: Virtual Router Affects Versions: 4.4.0 Environment: Cloudstack 4.4.0 Virtual Router Custom Disk Offering or Increase disk size or lvm partition Reporter: Keerthiraja I would like to suggest to bring up a new features. To bring cloudstack Virtual Router custom disk offering or to increase the disk space from default of 2GB to 4GB since when I did small test to collect the Virtual Router static using collectd I tried to install some package but unfortunately /usr partition seem to be full. Why can we increase the default disk space to 4GB or else at least create the partition with lvm so that we can increase the disk partition whenever we need. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (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 updated CLOUDSTACK-6414: - Fix Version/s: 4.4.0 [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 Fix For: 4.4.0 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) Attached Firebug snap. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6414) [UI] UI is not allowing to create DomainAdmin User (ReferenceError: rootDomainId is not defined)
Sailaja Mada created CLOUDSTACK-6414: Summary: [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 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) Attached Firebug snap. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (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 updated CLOUDSTACK-6414: - Description: 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. was: 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) Attached Firebug snap. [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 Fix For: 4.4.0 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.2#6252)
[jira] [Updated] (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 updated CLOUDSTACK-6414: - Attachment: FailedtoaddDomainAdminUI.png [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 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.2#6252)
[jira] [Created] (CLOUDSTACK-6415) [hyper-v] Format the Hyper-v agent code
Anshul Gangwar created CLOUDSTACK-6415: -- Summary: [hyper-v] Format the Hyper-v agent code Key: CLOUDSTACK-6415 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6415 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar currently hyper-v agent code contains mixed line endings. Even if we make minor change , then due to change in line ending it shows many changes while committing files. There are some places where trailing spaces are also present. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5825) Create snapshot API always returns success
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969410#comment-13969410 ] Alex Hitchins commented on CLOUDSTACK-5825: --- Made amendments to patch as per dev list discussion. Create snapshot API always returns success -- Key: CLOUDSTACK-5825 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5825 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.3.0 Reporter: Chris Suich Assignee: Alex Hitchins Priority: Critical Labels: api, create, snapshot Attachments: Snapshot_Logs.txt, snapshot_failure.JPG VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot() to VolumeServiceImpl.takeSnapshot(), you’ll notice that ANY exception that is thrown inside of SnapshotManager.takeSnapshot() is simply caught and ignored. Back up in VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(), JobInfo.Status.SUCCEEDED is ALWAYS returned, regardless of the snapshot result. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6416) Missing cloud-scripts in systemvm template built from 4.2 branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-6416: - Priority: Blocker (was: Critical) Missing cloud-scripts in systemvm template built from 4.2 branch Key: CLOUDSTACK-6416 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6416 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.2.0 Environment: 4.2 systemvm template Reporter: Sateesh Chodapuneedi Priority: Blocker cloud-scripts.tar is not built properly with scripts. It was filled up with source code of cloudstack project from ACS git repository. While building systemvm template, in postinstall.sh file, cloudstack source would be downloaded from ACS git repository and patching scripts would be bundled as cloud-scripts.tar after extracting cloudstack source tar ball. Untar operation of source tar ball failed with error no space left on device. Build script is not failing at this point but this is resulting in mal-formed cloud-scripts.tar. cloudstack-HEAD-2a02369/awsapi/src/com/amazon/ec2/DescribeConversionTasksType.java tar: /usr/share/cloud/cloud-scripts.tar: Cannot write: No space left on device tar: Error is not recoverable: exiting now ++ cd /opt ++ rm -fr /opt/cloudstack-HEAD-2a02369 /opt/cloudstack.tar.gz cloudstack.tar.gz ++ chkconfig --add cloud-early-config cloud-early-config: unknown service ++ chkconfig cloud-early-config on cloud-early-config: unknown service ++ chkconfig --add cloud-passwd-srvr cloud-passwd-srvr: unknown service ++ chkconfig cloud-passwd-srvr off cloud-passwd-srvr: unknown service ++ chkconfig --add cloud cloud: unknown service ++ chkconfig cloud off cloud: unknown service Downloaded system vm template generated by jenkins from http://jenkins.buildacloud.org/view/4.2/job/build-systemvm-4.2/ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6416) Missing cloud-scripts in systemvm template built from 4.2 branch
Sateesh Chodapuneedi created CLOUDSTACK-6416: Summary: Missing cloud-scripts in systemvm template built from 4.2 branch Key: CLOUDSTACK-6416 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6416 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.2.0 Environment: 4.2 systemvm template Reporter: Sateesh Chodapuneedi Priority: Critical cloud-scripts.tar is not built properly with scripts. It was filled up with source code of cloudstack project from ACS git repository. While building systemvm template, in postinstall.sh file, cloudstack source would be downloaded from ACS git repository and patching scripts would be bundled as cloud-scripts.tar after extracting cloudstack source tar ball. Untar operation of source tar ball failed with error no space left on device. Build script is not failing at this point but this is resulting in mal-formed cloud-scripts.tar. cloudstack-HEAD-2a02369/awsapi/src/com/amazon/ec2/DescribeConversionTasksType.java tar: /usr/share/cloud/cloud-scripts.tar: Cannot write: No space left on device tar: Error is not recoverable: exiting now ++ cd /opt ++ rm -fr /opt/cloudstack-HEAD-2a02369 /opt/cloudstack.tar.gz cloudstack.tar.gz ++ chkconfig --add cloud-early-config cloud-early-config: unknown service ++ chkconfig cloud-early-config on cloud-early-config: unknown service ++ chkconfig --add cloud-passwd-srvr cloud-passwd-srvr: unknown service ++ chkconfig cloud-passwd-srvr off cloud-passwd-srvr: unknown service ++ chkconfig --add cloud cloud: unknown service ++ chkconfig cloud off cloud: unknown service Downloaded system vm template generated by jenkins from http://jenkins.buildacloud.org/view/4.2/job/build-systemvm-4.2/ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6416) Missing cloud-scripts in systemvm template built from 4.2 branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969420#comment-13969420 ] Sateesh Chodapuneedi commented on CLOUDSTACK-6416: -- I am trying to pickup systemvm template with fix for HeartBleed security issue for ACS 4.2. The systemvm template does have openssl/libssl with fix for HeartBleed securirty hole. But this doesn't come with cloud-scripts.tar correctly built. This bug is blocking us in our attempt replace old systemvm template for ACS 4.2 with security hole. Missing cloud-scripts in systemvm template built from 4.2 branch Key: CLOUDSTACK-6416 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6416 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.2.0 Environment: 4.2 systemvm template Reporter: Sateesh Chodapuneedi Priority: Blocker cloud-scripts.tar is not built properly with scripts. It was filled up with source code of cloudstack project from ACS git repository. While building systemvm template, in postinstall.sh file, cloudstack source would be downloaded from ACS git repository and patching scripts would be bundled as cloud-scripts.tar after extracting cloudstack source tar ball. Untar operation of source tar ball failed with error no space left on device. Build script is not failing at this point but this is resulting in mal-formed cloud-scripts.tar. cloudstack-HEAD-2a02369/awsapi/src/com/amazon/ec2/DescribeConversionTasksType.java tar: /usr/share/cloud/cloud-scripts.tar: Cannot write: No space left on device tar: Error is not recoverable: exiting now ++ cd /opt ++ rm -fr /opt/cloudstack-HEAD-2a02369 /opt/cloudstack.tar.gz cloudstack.tar.gz ++ chkconfig --add cloud-early-config cloud-early-config: unknown service ++ chkconfig cloud-early-config on cloud-early-config: unknown service ++ chkconfig --add cloud-passwd-srvr cloud-passwd-srvr: unknown service ++ chkconfig cloud-passwd-srvr off cloud-passwd-srvr: unknown service ++ chkconfig --add cloud cloud: unknown service ++ chkconfig cloud off cloud: unknown service Downloaded system vm template generated by jenkins from http://jenkins.buildacloud.org/view/4.2/job/build-systemvm-4.2/ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6417) Adding the KVM host to management server is failing
manasaveloori created CLOUDSTACK-6417: - Summary: Adding the KVM host to management server is failing Key: CLOUDSTACK-6417 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6417 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup, Management Server Affects Versions: 4.4.0 Reporter: manasaveloori Priority: Blocker Fix For: 4.4.0 Updated java version to 1.7 in both MS and KVM host before installing the CS packages. When KVM agent is installed ,the agent package is installing java 1.6 Installing : 1:java-1.6.0-openjdk-1.6.0.0-1.45.1.11.1.el6.x86_64 Now java -verison was pointing to 1.6 Adding the host to CS is failing with following exception: 2014-04-15 06:33:43,505 DEBUG [c.c.h.k.d.LibvirtServerDiscoverer] (catalina-exec-25:ctx-cace7f62 ctx-dbfc6bb9) Timeout, to wait for the host connecting to mgt svr, assuming it is failed 2014-04-15 06:33:43,511 WARN [c.c.r.ResourceManagerImpl] (catalina-exec-25:ctx-cace7f62 ctx-dbfc6bb9) Unable to find the server resources at http://10.147.40.29 2014-04-15 06:33:43,513 INFO [c.c.u.e.CSExceptionErrorCode] (catalina-exec-25:ctx-cace7f62 ctx-dbfc6bb9) Could not find exception: com.cloud.exception.DiscoveryException in error code list for exceptions 2014-04-15 06:33:43,514 WARN [o.a.c.a.c.a.h.AddHostCmd] (catalina-exec-25:ctx-cace7f62 ctx-dbfc6bb9) Exception: com.cloud.exception.DiscoveryException: Unable to add the host at com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:791) at com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586) 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.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.$Proxy145.discoverHosts(Unknown Source) at org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:134) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:593) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:416) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330) at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) 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 com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115) at com.cloud.api.ApiServlet.doPost(ApiServlet.java:82) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) 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
[jira] [Updated] (CLOUDSTACK-6417) Adding the KVM host to management server is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] manasaveloori updated CLOUDSTACK-6417: -- Attachment: management-server.rar Adding the KVM host to management server is failing --- Key: CLOUDSTACK-6417 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6417 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Management Server Affects Versions: 4.4.0 Reporter: manasaveloori Priority: Blocker Fix For: 4.4.0 Attachments: management-server.rar Updated java version to 1.7 in both MS and KVM host before installing the CS packages. When KVM agent is installed ,the agent package is installing java 1.6 Installing : 1:java-1.6.0-openjdk-1.6.0.0-1.45.1.11.1.el6.x86_64 Now java -verison was pointing to 1.6 Adding the host to CS is failing with following exception: 2014-04-15 06:33:43,505 DEBUG [c.c.h.k.d.LibvirtServerDiscoverer] (catalina-exec-25:ctx-cace7f62 ctx-dbfc6bb9) Timeout, to wait for the host connecting to mgt svr, assuming it is failed 2014-04-15 06:33:43,511 WARN [c.c.r.ResourceManagerImpl] (catalina-exec-25:ctx-cace7f62 ctx-dbfc6bb9) Unable to find the server resources at http://10.147.40.29 2014-04-15 06:33:43,513 INFO [c.c.u.e.CSExceptionErrorCode] (catalina-exec-25:ctx-cace7f62 ctx-dbfc6bb9) Could not find exception: com.cloud.exception.DiscoveryException in error code list for exceptions 2014-04-15 06:33:43,514 WARN [o.a.c.a.c.a.h.AddHostCmd] (catalina-exec-25:ctx-cace7f62 ctx-dbfc6bb9) Exception: com.cloud.exception.DiscoveryException: Unable to add the host at com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:791) at com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586) 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.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.$Proxy145.discoverHosts(Unknown Source) at org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:134) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:593) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:416) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330) at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) 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 com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115) at com.cloud.api.ApiServlet.doPost(ApiServlet.java:82) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) 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)
[jira] [Commented] (CLOUDSTACK-6417) Adding the KVM host to management server is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969479#comment-13969479 ] manasaveloori commented on CLOUDSTACK-6417: --- followed http://www.pythian.com/blog/how-to-update-jdk-on-oracle-enterprise-linux/ steps to update the java version to 1.7. [root@Rack1Pod1Host29 ~]# java -version java version 1.7.0_51 Java(TM) SE Runtime Environment (build 1.7.0_51-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) After updating the java version installed both MS and KVM agent. MS working fine but KVM host addition is failing with timeout in connecting to MS. Adding the KVM host to management server is failing --- Key: CLOUDSTACK-6417 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6417 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Management Server Affects Versions: 4.4.0 Reporter: manasaveloori Priority: Blocker Fix For: 4.4.0 Attachments: management-server.rar Updated java version to 1.7 in both MS and KVM host before installing the CS packages. When KVM agent is installed ,the agent package is installing java 1.6 Installing : 1:java-1.6.0-openjdk-1.6.0.0-1.45.1.11.1.el6.x86_64 Now java -verison was pointing to 1.6 Adding the host to CS is failing with following exception: 2014-04-15 06:33:43,505 DEBUG [c.c.h.k.d.LibvirtServerDiscoverer] (catalina-exec-25:ctx-cace7f62 ctx-dbfc6bb9) Timeout, to wait for the host connecting to mgt svr, assuming it is failed 2014-04-15 06:33:43,511 WARN [c.c.r.ResourceManagerImpl] (catalina-exec-25:ctx-cace7f62 ctx-dbfc6bb9) Unable to find the server resources at http://10.147.40.29 2014-04-15 06:33:43,513 INFO [c.c.u.e.CSExceptionErrorCode] (catalina-exec-25:ctx-cace7f62 ctx-dbfc6bb9) Could not find exception: com.cloud.exception.DiscoveryException in error code list for exceptions 2014-04-15 06:33:43,514 WARN [o.a.c.a.c.a.h.AddHostCmd] (catalina-exec-25:ctx-cace7f62 ctx-dbfc6bb9) Exception: com.cloud.exception.DiscoveryException: Unable to add the host at com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:791) at com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586) 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.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.$Proxy145.discoverHosts(Unknown Source) at org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:134) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:593) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:416) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330) at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) 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 com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115) at com.cloud.api.ApiServlet.doPost(ApiServlet.java:82) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at
[jira] [Assigned] (CLOUDSTACK-6416) Missing cloud-scripts in systemvm template built from 4.2 branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanteswararao Talluri reassigned CLOUDSTACK-6416: Assignee: Srikanteswararao Talluri Missing cloud-scripts in systemvm template built from 4.2 branch Key: CLOUDSTACK-6416 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6416 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.2.0 Environment: 4.2 systemvm template Reporter: Sateesh Chodapuneedi Assignee: Srikanteswararao Talluri Priority: Blocker cloud-scripts.tar is not built properly with scripts. It was filled up with source code of cloudstack project from ACS git repository. While building systemvm template, in postinstall.sh file, cloudstack source would be downloaded from ACS git repository and patching scripts would be bundled as cloud-scripts.tar after extracting cloudstack source tar ball. Untar operation of source tar ball failed with error no space left on device. Build script is not failing at this point but this is resulting in mal-formed cloud-scripts.tar. cloudstack-HEAD-2a02369/awsapi/src/com/amazon/ec2/DescribeConversionTasksType.java tar: /usr/share/cloud/cloud-scripts.tar: Cannot write: No space left on device tar: Error is not recoverable: exiting now ++ cd /opt ++ rm -fr /opt/cloudstack-HEAD-2a02369 /opt/cloudstack.tar.gz cloudstack.tar.gz ++ chkconfig --add cloud-early-config cloud-early-config: unknown service ++ chkconfig cloud-early-config on cloud-early-config: unknown service ++ chkconfig --add cloud-passwd-srvr cloud-passwd-srvr: unknown service ++ chkconfig cloud-passwd-srvr off cloud-passwd-srvr: unknown service ++ chkconfig --add cloud cloud: unknown service ++ chkconfig cloud off cloud: unknown service Downloaded system vm template generated by jenkins from http://jenkins.buildacloud.org/view/4.2/job/build-systemvm-4.2/ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6418) Passing an integer as domainid to createDomain results in a broken Domain
David Grizzanti created CLOUDSTACK-6418: --- Summary: Passing an integer as domainid to createDomain results in a broken Domain Key: CLOUDSTACK-6418 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6418 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: David Grizzanti It appears that a few API calls allow you to pass in a UUID when creating a resource (i.e. createDomain, createAccount, etc). However, if you pass an integer as the UUID the resource will get created, but you can never list that resource after creating it. In fact, you can't do anything on that resource because cloudstack doesn't seem to be able to find it again. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6416) Missing cloud-scripts in systemvm template built from 4.2 branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969593#comment-13969593 ] Srikanteswararao Talluri commented on CLOUDSTACK-6416: -- There is a problem with tools/appliance/definitions/systemvmtemplate64/postinstall.sh which gets cloudstack.tar.gz as below snapshot_url=https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=snapshot;h=HEAD;sf=tgz which fetches latest master. However, 4.2 branch has a different directory structure than master branch. Hence, postinstall.sh script is failing to include scripts in cloud-scripts.tar This issue can be fixed by fetching appropriate branch snapshot rather than from the latest one. snapshot_url=https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=snapshot;h=4.2;sf=tgz Will push this change in a while Missing cloud-scripts in systemvm template built from 4.2 branch Key: CLOUDSTACK-6416 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6416 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.2.0 Environment: 4.2 systemvm template Reporter: Sateesh Chodapuneedi Assignee: Srikanteswararao Talluri Priority: Blocker cloud-scripts.tar is not built properly with scripts. It was filled up with source code of cloudstack project from ACS git repository. While building systemvm template, in postinstall.sh file, cloudstack source would be downloaded from ACS git repository and patching scripts would be bundled as cloud-scripts.tar after extracting cloudstack source tar ball. Untar operation of source tar ball failed with error no space left on device. Build script is not failing at this point but this is resulting in mal-formed cloud-scripts.tar. cloudstack-HEAD-2a02369/awsapi/src/com/amazon/ec2/DescribeConversionTasksType.java tar: /usr/share/cloud/cloud-scripts.tar: Cannot write: No space left on device tar: Error is not recoverable: exiting now ++ cd /opt ++ rm -fr /opt/cloudstack-HEAD-2a02369 /opt/cloudstack.tar.gz cloudstack.tar.gz ++ chkconfig --add cloud-early-config cloud-early-config: unknown service ++ chkconfig cloud-early-config on cloud-early-config: unknown service ++ chkconfig --add cloud-passwd-srvr cloud-passwd-srvr: unknown service ++ chkconfig cloud-passwd-srvr off cloud-passwd-srvr: unknown service ++ chkconfig --add cloud cloud: unknown service ++ chkconfig cloud off cloud: unknown service Downloaded system vm template generated by jenkins from http://jenkins.buildacloud.org/view/4.2/job/build-systemvm-4.2/ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6416) Missing cloud-scripts in systemvm template built from 4.2 branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969597#comment-13969597 ] ASF subversion and git services commented on CLOUDSTACK-6416: - Commit d6d5ca0ef7dc10d25d8c6c5312232caf06895d47 in cloudstack's branch refs/heads/4.2 from SrikanteswaraRao Talluri [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d6d5ca0 ] CLOUDSTACK-6416: fixed postinstall.sh script to fetch cloudstack snapshot from appropriate branch. Missing cloud-scripts in systemvm template built from 4.2 branch Key: CLOUDSTACK-6416 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6416 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.2.0 Environment: 4.2 systemvm template Reporter: Sateesh Chodapuneedi Assignee: Srikanteswararao Talluri Priority: Blocker cloud-scripts.tar is not built properly with scripts. It was filled up with source code of cloudstack project from ACS git repository. While building systemvm template, in postinstall.sh file, cloudstack source would be downloaded from ACS git repository and patching scripts would be bundled as cloud-scripts.tar after extracting cloudstack source tar ball. Untar operation of source tar ball failed with error no space left on device. Build script is not failing at this point but this is resulting in mal-formed cloud-scripts.tar. cloudstack-HEAD-2a02369/awsapi/src/com/amazon/ec2/DescribeConversionTasksType.java tar: /usr/share/cloud/cloud-scripts.tar: Cannot write: No space left on device tar: Error is not recoverable: exiting now ++ cd /opt ++ rm -fr /opt/cloudstack-HEAD-2a02369 /opt/cloudstack.tar.gz cloudstack.tar.gz ++ chkconfig --add cloud-early-config cloud-early-config: unknown service ++ chkconfig cloud-early-config on cloud-early-config: unknown service ++ chkconfig --add cloud-passwd-srvr cloud-passwd-srvr: unknown service ++ chkconfig cloud-passwd-srvr off cloud-passwd-srvr: unknown service ++ chkconfig --add cloud cloud: unknown service ++ chkconfig cloud off cloud: unknown service Downloaded system vm template generated by jenkins from http://jenkins.buildacloud.org/view/4.2/job/build-systemvm-4.2/ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CLOUDSTACK-6416) Missing cloud-scripts in systemvm template built from 4.2 branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13969593#comment-13969593 ] Srikanteswararao Talluri edited comment on CLOUDSTACK-6416 at 4/15/14 2:58 PM: --- There is a problem with tools/appliance/definitions/systemvmtemplate64/postinstall.sh which gets cloudstack.tar.gz as below snapshot_url=https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=snapshot;h=HEAD;sf=tgz which fetches latest master. However, 4.2 branch has a different directory structure than master branch. Hence, postinstall.sh script is failing to include scripts in cloud-scripts.tar In 4.2: systemvm files are placed under patches folder cd patches/systemvm/debian/config Srikanteswararaos-MacBook-Air:config talluri$ ls etc opt rootvar In master: systemvm files are directly placed under root cd systemvm/patches/debian/config Srikanteswararaos-MacBook-Air:config talluri$ ls etc opt rootvar This issue can be fixed by fetching appropriate branch snapshot rather than from the latest one. snapshot_url=https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=snapshot;h=4.2;sf=tgz was (Author: talluri): There is a problem with tools/appliance/definitions/systemvmtemplate64/postinstall.sh which gets cloudstack.tar.gz as below snapshot_url=https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=snapshot;h=HEAD;sf=tgz which fetches latest master. However, 4.2 branch has a different directory structure than master branch. Hence, postinstall.sh script is failing to include scripts in cloud-scripts.tar This issue can be fixed by fetching appropriate branch snapshot rather than from the latest one. snapshot_url=https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=snapshot;h=4.2;sf=tgz Will push this change in a while Missing cloud-scripts in systemvm template built from 4.2 branch Key: CLOUDSTACK-6416 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6416 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.2.0 Environment: 4.2 systemvm template Reporter: Sateesh Chodapuneedi Assignee: Srikanteswararao Talluri Priority: Blocker cloud-scripts.tar is not built properly with scripts. It was filled up with source code of cloudstack project from ACS git repository. While building systemvm template, in postinstall.sh file, cloudstack source would be downloaded from ACS git repository and patching scripts would be bundled as cloud-scripts.tar after extracting cloudstack source tar ball. Untar operation of source tar ball failed with error no space left on device. Build script is not failing at this point but this is resulting in mal-formed cloud-scripts.tar. cloudstack-HEAD-2a02369/awsapi/src/com/amazon/ec2/DescribeConversionTasksType.java tar: /usr/share/cloud/cloud-scripts.tar: Cannot write: No space left on device tar: Error is not recoverable: exiting now ++ cd /opt ++ rm -fr /opt/cloudstack-HEAD-2a02369 /opt/cloudstack.tar.gz cloudstack.tar.gz ++ chkconfig --add cloud-early-config cloud-early-config: unknown service ++ chkconfig cloud-early-config on cloud-early-config: unknown service ++ chkconfig --add cloud-passwd-srvr cloud-passwd-srvr: unknown service ++ chkconfig cloud-passwd-srvr off cloud-passwd-srvr: unknown service ++ chkconfig --add cloud cloud: unknown service ++ chkconfig cloud off cloud: unknown service Downloaded system vm template generated by jenkins from http://jenkins.buildacloud.org/view/4.2/job/build-systemvm-4.2/ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6416) Missing cloud-scripts in systemvm template built from 4.2 branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanteswararao Talluri resolved CLOUDSTACK-6416. -- Resolution: Fixed Missing cloud-scripts in systemvm template built from 4.2 branch Key: CLOUDSTACK-6416 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6416 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.2.0 Environment: 4.2 systemvm template Reporter: Sateesh Chodapuneedi Assignee: Srikanteswararao Talluri Priority: Blocker cloud-scripts.tar is not built properly with scripts. It was filled up with source code of cloudstack project from ACS git repository. While building systemvm template, in postinstall.sh file, cloudstack source would be downloaded from ACS git repository and patching scripts would be bundled as cloud-scripts.tar after extracting cloudstack source tar ball. Untar operation of source tar ball failed with error no space left on device. Build script is not failing at this point but this is resulting in mal-formed cloud-scripts.tar. cloudstack-HEAD-2a02369/awsapi/src/com/amazon/ec2/DescribeConversionTasksType.java tar: /usr/share/cloud/cloud-scripts.tar: Cannot write: No space left on device tar: Error is not recoverable: exiting now ++ cd /opt ++ rm -fr /opt/cloudstack-HEAD-2a02369 /opt/cloudstack.tar.gz cloudstack.tar.gz ++ chkconfig --add cloud-early-config cloud-early-config: unknown service ++ chkconfig cloud-early-config on cloud-early-config: unknown service ++ chkconfig --add cloud-passwd-srvr cloud-passwd-srvr: unknown service ++ chkconfig cloud-passwd-srvr off cloud-passwd-srvr: unknown service ++ chkconfig --add cloud cloud: unknown service ++ chkconfig cloud off cloud: unknown service Downloaded system vm template generated by jenkins from http://jenkins.buildacloud.org/view/4.2/job/build-systemvm-4.2/ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6419) Develop an OCCI interface
sebastien goasguen created CLOUDSTACK-6419: -- Summary: Develop an OCCI interface Key: CLOUDSTACK-6419 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6419 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: sebastien goasguen OCCI is a standard for cloud computing from the Open Grid Forum (OGF). Here is the background blog: http://buildacloud.org/blog/296-occi-interface-to-cloudstack.html Which was done with early work at: https://github.com/isaacchiang/rOCCI-server this was submitted as a pull request to: https://github.com/gwdg/rOCCI-server/pull/72 Since then the rOCCI-server has been re-architected and the OCCI driver for cloudstack needs to be refactored. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6384) [Marvin]: Base.py and Service class changes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla updated CLOUDSTACK-6384: Description: 1. Currently, the way base.py has been used especially with related to passing and using services dictiionary is far confusing. 2. Any change we do to services dictionary and its structure effects base.py functionality, ideally it should abstract the base.py interfaces from internal data structures usage. 3. We are not sure as which elements in services dictionary are mandatory and which are not. This we can make sure to mention and use base.py classes to have these parameters defined. 4. Writing test code in an easier fashion. We can make the base.py classes accept default keyword values defined from test_data, or services so that tests can start using them in tests with out worrying much with creating, listing, using etc. EX: We will just say Network_obj.create(), rather passing complete argument list at times, if we can define keyword and mandatory arguments defined with initial default values to these apis, then that should be good. 5. This makes test writing cleaner and simpler. Lot places, we play around and shuffle with services dictionary which is unwarranted. was: 1. Currently, the way base.py has been used especially with related to passing and using services dictiionary is far confusing. 2. Any change we do to services dictionary and its structure effects base.py functionality, ideally it should abstract the base.py interfaces from internal data structures usage. 3. We are not sure as which elements in services dictionary are mandatory and which are not. This we can make sure to mention and use base.py classes to have these parameters defined. 4. We can make the classes accept default keyword values defined from test_data, or services so that people can start using them in tests with out worrying much with creating, listing, using etc. EX: We will just say Network_obj.create(), rather passing complete argument list at times, if we can define keyword and mandatory arguments defined with initial default values to these apis, then that should be good. 5. This makes test writing cleaner and simpler. Lot places, we play around and shuffle with services dictionary which is little redundant. [Marvin]: Base.py and Service class changes --- Key: CLOUDSTACK-6384 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6384 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Reporter: Santhosh Kumar Edukulla 1. Currently, the way base.py has been used especially with related to passing and using services dictiionary is far confusing. 2. Any change we do to services dictionary and its structure effects base.py functionality, ideally it should abstract the base.py interfaces from internal data structures usage. 3. We are not sure as which elements in services dictionary are mandatory and which are not. This we can make sure to mention and use base.py classes to have these parameters defined. 4. Writing test code in an easier fashion. We can make the base.py classes accept default keyword values defined from test_data, or services so that tests can start using them in tests with out worrying much with creating, listing, using etc. EX: We will just say Network_obj.create(), rather passing complete argument list at times, if we can define keyword and mandatory arguments defined with initial default values to these apis, then that should be good. 5. This makes test writing cleaner and simpler. Lot places, we play around and shuffle with services dictionary which is unwarranted. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6420) Network implement: use network stateMachine instead of explicitly setting the state on network object
Alena Prokharchyk created CLOUDSTACK-6420:
-
Summary: Network implement: use network stateMachine instead of
explicitly setting the state on network object
Key: CLOUDSTACK-6420
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6420
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.4.0
Reporter: Alena Prokharchyk
Assignee: Murali Reddy
Fix For: 4.5.0
In NetworkOrchestrator, implementNetwork code, some places use state machine
when update the network's state, some just update the network directly. Have to
eliminate the latest, and use state machine everywhere.
if (isSharedNetworkWithServices(network)) {
network.setState(Network.State.Implementing);
} else {
stateTransitTo(network, Event.ImplementNetwork);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6420) Network implement: use network stateMachine instead of explicitly setting the state on network object
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alena Prokharchyk updated CLOUDSTACK-6420:
--
Component/s: Network Controller
Network implement: use network stateMachine instead of explicitly setting the
state on network object
-
Key: CLOUDSTACK-6420
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6420
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.4.0
Reporter: Alena Prokharchyk
Assignee: Murali Reddy
Fix For: 4.5.0
In NetworkOrchestrator, implementNetwork code, some places use state machine
when update the network's state, some just update the network directly. Have
to eliminate the latest, and use state machine everywhere.
if (isSharedNetworkWithServices(network)) {
network.setState(Network.State.Implementing);
} else {
stateTransitTo(network, Event.ImplementNetwork);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-6421) Creating multiple volume snapshots on KVM will eventually fail to back up snapshot.
Nicholas Bedi created CLOUDSTACK-6421: - Summary: Creating multiple volume snapshots on KVM will eventually fail to back up snapshot. Key: CLOUDSTACK-6421 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6421 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM, Snapshot Affects Versions: 4.2.1 Reporter: Nicholas Bedi Priority: Minor On a freshinstall of CentOS 6.3 KVM Volume snapshot backups will fail intermittantly. After setting the agent to log debug messages, we see the managesnapshots.sh script will return with an exit code 0 when called to create a snapshot of a volume. Afterwords, the managesnapshots.sh script fails to backup the snapshot because libvirt reports the snapshot as not existing. When running qemu-img info against the volume, it shows zero snapshots. If you attempt to manually create a snapshot with the managesnapshot.sh command, it succeeds and exits with code 0. Should I file a bug report for this issue and if so, where would I do that?? Thanks, Nick -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6406) system vms failed to come up due to copy_vhd_from_secondarystorage timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Xu resolved CLOUDSTACK-6406. Resolution: Fixed commit 46f6b26d49c39d6ec1c98876799c04d8cd92b46e Author: Anthony Xu anthony...@citrix.com Date: Tue Apr 15 11:26:17 2014 -0700 disable XAPI event system vms failed to come up due to copy_vhd_from_secondarystorage timeout -- Key: CLOUDSTACK-6406 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6406 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 Environment: Latest build from 4.4 with commit098324aa84d3835d2eca24d41f0266128d2d4f29 Hypervisor: XenServer 6.2 Reporter: Sanjeev N Priority: Blocker Labels: xenserver Fix For: 4.4.0 Attachments: SMlog.rar, management-server.rar system vms failed to come up due to copy_vhd_from_secondarystorage Read timeout Steps to reproduce: 1.Install latest 4.4 and create a zone using xenserver 6.2 2.Use NFS storage for both primary and secondary 3.Enable the zone During system vms spin up copying system template from secondary storage to primary storage failed with following error: 2014-04-14 18:05:08,626 DEBUG [c.c.h.x.r.XenServerConnectionPool] (DirectAgent-7:ctx-e86496e0) XmlRpcException for method: event.from due to org.apache.xmlrpc.XmlRpcException: Failed to create input stream: Read timed out 2014-04-14 18:05:08,626 WARN [c.c.h.x.r.CitrixResourceBase] (DirectAgent-7:ctx-e86496e0) callHostPlugin failed for cmd: copy_vhd_from_secondarystorage with args mountpoint: 10.147.28.7:/export/home/sanjeev/sec_44/template/tmpl/1/1/, sruuid: b7f87163-db1c-7bb4-29dd-2de89b82dea1, namelabel: cloud-f99a0e86-2455-427f-afc4-39167697b312, due to Failed to create input stream: Read timed out org.apache.xmlrpc.XmlRpcException: Failed to create input stream: Read timed out at org.apache.xmlrpc.client.XmlRpcSunHttpTransport.getInputStream(XmlRpcSunHttpTransport.java:99) at org.apache.xmlrpc.client.XmlRpcStreamTransport.sendRequest(XmlRpcStreamTransport.java:152) at org.apache.xmlrpc.client.XmlRpcHttpTransport.sendRequest(XmlRpcHttpTransport.java:143) at org.apache.xmlrpc.client.XmlRpcSunHttpTransport.sendRequest(XmlRpcSunHttpTransport.java:69) at org.apache.xmlrpc.client.XmlRpcClientWorker.execute(XmlRpcClientWorker.java:56) at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:167) at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:137) at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:126) at com.xensource.xenapi.Connection.dispatch(Connection.java:285) at com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:456) at com.xensource.xenapi.Event.properFrom(Event.java:310) at com.cloud.hypervisor.xen.resource.XenServer620Resource.waitForTask(XenServer620Resource.java:125) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.callHostPluginAsync(CitrixResourceBase.java:3558) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copy_vhd_from_secondarystorage(XenServerStorageProcessor.java:826) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copyTemplateToPrimaryStorage(XenServerStorageProcessor.java:962) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:77) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:52) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:542) at com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:60) at com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:92) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) 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)
[jira] [Updated] (CLOUDSTACK-6421) Creating multiple volume snapshots on KVM will eventually fail to back up snapshot.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Bedi updated CLOUDSTACK-6421: -- Attachment: logs.txt Associated logs. Creating multiple volume snapshots on KVM will eventually fail to back up snapshot. --- Key: CLOUDSTACK-6421 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6421 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM, Snapshot Affects Versions: 4.2.1 Reporter: Nicholas Bedi Priority: Minor Attachments: logs.txt On a freshinstall of CentOS 6.3 KVM Volume snapshot backups will fail intermittantly. After setting the agent to log debug messages, we see the managesnapshots.sh script will return with an exit code 0 when called to create a snapshot of a volume. Afterwords, the managesnapshots.sh script fails to backup the snapshot because libvirt reports the snapshot as not existing. When running qemu-img info against the volume, it shows zero snapshots. If you attempt to manually create a snapshot with the managesnapshot.sh command, it succeeds and exits with code 0. Should I file a bug report for this issue and if so, where would I do that?? Thanks, Nick -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6382) System VM's failing to start with XenServer 6.2.5
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Xu reassigned CLOUDSTACK-6382:
--
Assignee: Anthony Xu
System VM's failing to start with XenServer 6.2.5
-
Key: CLOUDSTACK-6382
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6382
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: XenServer
Affects Versions: 4.4.0
Reporter: Sailaja Mada
Assignee: Anthony Xu
Priority: Blocker
Fix For: 4.4.0
Steps:
Build : 4.4
Configure Adv zone with XenServer 6.2.5
Observation:
System VM’s are failing to start with below exception and there are lot of
SR’s that got added to XenServer .
2014-04-10 16:09:42,622 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-4:job-4/job-22 ctx-4609aa64) Seq 1-8947526559678332946:
Executing: { Cmd , MgmtId: 55355881446856, via: 1(cldstk-R720-10), Ver: v1,
Flags: 100011,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/1/,origUrl:http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-xen.vhd.bz2,uuid:dc8561e0-c097-11e3-8b80-32588ba65dc8,id:1,format:VHD,accountId:1,checksum:74b92f031cc5c2089ee89efb81344dcf,hvm:false,displayText:SystemVM
Template
(XenServer),imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.102.192.101/Sailaja/gpuss1,_role:Image}},name:routing-1,hypervisorType:XenServer}},destTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{origUrl:http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-xen.vhd.bz2,uuid:dc8561e0-c097-11e3-8b80-32588ba65dc8,id:1,format:VHD,accountId:1,checksum:74b92f031cc5c2089ee89efb81344dcf,hvm:false,displayText:SystemVM
Template
(XenServer),imageDataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:0a336642-b7d7-3262-ae46-8f06ccdf8c30,id:1,poolType:NetworkFilesystem,host:10.102.192.101,path:/Sailaja/gpups1,port:2049,url:NetworkFilesystem://10.102.192.101/Sailaja/gpups1/?ROLE=PrimarySTOREUUID=0a336642-b7d7-3262-ae46-8f06ccdf8c30}},name:routing-1,hypervisorType:XenServer}},executeInSequence:false,options:{},wait:10800}}]
}
2014-04-10 16:09:42,624 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl]
(Work-Job-Executor-3:job-3/job-21 ctx-2fcd2f5f) template 1 is already in
store:1, type:Primary
2014-04-10 16:09:42,627 DEBUG [o.a.c.s.v.VolumeServiceImpl]
(Work-Job-Executor-3:job-3/job-21 ctx-2fcd2f5f) Found template routing-1 in
storage pool 1 with VMTemplateStoragePool id: 2
2014-04-10 16:09:42,630 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-13:ctx-d982de4d) Seq 1-8947526559678332946: Executing request
2014-04-10 16:09:42,654 DEBUG [o.a.c.s.v.VolumeServiceImpl]
(Work-Job-Executor-3:job-3/job-21 ctx-2fcd2f5f) Acquire lock on
VMTemplateStoragePool 2 with timeout 3600 seconds
2014-04-10 16:09:42,657 DEBUG [c.c.h.x.r.XenServer620Resource]
(DirectAgent-13:ctx-d982de4d) Task is not done uuid:
b27d0997-2490-816a-b762-91cdf1ddc047
nameLabel: Async.host.call_plugin
nameDescription:
allowedOperations: []
currentOperations: {}
created: Thu Apr 10 21:30:06 IST 2014
finished: Thu Jan 01 05:30:00 IST 1970
status: pending
residentOn: com.xensource.xenapi.Host@514ac968
progress: 0.0
type: none/
result:
errorInfo: []
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
2014-04-10 16:09:42,660 DEBUG [c.c.h.x.r.XenServer620Resource]
(DirectAgent-13:ctx-d982de4d) Task is not done uuid:
b27d0997-2490-816a-b762-91cdf1ddc047
nameLabel: Async.host.call_plugin
nameDescription:
allowedOperations: []
currentOperations: {}
created: Thu Apr 10 21:30:06 IST 2014
finished: Thu Jan 01 05:30:00 IST 1970
status: pending
residentOn: com.xensource.xenapi.Host@514ac968
progress: 0.0
type: none/
result:
errorInfo: []
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
2014-04-10 16:09:42,916 DEBUG [c.c.h.x.r.XenServer620Resource]
(DirectAgent-13:ctx-d982de4d) Task is done success
2014-04-10 16:09:43,676 DEBUG [c.c.h.x.r.XenServerStorageProcessor]
(DirectAgent-13:ctx-d982de4d) Failed to destroy pbd
2014-04-10 16:09:42,916 DEBUG [c.c.h.x.r.XenServer620Resource]
(DirectAgent-13:ctx-d982de4d) Task is done success
2014-04-10 16:09:43,676 DEBUG [c.c.h.x.r.XenServerStorageProcessor]
[jira] [Created] (CLOUDSTACK-6422) Deleting and Reverting VM snapshots with simulator throw error
Chris Suich created CLOUDSTACK-6422: --- Summary: Deleting and Reverting VM snapshots with simulator throw error Key: CLOUDSTACK-6422 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6422 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Simulator, Snapshot Affects Versions: 4.4.0 Reporter: Chris Suich Assignee: Chris Suich Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6422) Deleting and Reverting VM snapshots with simulator throw error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Suich closed CLOUDSTACK-6422. --- Deleting and Reverting VM snapshots with simulator throw error -- Key: CLOUDSTACK-6422 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6422 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Simulator, Snapshot Affects Versions: 4.4.0 Reporter: Chris Suich Assignee: Chris Suich Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6422) Deleting and Reverting VM snapshots with simulator throw error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970072#comment-13970072 ] ASF subversion and git services commented on CLOUDSTACK-6422: - Commit 47208dc23d4ee68db758889cd9e60e58aca1b72f in cloudstack's branch refs/heads/4.4 from [~csuich2] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=47208dc ] CLOUDSTACK-6422: Fixed errors with simulator VM snapshot delete and revert Deleting and Reverting VM snapshots with simulator throw error -- Key: CLOUDSTACK-6422 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6422 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Simulator, Snapshot Affects Versions: 4.4.0 Reporter: Chris Suich Assignee: Chris Suich Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6422) Deleting and Reverting VM snapshots with simulator throw error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Suich resolved CLOUDSTACK-6422. - Resolution: Fixed Deleting and Reverting VM snapshots with simulator throw error -- Key: CLOUDSTACK-6422 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6422 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Simulator, Snapshot Affects Versions: 4.4.0 Reporter: Chris Suich Assignee: Chris Suich Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6422) Deleting and Reverting VM snapshots with simulator throw error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970073#comment-13970073 ] ASF subversion and git services commented on CLOUDSTACK-6422: - Commit 6d18654958ef1843de2820e46259e13828b81eb1 in cloudstack's branch refs/heads/master from [~csuich2] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6d18654 ] CLOUDSTACK-6422: Fixed errors with simulator VM snapshot delete and revert Deleting and Reverting VM snapshots with simulator throw error -- Key: CLOUDSTACK-6422 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6422 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Simulator, Snapshot Affects Versions: 4.4.0 Reporter: Chris Suich Assignee: Chris Suich Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6342) [UI] UI changes for feature use secondary IP address of NIC in Load balancing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970094#comment-13970094 ] ASF subversion and git services commented on CLOUDSTACK-6342: - Commit e35bec515fd1aca3e3e6e241c1534b40f890ce44 in cloudstack's branch refs/heads/master from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e35bec5 ] CLOUDSTACK-6342: UI changes for secondary IP on LB rules This is front-end only; API call changes still need to be done. [UI] UI changes for feature use secondary IP address of NIC in Load balancing -- Key: CLOUDSTACK-6342 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6342 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 Attachments: jessica-2014-04-08-listing-VmAndIp-under-each-LB-rule.PNG -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6342) [UI] UI changes for feature use secondary IP address of NIC in Load balancing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970096#comment-13970096 ] ASF subversion and git services commented on CLOUDSTACK-6342: - Commit 3263822bf4e64745681d535d7c1315120ddbbe62 in cloudstack's branch refs/heads/4.4 from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3263822 ] CLOUDSTACK-6342: UI changes for secondary IP on LB rules This is front-end only; API call changes still need to be done. [UI] UI changes for feature use secondary IP address of NIC in Load balancing -- Key: CLOUDSTACK-6342 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6342 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 Attachments: jessica-2014-04-08-listing-VmAndIp-under-each-LB-rule.PNG -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6406) system vms failed to come up due to copy_vhd_from_secondarystorage timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N closed CLOUDSTACK-6406. - Verified with the latest build from 4.4 with commit 80d82106dcc701e9569dde16161b24ff3abfa67f. Works fine. Now with the fix system vms spin up successfully. system vms failed to come up due to copy_vhd_from_secondarystorage timeout -- Key: CLOUDSTACK-6406 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6406 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 Environment: Latest build from 4.4 with commit098324aa84d3835d2eca24d41f0266128d2d4f29 Hypervisor: XenServer 6.2 Reporter: Sanjeev N Priority: Blocker Labels: xenserver Fix For: 4.4.0 Attachments: SMlog.rar, management-server.rar system vms failed to come up due to copy_vhd_from_secondarystorage Read timeout Steps to reproduce: 1.Install latest 4.4 and create a zone using xenserver 6.2 2.Use NFS storage for both primary and secondary 3.Enable the zone During system vms spin up copying system template from secondary storage to primary storage failed with following error: 2014-04-14 18:05:08,626 DEBUG [c.c.h.x.r.XenServerConnectionPool] (DirectAgent-7:ctx-e86496e0) XmlRpcException for method: event.from due to org.apache.xmlrpc.XmlRpcException: Failed to create input stream: Read timed out 2014-04-14 18:05:08,626 WARN [c.c.h.x.r.CitrixResourceBase] (DirectAgent-7:ctx-e86496e0) callHostPlugin failed for cmd: copy_vhd_from_secondarystorage with args mountpoint: 10.147.28.7:/export/home/sanjeev/sec_44/template/tmpl/1/1/, sruuid: b7f87163-db1c-7bb4-29dd-2de89b82dea1, namelabel: cloud-f99a0e86-2455-427f-afc4-39167697b312, due to Failed to create input stream: Read timed out org.apache.xmlrpc.XmlRpcException: Failed to create input stream: Read timed out at org.apache.xmlrpc.client.XmlRpcSunHttpTransport.getInputStream(XmlRpcSunHttpTransport.java:99) at org.apache.xmlrpc.client.XmlRpcStreamTransport.sendRequest(XmlRpcStreamTransport.java:152) at org.apache.xmlrpc.client.XmlRpcHttpTransport.sendRequest(XmlRpcHttpTransport.java:143) at org.apache.xmlrpc.client.XmlRpcSunHttpTransport.sendRequest(XmlRpcSunHttpTransport.java:69) at org.apache.xmlrpc.client.XmlRpcClientWorker.execute(XmlRpcClientWorker.java:56) at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:167) at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:137) at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:126) at com.xensource.xenapi.Connection.dispatch(Connection.java:285) at com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:456) at com.xensource.xenapi.Event.properFrom(Event.java:310) at com.cloud.hypervisor.xen.resource.XenServer620Resource.waitForTask(XenServer620Resource.java:125) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.callHostPluginAsync(CitrixResourceBase.java:3558) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copy_vhd_from_secondarystorage(XenServerStorageProcessor.java:826) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copyTemplateToPrimaryStorage(XenServerStorageProcessor.java:962) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:77) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:52) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:542) at com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:60) at com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:92) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) 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
[jira] [Commented] (CLOUDSTACK-6317) [VMware] Tagged VLAN support broken for Management/Control/Storage traffic
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970179#comment-13970179
]
Ram Ganesh commented on CLOUDSTACK-6317:
Sateesh is testing the fix. Should have an update in another couple of days.
[VMware] Tagged VLAN support broken for Management/Control/Storage traffic
--
Key: CLOUDSTACK-6317
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6317
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.4.0
Environment: VMware vCenter 5.1, ESXi 5.0 hosts
MS with ACS 4.3.0
Reporter: Sateesh Chodapuneedi
Assignee: Sateesh Chodapuneedi
Priority: Critical
Fix For: 4.4.0, 4.3.1
Prior to ACS 4.3.0 CloudStack used to support tagged VLAN for management /
storage / control traffic via traffic label, where admin would specify the
VLAN in comma separated string of vmware network traffic label. E.g.
vSwitch0,100 - This means management traffic would use standard vSwitch port
group tagged with VLAN 100 which sits on vSwitch0 existing on ESXi host.
This is functionality was broken since below commit in ACS 4.3 branch,
Commit 7c4831df9292115466fb9e01fcba952a5dad31c1 in branch refs/heads/4.3 from
Hugo Trippaers
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7c4831d ]
This commit overwrites the parsed vSwitch name, from traffic label, with
traffic label specified by admin resulting into below error during deployment
of SSVM (or any VM that needs management/storage traffic)
2014-04-01 08:23:19,866 DEBUG [c.c.h.v.r.VmwareResource]
(DirectAgent-9:ctx-862d86ff 10.102.192.3) VM v-2-VM will be started with NIC
device type: E1000
2014-04-01 08:23:19,866 INFO [c.c.h.v.r.VmwareResource]
(DirectAgent-9:ctx-862d86ff 10.102.192.3) Prepare NIC device based on NicTO:
{deviceId:0,networkRateMbps:-1,defaultNic:false,uuid:07c38800-6da3-4596-b0ea-09047d45970e,mac:02:00:63:46:00:02,broadcastType:LinkLocal,type:Control,isSecurityGroupEnabled:false,name:vSwitch0,100}
2014-04-01 08:23:21,150 ERROR [c.c.h.v.m.HypervisorHostHelper]
(DirectAgent-6:ctx-a6062e05 10.102.192.3) Unable to find vSwitchvSwitch0,100
2014-04-01 08:23:21,151 WARN [c.c.h.v.r.VmwareResource]
(DirectAgent-6:ctx-a6062e05 10.102.192.3) StartCommand failed due to
Exception: java.lang.Exception
Message: Unable to find vSwitchvSwitch0,100
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Issue Comment Deleted] (CLOUDSTACK-5785) VM display name cell not updated upon detaching volume from VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski updated CLOUDSTACK-5785: --- Comment: was deleted (was: How's the new job, Chris? What state are you located in? I just saw David La Motta this past week at CCC in Denver. He came to my presentation and I came to his. On Fri, Apr 11, 2014 at 12:56 AM, Mike Tutkowski -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloudhttp://solidfire.com/solution/overview/?video=play *(tm)* ) VM display name cell not updated upon detaching volume from VM -- Key: CLOUDSTACK-5785 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5785 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: Mac OS X 10.8.3 Chrome 31.0.1650.63 Reporter: Mike Tutkowski Assignee: Mike Tutkowski Fix For: 4.4.0 Attachments: Detach Volume.png In the Storage tab of the GUI, I detached a volume from a VM. The process was successful; however, the GUI did not update properly. After the detach has completed, the VM display name cell in the appropriate row should be empty, but I noticed it still contained the name of the VM the volume was attached to. I have included a screen shot. One point of note is that the GUI seems to update just fine when attaching a volume to a VM. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Issue Comment Deleted] (CLOUDSTACK-5785) VM display name cell not updated upon detaching volume from VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski updated CLOUDSTACK-5785: --- Comment: was deleted (was: I just tested it - looks good! Thanks) VM display name cell not updated upon detaching volume from VM -- Key: CLOUDSTACK-5785 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5785 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: Mac OS X 10.8.3 Chrome 31.0.1650.63 Reporter: Mike Tutkowski Assignee: Mike Tutkowski Fix For: 4.4.0 Attachments: Detach Volume.png In the Storage tab of the GUI, I detached a volume from a VM. The process was successful; however, the GUI did not update properly. After the detach has completed, the VM display name cell in the appropriate row should be empty, but I noticed it still contained the name of the VM the volume was attached to. I have included a screen shot. One point of note is that the GUI seems to update just fine when attaching a volume to a VM. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5785) VM display name cell not updated upon detaching volume from VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970200#comment-13970200 ] Mike Tutkowski commented on CLOUDSTACK-5785: I just tested it - looks good! Thanks VM display name cell not updated upon detaching volume from VM -- Key: CLOUDSTACK-5785 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5785 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: Mac OS X 10.8.3 Chrome 31.0.1650.63 Reporter: Mike Tutkowski Assignee: Mike Tutkowski Fix For: 4.4.0 Attachments: Detach Volume.png In the Storage tab of the GUI, I detached a volume from a VM. The process was successful; however, the GUI did not update properly. After the detach has completed, the VM display name cell in the appropriate row should be empty, but I noticed it still contained the name of the VM the volume was attached to. I have included a screen shot. One point of note is that the GUI seems to update just fine when attaching a volume to a VM. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-5785) VM display name cell not updated upon detaching volume from VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski resolved CLOUDSTACK-5785. Resolution: Fixed I just tested it - looks good. Thanks! VM display name cell not updated upon detaching volume from VM -- Key: CLOUDSTACK-5785 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5785 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: Mac OS X 10.8.3 Chrome 31.0.1650.63 Reporter: Mike Tutkowski Assignee: Mike Tutkowski Fix For: 4.4.0 Attachments: Detach Volume.png In the Storage tab of the GUI, I detached a volume from a VM. The process was successful; however, the GUI did not update properly. After the detach has completed, the VM display name cell in the appropriate row should be empty, but I noticed it still contained the name of the VM the volume was attached to. I have included a screen shot. One point of note is that the GUI seems to update just fine when attaching a volume to a VM. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-5785) VM display name cell not updated upon detaching volume from VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski closed CLOUDSTACK-5785. -- VM display name cell not updated upon detaching volume from VM -- Key: CLOUDSTACK-5785 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5785 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: Mac OS X 10.8.3 Chrome 31.0.1650.63 Reporter: Mike Tutkowski Assignee: Mike Tutkowski Fix For: 4.4.0 Attachments: Detach Volume.png In the Storage tab of the GUI, I detached a volume from a VM. The process was successful; however, the GUI did not update properly. After the detach has completed, the VM display name cell in the appropriate row should be empty, but I noticed it still contained the name of the VM the volume was attached to. I have included a screen shot. One point of note is that the GUI seems to update just fine when attaching a volume to a VM. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6416) Missing cloud-scripts in systemvm template built from 4.2 branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970221#comment-13970221 ] ASF subversion and git services commented on CLOUDSTACK-6416: - Commit 0610dbf803d1b1dc37b41b3a6319cfcd94cf6bbe in cloudstack's branch refs/heads/4.2 from rayeesn [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0610dbf ] Fixed provided for CLOUDSTACK-6416 need to be ported for 32 bit template also Missing cloud-scripts in systemvm template built from 4.2 branch Key: CLOUDSTACK-6416 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6416 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.2.0 Environment: 4.2 systemvm template Reporter: Sateesh Chodapuneedi Assignee: Srikanteswararao Talluri Priority: Blocker cloud-scripts.tar is not built properly with scripts. It was filled up with source code of cloudstack project from ACS git repository. While building systemvm template, in postinstall.sh file, cloudstack source would be downloaded from ACS git repository and patching scripts would be bundled as cloud-scripts.tar after extracting cloudstack source tar ball. Untar operation of source tar ball failed with error no space left on device. Build script is not failing at this point but this is resulting in mal-formed cloud-scripts.tar. cloudstack-HEAD-2a02369/awsapi/src/com/amazon/ec2/DescribeConversionTasksType.java tar: /usr/share/cloud/cloud-scripts.tar: Cannot write: No space left on device tar: Error is not recoverable: exiting now ++ cd /opt ++ rm -fr /opt/cloudstack-HEAD-2a02369 /opt/cloudstack.tar.gz cloudstack.tar.gz ++ chkconfig --add cloud-early-config cloud-early-config: unknown service ++ chkconfig cloud-early-config on cloud-early-config: unknown service ++ chkconfig --add cloud-passwd-srvr cloud-passwd-srvr: unknown service ++ chkconfig cloud-passwd-srvr off cloud-passwd-srvr: unknown service ++ chkconfig --add cloud cloud: unknown service ++ chkconfig cloud off cloud: unknown service Downloaded system vm template generated by jenkins from http://jenkins.buildacloud.org/view/4.2/job/build-systemvm-4.2/ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6349) IAM - No error message presented to the user , when invalid password is provided.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970258#comment-13970258 ] ASF subversion and git services commented on CLOUDSTACK-6349: - Commit 2cf4db5359fa6741beb7eed4a8b33b351a9a4634 in cloudstack's branch refs/heads/4.4 from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2cf4db5 ] CLOUDSTACK-6349: IAM - No error message presented to the user , when invalid password is provided. - AccountManager now works using accountId instead of accountType IAM - No error message presented to the user , when invalid password is provided. - Key: CLOUDSTACK-6349 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6349 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 Environment: Build from 4.4. Reporter: Sangeetha Hariharan Assignee: Prachi Damle Priority: Critical Fix For: 4.4.0 Try to log in as regular user , by providing invalid username/password. User is not presented with any error message: apilog.log: 2014-04-07 10:51:15,849 INFO [a.c.c.a.ApiServer] (catalina-exec-6:ctx-5511ac44) 10.215.3.0 -- POST command=login domain=/ unknown exception writing api response Management server log: 2014-04-07 10:47:28,001 DEBUG [c.c.a.ApiServlet] (catalina-exec-3:ctx-845578ba) ===START=== 10.215.3.0 -- POST 2014-04-07 10:47:28,003 DEBUG [c.c.u.AccountManagerImpl] (catalina-exec-3:ctx-845578ba) Attempting to log in user: test in domain 1 2014-04-07 10:47:28,003 DEBUG [c.c.s.a.SHA256SaltedUserAuthenticator] (catalina-exec-3:ctx-845578ba) Retrieving user: test 2014-04-07 10:47:28,005 DEBUG [c.c.s.a.MD5UserAuthenticator] (catalina-exec-3:ctx-845578ba) Retrieving user: test 2014-04-07 10:47:28,009 DEBUG [c.c.s.a.MD5UserAuthenticator] (catalina-exec-3:ctx-845578ba) Password does not match 2014-04-07 10:47:28,012 DEBUG [c.c.s.a.PlainTextUserAuthenticator] (catalina-exec-3:ctx-845578ba) Retrieving user: test 2014-04-07 10:47:28,016 DEBUG [c.c.s.a.PlainTextUserAuthenticator] (catalina-exec-3:ctx-845578ba) Password does not match 2014-04-07 10:47:28,016 DEBUG [c.c.u.AccountManagerImpl] (catalina-exec-3:ctx-845578ba) Unable to authenticate user with username test in domain 1 2014-04-07 10:47:28,019 ERROR [c.c.a.ApiServlet] (catalina-exec-3:ctx-845578ba) unknown exception writing api response com.cloud.exception.InvalidParameterValueException: Caller cannot be passed as NULL to IAM! at org.apache.cloudstack.iam.RoleBasedEntityAccessChecker.checkAccess(RoleBasedEntityAccessChecker.java:67) at com.cloud.user.AccountManagerImpl.isRootAdmin(AccountManagerImpl.java:371) at com.cloud.user.AccountManagerImpl.isInternalAccount(AccountManagerImpl.java:420) at com.cloud.user.AccountManagerImpl.getUserAccount(AccountManagerImpl.java:2045) at com.cloud.user.AccountManagerImpl.authenticateUser(AccountManagerImpl.java:1871) 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.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) 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 $Proxy99.authenticateUser(Unknown Source) at com.cloud.api.ApiServer.loginUser(ApiServer.java:850) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:231) at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) 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
[jira] [Created] (CLOUDSTACK-6423) No clusters found having a host with enough capacity
Ameen Ali created CLOUDSTACK-6423:
-
Summary: No clusters found having a host with enough capacity
Key: CLOUDSTACK-6423
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6423
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.2.0, 4.2.1
Environment: Centos 6.5 Master
Reporter: Ameen Ali
Fix For: 4.2.0
I have just installed CloudStack 4.2.1 as management server on my Centos 6.5. I
am having issues with starting the secondary storage VMs. Here are the messages
from the log /var/log/cloudstack/management/management-server.log :
2014-04-16 03:22:00,789 DEBUG
[network.router.VirtualNetworkApplianceManagerImpl]
(RouterStatusMonitor-1:null) Found 0 routers to update status.
2014-04-16 03:22:00,790 DEBUG
[network.router.VirtualNetworkApplianceManagerImpl]
(RouterStatusMonitor-1:null) Found 0 networks to update RvR status.
2014-04-16 03:22:06,032 DEBUG [host.dao.HostDaoImpl] (ClusteredAgentManager
Timer:null) Resetting hosts suitable for reconnect
2014-04-16 03:22:06,035 DEBUG [host.dao.HostDaoImpl] (ClusteredAgentManager
Timer:null) Completed resetting hosts suitable for reconnect
2014-04-16 03:22:06,035 DEBUG [host.dao.HostDaoImpl] (ClusteredAgentManager
Timer:null) Acquiring hosts for clusters already owned by this management server
2014-04-16 03:22:06,038 DEBUG [host.dao.HostDaoImpl] (ClusteredAgentManager
Timer:null) Completed acquiring hosts for clusters already owned by this
management server
2014-04-16 03:22:06,038 DEBUG [host.dao.HostDaoImpl] (ClusteredAgentManager
Timer:null) Acquiring hosts for clusters not owned by any management server
2014-04-16 03:22:06,039 DEBUG [host.dao.HostDaoImpl] (ClusteredAgentManager
Timer:null) Completed acquiring hosts for clusters not owned by any management
server
2014-04-16 03:22:08,039 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-27:null) Ping from 1
2014-04-16 03:22:09,155 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-16:null) Seq 1-2066939909: Executing request
2014-04-16 03:22:09,434 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-16:null) Seq 1-2066939909: Response Received:
2014-04-16 03:22:09,435 DEBUG [agent.transport.Request] (DirectAgent-16:null)
Seq 1-2066939909: Processing: { Ans: , MgmtId: 52240630156, via: 1, Ver: v1,
Flags: 10,
[{com.cloud.agent.api.ClusterSyncAnswer:{_clusterId:1,_newStates:{},_isExecuted:false,result:true,wait:0}}]
}
2014-04-16 03:22:28,685 DEBUG [storage.secondary.SecondaryStorageManagerImpl]
(secstorage-1:null) Zone 1 is ready to launch secondary storage VM
2014-04-16 03:22:28,687 INFO
[cloud.secstorage.PremiumSecondaryStorageManagerImpl] (secstorage-1:null) No
running secondary storage vms found in datacenter id=1, starting one
2014-04-16 03:22:28,690 INFO [storage.secondary.SecondaryStorageManagerImpl]
(secstorage-1:null) No stopped secondary storage vm is available, need to
allocate a new secondary storage vm
2014-04-16 03:22:28,691 DEBUG [storage.secondary.SecondaryStorageManagerImpl]
(secstorage-1:null) Assign secondary storage vm from a newly started instance
for request from data center : 1
2014-04-16 03:22:28,701 DEBUG [cloud.network.NetworkManagerImpl]
(secstorage-1:null) Found existing network configuration for offering [Network
Offering [6-Guest-DefaultSharedNetworkOfferingWithSGService]: Ntwk[204|Guest|6]
2014-04-16 03:22:28,702 DEBUG [cloud.network.NetworkManagerImpl]
(secstorage-1:null) Releasing lock for
Acct[63901c80-b520-11e3-83fd-000c29c8c18c-system]
2014-04-16 03:22:28,704 DEBUG [cloud.network.NetworkManagerImpl]
(secstorage-1:null) Found existing network configuration for offering [Network
Offering [3-Control-System-Control-Network]: Ntwk[202|Control|3]
2014-04-16 03:22:28,704 DEBUG [cloud.network.NetworkManagerImpl]
(secstorage-1:null) Releasing lock for
Acct[63901c80-b520-11e3-83fd-000c29c8c18c-system]
2014-04-16 03:22:28,706 DEBUG [cloud.network.NetworkManagerImpl]
(secstorage-1:null) Found existing network configuration for offering [Network
Offering [2-Management-System-Management-Network]: Ntwk[201|Management|2]
2014-04-16 03:22:28,706 DEBUG [cloud.network.NetworkManagerImpl]
(secstorage-1:null) Releasing lock for
Acct[63901c80-b520-11e3-83fd-000c29c8c18c-system]
2014-04-16 03:22:28,708 DEBUG [cloud.network.NetworkManagerImpl]
(secstorage-1:null) Found existing network configuration for offering [Network
Offering [4-Storage-System-Storage-Network]: Ntwk[203|Storage|4]
2014-04-16 03:22:28,708 DEBUG [cloud.network.NetworkManagerImpl]
(secstorage-1:null) Releasing lock for
Acct[63901c80-b520-11e3-83fd-000c29c8c18c-system]
2014-04-16 03:22:28,716 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(secstorage-1:null) Allocating entries for VM: VM[SecondaryStorageVm|s-316-VM]
[jira] [Updated] (CLOUDSTACK-6385) Can`t update systemvm.iso and authorized_keys on host after upgrade from 4.2 to 4.3
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Artemyev updated CLOUDSTACK-6385: Description: when I upgrade managment the server from 4.2 to 4.3. new ssh key-pair generated and intergate to systemvm.iso, but neither new publickey no systemvm.iso not upload to hypervisor hosts as result upgraded systemvm`s started but down by hypervisor which can`t access to it. clean install of CS not have this problem was: when I upgrade managment the server from 4.2 to 4.3. new ssh key-pair generated and intergate to systemvm.iso, but neither new publickey no systemvm.iso not upload to hypervisor host as result upgraded systemvm started but down by hypervisor which can`t access to it. clean install of CS not have this problem Can`t update systemvm.iso and authorized_keys on host after upgrade from 4.2 to 4.3 --- Key: CLOUDSTACK-6385 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6385 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, SystemVM, XenServer Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.2.0, 4.3.0 Reporter: Andrew Artemyev when I upgrade managment the server from 4.2 to 4.3. new ssh key-pair generated and intergate to systemvm.iso, but neither new publickey no systemvm.iso not upload to hypervisor hosts as result upgraded systemvm`s started but down by hypervisor which can`t access to it. clean install of CS not have this problem -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6420) Network implement: use network stateMachine instead of explicitly setting the state on network object
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Murali Reddy updated CLOUDSTACK-6420:
-
Fix Version/s: (was: 4.5.0)
Future
Network implement: use network stateMachine instead of explicitly setting the
state on network object
-
Key: CLOUDSTACK-6420
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6420
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.4.0
Reporter: Alena Prokharchyk
Assignee: Murali Reddy
Fix For: Future
In NetworkOrchestrator, implementNetwork code, some places use state machine
when update the network's state, some just update the network directly. Have
to eliminate the latest, and use state machine everywhere.
if (isSharedNetworkWithServices(network)) {
network.setState(Network.State.Implementing);
} else {
stateTransitTo(network, Event.ImplementNetwork);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6420) Network implement: use network stateMachine instead of explicitly setting the state on network object
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970463#comment-13970463
]
Murali Reddy commented on CLOUDSTACK-6420:
--
This can be a non-trivial change. Below snip is from dev list.
==
On 15/04/14 3:08 AM, Alena Prokharchyk alena.prokharc...@citrix.com
wrote:
Murali,
I have a question to you. In NetworkOrchestrator, implementNetwork code,
when we update the state for the network, why don¹t we use state machine
for Shared networks, but instead update it directly in the DB?
if (isSharedNetworkWithServices(network)) {
network.setState(Network.State.Implementing);
} else {
stateTransitTo(network, Event.ImplementNetwork);
}
That doesn¹t seem right to me as there should be no exception when it
comes to state update - the state machine should always be used once its
implemented for the object. If your code needs additional state
transitions for the Setup state, why can¹t you add it?
Initially network just had states and states were set explicitly. Actually
I happened to add state changes to explicitly happen through the state
machine for resource state change events for EventBus. But the problem I
had with
shared networks was, it had different life cycle (before cloudstack
supported L4-L7 services in shared networks) and shared network with L4-L7
service has life cycle similar to that of isolated network. For the
network in 'Setup' state, ImplementNetwork event shall succeed only for
shared network with services but should fail for shared network without
L4-L7 services. Similarly an implemented network in 'Implemented' state on
'ShutdownNetwork' event can go to 'Allocated' or 'Setup' state depending
on the network type (isolate/shared). I needed some sort of conditional
state transition in the state machine which is not there.
Due to time constraint I added minimal disruptive changes. Doing it
cleaner way means revamping the network states and transitions to avoid
conflicting transitions. Please do open a bug to fix it.
Network implement: use network stateMachine instead of explicitly setting the
state on network object
-
Key: CLOUDSTACK-6420
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6420
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.4.0
Reporter: Alena Prokharchyk
Assignee: Murali Reddy
Fix For: Future
In NetworkOrchestrator, implementNetwork code, some places use state machine
when update the network's state, some just update the network directly. Have
to eliminate the latest, and use state machine everywhere.
if (isSharedNetworkWithServices(network)) {
network.setState(Network.State.Implementing);
} else {
stateTransitTo(network, Event.ImplementNetwork);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6298) [Windows] If already tmp directory exist inject Keys is failing while starting management server on windows
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970467#comment-13970467 ] ASF subversion and git services commented on CLOUDSTACK-6298: - Commit b814783a636307bf73d359248ce33d541f534fda in cloudstack's branch refs/heads/master from [~damoder.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b814783 ] CLOUDSTACK-6298:[Windows] if already tmp directory exists inject keys is dailing on widows while starting the management server Signed-off-by: Abhinandan Prateek aprat...@apache.org [Windows] If already tmp directory exist inject Keys is failing while starting management server on windows --- Key: CLOUDSTACK-6298 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6298 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: Damodar Reddy T Assignee: Damodar Reddy T Priority: Critical Fix For: Future For any reason if tmp directory is not deleted by previous start of the management server next time when we do a fresh installation of the management server and try to start it then inject keys into systemvm,iso is failing as tmp directory is not able to create by python. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6410) [Windows] Integrate Windows wix tool to maven
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13970466#comment-13970466 ] ASF subversion and git services commented on CLOUDSTACK-6410: - Commit 54d3a3dc90bace7f85172ad8ada693566144d1d7 in cloudstack's branch refs/heads/master from [~damoder.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=54d3a3d ] CLOUDSTACK-6410 : Maven Integration for windows Wix tool to create msi installer thropugh maven build process Signed-off-by: Abhinandan Prateek aprat...@apache.org [Windows] Integrate Windows wix tool to maven - Key: CLOUDSTACK-6410 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6410 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: Future Reporter: Damodar Reddy T Assignee: Damodar Reddy T Fix For: Future Try to integrate Wix tool set with maven build process so that no manual steps are required to create windows msi installer file. -- This message was sent by Atlassian JIRA (v6.2#6252)
