[jira] [Commented] (CLOUDSTACK-9503) The router script times out resulting in failure of deployment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632111#comment-15632111 ] ASF GitHub Bot commented on CLOUDSTACK-9503: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1745 There was an issue with the additionaltests [script](https://github.com/shapeblue/Trillian/blob/master/Ansible/roles/marvin/templates/additionaltests.sh.j2) that caused no outputs in the last comment. I've re-kicked the tests now. > The router script times out resulting in failure of deployment > -- > > Key: CLOUDSTACK-9503 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9503 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.9.0 > Environment: KVM, Xen >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: 4.9.1.0 > > > When starting the virtual router in a shared network in advance zone the > scripts on router time out. This happen as there are several sub-commands > that are consolidated in a single command. The default timeout of 2 minutes > is short. > 2016-09-09 00:06:25,016 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) > (logid:8aedea66) process hasn't exited > 2016-09-09 00:06:25,016 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) > (logid:8aedea66) Command: com.cloud.agent.api.Command failed while starting > virtual router > 2016-09-09 00:06:25,016 INFO [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) > (logid:8aedea66) The guru did not like the answers so stopping > VM[DomainRouter|r-3445-VM] > — -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632160#comment-15632160 ] ASF GitHub Bot commented on CLOUDSTACK-9183: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1744 LGTM, this seems like a regression introduced by https://github.com/apache/cloudstack/commit/6477bd8ff7f982e10d0d20a97857262897dc05ed I think we can merge this, regression tests won't catch the error caused by this script's removal. Pinging for review @murali-reddy @abhinandanprateek @karuturi > CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory > --- > > Key: CLOUDSTACK-9183 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.7.0 > Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS >Reporter: Milamber > Labels: kvm, systemvm > > On my 4.7.0 RC1 test environment, I've this warning message: > 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts > from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or > directory > I don't find this bash script anywhere (on management node, host node and > inside the VR) > I find theses references to this script inside: > public static final String ROUTER_ALERTS = "getRouterAlerts.sh"; > ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java > ExecutionResult result = _vrDeployer.executeInVR(routerIp, > VRScripts.ROUTER_ALERTS, args); > ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632196#comment-15632196 ] ASF GitHub Bot commented on CLOUDSTACK-9183: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1744 I tested this, the script is useful for getting alerts when any expected service running on VR fails. A `monitorServices.py` script monitors such services and tries to recover failing services, while logging this at `/var/log/routerServiceMonitor.log`. Without this script, mgmt server/admins won't know when an error such as failing service has happened. LGTM on manual testing. > CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory > --- > > Key: CLOUDSTACK-9183 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.7.0 > Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS >Reporter: Milamber > Labels: kvm, systemvm > > On my 4.7.0 RC1 test environment, I've this warning message: > 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts > from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or > directory > I don't find this bash script anywhere (on management node, host node and > inside the VR) > I find theses references to this script inside: > public static final String ROUTER_ALERTS = "getRouterAlerts.sh"; > ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java > ExecutionResult result = _vrDeployer.executeInVR(routerIp, > VRScripts.ROUTER_ALERTS, args); > ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9226) Wrong number of sockets reported
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632278#comment-15632278 ] Andrija Panic commented on CLOUDSTACK-9226: --- Im not sure if this is the right place (I dont see other ticket for this) - on my host with E5-2650 v2 CPUs (native 2.6GHz, turbobust up to 3.4 GHz) - cloudstack reports 32 cores with 3.4 GHz speeds - and this effectively does over-provisioning of CPU (ACS think we have 32x3.4GHz, but in reality we have only 32x2.6GHz) Any info on this, this is killing performance for some hosts, that are near CPU limit... (we use KVM here, ACS 4.8, but same on 4.5) Thanks, Andrija > Wrong number of sockets reported > > > Key: CLOUDSTACK-9226 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9226 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.6.0, 4.7.0 > Environment: KVM, CentOS 7 mgmt + HV >Reporter: Nux > Labels: dashboard, kvm, sockets, statistics > > Hello, > My current setup includes a dual cpu, quad core + HT, however in the ACS > dashboard the "CPU sockets" says only one. > This value is wrong and as I undestand it, it is taken from "virsh nodeinfo" > which is known to give misleading information, as it reports stuff "per NUMA > cell" > As per the man page of virsh, the number of real physical sockets should be > calculated as "NUMA cell" multiplied by "CPU sockets". > e.g. > virsh nodeinfo > CPU model: x86_64 > CPU(s): 16 > CPU frequency: 2393 MHz > CPU socket(s): 1 > Core(s) per socket: 4 > Thread(s) per core: 2 > NUMA cell(s):2 > physical cpus = "CPU socket(s): 1" * "NUMA cell(s):2" = 2 > (correct) > Additional information can be taken from "virsh capabilities|grep socket_id" > (xml output) e.g.: > virsh capabilities|grep socket_id > > > > > > > > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632392#comment-15632392 ] ASF GitHub Bot commented on CLOUDSTACK-9183: Github user olafurgreen commented on the issue: https://github.com/apache/cloudstack/pull/1744 This file is also missing in 4.9 > CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory > --- > > Key: CLOUDSTACK-9183 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.7.0 > Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS >Reporter: Milamber > Labels: kvm, systemvm > > On my 4.7.0 RC1 test environment, I've this warning message: > 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts > from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or > directory > I don't find this bash script anywhere (on management node, host node and > inside the VR) > I find theses references to this script inside: > public static final String ROUTER_ALERTS = "getRouterAlerts.sh"; > ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java > ExecutionResult result = _vrDeployer.executeInVR(routerIp, > VRScripts.ROUTER_ALERTS, args); > ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9465) Several log refactoring/improvement suggestions
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632412#comment-15632412
]
ASF subversion and git services commented on CLOUDSTACK-9465:
-
Commit b59db0dc06e0ef14f6c1a54ffcdc5578ed203007 in cloudstack's branch
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b59db0d ]
Merge pull request #1705 from nemo9cby/CLOUDSTACK-9465
Made the changes to improve logging.CLOUSTACK-9465 Several log
refactoring/improvement suggestions.
There are two scenarios of logging which needs refactoring/improvement:
Method invocation replaced by variable
This means that in the logging code, the method invocation is pre-defined as a
variable. for simplicity, the method invocation should be replaced by
the variable.
Delete variable which must be null
The variable in the logging code is null, there is no need to put the variable
there.
* pr/1705:
Made the changes to improve logging.
Signed-off-by: Rohit Yadav
> Several log refactoring/improvement suggestions
> ---
>
> Key: CLOUDSTACK-9465
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9465
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.9.0
>Reporter: Nemo Chen
> Labels: easyfix, easytet
> Attachments: CLOUDSTACK-9465.001.patch
>
>
> *method invocation replaced by variable*
> file:
> apache-cloudstack-4.9.0-src/engine/orchestration/src/com/cloud/agent/manager/AgentManagerImpl.java
> void processRequest (final Link link, final Request request)
> {code}final long hostId=attache.getId(){code}
> {code}s_logger.trace("SeqA " + attache.getId() + "-"+ request.getSequence()+
> ": Processing "+ request);{code}
> file:
> apache-cloudstack-4.9.0-src/engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
> method: void orchestrateMigrateForScale (final String vmUuid, final long
> srcHostId, final DeployDestination dest, final Long oldSvcOfferingId)
> {code}final long dstHostId = dest.getHost().getId();{code}
> {code}s_logger.info("Source and destination host are not in same cluster,
> unable to migrate to host: " + dest.getHost().getId());{code}
> The method invocations in above examples are assigned to variables before, we
> should replace the method invocation with the variable for simpliciy and
> readabiliy of logs.
>
> *Delete variable which must be null*
> apache-cloudstack-4.9.0-src/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/KVMHAChecker.java
> Boolean checkingHB ()
> {code}s_logger.debug("read heartbeat failed: " + result);{code}
> In the above example, the variable is null in the log. There is no need to
> print the invalid variable in the logs. Suggestion: delete the variable in
> the logs to avoid confusion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9554) Juniper Contrail plug-in is publishing events to wrong message bus
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632415#comment-15632415 ] ASF subversion and git services commented on CLOUDSTACK-9554: - Commit 725ddb82a1c0f99f91ce1316d0e8082b6731d41e in cloudstack's branch refs/heads/4.8 from [~yvsubhash] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=725ddb8 ] CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wrong message bus > Juniper Contrail plug-in is publishing events to wrong message bus > -- > > Key: CLOUDSTACK-9554 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9554 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.9.0 > Environment: Citrix Xenserver with juniper contrail. >Reporter: subhash yedugundla > Fix For: 4.10.0.0 > > > Juniper contrail plugin is publishing events to internal message bus instead > of event bus. which can lead to a deadlock in the following scenario > 1. Create a VM in cloudstack with xenserver > 2. Create firewall rules on contrail for the same > 3. Delete the vm from xenserver directly. > 4. Next power state sync cycle would create a deadlock -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9554) Juniper Contrail plug-in is publishing events to wrong message bus
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632414#comment-15632414 ] ASF GitHub Bot commented on CLOUDSTACK-9554: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1715 Merging based on code review and Travis, regression tests. > Juniper Contrail plug-in is publishing events to wrong message bus > -- > > Key: CLOUDSTACK-9554 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9554 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.9.0 > Environment: Citrix Xenserver with juniper contrail. >Reporter: subhash yedugundla > Fix For: 4.10.0.0 > > > Juniper contrail plugin is publishing events to internal message bus instead > of event bus. which can lead to a deadlock in the following scenario > 1. Create a VM in cloudstack with xenserver > 2. Create firewall rules on contrail for the same > 3. Delete the vm from xenserver directly. > 4. Next power state sync cycle would create a deadlock -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9554) Juniper Contrail plug-in is publishing events to wrong message bus
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632417#comment-15632417 ] ASF subversion and git services commented on CLOUDSTACK-9554: - Commit 41ed00a8ca4143d7fcc740a1f3936d9248632948 in cloudstack's branch refs/heads/4.8 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=41ed00a ] Merge pull request #1715 from yvsubhash/CLOUDSTACK-9554 CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wronJuniper Contrail plug-in is publishing events to message bus instead of event bus * pr/1715: CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wrong message bus Signed-off-by: Rohit Yadav > Juniper Contrail plug-in is publishing events to wrong message bus > -- > > Key: CLOUDSTACK-9554 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9554 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.9.0 > Environment: Citrix Xenserver with juniper contrail. >Reporter: subhash yedugundla > Fix For: 4.10.0.0 > > > Juniper contrail plugin is publishing events to internal message bus instead > of event bus. which can lead to a deadlock in the following scenario > 1. Create a VM in cloudstack with xenserver > 2. Create firewall rules on contrail for the same > 3. Delete the vm from xenserver directly. > 4. Next power state sync cycle would create a deadlock -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9554) Juniper Contrail plug-in is publishing events to wrong message bus
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632419#comment-15632419 ] ASF subversion and git services commented on CLOUDSTACK-9554: - Commit 41ed00a8ca4143d7fcc740a1f3936d9248632948 in cloudstack's branch refs/heads/4.8 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=41ed00a ] Merge pull request #1715 from yvsubhash/CLOUDSTACK-9554 CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wronJuniper Contrail plug-in is publishing events to message bus instead of event bus * pr/1715: CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wrong message bus Signed-off-by: Rohit Yadav > Juniper Contrail plug-in is publishing events to wrong message bus > -- > > Key: CLOUDSTACK-9554 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9554 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.9.0 > Environment: Citrix Xenserver with juniper contrail. >Reporter: subhash yedugundla > Fix For: 4.10.0.0 > > > Juniper contrail plugin is publishing events to internal message bus instead > of event bus. which can lead to a deadlock in the following scenario > 1. Create a VM in cloudstack with xenserver > 2. Create firewall rules on contrail for the same > 3. Delete the vm from xenserver directly. > 4. Next power state sync cycle would create a deadlock -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9554) Juniper Contrail plug-in is publishing events to wrong message bus
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632416#comment-15632416 ] ASF subversion and git services commented on CLOUDSTACK-9554: - Commit 41ed00a8ca4143d7fcc740a1f3936d9248632948 in cloudstack's branch refs/heads/4.8 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=41ed00a ] Merge pull request #1715 from yvsubhash/CLOUDSTACK-9554 CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wronJuniper Contrail plug-in is publishing events to message bus instead of event bus * pr/1715: CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wrong message bus Signed-off-by: Rohit Yadav > Juniper Contrail plug-in is publishing events to wrong message bus > -- > > Key: CLOUDSTACK-9554 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9554 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.9.0 > Environment: Citrix Xenserver with juniper contrail. >Reporter: subhash yedugundla > Fix For: 4.10.0.0 > > > Juniper contrail plugin is publishing events to internal message bus instead > of event bus. which can lead to a deadlock in the following scenario > 1. Create a VM in cloudstack with xenserver > 2. Create firewall rules on contrail for the same > 3. Delete the vm from xenserver directly. > 4. Next power state sync cycle would create a deadlock -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9554) Juniper Contrail plug-in is publishing events to wrong message bus
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632420#comment-15632420 ] ASF GitHub Bot commented on CLOUDSTACK-9554: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1715 > Juniper Contrail plug-in is publishing events to wrong message bus > -- > > Key: CLOUDSTACK-9554 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9554 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.9.0 > Environment: Citrix Xenserver with juniper contrail. >Reporter: subhash yedugundla > Fix For: 4.10.0.0 > > > Juniper contrail plugin is publishing events to internal message bus instead > of event bus. which can lead to a deadlock in the following scenario > 1. Create a VM in cloudstack with xenserver > 2. Create firewall rules on contrail for the same > 3. Delete the vm from xenserver directly. > 4. Next power state sync cycle would create a deadlock -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9554) Juniper Contrail plug-in is publishing events to wrong message bus
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632431#comment-15632431 ] ASF subversion and git services commented on CLOUDSTACK-9554: - Commit 41ed00a8ca4143d7fcc740a1f3936d9248632948 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=41ed00a ] Merge pull request #1715 from yvsubhash/CLOUDSTACK-9554 CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wronJuniper Contrail plug-in is publishing events to message bus instead of event bus * pr/1715: CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wrong message bus Signed-off-by: Rohit Yadav > Juniper Contrail plug-in is publishing events to wrong message bus > -- > > Key: CLOUDSTACK-9554 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9554 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.9.0 > Environment: Citrix Xenserver with juniper contrail. >Reporter: subhash yedugundla > Fix For: 4.10.0.0 > > > Juniper contrail plugin is publishing events to internal message bus instead > of event bus. which can lead to a deadlock in the following scenario > 1. Create a VM in cloudstack with xenserver > 2. Create firewall rules on contrail for the same > 3. Delete the vm from xenserver directly. > 4. Next power state sync cycle would create a deadlock -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9554) Juniper Contrail plug-in is publishing events to wrong message bus
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632429#comment-15632429 ] ASF subversion and git services commented on CLOUDSTACK-9554: - Commit 725ddb82a1c0f99f91ce1316d0e8082b6731d41e in cloudstack's branch refs/heads/master from [~yvsubhash] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=725ddb8 ] CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wrong message bus > Juniper Contrail plug-in is publishing events to wrong message bus > -- > > Key: CLOUDSTACK-9554 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9554 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.9.0 > Environment: Citrix Xenserver with juniper contrail. >Reporter: subhash yedugundla > Fix For: 4.10.0.0 > > > Juniper contrail plugin is publishing events to internal message bus instead > of event bus. which can lead to a deadlock in the following scenario > 1. Create a VM in cloudstack with xenserver > 2. Create firewall rules on contrail for the same > 3. Delete the vm from xenserver directly. > 4. Next power state sync cycle would create a deadlock -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9554) Juniper Contrail plug-in is publishing events to wrong message bus
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632423#comment-15632423 ] ASF subversion and git services commented on CLOUDSTACK-9554: - Commit 725ddb82a1c0f99f91ce1316d0e8082b6731d41e in cloudstack's branch refs/heads/4.9 from [~yvsubhash] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=725ddb8 ] CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wrong message bus > Juniper Contrail plug-in is publishing events to wrong message bus > -- > > Key: CLOUDSTACK-9554 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9554 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.9.0 > Environment: Citrix Xenserver with juniper contrail. >Reporter: subhash yedugundla > Fix For: 4.10.0.0 > > > Juniper contrail plugin is publishing events to internal message bus instead > of event bus. which can lead to a deadlock in the following scenario > 1. Create a VM in cloudstack with xenserver > 2. Create firewall rules on contrail for the same > 3. Delete the vm from xenserver directly. > 4. Next power state sync cycle would create a deadlock -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9554) Juniper Contrail plug-in is publishing events to wrong message bus
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632424#comment-15632424 ] ASF subversion and git services commented on CLOUDSTACK-9554: - Commit 41ed00a8ca4143d7fcc740a1f3936d9248632948 in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=41ed00a ] Merge pull request #1715 from yvsubhash/CLOUDSTACK-9554 CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wronJuniper Contrail plug-in is publishing events to message bus instead of event bus * pr/1715: CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wrong message bus Signed-off-by: Rohit Yadav > Juniper Contrail plug-in is publishing events to wrong message bus > -- > > Key: CLOUDSTACK-9554 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9554 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.9.0 > Environment: Citrix Xenserver with juniper contrail. >Reporter: subhash yedugundla > Fix For: 4.10.0.0 > > > Juniper contrail plugin is publishing events to internal message bus instead > of event bus. which can lead to a deadlock in the following scenario > 1. Create a VM in cloudstack with xenserver > 2. Create firewall rules on contrail for the same > 3. Delete the vm from xenserver directly. > 4. Next power state sync cycle would create a deadlock -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9554) Juniper Contrail plug-in is publishing events to wrong message bus
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632430#comment-15632430 ] ASF subversion and git services commented on CLOUDSTACK-9554: - Commit 41ed00a8ca4143d7fcc740a1f3936d9248632948 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=41ed00a ] Merge pull request #1715 from yvsubhash/CLOUDSTACK-9554 CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wronJuniper Contrail plug-in is publishing events to message bus instead of event bus * pr/1715: CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wrong message bus Signed-off-by: Rohit Yadav > Juniper Contrail plug-in is publishing events to wrong message bus > -- > > Key: CLOUDSTACK-9554 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9554 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.9.0 > Environment: Citrix Xenserver with juniper contrail. >Reporter: subhash yedugundla > Fix For: 4.10.0.0 > > > Juniper contrail plugin is publishing events to internal message bus instead > of event bus. which can lead to a deadlock in the following scenario > 1. Create a VM in cloudstack with xenserver > 2. Create firewall rules on contrail for the same > 3. Delete the vm from xenserver directly. > 4. Next power state sync cycle would create a deadlock -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9554) Juniper Contrail plug-in is publishing events to wrong message bus
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632425#comment-15632425 ] ASF subversion and git services commented on CLOUDSTACK-9554: - Commit 41ed00a8ca4143d7fcc740a1f3936d9248632948 in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=41ed00a ] Merge pull request #1715 from yvsubhash/CLOUDSTACK-9554 CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wronJuniper Contrail plug-in is publishing events to message bus instead of event bus * pr/1715: CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wrong message bus Signed-off-by: Rohit Yadav > Juniper Contrail plug-in is publishing events to wrong message bus > -- > > Key: CLOUDSTACK-9554 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9554 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.9.0 > Environment: Citrix Xenserver with juniper contrail. >Reporter: subhash yedugundla > Fix For: 4.10.0.0 > > > Juniper contrail plugin is publishing events to internal message bus instead > of event bus. which can lead to a deadlock in the following scenario > 1. Create a VM in cloudstack with xenserver > 2. Create firewall rules on contrail for the same > 3. Delete the vm from xenserver directly. > 4. Next power state sync cycle would create a deadlock -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9554) Juniper Contrail plug-in is publishing events to wrong message bus
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632432#comment-15632432 ] ASF subversion and git services commented on CLOUDSTACK-9554: - Commit 41ed00a8ca4143d7fcc740a1f3936d9248632948 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=41ed00a ] Merge pull request #1715 from yvsubhash/CLOUDSTACK-9554 CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wronJuniper Contrail plug-in is publishing events to message bus instead of event bus * pr/1715: CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wrong message bus Signed-off-by: Rohit Yadav > Juniper Contrail plug-in is publishing events to wrong message bus > -- > > Key: CLOUDSTACK-9554 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9554 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.9.0 > Environment: Citrix Xenserver with juniper contrail. >Reporter: subhash yedugundla > Fix For: 4.10.0.0 > > > Juniper contrail plugin is publishing events to internal message bus instead > of event bus. which can lead to a deadlock in the following scenario > 1. Create a VM in cloudstack with xenserver > 2. Create firewall rules on contrail for the same > 3. Delete the vm from xenserver directly. > 4. Next power state sync cycle would create a deadlock -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9554) Juniper Contrail plug-in is publishing events to wrong message bus
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632426#comment-15632426 ] ASF subversion and git services commented on CLOUDSTACK-9554: - Commit 41ed00a8ca4143d7fcc740a1f3936d9248632948 in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=41ed00a ] Merge pull request #1715 from yvsubhash/CLOUDSTACK-9554 CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wronJuniper Contrail plug-in is publishing events to message bus instead of event bus * pr/1715: CLOUDSTACK-9554 Juniper Contrail plug-in is publishing events to wrong message bus Signed-off-by: Rohit Yadav > Juniper Contrail plug-in is publishing events to wrong message bus > -- > > Key: CLOUDSTACK-9554 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9554 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.9.0 > Environment: Citrix Xenserver with juniper contrail. >Reporter: subhash yedugundla > Fix For: 4.10.0.0 > > > Juniper contrail plugin is publishing events to internal message bus instead > of event bus. which can lead to a deadlock in the following scenario > 1. Create a VM in cloudstack with xenserver > 2. Create firewall rules on contrail for the same > 3. Delete the vm from xenserver directly. > 4. Next power state sync cycle would create a deadlock -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632437#comment-15632437 ] ASF GitHub Bot commented on CLOUDSTACK-9553: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1714 Merging this based on code review and test results. The one failing test is not related to the change but related to env issue. > Usage event is not getting recorded for snapshots in a specific scenario > > > Key: CLOUDSTACK-9553 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9553 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.9.0 > Environment: vmware 4.5.1 >Reporter: subhash yedugundla > Fix For: Future > > > 1. Create a scheduled snapshot of the volume > 2. Delete the snapshot schedule before the run of the usage job for the day. > 3. The usage job completes successfully but there is a error message "post > process snapshot failed" > 4. The snapshot.create event is captured in the event table, but not in the > usage event table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632443#comment-15632443 ] ASF subversion and git services commented on CLOUDSTACK-9553: - Commit c0a6fc2bfb5126fad5d8cfb7b179d120d6b935a4 in cloudstack's branch refs/heads/4.8 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c0a6fc2 ] Merge pull request #1714 from yvsubhash/CLOUDSTACK-9553 CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario * pr/1714: CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario Signed-off-by: Rohit Yadav > Usage event is not getting recorded for snapshots in a specific scenario > > > Key: CLOUDSTACK-9553 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9553 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.9.0 > Environment: vmware 4.5.1 >Reporter: subhash yedugundla > Fix For: Future > > > 1. Create a scheduled snapshot of the volume > 2. Delete the snapshot schedule before the run of the usage job for the day. > 3. The usage job completes successfully but there is a error message "post > process snapshot failed" > 4. The snapshot.create event is captured in the event table, but not in the > usage event table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632440#comment-15632440 ] ASF subversion and git services commented on CLOUDSTACK-9553: - Commit c0a6fc2bfb5126fad5d8cfb7b179d120d6b935a4 in cloudstack's branch refs/heads/4.8 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c0a6fc2 ] Merge pull request #1714 from yvsubhash/CLOUDSTACK-9553 CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario * pr/1714: CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario Signed-off-by: Rohit Yadav > Usage event is not getting recorded for snapshots in a specific scenario > > > Key: CLOUDSTACK-9553 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9553 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.9.0 > Environment: vmware 4.5.1 >Reporter: subhash yedugundla > Fix For: Future > > > 1. Create a scheduled snapshot of the volume > 2. Delete the snapshot schedule before the run of the usage job for the day. > 3. The usage job completes successfully but there is a error message "post > process snapshot failed" > 4. The snapshot.create event is captured in the event table, but not in the > usage event table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632441#comment-15632441 ] ASF subversion and git services commented on CLOUDSTACK-9553: - Commit c0a6fc2bfb5126fad5d8cfb7b179d120d6b935a4 in cloudstack's branch refs/heads/4.8 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c0a6fc2 ] Merge pull request #1714 from yvsubhash/CLOUDSTACK-9553 CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario * pr/1714: CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario Signed-off-by: Rohit Yadav > Usage event is not getting recorded for snapshots in a specific scenario > > > Key: CLOUDSTACK-9553 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9553 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.9.0 > Environment: vmware 4.5.1 >Reporter: subhash yedugundla > Fix For: Future > > > 1. Create a scheduled snapshot of the volume > 2. Delete the snapshot schedule before the run of the usage job for the day. > 3. The usage job completes successfully but there is a error message "post > process snapshot failed" > 4. The snapshot.create event is captured in the event table, but not in the > usage event table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632438#comment-15632438 ] ASF subversion and git services commented on CLOUDSTACK-9553: - Commit 3987b8c6b4549360ff2b0a14296e65cf3d437d49 in cloudstack's branch refs/heads/4.8 from subhash_y [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3987b8c ] CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario > Usage event is not getting recorded for snapshots in a specific scenario > > > Key: CLOUDSTACK-9553 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9553 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.9.0 > Environment: vmware 4.5.1 >Reporter: subhash yedugundla > Fix For: Future > > > 1. Create a scheduled snapshot of the volume > 2. Delete the snapshot schedule before the run of the usage job for the day. > 3. The usage job completes successfully but there is a error message "post > process snapshot failed" > 4. The snapshot.create event is captured in the event table, but not in the > usage event table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632445#comment-15632445 ] ASF GitHub Bot commented on CLOUDSTACK-9553: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1714 > Usage event is not getting recorded for snapshots in a specific scenario > > > Key: CLOUDSTACK-9553 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9553 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.9.0 > Environment: vmware 4.5.1 >Reporter: subhash yedugundla > Fix For: Future > > > 1. Create a scheduled snapshot of the volume > 2. Delete the snapshot schedule before the run of the usage job for the day. > 3. The usage job completes successfully but there is a error message "post > process snapshot failed" > 4. The snapshot.create event is captured in the event table, but not in the > usage event table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632446#comment-15632446 ] ASF subversion and git services commented on CLOUDSTACK-9553: - Commit 3987b8c6b4549360ff2b0a14296e65cf3d437d49 in cloudstack's branch refs/heads/4.9 from subhash_y [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3987b8c ] CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario > Usage event is not getting recorded for snapshots in a specific scenario > > > Key: CLOUDSTACK-9553 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9553 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.9.0 > Environment: vmware 4.5.1 >Reporter: subhash yedugundla > Fix For: Future > > > 1. Create a scheduled snapshot of the volume > 2. Delete the snapshot schedule before the run of the usage job for the day. > 3. The usage job completes successfully but there is a error message "post > process snapshot failed" > 4. The snapshot.create event is captured in the event table, but not in the > usage event table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632448#comment-15632448 ] ASF subversion and git services commented on CLOUDSTACK-9553: - Commit c0a6fc2bfb5126fad5d8cfb7b179d120d6b935a4 in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c0a6fc2 ] Merge pull request #1714 from yvsubhash/CLOUDSTACK-9553 CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario * pr/1714: CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario Signed-off-by: Rohit Yadav > Usage event is not getting recorded for snapshots in a specific scenario > > > Key: CLOUDSTACK-9553 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9553 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.9.0 > Environment: vmware 4.5.1 >Reporter: subhash yedugundla > Fix For: Future > > > 1. Create a scheduled snapshot of the volume > 2. Delete the snapshot schedule before the run of the usage job for the day. > 3. The usage job completes successfully but there is a error message "post > process snapshot failed" > 4. The snapshot.create event is captured in the event table, but not in the > usage event table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632447#comment-15632447 ] ASF subversion and git services commented on CLOUDSTACK-9553: - Commit c0a6fc2bfb5126fad5d8cfb7b179d120d6b935a4 in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c0a6fc2 ] Merge pull request #1714 from yvsubhash/CLOUDSTACK-9553 CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario * pr/1714: CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario Signed-off-by: Rohit Yadav > Usage event is not getting recorded for snapshots in a specific scenario > > > Key: CLOUDSTACK-9553 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9553 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.9.0 > Environment: vmware 4.5.1 >Reporter: subhash yedugundla > Fix For: Future > > > 1. Create a scheduled snapshot of the volume > 2. Delete the snapshot schedule before the run of the usage job for the day. > 3. The usage job completes successfully but there is a error message "post > process snapshot failed" > 4. The snapshot.create event is captured in the event table, but not in the > usage event table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632449#comment-15632449 ] ASF subversion and git services commented on CLOUDSTACK-9553: - Commit c0a6fc2bfb5126fad5d8cfb7b179d120d6b935a4 in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c0a6fc2 ] Merge pull request #1714 from yvsubhash/CLOUDSTACK-9553 CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario * pr/1714: CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario Signed-off-by: Rohit Yadav > Usage event is not getting recorded for snapshots in a specific scenario > > > Key: CLOUDSTACK-9553 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9553 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.9.0 > Environment: vmware 4.5.1 >Reporter: subhash yedugundla > Fix For: Future > > > 1. Create a scheduled snapshot of the volume > 2. Delete the snapshot schedule before the run of the usage job for the day. > 3. The usage job completes successfully but there is a error message "post > process snapshot failed" > 4. The snapshot.create event is captured in the event table, but not in the > usage event table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9563) ExtractTemplate returns malformed URL after migrating NFS to s3
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632451#comment-15632451 ] ASF GitHub Bot commented on CLOUDSTACK-9563: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1733 @blueorangutan package > ExtractTemplate returns malformed URL after migrating NFS to s3 > --- > > Key: CLOUDSTACK-9563 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9563 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: sudharma jain > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9562) Linux Guest VM get wrong default route when there are multiple Nic with a nic with vpc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632453#comment-15632453 ] ASF GitHub Bot commented on CLOUDSTACK-9562: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1736 @blueorangutan package > Linux Guest VM get wrong default route when there are multiple Nic with a nic > with vpc > -- > > Key: CLOUDSTACK-9562 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9562 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: sudharma jain > > REPRO STEPS > == > 1. Log as admin, create a VM CentOSx64 integrate with default network > "Admin-Network" (gateway is 10.1.1.1) > 2. Create a VPC "TestVpc" and inside network named "TechNet" (gateway is > 10.0.0.1) > 3. Add VPC network to VM as NIC 2 > 4. Reboot VM and examine VM default VR changed to VPC default gateway -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9563) ExtractTemplate returns malformed URL after migrating NFS to s3
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632452#comment-15632452 ] ASF GitHub Bot commented on CLOUDSTACK-9563: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1733 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > ExtractTemplate returns malformed URL after migrating NFS to s3 > --- > > Key: CLOUDSTACK-9563 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9563 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: sudharma jain > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632458#comment-15632458 ] ASF subversion and git services commented on CLOUDSTACK-9553: - Commit c0a6fc2bfb5126fad5d8cfb7b179d120d6b935a4 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c0a6fc2 ] Merge pull request #1714 from yvsubhash/CLOUDSTACK-9553 CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario * pr/1714: CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario Signed-off-by: Rohit Yadav > Usage event is not getting recorded for snapshots in a specific scenario > > > Key: CLOUDSTACK-9553 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9553 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.9.0 > Environment: vmware 4.5.1 >Reporter: subhash yedugundla > Fix For: Future > > > 1. Create a scheduled snapshot of the volume > 2. Delete the snapshot schedule before the run of the usage job for the day. > 3. The usage job completes successfully but there is a error message "post > process snapshot failed" > 4. The snapshot.create event is captured in the event table, but not in the > usage event table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632461#comment-15632461 ] ASF subversion and git services commented on CLOUDSTACK-9553: - Commit c0a6fc2bfb5126fad5d8cfb7b179d120d6b935a4 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c0a6fc2 ] Merge pull request #1714 from yvsubhash/CLOUDSTACK-9553 CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario * pr/1714: CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario Signed-off-by: Rohit Yadav > Usage event is not getting recorded for snapshots in a specific scenario > > > Key: CLOUDSTACK-9553 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9553 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.9.0 > Environment: vmware 4.5.1 >Reporter: subhash yedugundla > Fix For: Future > > > 1. Create a scheduled snapshot of the volume > 2. Delete the snapshot schedule before the run of the usage job for the day. > 3. The usage job completes successfully but there is a error message "post > process snapshot failed" > 4. The snapshot.create event is captured in the event table, but not in the > usage event table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9567) Difference in the api call outputs for CAPACITY_TYPE_CPU = 1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632456#comment-15632456 ] ASF GitHub Bot commented on CLOUDSTACK-9567: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1734 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > Difference in the api call outputs for CAPACITY_TYPE_CPU = 1 > > > Key: CLOUDSTACK-9567 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9567 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: sudharma jain > > The total capacity reported is different, ideally they have to be same > http://10.223.59.69:8096/client/api?command=listPods&id=78c23ee6-c585-4065-a03c-08c15492c077&zoneid=48889c46-dd04-4a50-af06-8aad7ea46f61&showcapacities=true > > 1 > 1042980 > 1621776 > 64.31 > > http://10.223.59.69:8096/client/api?command=listCapacity&podid=78c23ee6-c585-4065-a03c-08c15492c077&zoneid=48889c46-dd04-4a50-af06-8aad7ea46f61&type=1 > > 1 > > 1 > 48889c46-dd04-4a50-af06-8aad7ea46f61 > jp2-east01 > 78c23ee6-c585-4065-a03c-08c15492c077 > RG1-ck2ejo2-Pod11 > 1042980 > 2453456 > 42.51 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632459#comment-15632459 ] ASF subversion and git services commented on CLOUDSTACK-9553: - Commit c0a6fc2bfb5126fad5d8cfb7b179d120d6b935a4 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c0a6fc2 ] Merge pull request #1714 from yvsubhash/CLOUDSTACK-9553 CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario * pr/1714: CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario Signed-off-by: Rohit Yadav > Usage event is not getting recorded for snapshots in a specific scenario > > > Key: CLOUDSTACK-9553 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9553 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.9.0 > Environment: vmware 4.5.1 >Reporter: subhash yedugundla > Fix For: Future > > > 1. Create a scheduled snapshot of the volume > 2. Delete the snapshot schedule before the run of the usage job for the day. > 3. The usage job completes successfully but there is a error message "post > process snapshot failed" > 4. The snapshot.create event is captured in the event table, but not in the > usage event table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9562) Linux Guest VM get wrong default route when there are multiple Nic with a nic with vpc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632455#comment-15632455 ] ASF GitHub Bot commented on CLOUDSTACK-9562: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1736 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > Linux Guest VM get wrong default route when there are multiple Nic with a nic > with vpc > -- > > Key: CLOUDSTACK-9562 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9562 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: sudharma jain > > REPRO STEPS > == > 1. Log as admin, create a VM CentOSx64 integrate with default network > "Admin-Network" (gateway is 10.1.1.1) > 2. Create a VPC "TestVpc" and inside network named "TechNet" (gateway is > 10.0.0.1) > 3. Add VPC network to VM as NIC 2 > 4. Reboot VM and examine VM default VR changed to VPC default gateway -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632457#comment-15632457 ] ASF subversion and git services commented on CLOUDSTACK-9553: - Commit 3987b8c6b4549360ff2b0a14296e65cf3d437d49 in cloudstack's branch refs/heads/master from subhash_y [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3987b8c ] CLOUDSTACK-9553 Usage event is not getting recorded for snapshots in a specific scenario > Usage event is not getting recorded for snapshots in a specific scenario > > > Key: CLOUDSTACK-9553 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9553 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.9.0 > Environment: vmware 4.5.1 >Reporter: subhash yedugundla > Fix For: Future > > > 1. Create a scheduled snapshot of the volume > 2. Delete the snapshot schedule before the run of the usage job for the day. > 3. The usage job completes successfully but there is a error message "post > process snapshot failed" > 4. The snapshot.create event is captured in the event table, but not in the > usage event table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632465#comment-15632465 ] ASF GitHub Bot commented on CLOUDSTACK-9183: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1744 @olafurgreen thanks, we'll fwd-merge this on all 4.7+ branches. > CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory > --- > > Key: CLOUDSTACK-9183 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.7.0 > Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS >Reporter: Milamber > Labels: kvm, systemvm > > On my 4.7.0 RC1 test environment, I've this warning message: > 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts > from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or > directory > I don't find this bash script anywhere (on management node, host node and > inside the VR) > I find theses references to this script inside: > public static final String ROUTER_ALERTS = "getRouterAlerts.sh"; > ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java > ExecutionResult result = _vrDeployer.executeInVR(routerIp, > VRScripts.ROUTER_ALERTS, args); > ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632467#comment-15632467 ] ASF GitHub Bot commented on CLOUDSTACK-9183: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1744 @blueorangutan package > CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory > --- > > Key: CLOUDSTACK-9183 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.7.0 > Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS >Reporter: Milamber > Labels: kvm, systemvm > > On my 4.7.0 RC1 test environment, I've this warning message: > 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts > from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or > directory > I don't find this bash script anywhere (on management node, host node and > inside the VR) > I find theses references to this script inside: > public static final String ROUTER_ALERTS = "getRouterAlerts.sh"; > ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java > ExecutionResult result = _vrDeployer.executeInVR(routerIp, > VRScripts.ROUTER_ALERTS, args); > ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632468#comment-15632468 ] ASF GitHub Bot commented on CLOUDSTACK-9183: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1744 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory > --- > > Key: CLOUDSTACK-9183 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.7.0 > Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS >Reporter: Milamber > Labels: kvm, systemvm > > On my 4.7.0 RC1 test environment, I've this warning message: > 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts > from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or > directory > I don't find this bash script anywhere (on management node, host node and > inside the VR) > I find theses references to this script inside: > public static final String ROUTER_ALERTS = "getRouterAlerts.sh"; > ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java > ExecutionResult result = _vrDeployer.executeInVR(routerIp, > VRScripts.ROUTER_ALERTS, args); > ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632491#comment-15632491 ] ASF GitHub Bot commented on CLOUDSTACK-9500: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1706 Trillian test result (tid-269) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 24772 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1706-t269-kvm-centos7.zip Test completed. 45 look ok, 3 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_02_redundant_VPC_default_routes | `Failure` | 845.38 | test_vpc_redundant.py test_oobm_zchange_password | `Failure` | 20.38 | test_outofbandmanagement.py test_network_rules_acquired_public_ip_3_Load_Balancer_Rule | `Failure` | 36.36 | test_network.py test_network_rules_acquired_public_ip_2_nat_rule | `Failure` | 31.31 | test_network.py test_network_rules_acquired_public_ip_1_static_nat_rule | `Failure` | 93.29 | test_network.py test_10_attachAndDetach_iso | `Error` | 32.29 | test_vm_life_cycle.py test_01_vpc_site2site_vpn | Success | 144.27 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 61.00 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 227.25 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 253.81 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 515.20 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 494.85 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1402.39 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 525.90 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1235.82 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 15.35 | test_volumes.py test_08_resize_volume | Success | 15.28 | test_volumes.py test_07_resize_fail | Success | 20.35 | test_volumes.py test_06_download_detached_volume | Success | 15.22 | test_volumes.py test_05_detach_volume | Success | 100.24 | test_volumes.py test_04_delete_attached_volume | Success | 10.16 | test_volumes.py test_03_download_attached_volume | Success | 15.24 | test_volumes.py test_02_attach_volume | Success | 43.61 | test_volumes.py test_01_create_volume | Success | 617.32 | test_volumes.py test_deploy_vm_multiple | Success | 338.31 | test_vm_life_cycle.py test_deploy_vm | Success | 0.02 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.21 | test_vm_life_cycle.py test_08_migrate_vm | Success | 35.66 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.08 | test_vm_life_cycle.py test_06_destroy_vm | Success | 125.63 | test_vm_life_cycle.py test_03_reboot_vm | Success | 125.67 | test_vm_life_cycle.py test_02_start_vm | Success | 10.13 | test_vm_life_cycle.py test_01_stop_vm | Success | 35.22 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 65.67 | test_templates.py test_08_list_system_templates | Success | 0.02 | test_templates.py test_07_list_public_templates | Success | 0.03 | test_templates.py test_05_template_permissions | Success | 0.04 | test_templates.py test_04_extract_template | Success | 5.44 | test_templates.py test_03_delete_template | Success | 5.11 | test_templates.py test_02_edit_template | Success | 90.10 | test_templates.py test_01_create_template | Success | 45.35 | test_templates.py test_10_destroy_cpvm | Success | 131.23 | test_ssvm.py test_09_destroy_ssvm | Success | 163.00 | test_ssvm.py test_08_reboot_cpvm | Success | 101.22 | test_ssvm.py test_07_reboot_ssvm | Success | 102.97 | test_ssvm.py test_06_stop_cpvm | Success | 131.34 | test_ssvm.py test_05_stop_ssvm | Success | 133.09 | test_ssvm.py test_04_cpvm_internals | Success | 0.93 | test_ssvm.py test_03_ssvm_internals | Success | 4.03 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.09 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.09 | test_ssvm.py test_01_snapshot_root_disk | Success | 11.01 | test_snapshots.py test_04_change_offering_small | Success | 204.31 | test_service_offerings.py test_03_delete_service_offering | Success | 0.03 | test_service_offerings.py test_02_edit_service_offering | Success | 0.04 | test_service_offerings.py test_01_create_service_offering | Success | 0.07 | test_service_offerings.py test_02_sys_template_ready | Success | 0.09 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.12 | test_secondary_storage.py test_09_reboot_router
[jira] [Commented] (CLOUDSTACK-9226) Wrong number of sockets reported
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632522#comment-15632522 ] Nux commented on CLOUDSTACK-9226: - Hi Andrija, Unless the number of sockets is not reported correctly, then I don't think this is the right place for your issue. It looks more like an issue of how CPU is reported by OS/libvirt. > Wrong number of sockets reported > > > Key: CLOUDSTACK-9226 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9226 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.6.0, 4.7.0 > Environment: KVM, CentOS 7 mgmt + HV >Reporter: Nux > Labels: dashboard, kvm, sockets, statistics > > Hello, > My current setup includes a dual cpu, quad core + HT, however in the ACS > dashboard the "CPU sockets" says only one. > This value is wrong and as I undestand it, it is taken from "virsh nodeinfo" > which is known to give misleading information, as it reports stuff "per NUMA > cell" > As per the man page of virsh, the number of real physical sockets should be > calculated as "NUMA cell" multiplied by "CPU sockets". > e.g. > virsh nodeinfo > CPU model: x86_64 > CPU(s): 16 > CPU frequency: 2393 MHz > CPU socket(s): 1 > Core(s) per socket: 4 > Thread(s) per core: 2 > NUMA cell(s):2 > physical cpus = "CPU socket(s): 1" * "NUMA cell(s):2" = 2 > (correct) > Additional information can be taken from "virsh capabilities|grep socket_id" > (xml output) e.g.: > virsh capabilities|grep socket_id > > > > > > > > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9563) ExtractTemplate returns malformed URL after migrating NFS to s3
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632541#comment-15632541 ] ASF GitHub Bot commented on CLOUDSTACK-9563: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1733 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-144 > ExtractTemplate returns malformed URL after migrating NFS to s3 > --- > > Key: CLOUDSTACK-9563 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9563 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: sudharma jain > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9562) Linux Guest VM get wrong default route when there are multiple Nic with a nic with vpc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632546#comment-15632546 ] ASF GitHub Bot commented on CLOUDSTACK-9562: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1736 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-145 > Linux Guest VM get wrong default route when there are multiple Nic with a nic > with vpc > -- > > Key: CLOUDSTACK-9562 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9562 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: sudharma jain > > REPRO STEPS > == > 1. Log as admin, create a VM CentOSx64 integrate with default network > "Admin-Network" (gateway is 10.1.1.1) > 2. Create a VPC "TestVpc" and inside network named "TechNet" (gateway is > 10.0.0.1) > 3. Add VPC network to VM as NIC 2 > 4. Reboot VM and examine VM default VR changed to VPC default gateway -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9567) Difference in the api call outputs for CAPACITY_TYPE_CPU = 1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632548#comment-15632548 ] ASF GitHub Bot commented on CLOUDSTACK-9567: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1734 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-146 > Difference in the api call outputs for CAPACITY_TYPE_CPU = 1 > > > Key: CLOUDSTACK-9567 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9567 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: sudharma jain > > The total capacity reported is different, ideally they have to be same > http://10.223.59.69:8096/client/api?command=listPods&id=78c23ee6-c585-4065-a03c-08c15492c077&zoneid=48889c46-dd04-4a50-af06-8aad7ea46f61&showcapacities=true > > 1 > 1042980 > 1621776 > 64.31 > > http://10.223.59.69:8096/client/api?command=listCapacity&podid=78c23ee6-c585-4065-a03c-08c15492c077&zoneid=48889c46-dd04-4a50-af06-8aad7ea46f61&type=1 > > 1 > > 1 > 48889c46-dd04-4a50-af06-8aad7ea46f61 > jp2-east01 > 78c23ee6-c585-4065-a03c-08c15492c077 > RG1-ck2ejo2-Pod11 > 1042980 > 2453456 > 42.51 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632580#comment-15632580 ] ASF GitHub Bot commented on CLOUDSTACK-9183: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1744 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-147 > CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory > --- > > Key: CLOUDSTACK-9183 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.7.0 > Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS >Reporter: Milamber > Labels: kvm, systemvm > > On my 4.7.0 RC1 test environment, I've this warning message: > 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts > from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or > directory > I don't find this bash script anywhere (on management node, host node and > inside the VR) > I find theses references to this script inside: > public static final String ROUTER_ALERTS = "getRouterAlerts.sh"; > ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java > ExecutionResult result = _vrDeployer.executeInVR(routerIp, > VRScripts.ROUTER_ALERTS, args); > ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632605#comment-15632605 ] ASF GitHub Bot commented on CLOUDSTACK-9183: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1744 @blueorangutan centos7 vmware-55u3 > CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory > --- > > Key: CLOUDSTACK-9183 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.7.0 > Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS >Reporter: Milamber > Labels: kvm, systemvm > > On my 4.7.0 RC1 test environment, I've this warning message: > 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts > from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or > directory > I don't find this bash script anywhere (on management node, host node and > inside the VR) > I find theses references to this script inside: > public static final String ROUTER_ALERTS = "getRouterAlerts.sh"; > ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java > ExecutionResult result = _vrDeployer.executeInVR(routerIp, > VRScripts.ROUTER_ALERTS, args); > ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632616#comment-15632616 ] ASF GitHub Bot commented on CLOUDSTACK-9183: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1744 @blueorangutan centos7 vmware-55u3 > CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory > --- > > Key: CLOUDSTACK-9183 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.7.0 > Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS >Reporter: Milamber > Labels: kvm, systemvm > > On my 4.7.0 RC1 test environment, I've this warning message: > 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts > from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or > directory > I don't find this bash script anywhere (on management node, host node and > inside the VR) > I find theses references to this script inside: > public static final String ROUTER_ALERTS = "getRouterAlerts.sh"; > ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java > ExecutionResult result = _vrDeployer.executeInVR(routerIp, > VRScripts.ROUTER_ALERTS, args); > ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632690#comment-15632690 ] ASF GitHub Bot commented on CLOUDSTACK-9509: Github user nathanejohnson commented on the issue: https://github.com/apache/cloudstack/pull/1694 @rthyd ahh, it didn't occur to me to just pass null. I was trying to initialize that third parameter with a mock (like the other two). Thanks again! > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9503) The router script times out resulting in failure of deployment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633450#comment-15633450 ] ASF GitHub Bot commented on CLOUDSTACK-9503: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1745 Trillian test result (tid-275) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 28972 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1745-t275-kvm-centos7.zip Test completed. 42 look ok, 1 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_02_redundant_VPC_default_routes | `Failure` | 870.32 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Failure` | 376.01 | test_vpc_redundant.py test_01_vpc_site2site_vpn | Success | 171.12 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 87.25 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 277.82 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 296.83 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 551.72 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 525.09 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1463.08 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 554.08 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 15.77 | test_volumes.py test_08_resize_volume | Success | 15.55 | test_volumes.py test_07_resize_fail | Success | 20.56 | test_volumes.py test_06_download_detached_volume | Success | 15.37 | test_volumes.py test_05_detach_volume | Success | 100.28 | test_volumes.py test_04_delete_attached_volume | Success | 10.24 | test_volumes.py test_03_download_attached_volume | Success | 15.38 | test_volumes.py test_02_attach_volume | Success | 45.92 | test_volumes.py test_01_create_volume | Success | 711.89 | test_volumes.py test_deploy_vm_multiple | Success | 330.35 | test_vm_life_cycle.py test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 26.99 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.28 | test_vm_life_cycle.py test_08_migrate_vm | Success | 36.01 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.14 | test_vm_life_cycle.py test_06_destroy_vm | Success | 131.06 | test_vm_life_cycle.py test_03_reboot_vm | Success | 125.94 | test_vm_life_cycle.py test_02_start_vm | Success | 10.27 | test_vm_life_cycle.py test_01_stop_vm | Success | 40.40 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 91.05 | test_templates.py test_08_list_system_templates | Success | 0.04 | test_templates.py test_07_list_public_templates | Success | 0.04 | test_templates.py test_05_template_permissions | Success | 0.07 | test_templates.py test_04_extract_template | Success | 5.22 | test_templates.py test_03_delete_template | Success | 5.21 | test_templates.py test_02_edit_template | Success | 90.30 | test_templates.py test_01_create_template | Success | 56.55 | test_templates.py test_10_destroy_cpvm | Success | 161.80 | test_ssvm.py test_09_destroy_ssvm | Success | 225.07 | test_ssvm.py test_08_reboot_cpvm | Success | 161.72 | test_ssvm.py test_07_reboot_ssvm | Success | 134.01 | test_ssvm.py test_06_stop_cpvm | Success | 131.63 | test_ssvm.py test_05_stop_ssvm | Success | 133.90 | test_ssvm.py test_04_cpvm_internals | Success | 1.20 | test_ssvm.py test_03_ssvm_internals | Success | 3.34 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.13 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.16 | test_ssvm.py test_01_snapshot_root_disk | Success | 11.55 | test_snapshots.py test_04_change_offering_small | Success | 210.64 | test_service_offerings.py test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py test_02_edit_service_offering | Success | 0.10 | test_service_offerings.py test_01_create_service_offering | Success | 0.23 | test_service_offerings.py test_02_sys_template_ready | Success | 0.10 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.15 | test_secondary_storage.py test_09_reboot_router | Success | 35.58 | test_routers.py test_08_start_router | Success | 30.29 | test_routers.py test_07_stop_router | Success | 10.26 | test_routers.py test_06_router_advanced | Success | 0.11 | test_routers.py test_05_router_basic | Success | 0.04 | test_routers.py test_04_restart_network_wo_cleanup | Success | 5.76 | test_routers.py test_03_restar
[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633700#comment-15633700 ] ASF GitHub Bot commented on CLOUDSTACK-9539: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1727 Trillian test result (tid-278) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 26230 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1727-t278-kvm-centos7.zip Test completed. 47 look ok, 1 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_change_service_offering_for_vm_with_snapshots | `Error` | 139.92 | test_vm_snapshots.py test_01_vpc_site2site_vpn | Success | 154.91 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 66.15 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 260.87 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 276.30 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 564.17 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 516.91 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1427.48 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 559.98 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 762.23 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1291.35 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 15.48 | test_volumes.py test_08_resize_volume | Success | 15.41 | test_volumes.py test_07_resize_fail | Success | 20.45 | test_volumes.py test_06_download_detached_volume | Success | 15.29 | test_volumes.py test_05_detach_volume | Success | 100.22 | test_volumes.py test_04_delete_attached_volume | Success | 10.20 | test_volumes.py test_03_download_attached_volume | Success | 15.31 | test_volumes.py test_02_attach_volume | Success | 75.03 | test_volumes.py test_01_create_volume | Success | 713.88 | test_volumes.py test_deploy_vm_multiple | Success | 293.79 | test_vm_life_cycle.py test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 26.66 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.17 | test_vm_life_cycle.py test_08_migrate_vm | Success | 40.95 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.14 | test_vm_life_cycle.py test_06_destroy_vm | Success | 125.80 | test_vm_life_cycle.py test_03_reboot_vm | Success | 125.93 | test_vm_life_cycle.py test_02_start_vm | Success | 10.17 | test_vm_life_cycle.py test_01_stop_vm | Success | 40.31 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 85.74 | test_templates.py test_08_list_system_templates | Success | 0.06 | test_templates.py test_07_list_public_templates | Success | 0.04 | test_templates.py test_05_template_permissions | Success | 0.06 | test_templates.py test_04_extract_template | Success | 5.16 | test_templates.py test_03_delete_template | Success | 5.11 | test_templates.py test_02_edit_template | Success | 90.17 | test_templates.py test_01_create_template | Success | 60.56 | test_templates.py test_10_destroy_cpvm | Success | 161.79 | test_ssvm.py test_09_destroy_ssvm | Success | 168.75 | test_ssvm.py test_08_reboot_cpvm | Success | 131.79 | test_ssvm.py test_07_reboot_ssvm | Success | 133.62 | test_ssvm.py test_06_stop_cpvm | Success | 131.74 | test_ssvm.py test_05_stop_ssvm | Success | 138.75 | test_ssvm.py test_04_cpvm_internals | Success | 1.26 | test_ssvm.py test_03_ssvm_internals | Success | 3.87 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.15 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.14 | test_ssvm.py test_01_snapshot_root_disk | Success | 11.41 | test_snapshots.py test_04_change_offering_small | Success | 210.61 | test_service_offerings.py test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py test_02_edit_service_offering | Success | 0.08 | test_service_offerings.py test_01_create_service_offering | Success | 0.13 | test_service_offerings.py test_02_sys_template_ready | Success | 0.13 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.18 | test_secondary_storage.py test_09_reboot_router | Success | 35.30 | test_routers.py test_08_start_router | Success | 30.31 | test_routers.py test_07_stop_router | Success | 10.17 | test_routers.py test_06_router_advanced | Success | 0.06 | test_routers.py test_05_router_basic | Success | 0.04 | test_routers.
[jira] [Updated] (CLOUDSTACK-9574) Redesign storage views
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Vazquez updated CLOUDSTACK-9574:
Summary: Redesign storage views (was: Redesign storage tags for primary
storage)
> Redesign storage views
> --
>
> Key: CLOUDSTACK-9574
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9574
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, UI
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Attachments: PS-DETAILS.PNG, PS.PNG
>
>
> h3. Actual behavior
> Primary storage tags are being saved as an entry on {{storage_pool_details}}
> with:
> * name = TAG_NAME
> * value = "true"
> When a boolean property is defined in {{storage_pool_details}} and has value
> = "true", it is displayed as a tag.
> !https://issues.apache.org/jira/secure/attachment/12836196/PS-DETAILS.PNG!
> !https://issues.apache.org/jira/secure/attachment/12836195/PS.PNG!
> h3. Goal
> Redesign {{Storage Tags}} for Primary Storage view, as it is done in Host
> Tags.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9574) Redesign storage views
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Vazquez updated CLOUDSTACK-9574:
Description:
h2. Part 1: Redesign storage tags
h3. Actual behavior
Primary storage tags are being saved as an entry on {{storage_pool_details}}
with:
* name = TAG_NAME
* value = "true"
When a boolean property is defined in {{storage_pool_details}} and has value =
"true", it is displayed as a tag.
!https://issues.apache.org/jira/secure/attachment/12836196/PS-DETAILS.PNG!
!https://issues.apache.org/jira/secure/attachment/12836195/PS.PNG!
h3. Goal
Redesign {{Storage Tags}} for Primary Storage view, to list only tags, as it is
done in Host Tags (Hosts view).
h2. Part 2: Remove details from listImageStores API call response and UI
h3. Description
In Secondary Storage view we propose removing Details field, as Setting tab
list details for a given image store. We also remove details from response on
listImageStores API method
was:
h2. Part 1: Redesign storage tags
h3. Actual behavior
Primary storage tags are being saved as an entry on {{storage_pool_details}}
with:
* name = TAG_NAME
* value = "true"
When a boolean property is defined in {{storage_pool_details}} and has value =
"true", it is displayed as a tag.
!https://issues.apache.org/jira/secure/attachment/12836196/PS-DETAILS.PNG!
!https://issues.apache.org/jira/secure/attachment/12836195/PS.PNG!
h3. Goal
Redesign {{Storage Tags}} for Primary Storage view, as it is done in Host Tags.
h2. Part 2: Remove details from listImageStores API call response and UI
h3. Description
In Secondary Storage view we propose removing Details field, as Setting tab
list details for a given image store. We also remove details from response on
listImageStores API method
> Redesign storage views
> --
>
> Key: CLOUDSTACK-9574
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9574
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, UI
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Attachments: PS-DETAILS.PNG, PS.PNG
>
>
> h2. Part 1: Redesign storage tags
> h3. Actual behavior
> Primary storage tags are being saved as an entry on {{storage_pool_details}}
> with:
> * name = TAG_NAME
> * value = "true"
> When a boolean property is defined in {{storage_pool_details}} and has value
> = "true", it is displayed as a tag.
> !https://issues.apache.org/jira/secure/attachment/12836196/PS-DETAILS.PNG!
> !https://issues.apache.org/jira/secure/attachment/12836195/PS.PNG!
> h3. Goal
> Redesign {{Storage Tags}} for Primary Storage view, to list only tags, as it
> is done in Host Tags (Hosts view).
> h2. Part 2: Remove details from listImageStores API call response and UI
> h3. Description
> In Secondary Storage view we propose removing Details field, as Setting tab
> list details for a given image store. We also remove details from response on
> listImageStores API method
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15634030#comment-15634030 ] ASF GitHub Bot commented on CLOUDSTACK-9183: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1744 Trillian test result (tid-285) Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7 Total time taken: 25849 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1744-t285-vmware-55u3.zip Test completed. 32 look ok, 12 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_02_VPC_default_routes | `Failure` | 206.70 | test_vpc_router_nics.py test_02_redundant_VPC_default_routes | `Failure` | 475.95 | test_vpc_redundant.py test_router_dhcphosts | `Failure` | 56.26 | test_router_dhcphosts.py test_isolate_network_password_server | `Failure` | 23.24 | test_password_server.py ContextSuite context=TestVpcSite2SiteVpn>:setup | `Error` | 0.00 | test_vpc_vpn.py ContextSuite context=TestVpcRemoteAccessVpn>:setup | `Error` | 0.00 | test_vpc_vpn.py ContextSuite context=TestRVPCSite2SiteVpn>:setup | `Error` | 0.00 | test_vpc_vpn.py test_01_test_vm_volume_snapshot | `Error` | 196.61 | test_vm_snapshots.py test_CreateTemplateWithDuplicateName | `Error` | 5.15 | test_templates.py test_01_create_template | `Error` | 35.55 | test_templates.py ContextSuite context=TestTemplates>:setup | `Error` | 362.43 | test_templates.py ContextSuite context=TestRouterDHCPHosts>:teardown | `Error` | 76.53 | test_router_dhcphosts.py test_07_quota | `Error` | 0.04 | test_quota.py test_06_quota | `Error` | 0.04 | test_quota.py test_05_quota | `Error` | 0.04 | test_quota.py test_04_quota | `Error` | 0.04 | test_quota.py test_03_quota | `Error` | 0.04 | test_quota.py test_02_quota | `Error` | 0.04 | test_quota.py test_01_quota | `Error` | 0.04 | test_quota.py test_04_rvpc_privategw_static_routes | `Error` | 344.19 | test_privategw_acl.py test_03_vpc_privategw_restart_vpc_cleanup | `Error` | 188.06 | test_privategw_acl.py test_02_vpc_privategw_static_routes | `Error` | 188.17 | test_privategw_acl.py test_01_vpc_privategw_acl | `Error` | 97.39 | test_privategw_acl.py test_extendPhysicalNetworkVlan | `Error` | 0.03 | test_non_contigiousvlan.py ContextSuite context=TestInternalLb>:setup | `Error` | 0.00 | test_internal_lb.py ContextSuite context=TestDedicateGuestVlanRange>:setup | `Error` | 0.00 | test_guest_vlan_range.py test_01_VPC_nics_after_destroy | Success | 668.74 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 589.48 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1591.49 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 647.44 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1204.26 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 35.88 | test_volumes.py test_06_download_detached_volume | Success | 55.58 | test_volumes.py test_05_detach_volume | Success | 100.30 | test_volumes.py test_04_delete_attached_volume | Success | 10.27 | test_volumes.py test_03_download_attached_volume | Success | 15.32 | test_volumes.py test_02_attach_volume | Success | 63.89 | test_volumes.py test_01_create_volume | Success | 519.24 | test_volumes.py test_03_delete_vm_snapshots | Success | 275.23 | test_vm_snapshots.py test_02_revert_vm_snapshots | Success | 194.21 | test_vm_snapshots.py test_01_create_vm_snapshots | Success | 161.63 | test_vm_snapshots.py test_deploy_vm_multiple | Success | 208.45 | test_vm_life_cycle.py test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 71.72 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.22 | test_vm_life_cycle.py test_08_migrate_vm | Success | 66.19 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.14 | test_vm_life_cycle.py test_06_destroy_vm | Success | 10.31 | test_vm_life_cycle.py test_03_reboot_vm | Success | 5.21 | test_vm_life_cycle.py test_02_start_vm | Success | 15.19 | test_vm_life_cycle.py test_01_stop_vm | Success | 5.17 | test_vm_life_cycle.py test_10_destroy_cpvm | Success | 206.76 | test_ssvm.py test_09_destroy_ssvm | Success | 238.85 | test_ssvm.py test_08_reboot_cpvm | Success | 127.31 | test_ssvm.py test_07_reboot_ssvm | Success | 128.28 | test_ssvm.py test_06_stop_cpvm | Success | 207.06 | test_ssvm.py test_05_stop_ssvm | Success | 203.53 | test_ssvm.py test_04_cpvm_internals | Success | 1.24
[jira] [Updated] (CLOUDSTACK-9574) Redesign storage views
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Vazquez updated CLOUDSTACK-9574:
Description:
h2. Part 1: Redesign storage tags
h3. Actual behavior
Primary storage tags are being saved as an entry on {{storage_pool_details}}
with:
* name = TAG_NAME
* value = "true"
When a boolean property is defined in {{storage_pool_details}} and has value =
"true", it is displayed as a tag.
!https://issues.apache.org/jira/secure/attachment/12836196/PS-DETAILS.PNG!
!https://issues.apache.org/jira/secure/attachment/12836195/PS.PNG!
h3. Goal
Redesign {{Storage Tags}} for Primary Storage view, as it is done in Host Tags.
h2. Part 2: Remove details from listImageStores API call response and UI
h3. Description
In Secondary Storage view we propose removing Details field, as Setting tab
list details for a given image store. We also remove details from response on
listImageStores API method
was:
h3. Actual behavior
Primary storage tags are being saved as an entry on {{storage_pool_details}}
with:
* name = TAG_NAME
* value = "true"
When a boolean property is defined in {{storage_pool_details}} and has value =
"true", it is displayed as a tag.
!https://issues.apache.org/jira/secure/attachment/12836196/PS-DETAILS.PNG!
!https://issues.apache.org/jira/secure/attachment/12836195/PS.PNG!
h3. Goal
Redesign {{Storage Tags}} for Primary Storage view, as it is done in Host Tags.
> Redesign storage views
> --
>
> Key: CLOUDSTACK-9574
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9574
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, UI
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Attachments: PS-DETAILS.PNG, PS.PNG
>
>
> h2. Part 1: Redesign storage tags
> h3. Actual behavior
> Primary storage tags are being saved as an entry on {{storage_pool_details}}
> with:
> * name = TAG_NAME
> * value = "true"
> When a boolean property is defined in {{storage_pool_details}} and has value
> = "true", it is displayed as a tag.
> !https://issues.apache.org/jira/secure/attachment/12836196/PS-DETAILS.PNG!
> !https://issues.apache.org/jira/secure/attachment/12836195/PS.PNG!
> h3. Goal
> Redesign {{Storage Tags}} for Primary Storage view, as it is done in Host
> Tags.
> h2. Part 2: Remove details from listImageStores API call response and UI
> h3. Description
> In Secondary Storage view we propose removing Details field, as Setting tab
> list details for a given image store. We also remove details from response on
> listImageStores API method
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9563) ExtractTemplate returns malformed URL after migrating NFS to s3
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15634217#comment-15634217 ] ASF GitHub Bot commented on CLOUDSTACK-9563: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1733 Trillian test result (tid-286) Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7 Total time taken: 28968 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1733-t286-vmware-55u3.zip Test completed. 37 look ok, 6 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_05_rvpc_multi_tiers | `Failure` | 564.88 | test_vpc_redundant.py test_01_vpc_site2site_vpn | `Error` | 451.43 | test_vpc_vpn.py ContextSuite context=TestRVPCSite2SiteVpn>:setup | `Error` | 0.00 | test_vpc_vpn.py test_05_rvpc_multi_tiers | `Error` | 650.72 | test_vpc_redundant.py test_07_resize_fail | `Error` | 15.32 | test_volumes.py test_06_download_detached_volume | `Error` | 45.43 | test_volumes.py ContextSuite context=TestVmSnapshot>:setup | `Error` | 343.54 | test_vm_snapshots.py ContextSuite context=TestVMLifeCycle>:setup | `Error` | 364.98 | test_vm_life_cycle.py ContextSuite context=TestTemplates>:setup | `Error` | 0.00 | test_templates.py test_01_vpc_remote_access_vpn | Success | 151.47 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 307.21 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 603.41 | test_vpc_router_nics.py test_04_rvpc_network_garbage_collector_nics | Success | 1511.62 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 513.17 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 583.46 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1110.89 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 30.72 | test_volumes.py test_05_detach_volume | Success | 105.81 | test_volumes.py test_04_delete_attached_volume | Success | 10.38 | test_volumes.py test_03_download_attached_volume | Success | 25.42 | test_volumes.py test_02_attach_volume | Success | 53.63 | test_volumes.py test_01_create_volume | Success | 457.18 | test_volumes.py test_01_test_vm_volume_snapshot | Success | 146.04 | test_vm_snapshots.py test_deploy_vm_multiple | Success | 182.48 | test_vm_life_cycle.py test_deploy_vm | Success | 0.02 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py test_10_destroy_cpvm | Success | 241.94 | test_ssvm.py test_09_destroy_ssvm | Success | 238.49 | test_ssvm.py test_08_reboot_cpvm | Success | 156.33 | test_ssvm.py test_07_reboot_ssvm | Success | 128.02 | test_ssvm.py test_06_stop_cpvm | Success | 206.58 | test_ssvm.py test_05_stop_ssvm | Success | 173.56 | test_ssvm.py test_04_cpvm_internals | Success | 1.26 | test_ssvm.py test_03_ssvm_internals | Success | 3.01 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.08 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.08 | test_ssvm.py test_01_snapshot_root_disk | Success | 67.17 | test_snapshots.py test_04_change_offering_small | Success | 86.70 | test_service_offerings.py test_03_delete_service_offering | Success | 0.03 | test_service_offerings.py test_02_edit_service_offering | Success | 0.05 | test_service_offerings.py test_01_create_service_offering | Success | 0.08 | test_service_offerings.py test_02_sys_template_ready | Success | 0.08 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.13 | test_secondary_storage.py test_09_reboot_router | Success | 115.67 | test_routers.py test_08_start_router | Success | 100.69 | test_routers.py test_07_stop_router | Success | 20.22 | test_routers.py test_06_router_advanced | Success | 0.05 | test_routers.py test_05_router_basic | Success | 0.03 | test_routers.py test_04_restart_network_wo_cleanup | Success | 5.56 | test_routers.py test_03_restart_network_cleanup | Success | 181.11 | test_routers.py test_02_router_internal_adv | Success | 0.88 | test_routers.py test_01_router_internal_basic | Success | 0.48 | test_routers.py test_router_dhcphosts | Success | 132.07 | test_router_dhcphosts.py test_01_updatevolumedetail | Success | 5.12 | test_resource_detail.py test_01_reset_vm_on_reboot | Success | 35.32 | test_reset_vm_on_reboot.py test_createRegion | Success | 0.03 | test_regions.py test_create_pvlan_network | Success | 5.14 | test_pvlan.py test_dedicatePublicIpRange | Success | 0.27 | test_public_ip_range.py test_04_rvpc_privategw_static_routes | Success | 833.75 | test_privategw_acl.py test_03_vpc_
[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15634290#comment-15634290
]
ASF GitHub Bot commented on CLOUDSTACK-9539:
Github user nvazquez commented on the issue:
https://github.com/apache/cloudstack/pull/1727
@rhtyd thanks for running tests. Looking at blueorangutan we realized that
new marvin test should exclude some hypervisors that don't allow vm snapshots,
in this case was KVM:
```
raise e\n', 'CloudstackAPIException: Execute cmd: createvmsnapshot failed,
due to: errorCode: 431, errorText:VM snapshot is not enabled for hypervisor
type: KVM\n'
```
I0ll refactor test file so new marvin test introduced in this PR uses only
those hypervisors that allow vm snapshots
> Support changing Service offering for instance with VM Snapshots
>
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which
> have vm snapshots. In that case, previously taken snapshots (if reverted)
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way
> snapshot can be reverted to original state even though service offering can
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}}
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9567) Difference in the api call outputs for CAPACITY_TYPE_CPU = 1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15634447#comment-15634447 ] ASF GitHub Bot commented on CLOUDSTACK-9567: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1734 Trillian test result (tid-288) Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7 Total time taken: 33675 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1734-t288-vmware-55u3.zip Test completed. 41 look ok, 2 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_01_vpc_site2site_vpn | `Error` | 457.67 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | `Error` | 699.52 | test_vpc_vpn.py ContextSuite context=TestVpcRemoteAccessVpn>:setup | `Error` | 2361.99 | test_vpc_vpn.py ContextSuite context=TestVPCRedundancy>:teardown | `Error` | 533.36 | test_vpc_redundant.py test_02_VPC_default_routes | Success | 334.98 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 673.91 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 528.26 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1532.56 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 616.59 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 563.57 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1179.87 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 30.90 | test_volumes.py test_06_download_detached_volume | Success | 65.83 | test_volumes.py test_05_detach_volume | Success | 105.38 | test_volumes.py test_04_delete_attached_volume | Success | 15.36 | test_volumes.py test_03_download_attached_volume | Success | 15.35 | test_volumes.py test_02_attach_volume | Success | 58.88 | test_volumes.py test_01_create_volume | Success | 517.05 | test_volumes.py test_03_delete_vm_snapshots | Success | 275.28 | test_vm_snapshots.py test_02_revert_vm_snapshots | Success | 199.23 | test_vm_snapshots.py test_01_test_vm_volume_snapshot | Success | 192.07 | test_vm_snapshots.py test_01_create_vm_snapshots | Success | 161.63 | test_vm_snapshots.py test_deploy_vm_multiple | Success | 269.24 | test_vm_life_cycle.py test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 26.83 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.26 | test_vm_life_cycle.py test_08_migrate_vm | Success | 71.37 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.16 | test_vm_life_cycle.py test_06_destroy_vm | Success | 10.14 | test_vm_life_cycle.py test_03_reboot_vm | Success | 5.26 | test_vm_life_cycle.py test_02_start_vm | Success | 20.31 | test_vm_life_cycle.py test_01_stop_vm | Success | 10.20 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 246.94 | test_templates.py test_08_list_system_templates | Success | 0.05 | test_templates.py test_07_list_public_templates | Success | 0.04 | test_templates.py test_05_template_permissions | Success | 0.08 | test_templates.py test_04_extract_template | Success | 15.25 | test_templates.py test_03_delete_template | Success | 5.13 | test_templates.py test_02_edit_template | Success | 90.22 | test_templates.py test_01_create_template | Success | 131.35 | test_templates.py test_10_destroy_cpvm | Success | 267.05 | test_ssvm.py test_09_destroy_ssvm | Success | 269.06 | test_ssvm.py test_08_reboot_cpvm | Success | 157.41 | test_ssvm.py test_07_reboot_ssvm | Success | 158.78 | test_ssvm.py test_06_stop_cpvm | Success | 172.72 | test_ssvm.py test_05_stop_ssvm | Success | 244.00 | test_ssvm.py test_04_cpvm_internals | Success | 1.22 | test_ssvm.py test_03_ssvm_internals | Success | 3.32 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.12 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.12 | test_ssvm.py test_01_snapshot_root_disk | Success | 27.71 | test_snapshots.py test_04_change_offering_small | Success | 92.67 | test_service_offerings.py test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py test_02_edit_service_offering | Success | 0.08 | test_service_offerings.py test_01_create_service_offering | Success | 0.11 | test_service_offerings.py test_02_sys_template_ready | Success | 0.16 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.17 | test_secondary_storage.py test_09_reboot_router | Success | 166.51 | test_routers.py test_08_start_router | Success | 121
[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15635317#comment-15635317
]
ASF GitHub Bot commented on CLOUDSTACK-9539:
Github user rhtyd commented on the issue:
https://github.com/apache/cloudstack/pull/1727
@nvazquez thanks, I'll kick another one against vmware
@blueorangutan test centos7 vmware-55u3
> Support changing Service offering for instance with VM Snapshots
>
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which
> have vm snapshots. In that case, previously taken snapshots (if reverted)
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way
> snapshot can be reverted to original state even though service offering can
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}}
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15635319#comment-15635319
]
ASF GitHub Bot commented on CLOUDSTACK-9539:
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1727
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + vmware-55u3) has been
kicked to run smoke tests
> Support changing Service offering for instance with VM Snapshots
>
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which
> have vm snapshots. In that case, previously taken snapshots (if reverted)
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way
> snapshot can be reverted to original state even though service offering can
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}}
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15635320#comment-15635320 ] ASF GitHub Bot commented on CLOUDSTACK-9183: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1744 @blueorangutan test > CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory > --- > > Key: CLOUDSTACK-9183 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.7.0 > Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS >Reporter: Milamber > Labels: kvm, systemvm > > On my 4.7.0 RC1 test environment, I've this warning message: > 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts > from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or > directory > I don't find this bash script anywhere (on management node, host node and > inside the VR) > I find theses references to this script inside: > public static final String ROUTER_ALERTS = "getRouterAlerts.sh"; > ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java > ExecutionResult result = _vrDeployer.executeInVR(routerIp, > VRScripts.ROUTER_ALERTS, args); > ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15635323#comment-15635323 ] ASF GitHub Bot commented on CLOUDSTACK-9183: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1744 @rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests > CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory > --- > > Key: CLOUDSTACK-9183 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.7.0 > Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS >Reporter: Milamber > Labels: kvm, systemvm > > On my 4.7.0 RC1 test environment, I've this warning message: > 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts > from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or > directory > I don't find this bash script anywhere (on management node, host node and > inside the VR) > I find theses references to this script inside: > public static final String ROUTER_ALERTS = "getRouterAlerts.sh"; > ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java > ExecutionResult result = _vrDeployer.executeInVR(routerIp, > VRScripts.ROUTER_ALERTS, args); > ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15635325#comment-15635325 ] ASF GitHub Bot commented on CLOUDSTACK-9183: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1744 The failures from last test run are related to env, also they ran on 4.7 branch where several of the integration test fixes were not made. > CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory > --- > > Key: CLOUDSTACK-9183 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.7.0 > Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS >Reporter: Milamber > Labels: kvm, systemvm > > On my 4.7.0 RC1 test environment, I've this warning message: > 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts > from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or > directory > I don't find this bash script anywhere (on management node, host node and > inside the VR) > I find theses references to this script inside: > public static final String ROUTER_ALERTS = "getRouterAlerts.sh"; > ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java > ExecutionResult result = _vrDeployer.executeInVR(routerIp, > VRScripts.ROUTER_ALERTS, args); > ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
