[jira] [Commented] (CLOUDSTACK-9042) VR: Missing dhcp entries in /etc/dhpchosts.txt after starting a few VMs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050312#comment-15050312
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9042:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1093#issuecomment-163532209
  
Hi @resmo 

Could you please close this PR? The PR #1084 was already merged. As I 
mentioned above, the edithosts.txt is used by hyperv.

Cheers,
Wilder


> VR: Missing dhcp entries in /etc/dhpchosts.txt after starting a few VMs
> ---
>
> Key: CLOUDSTACK-9042
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9042
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.4.4, 4.5.2
>Reporter: René Moser
>Assignee: René Moser
>Priority: Critical
> Fix For: 4.4.5, 4.5.3
>
>
> VR advanced networking.
> We experienced an issue when a few VMs were started at a time, some of them 
> and always the same ones did not receive a IP from DHCP. 
> After a debuging, we identified the problem in this sed command in 
> ./systemvm/patches/debian/config/opt/cloud/bin/edithosts.sh
> the VM which was not in /etc/dhcphosts.txt was named:
> songlog-1
> When another VM was started named "log-1" the "songlog-1" entry was removed 
> unexpectedly. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9042) VR: Missing dhcp entries in /etc/dhpchosts.txt after starting a few VMs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050316#comment-15050316
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9042:


Github user resmo closed the pull request at:

https://github.com/apache/cloudstack/pull/1093


> VR: Missing dhcp entries in /etc/dhpchosts.txt after starting a few VMs
> ---
>
> Key: CLOUDSTACK-9042
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9042
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.4.4, 4.5.2
>Reporter: René Moser
>Assignee: René Moser
>Priority: Critical
> Fix For: 4.4.5, 4.5.3
>
>
> VR advanced networking.
> We experienced an issue when a few VMs were started at a time, some of them 
> and always the same ones did not receive a IP from DHCP. 
> After a debuging, we identified the problem in this sed command in 
> ./systemvm/patches/debian/config/opt/cloud/bin/edithosts.sh
> the VM which was not in /etc/dhcphosts.txt was named:
> songlog-1
> When another VM was started named "log-1" the "songlog-1" entry was removed 
> unexpectedly. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9067) As I developer I want to remove all the unused router-shell scripts from ACS

[Wilder Rodrigues (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues resolved CLOUDSTACK-9067.
--
Resolution: Fixed

PR merged

> As I developer I want to remove all the unused router-shell scripts from ACS
> 
>
> Key: CLOUDSTACK-9067
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9067
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-8822) Replace Runnable by Callable in the com.cloud.utils.nio.Task class.

[Wilder Rodrigues (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues resolved CLOUDSTACK-8822.
--
Resolution: Fixed

PR merged.

> Replace Runnable by Callable in the com.cloud.utils.nio.Task class.
> ---
>
> Key: CLOUDSTACK-8822
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8822
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.6.1
>
>
> The current implementation of the Task abstract class swallows all the 
> exceptions - everything extending Throwable - with only a WARN message.
> The best way to do that is by implementing Callable, which returns a value 
> and also has a "throws Exception" in the call(0 method signature.
> This work will be structural, changing the hierarchy of Task and also its 
> subclasses.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9118) As a Developer I want the checkrouter.sh script to report the right information about RVR routers state

[Wilder Rodrigues (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues resolved CLOUDSTACK-9118.
--
Resolution: Fixed

PR merged.

> As a Developer I want the checkrouter.sh script to report the right 
> information about RVR routers state
> ---
>
> Key: CLOUDSTACK-9118
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9118
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0, 4.6.2
>
>
> The routers are working properly, as BACK and MASTER, but the checkrouter.sh 
> script is not working properly and show both router as MASTER.
> The script is working fine for rVPC routers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9133) Two volume.delete usage events are getting generated for destoy vm

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050348#comment-15050348
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9133:


GitHub user priyankparihar opened a pull request:

https://github.com/apache/cloudstack/pull/1207

CLOUDSTACK-9133: Two volume.delete usage events are getting generated…

It was happening because event triggering  was happening in 
UserVmManagerImpl.java and VolumeStateListener.java respectively. So i have 
removed it from UserVmManagerImpl.java.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/priyankparihar/cloudstack CLOUDSTACK-9133

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1207.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1207


commit 5af3fd1987e797358e9bc99232202225850ed2c1
Author: Priyank Parihar 
Date:   2015-12-10T07:14:06Z

CLOUDSTACK-9133: Two volume.delete usage events are getting generated for 
destoy vm.




> Two volume.delete usage events are getting generated for destoy vm
> --
>
> Key: CLOUDSTACK-9133
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9133
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Priyank Parihar
>
> Steps to reproduce the Bug ==>
> ---
> 1- Deploy a VM 
> 2- Destory  VM 
> 3- Check usage_event table.
> ---
> Issue  ==>
> Two volume.delete usage events are getting generated for destroy VM.
> | 127 | VOLUME.DELETE   |  2 | 2015-12-08 09:30:18 |   1 
> |  25 | ROOT-14 |NULL |   
>  NULL |   NULL | NULL   | 0 | NULL |
> | 128 | VOLUME.DELETE   |  2 | 2015-12-08 09:30:20 |   1 
> |  25 | ROOT-14 |NULL |   
>  NULL |   NULL | NULL   | 0 | NULL |



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9120) As a Developer I want the new component tests to be moved into the smoke directory

[Wilder Rodrigues (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues resolved CLOUDSTACK-9120.
--
Resolution: Fixed

PR merged.

> As a Developer I want the new component tests to be moved into the smoke 
> directory
> --
>
> Key: CLOUDSTACK-9120
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9120
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Minor
>
> The following tests...
> component/test_routers_network_ops.py
> component/test_vpc_redundant.py
> component/test_router_dhcphosts.py
> component/test_routers_iptables_default_policy
> component/test_vpc_router_nics
> ... should be moved into the smoke directory due to their nature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9094) Multiple threads are being used to collect the stats from the same VR

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050364#comment-15050364
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9094:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1140#issuecomment-163536428
  
@bhaisaab 

I thought only RMs would merge PR... isn't that so?

Plus, the PR was merged without one single person executing any test 
against it.

@remibergsma, could you please revert it so someone can actually test the 
change?

Cheers,
Wilder


> Multiple threads are being used to collect the stats from the same VR
> -
>
> Key: CLOUDSTACK-9094
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9094
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.6.0
>Reporter: Harikrishna Patnala
>Assignee: Harikrishna Patnala
> Fix For: 4.7.0
>
>
> From the logs we can see that the management server is sending the 
> networkusagecommand to a VR twice within a very short interval. This doesn't 
> have any impact on the network usage being reported, however it seems to 
> consume direct agent threads unnecessarily.
> See the below snippet from the logs where networkusage command was sent to 
> the same VR at the same time
> 2014-03-04 00:02:07,178 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-113:null) Seq 10-1242718973: Executing request
> 2014-03-04 00:02:07,482 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-113:null) Seq 10-1242718973: Response Received:
> 2014-03-04 00:02:07,482 DEBUG [agent.transport.Request] 
> (DirectAgent-113:null) Seq 10-1242718973: Processing:  { Ans: , MgmtId: 
> 144027776315500, via: 10, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-59-VM","bytesSent":2937782,"bytesReceived":114175352,"result":true,"details":"","wait":0}}]
>  }
> 2014-03-04 00:02:07,482 DEBUG [agent.transport.Request] 
> (RouterMonitor-1:null) Seq 10-1242718973: Received:  { Ans: , MgmtId: 
> 144027776315500, via: 10, Ver: v1, Flags: 10, { NetworkUsageAnswer } }
> 2014-03-04 00:02:07,482 DEBUG [agent.manager.AgentManagerImpl] 
> (RouterMonitor-1:null) Details from executing class 
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-03-04 00:02:07,198 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-244:null) Seq 10-1242718974: Executing request
> 2014-03-04 00:02:07,510 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-244:null) Seq 10-1242718974: Response Received:
> 2014-03-04 00:02:07,510 DEBUG [agent.transport.Request] 
> (DirectAgent-244:null) Seq 10-1242718974: Processing:  { Ans: , MgmtId: 
> 144027776315500, via: 10, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-59-VM","bytesSent":2937782,"bytesReceived":114175352,"result":true,"details":"","wait":0}}]
>  }
> 2014-03-04 00:02:07,510 DEBUG [agent.transport.Request] 
> (RouterMonitor-1:null) Seq 10-1242718974: Received:  { Ans: , MgmtId: 
> 144027776315500, via: 10, Ver: v1, Flags: 10, { NetworkUsageAnswer } }
> 2014-03-04 00:02:07,510 DEBUG [agent.manager.AgentManagerImpl] 
> (RouterMonitor-1:null) Details from executing class 
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-03-04 00:02:07,513 DEBUG 
> [network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null) 
> Router stats changed from the time NetworkUsageCommand was sent. Ignoring 
> current answer. Router: r-59-VM Rcvd: 114175352Sent: 2937782
> 2014-03-04 00:02:07,514 DEBUG [db.Transaction.Transaction] 
> (RouterMonitor-1:null) Rolling back the transaction: Time = 2 Name =  
> -VirtualNetworkApplianceManagerImpl$NetworkUsageTask.run:900-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWorker:1146-ThreadPoolExecutor$Worker.run:615-Thread.run:701;
>  called by 
> -Transaction.rollback:897-Transaction.removeUpTo:840-Transaction.close:664-VirtualNetworkApplianceManagerImpl$NetworkUsageTask.run:955-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWorker:1146-ThreadPoolExecutor$Worker.run:615-Thread.run:701



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050362#comment-15050362
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9123:


Github user borisroman commented on the pull request:

https://github.com/apache/cloudstack/pull/1204#issuecomment-163536301
  
@wilderrodrigues @remibergsma I could only verify for KVM. 

Ran tests on Ubuntu 14.04 management/hypervisor.

```
Test to verify access to loadbalancer haproxy admin stats page ... === 
TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS 
===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic 
to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 
| Status : SUCCESS ===
ok

--
Ran 2 tests in 2532.875s
```

LGTM :+1: 


> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050367#comment-15050367
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9114:


Github user wilderrodrigues commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1198#discussion_r47201591
  
--- Diff: 
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
 ---
@@ -2558,6 +2575,62 @@ public boolean restartNetwork(Long networkId, 
Account callerAccount, User caller
 }
 }
 
+/* If there are redundant routers in the isolated network, we follow 
the steps to make the network working better
+ *  (1) destroy backup router if exists
+ *  (2) create new backup router
+ *  (3) destroy master router (then the backup will become master)
+ *  (4) create a new router as backup router.
+ */
+private boolean restartGuestNetworkWithRedundantRouters(NetworkVO 
network, List routers, ReservationContext context) throws 
ResourceUnavailableException, ConcurrentOperationException, 
InsufficientCapacityException {
+Account caller = CallContext.current().getCallingAccount();
+long callerUserId = CallContext.current().getCallingUserId();
+
+// check the master and backup redundant state
+DomainRouterVO masterRouter = null;
+DomainRouterVO backupRouter = null;
+if (routers != null && routers.size() == 1) {
+masterRouter = routers.get(0);
+} if (routers != null && routers.size() == 2) {
--- End diff --

Avoid magic numbers by putting them in constants.


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9094) Multiple threads are being used to collect the stats from the same VR

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050371#comment-15050371
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9094:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1140#issuecomment-163537454
  
@wilderrodrigues it was merged before the freeze so I didn't revert it as 
RM. But you are right about the not being tested.


> Multiple threads are being used to collect the stats from the same VR
> -
>
> Key: CLOUDSTACK-9094
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9094
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.6.0
>Reporter: Harikrishna Patnala
>Assignee: Harikrishna Patnala
> Fix For: 4.7.0
>
>
> From the logs we can see that the management server is sending the 
> networkusagecommand to a VR twice within a very short interval. This doesn't 
> have any impact on the network usage being reported, however it seems to 
> consume direct agent threads unnecessarily.
> See the below snippet from the logs where networkusage command was sent to 
> the same VR at the same time
> 2014-03-04 00:02:07,178 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-113:null) Seq 10-1242718973: Executing request
> 2014-03-04 00:02:07,482 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-113:null) Seq 10-1242718973: Response Received:
> 2014-03-04 00:02:07,482 DEBUG [agent.transport.Request] 
> (DirectAgent-113:null) Seq 10-1242718973: Processing:  { Ans: , MgmtId: 
> 144027776315500, via: 10, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-59-VM","bytesSent":2937782,"bytesReceived":114175352,"result":true,"details":"","wait":0}}]
>  }
> 2014-03-04 00:02:07,482 DEBUG [agent.transport.Request] 
> (RouterMonitor-1:null) Seq 10-1242718973: Received:  { Ans: , MgmtId: 
> 144027776315500, via: 10, Ver: v1, Flags: 10, { NetworkUsageAnswer } }
> 2014-03-04 00:02:07,482 DEBUG [agent.manager.AgentManagerImpl] 
> (RouterMonitor-1:null) Details from executing class 
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-03-04 00:02:07,198 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-244:null) Seq 10-1242718974: Executing request
> 2014-03-04 00:02:07,510 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-244:null) Seq 10-1242718974: Response Received:
> 2014-03-04 00:02:07,510 DEBUG [agent.transport.Request] 
> (DirectAgent-244:null) Seq 10-1242718974: Processing:  { Ans: , MgmtId: 
> 144027776315500, via: 10, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-59-VM","bytesSent":2937782,"bytesReceived":114175352,"result":true,"details":"","wait":0}}]
>  }
> 2014-03-04 00:02:07,510 DEBUG [agent.transport.Request] 
> (RouterMonitor-1:null) Seq 10-1242718974: Received:  { Ans: , MgmtId: 
> 144027776315500, via: 10, Ver: v1, Flags: 10, { NetworkUsageAnswer } }
> 2014-03-04 00:02:07,510 DEBUG [agent.manager.AgentManagerImpl] 
> (RouterMonitor-1:null) Details from executing class 
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-03-04 00:02:07,513 DEBUG 
> [network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null) 
> Router stats changed from the time NetworkUsageCommand was sent. Ignoring 
> current answer. Router: r-59-VM Rcvd: 114175352Sent: 2937782
> 2014-03-04 00:02:07,514 DEBUG [db.Transaction.Transaction] 
> (RouterMonitor-1:null) Rolling back the transaction: Time = 2 Name =  
> -VirtualNetworkApplianceManagerImpl$NetworkUsageTask.run:900-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWorker:1146-ThreadPoolExecutor$Worker.run:615-Thread.run:701;
>  called by 
> -Transaction.rollback:897-Transaction.removeUpTo:840-Transaction.close:664-VirtualNetworkApplianceManagerImpl$NetworkUsageTask.run:955-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWorker:1146-ThreadPoolExecutor$Worker.run:615-Thread.run:701



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050378#comment-15050378
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9114:


Github user wilderrodrigues commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1198#discussion_r47201935
  
--- Diff: 
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
 ---
@@ -2558,6 +2575,62 @@ public boolean restartNetwork(Long networkId, 
Account callerAccount, User caller
 }
 }
 
+/* If there are redundant routers in the isolated network, we follow 
the steps to make the network working better
+ *  (1) destroy backup router if exists
+ *  (2) create new backup router
+ *  (3) destroy master router (then the backup will become master)
+ *  (4) create a new router as backup router.
+ */
+private boolean restartGuestNetworkWithRedundantRouters(NetworkVO 
network, List routers, ReservationContext context) throws 
ResourceUnavailableException, ConcurrentOperationException, 
InsufficientCapacityException {
+Account caller = CallContext.current().getCallingAccount();
+long callerUserId = CallContext.current().getCallingUserId();
+
+// check the master and backup redundant state
+DomainRouterVO masterRouter = null;
+DomainRouterVO backupRouter = null;
+if (routers != null && routers.size() == 1) {
+masterRouter = routers.get(0);
+} if (routers != null && routers.size() == 2) {
+DomainRouterVO router1 = routers.get(0);
+DomainRouterVO router2 = routers.get(1);
+if (router1.getRedundantState() == RedundantState.MASTER || 
router2.getRedundantState() == RedundantState.BACKUP) {
+masterRouter = router1;
+backupRouter = router2;
+} else if (router1.getRedundantState() == 
RedundantState.BACKUP || router2.getRedundantState() == RedundantState.MASTER) {
+masterRouter = router2;
+backupRouter = router1;
+} else { // both routers are in UNKNOWN state
+masterRouter = router1;
+backupRouter = router2;
+}
+}
+
+NetworkOfferingVO offering = 
_networkOfferingDao.findByIdIncludingRemoved(network.getNetworkOfferingId());
+DeployDestination dest = new 
DeployDestination(_dcDao.findById(network.getDataCenterId()), null, null, null);
+List providersToImplement = 
getNetworkProviders(network.getId());
+
+// destroy backup router
+if (backupRouter != null) {
+_routerService.destroyRouter(backupRouter.getId(), caller, 
callerUserId);
+}
+// create new backup router
+implementNetworkElements(dest, context, network, offering, 
providersToImplement);
+
+// destroy master router
+if (masterRouter != null) {
+try {
+Thread.sleep(1); // wait 10s for the 
keepalived/conntrackd on backup router
--- End diff --

The ```implementNetworkElements()``` is a blocking call. So, you don't need 
the sleep here. Even if you would, 10 seconds is way too much.

I would suggest that first you destroy the master router! The back becomes 
master in no time, so no sleep needed. Then you spin up a new router (which 
will be backup, and destroy the previous (old) master. Serious, no sleep needed.


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9129) Cannot list vpc routers by keyword in Infrastructure -> Virtual Routers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050387#comment-15050387
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9129:


Github user kishankavala commented on the pull request:

https://github.com/apache/cloudstack/pull/1197#issuecomment-163538722
  
You are right @ustcweizhou . My branch was not up to date. Applied the 
patch on latest master.
- Able to see vpcname and vpcid in listRouters response
- Keyword search with vpc name also worked.

LGTM



> Cannot list vpc routers by keyword in Infrastructure -> Virtual Routers
> ---
>
> Key: CLOUDSTACK-9129
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9129
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> when search by keyword  in Infrastructure -> Virtual Routers page, it lists 
> only the routers searched by name/instancename/networkname, but not vpc name.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9129) Cannot list vpc routers by keyword in Infrastructure -> Virtual Routers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050393#comment-15050393
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9129:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1197#issuecomment-163539316
  
Did the regression tests:

[1197.network.results.txt](https://github.com/apache/cloudstack/files/57825/1197.network.results.txt)

[1197.vpc.results.txt](https://github.com/apache/cloudstack/files/57826/1197.vpc.results.txt)
and a review: LGTM


> Cannot list vpc routers by keyword in Infrastructure -> Virtual Routers
> ---
>
> Key: CLOUDSTACK-9129
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9129
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> when search by keyword  in Infrastructure -> Virtual Routers page, it lists 
> only the routers searched by name/instancename/networkname, but not vpc name.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050397#comment-15050397
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9114:


Github user ustcweizhou commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1198#discussion_r47202713
  
--- Diff: 
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
 ---
@@ -2558,6 +2575,62 @@ public boolean restartNetwork(Long networkId, 
Account callerAccount, User caller
 }
 }
 
+/* If there are redundant routers in the isolated network, we follow 
the steps to make the network working better
+ *  (1) destroy backup router if exists
+ *  (2) create new backup router
+ *  (3) destroy master router (then the backup will become master)
+ *  (4) create a new router as backup router.
+ */
+private boolean restartGuestNetworkWithRedundantRouters(NetworkVO 
network, List routers, ReservationContext context) throws 
ResourceUnavailableException, ConcurrentOperationException, 
InsufficientCapacityException {
+Account caller = CallContext.current().getCallingAccount();
+long callerUserId = CallContext.current().getCallingUserId();
+
+// check the master and backup redundant state
+DomainRouterVO masterRouter = null;
+DomainRouterVO backupRouter = null;
+if (routers != null && routers.size() == 1) {
+masterRouter = routers.get(0);
+} if (routers != null && routers.size() == 2) {
+DomainRouterVO router1 = routers.get(0);
+DomainRouterVO router2 = routers.get(1);
+if (router1.getRedundantState() == RedundantState.MASTER || 
router2.getRedundantState() == RedundantState.BACKUP) {
+masterRouter = router1;
+backupRouter = router2;
+} else if (router1.getRedundantState() == 
RedundantState.BACKUP || router2.getRedundantState() == RedundantState.MASTER) {
+masterRouter = router2;
+backupRouter = router1;
+} else { // both routers are in UNKNOWN state
+masterRouter = router1;
+backupRouter = router2;
+}
+}
+
+NetworkOfferingVO offering = 
_networkOfferingDao.findByIdIncludingRemoved(network.getNetworkOfferingId());
+DeployDestination dest = new 
DeployDestination(_dcDao.findById(network.getDataCenterId()), null, null, null);
+List providersToImplement = 
getNetworkProviders(network.getId());
+
+// destroy backup router
+if (backupRouter != null) {
+_routerService.destroyRouter(backupRouter.getId(), caller, 
callerUserId);
+}
+// create new backup router
+implementNetworkElements(dest, context, network, offering, 
providersToImplement);
+
+// destroy master router
+if (masterRouter != null) {
+try {
+Thread.sleep(1); // wait 10s for the 
keepalived/conntrackd on backup router
--- End diff --

if we can make sure that the keepalived/conntrackd are running when the VR 
becomes Running.
I think the sleep is needed, no matter we destroy/create backup or master 
router at first, because there is always a state change from BACKUP to MASTER.

in your method, the sleep is not needed at the first step, but it does at 
the second step.



> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050396#comment-15050396
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9114:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1198#issuecomment-163539499
  
Hi @ustcweizhou,

I made a couple of comments in your code that would need addressing. Could 
you have a look at that?

In addition, would you mind improving the smoke/test_vpc_redundant.py in 
order to add a check for the improvements you added?

Did you test this against RVR networks as well?

Cheers,
Wilder


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050403#comment-15050403
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9123:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1204#issuecomment-163539777
  
Thanks, @borisroman!

@michaelandersen, have you already tested this against Xen?

By the way, I did both already.

Cheers,
Wilder


> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050405#comment-15050405
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9123:


Github user michaelandersen commented on the pull request:

https://github.com/apache/cloudstack/pull/1204#issuecomment-163539898
  
Ran tests on Xenserver 6.2:

Results:
```
Test to verify access to loadbalancer haproxy admin stats page ... === 
TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS 
===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic 
to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 
| Status : SUCCESS ===
ok

--
Ran 2 tests in 1064.773s

OK

```
Environment:

```
1 XenServer 6.2
Management Server on CentOS 7.1
```

Test command:
```
nosetests --with-marvin 
--marvin-config=/data/shared/marvin/mct-zone1-xen1.cfg -a 
tags=advanced,required_hardware=true test_internal_lb.py
```

LGTM!
good work @wilderrodrigues 


> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9099) SecretKey is returned from the APIs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050404#comment-15050404
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9099:


Github user kansal commented on the pull request:

https://github.com/apache/cloudstack/pull/1152#issuecomment-163539799
  
@DaanHoogland Sure will try. Will take some time as I have to go through 
the documentation first. 


> SecretKey is returned from the APIs
> ---
>
> Key: CLOUDSTACK-9099
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9099
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kshitij Kansal
>Assignee: Kshitij Kansal
>
> The sercreKey parameter is returned from the following APIs:
> createAccount
> createUser
> disableAccount
> disableUser
> enableAccount
> enableUser
> listAccounts
> listUsers
> lockAccount
> lockUser
> registerUserKeys
> updateAccount
> updateUser



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050407#comment-15050407
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9114:


Github user ustcweizhou commented on the pull request:

https://github.com/apache/cloudstack/pull/1198#issuecomment-163540200
  
@wilderrodrigues thanks for review!
This PR apply on redundant networks, not redundant VR for VPC.
I tested it several times. you may get a result from my first comment of 
this PR.




> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9129) Cannot list vpc routers by keyword in Infrastructure -> Virtual Routers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050412#comment-15050412
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9129:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1197#issuecomment-163540517
  
One of the tests (network_results) says:

Test redundant router internals ... === TestName: 
test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : FAILED ===
FAIL

```
==
FAIL: Test redundant router internals
--
Traceback (most recent call last):
  File 
"/data/git/cs1/cloudstack/test/integration/component/test_routers_network_ops.py",
 line 290, in test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true
"Attempt to retrieve google.com index page should be successful!"
AssertionError: Attempt to retrieve google.com index page should be 
successful!
```

Was it rebased with latest master before tests?

So, do not merge yet. Unless you redo the failed test manually.


> Cannot list vpc routers by keyword in Infrastructure -> Virtual Routers
> ---
>
> Key: CLOUDSTACK-9129
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9129
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> when search by keyword  in Infrastructure -> Virtual Routers page, it lists 
> only the routers searched by name/instancename/networkname, but not vpc name.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9094) Multiple threads are being used to collect the stats from the same VR

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050419#comment-15050419
 ] 

ASF subversion and git services commented on CLOUDSTACK-9094:
-

Commit 88a293b584f42a5467e64c35a08eb2c5d337 in cloudstack's branch 
refs/heads/master from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=88a293b ]

Revert "Merge pull request #1140 from harikrishna-patnala/CLOUDSTACK-9094"

This reverts commit fbc8f5d7e9f31752248905d6ef321b8bfdb2a7cf, reversing
changes made to c67d1da5dd1750cd7e5a95a91a2f31a340988713.


> Multiple threads are being used to collect the stats from the same VR
> -
>
> Key: CLOUDSTACK-9094
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9094
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.6.0
>Reporter: Harikrishna Patnala
>Assignee: Harikrishna Patnala
> Fix For: 4.7.0
>
>
> From the logs we can see that the management server is sending the 
> networkusagecommand to a VR twice within a very short interval. This doesn't 
> have any impact on the network usage being reported, however it seems to 
> consume direct agent threads unnecessarily.
> See the below snippet from the logs where networkusage command was sent to 
> the same VR at the same time
> 2014-03-04 00:02:07,178 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-113:null) Seq 10-1242718973: Executing request
> 2014-03-04 00:02:07,482 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-113:null) Seq 10-1242718973: Response Received:
> 2014-03-04 00:02:07,482 DEBUG [agent.transport.Request] 
> (DirectAgent-113:null) Seq 10-1242718973: Processing:  { Ans: , MgmtId: 
> 144027776315500, via: 10, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-59-VM","bytesSent":2937782,"bytesReceived":114175352,"result":true,"details":"","wait":0}}]
>  }
> 2014-03-04 00:02:07,482 DEBUG [agent.transport.Request] 
> (RouterMonitor-1:null) Seq 10-1242718973: Received:  { Ans: , MgmtId: 
> 144027776315500, via: 10, Ver: v1, Flags: 10, { NetworkUsageAnswer } }
> 2014-03-04 00:02:07,482 DEBUG [agent.manager.AgentManagerImpl] 
> (RouterMonitor-1:null) Details from executing class 
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-03-04 00:02:07,198 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-244:null) Seq 10-1242718974: Executing request
> 2014-03-04 00:02:07,510 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-244:null) Seq 10-1242718974: Response Received:
> 2014-03-04 00:02:07,510 DEBUG [agent.transport.Request] 
> (DirectAgent-244:null) Seq 10-1242718974: Processing:  { Ans: , MgmtId: 
> 144027776315500, via: 10, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-59-VM","bytesSent":2937782,"bytesReceived":114175352,"result":true,"details":"","wait":0}}]
>  }
> 2014-03-04 00:02:07,510 DEBUG [agent.transport.Request] 
> (RouterMonitor-1:null) Seq 10-1242718974: Received:  { Ans: , MgmtId: 
> 144027776315500, via: 10, Ver: v1, Flags: 10, { NetworkUsageAnswer } }
> 2014-03-04 00:02:07,510 DEBUG [agent.manager.AgentManagerImpl] 
> (RouterMonitor-1:null) Details from executing class 
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-03-04 00:02:07,513 DEBUG 
> [network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null) 
> Router stats changed from the time NetworkUsageCommand was sent. Ignoring 
> current answer. Router: r-59-VM Rcvd: 114175352Sent: 2937782
> 2014-03-04 00:02:07,514 DEBUG [db.Transaction.Transaction] 
> (RouterMonitor-1:null) Rolling back the transaction: Time = 2 Name =  
> -VirtualNetworkApplianceManagerImpl$NetworkUsageTask.run:900-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWorker:1146-ThreadPoolExecutor$Worker.run:615-Thread.run:701;
>  called by 
> -Transaction.rollback:897-Transaction.removeUpTo:840-Transaction.close:664-VirtualNetworkApplianceManagerImpl$NetworkUsageTask.run:955-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWorker:1146-ThreadPoolExecutor$Worker.run:615-Thread.run:701



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9129) Cannot list vpc routers by keyword in Infrastructure -> Virtual Routers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050421#comment-15050421
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9129:


Github user ustcweizhou commented on the pull request:

https://github.com/apache/cloudstack/pull/1197#issuecomment-163541483
  
@wilderrodrigues yes, it is rebased with latest master.
going through the files changed in this PR, I think the failure is not 
related to it.
This PR does not touch any operation on networks/vpcs, etc


> Cannot list vpc routers by keyword in Infrastructure -> Virtual Routers
> ---
>
> Key: CLOUDSTACK-9129
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9129
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> when search by keyword  in Infrastructure -> Virtual Routers page, it lists 
> only the routers searched by name/instancename/networkname, but not vpc name.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050424#comment-15050424
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9114:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1198#issuecomment-163541774
  
Hi @ustcweizhou,

The content is a bit misleading because you used the 
```VpcVirtualNetworkApplianceService``` instead of 
```VirtualNetworkApplianceService```.

Concerning the tests, I know you did that. But if tomorrow (or within a 
week) we have to improve it, we will have to do the tests, manually, again. So 
improving the existing integration test will help everybody.

Could you also apply the changes I mentioned against the code, please?

Cheers,
Wilder


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050427#comment-15050427
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9123:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1204#issuecomment-163542058
  
Thanks, @michaelandersen!

Ping @remibergsma @DaanHoogland - this one is ready to be merged.

Cheers,
Wilder


> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8841) Storage XenMotion from XS 6.2 to XS 6.5 fails.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050431#comment-15050431
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8841:


Github user priyankparihar commented on the pull request:

https://github.com/apache/cloudstack/pull/815#issuecomment-163542539
  
@DaanHoogland I did this change because UI does not allow  migration 
between different versions of hyper-visors of  but sometimes user wants to do 
migration from  Lower to Higher Version. So now he can do it via API.


> Storage XenMotion from XS 6.2 to XS 6.5 fails.
> --
>
> Key: CLOUDSTACK-8841
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8841
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Reporter: Priyank Parihar
>
> Storage XenMotion from XS 6.2 to XS 6.5 fails with error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9094) Multiple threads are being used to collect the stats from the same VR

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050429#comment-15050429
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9094:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1140#issuecomment-163542373
  
@harikrishna-patnala This is reverted because of the lack of test report, 
not the logic of your code. If you feel it must go in anyway please rebase the 
code and make a new PR, make sure you add test instruction to up the chance 
reviewers actually test.


> Multiple threads are being used to collect the stats from the same VR
> -
>
> Key: CLOUDSTACK-9094
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9094
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.6.0
>Reporter: Harikrishna Patnala
>Assignee: Harikrishna Patnala
> Fix For: 4.7.0
>
>
> From the logs we can see that the management server is sending the 
> networkusagecommand to a VR twice within a very short interval. This doesn't 
> have any impact on the network usage being reported, however it seems to 
> consume direct agent threads unnecessarily.
> See the below snippet from the logs where networkusage command was sent to 
> the same VR at the same time
> 2014-03-04 00:02:07,178 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-113:null) Seq 10-1242718973: Executing request
> 2014-03-04 00:02:07,482 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-113:null) Seq 10-1242718973: Response Received:
> 2014-03-04 00:02:07,482 DEBUG [agent.transport.Request] 
> (DirectAgent-113:null) Seq 10-1242718973: Processing:  { Ans: , MgmtId: 
> 144027776315500, via: 10, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-59-VM","bytesSent":2937782,"bytesReceived":114175352,"result":true,"details":"","wait":0}}]
>  }
> 2014-03-04 00:02:07,482 DEBUG [agent.transport.Request] 
> (RouterMonitor-1:null) Seq 10-1242718973: Received:  { Ans: , MgmtId: 
> 144027776315500, via: 10, Ver: v1, Flags: 10, { NetworkUsageAnswer } }
> 2014-03-04 00:02:07,482 DEBUG [agent.manager.AgentManagerImpl] 
> (RouterMonitor-1:null) Details from executing class 
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-03-04 00:02:07,198 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-244:null) Seq 10-1242718974: Executing request
> 2014-03-04 00:02:07,510 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-244:null) Seq 10-1242718974: Response Received:
> 2014-03-04 00:02:07,510 DEBUG [agent.transport.Request] 
> (DirectAgent-244:null) Seq 10-1242718974: Processing:  { Ans: , MgmtId: 
> 144027776315500, via: 10, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-59-VM","bytesSent":2937782,"bytesReceived":114175352,"result":true,"details":"","wait":0}}]
>  }
> 2014-03-04 00:02:07,510 DEBUG [agent.transport.Request] 
> (RouterMonitor-1:null) Seq 10-1242718974: Received:  { Ans: , MgmtId: 
> 144027776315500, via: 10, Ver: v1, Flags: 10, { NetworkUsageAnswer } }
> 2014-03-04 00:02:07,510 DEBUG [agent.manager.AgentManagerImpl] 
> (RouterMonitor-1:null) Details from executing class 
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-03-04 00:02:07,513 DEBUG 
> [network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null) 
> Router stats changed from the time NetworkUsageCommand was sent. Ignoring 
> current answer. Router: r-59-VM Rcvd: 114175352Sent: 2937782
> 2014-03-04 00:02:07,514 DEBUG [db.Transaction.Transaction] 
> (RouterMonitor-1:null) Rolling back the transaction: Time = 2 Name =  
> -VirtualNetworkApplianceManagerImpl$NetworkUsageTask.run:900-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWorker:1146-ThreadPoolExecutor$Worker.run:615-Thread.run:701;
>  called by 
> -Transaction.rollback:897-Transaction.removeUpTo:840-Transaction.close:664-VirtualNetworkApplianceManagerImpl$NetworkUsageTask.run:955-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWorker:1146-ThreadPoolExecutor$Worker.run:615-Thread.run:701



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050433#comment-15050433
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9114:


Github user wilderrodrigues commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1198#discussion_r47204055
  
--- Diff: 
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
 ---
@@ -2558,6 +2575,62 @@ public boolean restartNetwork(Long networkId, 
Account callerAccount, User caller
 }
 }
 
+/* If there are redundant routers in the isolated network, we follow 
the steps to make the network working better
+ *  (1) destroy backup router if exists
+ *  (2) create new backup router
+ *  (3) destroy master router (then the backup will become master)
+ *  (4) create a new router as backup router.
+ */
+private boolean restartGuestNetworkWithRedundantRouters(NetworkVO 
network, List routers, ReservationContext context) throws 
ResourceUnavailableException, ConcurrentOperationException, 
InsufficientCapacityException {
+Account caller = CallContext.current().getCallingAccount();
+long callerUserId = CallContext.current().getCallingUserId();
+
+// check the master and backup redundant state
+DomainRouterVO masterRouter = null;
+DomainRouterVO backupRouter = null;
+if (routers != null && routers.size() == 1) {
+masterRouter = routers.get(0);
+} if (routers != null && routers.size() == 2) {
+DomainRouterVO router1 = routers.get(0);
+DomainRouterVO router2 = routers.get(1);
+if (router1.getRedundantState() == RedundantState.MASTER || 
router2.getRedundantState() == RedundantState.BACKUP) {
+masterRouter = router1;
+backupRouter = router2;
+} else if (router1.getRedundantState() == 
RedundantState.BACKUP || router2.getRedundantState() == RedundantState.MASTER) {
+masterRouter = router2;
+backupRouter = router1;
+} else { // both routers are in UNKNOWN state
+masterRouter = router1;
+backupRouter = router2;
+}
+}
+
+NetworkOfferingVO offering = 
_networkOfferingDao.findByIdIncludingRemoved(network.getNetworkOfferingId());
+DeployDestination dest = new 
DeployDestination(_dcDao.findById(network.getDataCenterId()), null, null, null);
+List providersToImplement = 
getNetworkProviders(network.getId());
+
+// destroy backup router
+if (backupRouter != null) {
+_routerService.destroyRouter(backupRouter.getId(), caller, 
callerUserId);
+}
+// create new backup router
+implementNetworkElements(dest, context, network, offering, 
providersToImplement);
+
+// destroy master router
+if (masterRouter != null) {
+try {
+Thread.sleep(1); // wait 10s for the 
keepalived/conntrackd on backup router
--- End diff --

It's a blocking call, you don't need it. Also, the keepalived is started 
with the kernel module. It would be way easier to prove the behaviour with an 
automated test.

If you don't feel confident with writing the test, I can do it after 
christmas/new year and change the java code as well.


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8847) ListServiceOfferings is returning incompatible tagged offerings when called with VM id

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050444#comment-15050444
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8847:


Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/823#issuecomment-163550095
  
@DaanHoogland : No, it needn't not be an exact match but the new one should 
be a superset of the current one. According to your scenario, as the new one 
supports (x,y) as well as supports an extra tag (z). The interpretation will be 
more clear if we think of this in terms of venn diagram.

The migration will fail in running mode. Dynamic scaling cannot be done. It 
will only be done on reboot.


> ListServiceOfferings is returning incompatible tagged offerings when called 
> with VM id
> --
>
> Key: CLOUDSTACK-8847
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8847
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> When calling listServiceOfferings with VM id as parameter. It is returning 
> incompatible tagged offerings. It should only list all compatible tagged 
> offerings. The new service offering should contain all the tags of the 
> existing service offering. If that is the case It should list in the result.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050445#comment-15050445
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9114:


Github user ustcweizhou commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1198#discussion_r47204914
  
--- Diff: 
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
 ---
@@ -2558,6 +2575,62 @@ public boolean restartNetwork(Long networkId, 
Account callerAccount, User caller
 }
 }
 
+/* If there are redundant routers in the isolated network, we follow 
the steps to make the network working better
+ *  (1) destroy backup router if exists
+ *  (2) create new backup router
+ *  (3) destroy master router (then the backup will become master)
+ *  (4) create a new router as backup router.
+ */
+private boolean restartGuestNetworkWithRedundantRouters(NetworkVO 
network, List routers, ReservationContext context) throws 
ResourceUnavailableException, ConcurrentOperationException, 
InsufficientCapacityException {
+Account caller = CallContext.current().getCallingAccount();
+long callerUserId = CallContext.current().getCallingUserId();
+
+// check the master and backup redundant state
+DomainRouterVO masterRouter = null;
+DomainRouterVO backupRouter = null;
+if (routers != null && routers.size() == 1) {
+masterRouter = routers.get(0);
+} if (routers != null && routers.size() == 2) {
+DomainRouterVO router1 = routers.get(0);
+DomainRouterVO router2 = routers.get(1);
+if (router1.getRedundantState() == RedundantState.MASTER || 
router2.getRedundantState() == RedundantState.BACKUP) {
+masterRouter = router1;
+backupRouter = router2;
+} else if (router1.getRedundantState() == 
RedundantState.BACKUP || router2.getRedundantState() == RedundantState.MASTER) {
+masterRouter = router2;
+backupRouter = router1;
+} else { // both routers are in UNKNOWN state
+masterRouter = router1;
+backupRouter = router2;
+}
+}
+
+NetworkOfferingVO offering = 
_networkOfferingDao.findByIdIncludingRemoved(network.getNetworkOfferingId());
+DeployDestination dest = new 
DeployDestination(_dcDao.findById(network.getDataCenterId()), null, null, null);
+List providersToImplement = 
getNetworkProviders(network.getId());
+
+// destroy backup router
+if (backupRouter != null) {
+_routerService.destroyRouter(backupRouter.getId(), caller, 
callerUserId);
+}
+// create new backup router
+implementNetworkElements(dest, context, network, offering, 
providersToImplement);
+
+// destroy master router
+if (masterRouter != null) {
+try {
+Thread.sleep(1); // wait 10s for the 
keepalived/conntrackd on backup router
--- End diff --

@wilderrodrigues 
I made this change for 4.2.1 at first. I met some issues during the 
restartnetwork because of the keepalived/conntrackd, hence I added the sleep. 
10 seconds is enough to wait the services to be running.
I did not check the difference between keepalived on Debian 7.0.0 and 
Debian 7.9.0, so I thought the issue still exist.

I am busy on other issues and have no time on writing the test, automated 
test and improvement are welcome.




> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9129) Cannot list vpc routers by keyword in Infrastructure -> Virtual Routers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050454#comment-15050454
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9129:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1197#issuecomment-163554166
  
@ustcweizhou, @wilderrodrigues is right to ask for a retest anyway, will do


> Cannot list vpc routers by keyword in Infrastructure -> Virtual Routers
> ---
>
> Key: CLOUDSTACK-9129
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9129
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> when search by keyword  in Infrastructure -> Virtual Routers page, it lists 
> only the routers searched by name/instancename/networkname, but not vpc name.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050455#comment-15050455
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9114:


Github user ustcweizhou commented on the pull request:

https://github.com/apache/cloudstack/pull/1198#issuecomment-163554256
  
@wilderrodrigues 

I used VirtualNetworkApplianceService at first, and met an issue like:
"spring autowiring with unique beans: Spring expected single matching bean 
but found 2"
this is because some functions are implemented in both of 
VirtualNetworkApplianceManagerImpl and VpcVirtualNetworkApplianceManagerImpl .

I changed it back to VirtualNetworkApplianceService  just now, the 
compilation succeed, the issue  does not exist any more, weird. 

Anyway, I think it is not important. that is the same to definition in 
api/src/org/apache/cloudstack/api/BaseCmd.java:
public VpcVirtualNetworkApplianceService _routerService;



> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050461#comment-15050461
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9114:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1198#issuecomment-163557163
  
I know this issue. You can get it working with @Autowire and @Quialifier 
annotations. If BaseCmd does the same, then it should be fine.

Cheers,
Wilder


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9129) Cannot list vpc routers by keyword in Infrastructure -> Virtual Routers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050480#comment-15050480
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9129:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1197#issuecomment-163560328
  
LGTM Tested the actual feature:

Created a VPC:
![screen shot 2015-12-10 at 10 49 
05](https://cloud.githubusercontent.com/assets/1630096/11712205/b9f2dfee-9f2b-11e5-9840-9c7c4f991cf8.png)

Tried to search for it:
![screen shot 2015-12-10 at 10 53 
21](https://cloud.githubusercontent.com/assets/1630096/11712280/474ee108-9f2c-11e5-8aab-560c45cfd0b5.png)

Tried a search that should result noting:
![screen shot 2015-12-10 at 10 53 
29](https://cloud.githubusercontent.com/assets/1630096/11712285/50efcda8-9f2c-11e5-97b3-efff2d3a2e94.png)

Before merge, be sure all integration tests pass. If you need help, let me 
know.


> Cannot list vpc routers by keyword in Infrastructure -> Virtual Routers
> ---
>
> Key: CLOUDSTACK-9129
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9129
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> when search by keyword  in Infrastructure -> Virtual Routers page, it lists 
> only the routers searched by name/instancename/networkname, but not vpc name.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050488#comment-15050488
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9131:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1201#issuecomment-163562169
  
LGTM, both users and admins can login with/without this plugin enabled.

User login with plugin disabled:
![screen shot 2015-12-10 at 10 52 
03](https://cloud.githubusercontent.com/assets/1630096/11712364/db9e8da4-9f2c-11e5-9ba2-40bce6da2aba.png)

Enabled plugin, restarted mgt afterwards:
![screen shot 2015-12-10 at 10 53 
29](https://cloud.githubusercontent.com/assets/1630096/11712356/ce88281e-9f2c-11e5-87bf-56f403b95a06.png)

Admin with plugin enabled:
![screen shot 2015-12-10 at 10 55 
44](https://cloud.githubusercontent.com/assets/1630096/11712349/c34388b8-9f2c-11e5-988e-b7f795dfdf36.png)

User with plugin enabled:
![screen shot 2015-12-10 at 10 56 
05](https://cloud.githubusercontent.com/assets/1630096/11712346/b9fab7f4-9f2c-11e5-99e7-ce1f0694269b.png)

Pinging @DaanHoogland to also review.

I will also start some integration tests to be sure.


> User/Domain admin cannot login to UI
> 
>
> Key: CLOUDSTACK-9131
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9131
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Abhinandan Prateek
>Priority: Blocker
> Attachments: Screen Shot 2015-12-09 at 11.08.47.png
>
>
> The Quota plugin checks whether the plugin is enabled but the call it uses it 
> only available for root admins. As a result, no one can login except for root 
> admins.
> Pinging [~bhaisaab]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050507#comment-15050507
 ] 

ASF subversion and git services commented on CLOUDSTACK-9123:
-

Commit cd81982b3948e0d033baa4ea1d47b1aa93e36495 in cloudstack's branch 
refs/heads/master from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cd81982 ]

Merge pull request #1204 from ekholabs/improve/test-internal-lb-CLOUDSTACK-9123

CLOUDSTACK-9123 - As a Developer I want the test_internal_lb.py to work with 
multiple hypervisorsThis PR make the test_internal_lb.py work with other 
Hypervisors types.

   - Get hypervisor information from testClient.getHypervisorInfo()
   - Adds XenServer, HyperV and VMware hypervisors
   - Makes sure the OS type is "Other PV (64-bit)"

* pr/1204:
  CLOUDSTACK-9123 - Make test compliant with multiple hypervisors

Signed-off-by: Remi Bergsma 


> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050508#comment-15050508
 ] 

ASF subversion and git services commented on CLOUDSTACK-9123:
-

Commit cd81982b3948e0d033baa4ea1d47b1aa93e36495 in cloudstack's branch 
refs/heads/master from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cd81982 ]

Merge pull request #1204 from ekholabs/improve/test-internal-lb-CLOUDSTACK-9123

CLOUDSTACK-9123 - As a Developer I want the test_internal_lb.py to work with 
multiple hypervisorsThis PR make the test_internal_lb.py work with other 
Hypervisors types.

   - Get hypervisor information from testClient.getHypervisorInfo()
   - Adds XenServer, HyperV and VMware hypervisors
   - Makes sure the OS type is "Other PV (64-bit)"

* pr/1204:
  CLOUDSTACK-9123 - Make test compliant with multiple hypervisors

Signed-off-by: Remi Bergsma 


> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050505#comment-15050505
 ] 

ASF subversion and git services commented on CLOUDSTACK-9123:
-

Commit c7f5e8a82724d09b61884e1f45f3995a93f9e3a0 in cloudstack's branch 
refs/heads/master from [~wilder.rodrigues]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c7f5e8a ]

CLOUDSTACK-9123 - Make test compliant with multiple hypervisors

   - Get hypervisor information from testClient.getHypervisorInfo()
   - Adds HyperV and VMware hypervisors
   - Makes sure the OS type is "Other PV (64-bit)"


> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050506#comment-15050506
 ] 

ASF subversion and git services commented on CLOUDSTACK-9123:
-

Commit cd81982b3948e0d033baa4ea1d47b1aa93e36495 in cloudstack's branch 
refs/heads/master from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cd81982 ]

Merge pull request #1204 from ekholabs/improve/test-internal-lb-CLOUDSTACK-9123

CLOUDSTACK-9123 - As a Developer I want the test_internal_lb.py to work with 
multiple hypervisorsThis PR make the test_internal_lb.py work with other 
Hypervisors types.

   - Get hypervisor information from testClient.getHypervisorInfo()
   - Adds XenServer, HyperV and VMware hypervisors
   - Makes sure the OS type is "Other PV (64-bit)"

* pr/1204:
  CLOUDSTACK-9123 - Make test compliant with multiple hypervisors

Signed-off-by: Remi Bergsma 


> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050509#comment-15050509
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9123:


Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/1204


> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9127) Missing PV-bootloader-args for "SUSE Linux Enterprise Server 10 SP2 and SP3"

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050548#comment-15050548
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9127:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1196#issuecomment-163570286
  
LGTM based on these tests:

```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a 
tags=advanced,required_hardware=true \
component/test_vpc_redundant.py \
component/test_routers_iptables_default_policy.py \
component/test_routers_network_ops.py \
component/test_vpc_router_nics.py \
smoke/test_loadbalance.py \
smoke/test_internal_lb.py \
smoke/test_ssvm.py \
smoke/test_network.py

```

Result:

```
Test iptables default INPUT/FORWARD policies on VPC router ... === 
TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test nics 
after destroy ... === TestName: test_01_VPC_nics_after_destroy | Status : 
SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test default 
routes ... === TestName: test_02_VPC_default_routes | Status : SUCCESS ===
ok
Check the password file in the Router VM ... === TestName: 
test_isolate_network_password_server | Status : SUCCESS ===
ok
Check that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... === 
TestName: test_router_dhcphosts | Status : SUCCESS ===
ok
Test to create Load balancing rule with source NAT ... === TestName: 
test_01_create_lb_rule_src_nat | Status : SUCCESS ===
ok
Test to create Load balancing rule with non source NAT ... === TestName: 
test_02_create_lb_rule_non_nat | Status : SUCCESS ===
ok
Test for assign & removing load balancing rule ... === TestName: 
test_assign_and_removal_lb | Status : SUCCESS ===
ok
Test to verify access to loadbalancer haproxy admin stats page ... === 
TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS 
===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic 
to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 
| Status : SUCCESS ===
ok
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status : 
SUCCESS ===
ok
Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status : 
SUCCESS ===
ok
Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS ===
ok
Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS ===
ok
Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS 
===
ok
Test reboot CPVM ... === TestName: test_08_reboot_cpvm | Status : SUCCESS 
===
ok
Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : SUCCESS 
===
ok
Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : SUCCESS 
===
ok
Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn 
| Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS 
===
ok
Test for port forwarding on source NAT ... === TestName: 
test_01_port_fwd_on_src_nat | Status : SUCCESS ===
ok
Test for port forwarding on non source NAT ... === TestName: 
test_02_port_fwd_on_non_src_nat | Status : SUCCESS ===
ok
Test for reboot router ... === TestName: test_reboot_router | Status : 
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status : 
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: test_network_rules_acquired_public_ip_2_nat_rule | Status : SUCCESS 
===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: test_network_rules_acquired_public_ip_3_Load_Balancer_Rule | Status : 
SUCCESS ===
ok

--
Ran 33 tests in 18877.209s

OK
```


And:

```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a 
tags=advanced,requir

[jira] [Updated] (CLOUDSTACK-4374) Enable HA for routers that are part or a redundant network or VPC

[Wilder Rodrigues (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues updated CLOUDSTACK-4374:
-
Summary: Enable HA for routers that are part or a redundant network or VPC  
(was: No HA for redundant routers)

> Enable HA for routers that are part or a redundant network or VPC
> -
>
> Key: CLOUDSTACK-4374
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4374
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.1.0
>Reporter: Roeland Kuipers
>Assignee: Wilder Rodrigues
>
> We provide redundant routers with HA functionality through a special service 
> offering.
> However these router pairs are provisioned with ha_enabled=0, so when one or 
> both of them fail they will never be restarted by CS. 
> 2013-08-16 15:51:16,101 DEBUG [cloud.ha.HighAvailabilityManagerImpl] 
> (HA-Worker-0:work-4335) VM is not HA enabled so we're done.
> This is currently hardcoded in VirtualNetworkApplianceManagerImpl.java @ 1633
>boolean offerHA = routerOffering.getOfferHA();
> /* We don't provide HA to redundant router VMs, admin should 
> own it all, and redundant router themselves are HA */
> if (isRedundant) {
> offerHA = false;
> }
> We like redundancy and like to have HA on our redundant routers. We like to 
> configure this ourselves through service offerings and do not like being helt 
> hostage by these lines of codes:) We do like to own it all in our admin role 
> :)
> Besides this, this is also very counter-intuitive as we were expecting HA on 
> our redundant routers, since it was configured on their service offering.
> So can we get rid of these lines of code? And have this controlled through 
> service offerings as it should IMHO.? Unless this has negative impact which 
> we are not aware off?
> Cheers & Thanks,
> Roeland
> Details of the original commit which injected this code:
> Commit: a269b089ae38d0d04db2fa0f4c8e839480476ddc [a269b08]
> Parents: a2cc66ce41
> Author: Sheng Yang 
> Date: 17 december 2011 03:52:59 CET
> Commit Date: 19 december 2011 22:29:48 CET
> bug 12608: NaaS: Don't shutdown elements if cleanup=false
> We can use the restartNetwork mechanism to recover the disconnected redundant
> router.
> Also disable HA for redundant router. Admin would take responsibilty to 
> recover
> the failure router, because redundant routers themselves are one layer HA.
> status 12608: resolved fixed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-4374) No HA for redundant routers

[Wilder Rodrigues (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues reassigned CLOUDSTACK-4374:


Assignee: Wilder Rodrigues

> No HA for redundant routers
> ---
>
> Key: CLOUDSTACK-4374
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4374
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.1.0
>Reporter: Roeland Kuipers
>Assignee: Wilder Rodrigues
>
> We provide redundant routers with HA functionality through a special service 
> offering.
> However these router pairs are provisioned with ha_enabled=0, so when one or 
> both of them fail they will never be restarted by CS. 
> 2013-08-16 15:51:16,101 DEBUG [cloud.ha.HighAvailabilityManagerImpl] 
> (HA-Worker-0:work-4335) VM is not HA enabled so we're done.
> This is currently hardcoded in VirtualNetworkApplianceManagerImpl.java @ 1633
>boolean offerHA = routerOffering.getOfferHA();
> /* We don't provide HA to redundant router VMs, admin should 
> own it all, and redundant router themselves are HA */
> if (isRedundant) {
> offerHA = false;
> }
> We like redundancy and like to have HA on our redundant routers. We like to 
> configure this ourselves through service offerings and do not like being helt 
> hostage by these lines of codes:) We do like to own it all in our admin role 
> :)
> Besides this, this is also very counter-intuitive as we were expecting HA on 
> our redundant routers, since it was configured on their service offering.
> So can we get rid of these lines of code? And have this controlled through 
> service offerings as it should IMHO.? Unless this has negative impact which 
> we are not aware off?
> Cheers & Thanks,
> Roeland
> Details of the original commit which injected this code:
> Commit: a269b089ae38d0d04db2fa0f4c8e839480476ddc [a269b08]
> Parents: a2cc66ce41
> Author: Sheng Yang 
> Date: 17 december 2011 03:52:59 CET
> Commit Date: 19 december 2011 22:29:48 CET
> bug 12608: NaaS: Don't shutdown elements if cleanup=false
> We can use the restartNetwork mechanism to recover the disconnected redundant
> router.
> Also disable HA for redundant router. Admin would take responsibilty to 
> recover
> the failure router, because redundant routers themselves are one layer HA.
> status 12608: resolved fixed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-4374) Enable HA for routers that are part or a redundant network or VPC

[Wilder Rodrigues (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050573#comment-15050573
 ] 

Wilder Rodrigues commented on CLOUDSTACK-4374:
--

I will fix this.

Redundant Routers is not the same as Haigh Available. What makes a network 
redundant is having 2 routers that are managed by a third part application, for 
instance keepalived. Having a router HA is actually saying that the given 
router will be controlled by the  High Availability monitor. Hence fix any 
problem we might face.

To sum it up: high availability and redundancy are 2 different things, 
conceptually.

Cheers,
Wilder

> Enable HA for routers that are part or a redundant network or VPC
> -
>
> Key: CLOUDSTACK-4374
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4374
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.1.0
>Reporter: Roeland Kuipers
>Assignee: Wilder Rodrigues
>
> We provide redundant routers with HA functionality through a special service 
> offering.
> However these router pairs are provisioned with ha_enabled=0, so when one or 
> both of them fail they will never be restarted by CS. 
> 2013-08-16 15:51:16,101 DEBUG [cloud.ha.HighAvailabilityManagerImpl] 
> (HA-Worker-0:work-4335) VM is not HA enabled so we're done.
> This is currently hardcoded in VirtualNetworkApplianceManagerImpl.java @ 1633
>boolean offerHA = routerOffering.getOfferHA();
> /* We don't provide HA to redundant router VMs, admin should 
> own it all, and redundant router themselves are HA */
> if (isRedundant) {
> offerHA = false;
> }
> We like redundancy and like to have HA on our redundant routers. We like to 
> configure this ourselves through service offerings and do not like being helt 
> hostage by these lines of codes:) We do like to own it all in our admin role 
> :)
> Besides this, this is also very counter-intuitive as we were expecting HA on 
> our redundant routers, since it was configured on their service offering.
> So can we get rid of these lines of code? And have this controlled through 
> service offerings as it should IMHO.? Unless this has negative impact which 
> we are not aware off?
> Cheers & Thanks,
> Roeland
> Details of the original commit which injected this code:
> Commit: a269b089ae38d0d04db2fa0f4c8e839480476ddc [a269b08]
> Parents: a2cc66ce41
> Author: Sheng Yang 
> Date: 17 december 2011 03:52:59 CET
> Commit Date: 19 december 2011 22:29:48 CET
> bug 12608: NaaS: Don't shutdown elements if cleanup=false
> We can use the restartNetwork mechanism to recover the disconnected redundant
> router.
> Also disable HA for redundant router. Admin would take responsibilty to 
> recover
> the failure router, because redundant routers themselves are one layer HA.
> status 12608: resolved fixed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050580#comment-15050580
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9131:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1201#issuecomment-163578041
  
Integration tests are also OK:

```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a 
tags=advanced,required_hardware=true \
component/test_vpc_redundant.py \
component/test_routers_iptables_default_policy.py \
component/test_routers_network_ops.py \
component/test_vpc_router_nics.py \
smoke/test_loadbalance.py \
smoke/test_internal_lb.py \
smoke/test_ssvm.py \
smoke/test_network.py

```

Result:

```
Test iptables default INPUT/FORWARD policies on VPC router ... === 
TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test nics 
after destroy ... === TestName: test_01_VPC_nics_after_destroy | Status : 
SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test default 
routes ... === TestName: test_02_VPC_default_routes | Status : SUCCESS ===
ok
Check the password file in the Router VM ... === TestName: 
test_isolate_network_password_server | Status : SUCCESS ===
ok
Check that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... === 
TestName: test_router_dhcphosts | Status : SUCCESS ===
ok
Test to create Load balancing rule with source NAT ... === TestName: 
test_01_create_lb_rule_src_nat | Status : SUCCESS ===
ok
Test to create Load balancing rule with non source NAT ... === TestName: 
test_02_create_lb_rule_non_nat | Status : SUCCESS ===
ok
Test for assign & removing load balancing rule ... === TestName: 
test_assign_and_removal_lb | Status : SUCCESS ===
ok
Test to verify access to loadbalancer haproxy admin stats page ... === 
TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS 
===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic 
to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 
| Status : SUCCESS ===
ok
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status : 
SUCCESS ===
ok
Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status : 
SUCCESS ===
ok
Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS ===
ok
Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS ===
ok
Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS 
===
ok
Test reboot CPVM ... === TestName: test_08_reboot_cpvm | Status : SUCCESS 
===
ok
Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : SUCCESS 
===
ok
Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : SUCCESS 
===
ok
Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn 
| Status : SUCCESS ===
ok
Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS 
===
ok
Test for port forwarding on source NAT ... === TestName: 
test_01_port_fwd_on_src_nat | Status : SUCCESS ===
ok
Test for port forwarding on non source NAT ... === TestName: 
test_02_port_fwd_on_non_src_nat | Status : SUCCESS ===
ok
Test for reboot router ... === TestName: test_reboot_router | Status : 
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status : 
SUCCESS ===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: test_network_rules_acquired_public_ip_2_nat_rule | Status : SUCCESS 
===
ok
Test for Router rules for network rules on acquired public IP ... === 
TestName: test_network_rules_acquired_public_ip_3_Load_Balancer_Rule | Status : 
SUCCESS ===
ok

--
Ran 33 tests in 19982.059s

OK
```


And:

```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a 
tags=advanced,re

[jira] [Commented] (CLOUDSTACK-9127) Missing PV-bootloader-args for "SUSE Linux Enterprise Server 10 SP2 and SP3"

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050582#comment-15050582
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9127:


Github user wilderrodrigues commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1196#discussion_r47212450
  
--- Diff: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixHelper.java
 ---
@@ -236,4 +236,15 @@ public static String getProductVersion(final 
Host.Record record) {
 }
 return prodVersion;
 }
+
+public static String getPVbootloaderArgs(String guestOS) {
+if (guestOS.startsWith("SUSE Linux Enterprise Server")) {
+if (guestOS.contains("64-bit")) {
+return "--kernel /boot/vmlinuz-xen --ramdisk 
/boot/initrd-xen";
+} else if (guestOS.contains("32-bit")) {
+return "--kernel /boot/vmlinuz-xenpae --ramdisk 
/boot/initrd-xenpae";
+}
+}
+return "";
+}
--- End diff --

Change looks good and simple. Could you please add an unit test to cover 
the new method?

Cheers,
Wilder


> Missing PV-bootloader-args for "SUSE Linux Enterprise Server 10 SP2 and SP3"
> 
>
> Key: CLOUDSTACK-9127
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9127
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>
> STOP-START of SUSE Linux VMs fail, as PV-bootloader-args are missing during 
> the start command.
> DESCRIPTION
> ===
> Repro steps
> 1. Upload Suse ISO 
> 2. Create a VM with this ISO, and install it.
> 3. Detach ISO from the VM. 
> 4. Reboot the VM, : This will work fine, as the pv-bootloader-args are 
> not missing during reboot.
> 5.Stop the VM from CCP(VM will get destroyed in Xencenter)
> 6. Start the same VM from CCP , it will try to start but will fail with below 
> error



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9127) Missing PV-bootloader-args for "SUSE Linux Enterprise Server 10 SP2 and SP3"

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050584#comment-15050584
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9127:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1196#issuecomment-163578421
  
Thanks for testing and adding the screenshots, @SudharmaJain!

Waiting for you reply on the unit test question I asked.


> Missing PV-bootloader-args for "SUSE Linux Enterprise Server 10 SP2 and SP3"
> 
>
> Key: CLOUDSTACK-9127
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9127
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>
> STOP-START of SUSE Linux VMs fail, as PV-bootloader-args are missing during 
> the start command.
> DESCRIPTION
> ===
> Repro steps
> 1. Upload Suse ISO 
> 2. Create a VM with this ISO, and install it.
> 3. Detach ISO from the VM. 
> 4. Reboot the VM, : This will work fine, as the pv-bootloader-args are 
> not missing during reboot.
> 5.Stop the VM from CCP(VM will get destroyed in Xencenter)
> 6. Start the same VM from CCP , it will try to start but will fail with below 
> error



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050589#comment-15050589
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9131:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1201#issuecomment-163579051
  
Had a look at the code and trusting @remibergsma his test work: LGTM


> User/Domain admin cannot login to UI
> 
>
> Key: CLOUDSTACK-9131
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9131
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Abhinandan Prateek
>Priority: Blocker
> Attachments: Screen Shot 2015-12-09 at 11.08.47.png
>
>
> The Quota plugin checks whether the plugin is enabled but the call it uses it 
> only available for root admins. As a result, no one can login except for root 
> admins.
> Pinging [~bhaisaab]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050598#comment-15050598
 ] 

ASF subversion and git services commented on CLOUDSTACK-9131:
-

Commit 0c7a5620fdde9bf62af9246af5dc681d1c144d28 in cloudstack's branch 
refs/heads/master from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0c7a562 ]

Merge pull request #1201 from shapeblue/master-CLOUDSTACK-9131

CLOUDSTACK-9131: Create a new API to check if the plugin is enabled.
Adding a new command to check if the quota plugin is enabled.
Also changed the command version to 4.7.

* pr/1201:
  CLOUDSTACK-9131: Create a new API to check if the plugin is enabled.

Signed-off-by: Remi Bergsma 


> User/Domain admin cannot login to UI
> 
>
> Key: CLOUDSTACK-9131
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9131
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Abhinandan Prateek
>Priority: Blocker
> Attachments: Screen Shot 2015-12-09 at 11.08.47.png
>
>
> The Quota plugin checks whether the plugin is enabled but the call it uses it 
> only available for root admins. As a result, no one can login except for root 
> admins.
> Pinging [~bhaisaab]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050595#comment-15050595
 ] 

ASF subversion and git services commented on CLOUDSTACK-9131:
-

Commit 0c7a5620fdde9bf62af9246af5dc681d1c144d28 in cloudstack's branch 
refs/heads/master from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0c7a562 ]

Merge pull request #1201 from shapeblue/master-CLOUDSTACK-9131

CLOUDSTACK-9131: Create a new API to check if the plugin is enabled.
Adding a new command to check if the quota plugin is enabled.
Also changed the command version to 4.7.

* pr/1201:
  CLOUDSTACK-9131: Create a new API to check if the plugin is enabled.

Signed-off-by: Remi Bergsma 


> User/Domain admin cannot login to UI
> 
>
> Key: CLOUDSTACK-9131
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9131
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Abhinandan Prateek
>Priority: Blocker
> Attachments: Screen Shot 2015-12-09 at 11.08.47.png
>
>
> The Quota plugin checks whether the plugin is enabled but the call it uses it 
> only available for root admins. As a result, no one can login except for root 
> admins.
> Pinging [~bhaisaab]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050594#comment-15050594
 ] 

ASF subversion and git services commented on CLOUDSTACK-9131:
-

Commit 3e22fbe457152934387847ccbc8dc46fbe915a1b in cloudstack's branch 
refs/heads/master from [~abhi_shapeblue]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3e22fbe ]

CLOUDSTACK-9131: Create a new API to check if the plugin is enabled.

fixing type


> User/Domain admin cannot login to UI
> 
>
> Key: CLOUDSTACK-9131
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9131
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Abhinandan Prateek
>Priority: Blocker
> Attachments: Screen Shot 2015-12-09 at 11.08.47.png
>
>
> The Quota plugin checks whether the plugin is enabled but the call it uses it 
> only available for root admins. As a result, no one can login except for root 
> admins.
> Pinging [~bhaisaab]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050599#comment-15050599
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9131:


Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/1201


> User/Domain admin cannot login to UI
> 
>
> Key: CLOUDSTACK-9131
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9131
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Abhinandan Prateek
>Priority: Blocker
> Attachments: Screen Shot 2015-12-09 at 11.08.47.png
>
>
> The Quota plugin checks whether the plugin is enabled but the call it uses it 
> only available for root admins. As a result, no one can login except for root 
> admins.
> Pinging [~bhaisaab]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050597#comment-15050597
 ] 

ASF subversion and git services commented on CLOUDSTACK-9131:
-

Commit 0c7a5620fdde9bf62af9246af5dc681d1c144d28 in cloudstack's branch 
refs/heads/master from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0c7a562 ]

Merge pull request #1201 from shapeblue/master-CLOUDSTACK-9131

CLOUDSTACK-9131: Create a new API to check if the plugin is enabled.
Adding a new command to check if the quota plugin is enabled.
Also changed the command version to 4.7.

* pr/1201:
  CLOUDSTACK-9131: Create a new API to check if the plugin is enabled.

Signed-off-by: Remi Bergsma 


> User/Domain admin cannot login to UI
> 
>
> Key: CLOUDSTACK-9131
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9131
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Abhinandan Prateek
>Priority: Blocker
> Attachments: Screen Shot 2015-12-09 at 11.08.47.png
>
>
> The Quota plugin checks whether the plugin is enabled but the call it uses it 
> only available for root admins. As a result, no one can login except for root 
> admins.
> Pinging [~bhaisaab]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-9131.
--
Resolution: Fixed

PR merged

> User/Domain admin cannot login to UI
> 
>
> Key: CLOUDSTACK-9131
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9131
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Abhinandan Prateek
>Priority: Blocker
> Attachments: Screen Shot 2015-12-09 at 11.08.47.png
>
>
> The Quota plugin checks whether the plugin is enabled but the call it uses it 
> only available for root admins. As a result, no one can login except for root 
> admins.
> Pinging [~bhaisaab]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-9131.


> User/Domain admin cannot login to UI
> 
>
> Key: CLOUDSTACK-9131
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9131
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Abhinandan Prateek
>Priority: Blocker
> Attachments: Screen Shot 2015-12-09 at 11.08.47.png
>
>
> The Quota plugin checks whether the plugin is enabled but the call it uses it 
> only available for root admins. As a result, no one can login except for root 
> admins.
> Pinging [~bhaisaab]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9129) Cannot list vpc routers by keyword in Infrastructure -> Virtual Routers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050602#comment-15050602
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9129:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1197#issuecomment-163579922
  
I reran the test and it failed again:
```
Test redundant router internals ... === TestName: 
test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : FAILED ===
FAIL
Test redundant router internals ... === TestName: 
test_03_RVR_Network_check_router_state | Status : SUCCESS ===
ok

==
FAIL: Test redundant router internals
--
Traceback (most recent call last):
  File 
"/data/git/cs1/cloudstack/test/integration/component/test_routers_network_ops.py",
 line 483, in test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false
"Attempt to retrieve google.com index page should be successful once 
rule is added!"
AssertionError: Attempt to retrieve google.com index page should be 
successful once rule is added!
 >> begin captured logging << 
```


> Cannot list vpc routers by keyword in Infrastructure -> Virtual Routers
> ---
>
> Key: CLOUDSTACK-9129
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9129
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> when search by keyword  in Infrastructure -> Virtual Routers page, it lists 
> only the routers searched by name/instancename/networkname, but not vpc name.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-4374) Enable HA for routers that are part or a redundant network or VPC

[Wilder Rodrigues (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues updated CLOUDSTACK-4374:
-
Affects Version/s: 4.6.1
   4.4.0
   4.5.0
   4.6.0

> Enable HA for routers that are part or a redundant network or VPC
> -
>
> Key: CLOUDSTACK-4374
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4374
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.1.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1
>Reporter: Roeland Kuipers
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0, 4.6.2
>
>
> We provide redundant routers with HA functionality through a special service 
> offering.
> However these router pairs are provisioned with ha_enabled=0, so when one or 
> both of them fail they will never be restarted by CS. 
> 2013-08-16 15:51:16,101 DEBUG [cloud.ha.HighAvailabilityManagerImpl] 
> (HA-Worker-0:work-4335) VM is not HA enabled so we're done.
> This is currently hardcoded in VirtualNetworkApplianceManagerImpl.java @ 1633
>boolean offerHA = routerOffering.getOfferHA();
> /* We don't provide HA to redundant router VMs, admin should 
> own it all, and redundant router themselves are HA */
> if (isRedundant) {
> offerHA = false;
> }
> We like redundancy and like to have HA on our redundant routers. We like to 
> configure this ourselves through service offerings and do not like being helt 
> hostage by these lines of codes:) We do like to own it all in our admin role 
> :)
> Besides this, this is also very counter-intuitive as we were expecting HA on 
> our redundant routers, since it was configured on their service offering.
> So can we get rid of these lines of code? And have this controlled through 
> service offerings as it should IMHO.? Unless this has negative impact which 
> we are not aware off?
> Cheers & Thanks,
> Roeland
> Details of the original commit which injected this code:
> Commit: a269b089ae38d0d04db2fa0f4c8e839480476ddc [a269b08]
> Parents: a2cc66ce41
> Author: Sheng Yang 
> Date: 17 december 2011 03:52:59 CET
> Commit Date: 19 december 2011 22:29:48 CET
> bug 12608: NaaS: Don't shutdown elements if cleanup=false
> We can use the restartNetwork mechanism to recover the disconnected redundant
> router.
> Also disable HA for redundant router. Admin would take responsibilty to 
> recover
> the failure router, because redundant routers themselves are one layer HA.
> status 12608: resolved fixed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-4374) Enable HA for routers that are part or a redundant network or VPC

[Wilder Rodrigues (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues updated CLOUDSTACK-4374:
-
Fix Version/s: 4.6.2
   4.7.0

> Enable HA for routers that are part or a redundant network or VPC
> -
>
> Key: CLOUDSTACK-4374
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4374
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.1.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1
>Reporter: Roeland Kuipers
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0, 4.6.2
>
>
> We provide redundant routers with HA functionality through a special service 
> offering.
> However these router pairs are provisioned with ha_enabled=0, so when one or 
> both of them fail they will never be restarted by CS. 
> 2013-08-16 15:51:16,101 DEBUG [cloud.ha.HighAvailabilityManagerImpl] 
> (HA-Worker-0:work-4335) VM is not HA enabled so we're done.
> This is currently hardcoded in VirtualNetworkApplianceManagerImpl.java @ 1633
>boolean offerHA = routerOffering.getOfferHA();
> /* We don't provide HA to redundant router VMs, admin should 
> own it all, and redundant router themselves are HA */
> if (isRedundant) {
> offerHA = false;
> }
> We like redundancy and like to have HA on our redundant routers. We like to 
> configure this ourselves through service offerings and do not like being helt 
> hostage by these lines of codes:) We do like to own it all in our admin role 
> :)
> Besides this, this is also very counter-intuitive as we were expecting HA on 
> our redundant routers, since it was configured on their service offering.
> So can we get rid of these lines of code? And have this controlled through 
> service offerings as it should IMHO.? Unless this has negative impact which 
> we are not aware off?
> Cheers & Thanks,
> Roeland
> Details of the original commit which injected this code:
> Commit: a269b089ae38d0d04db2fa0f4c8e839480476ddc [a269b08]
> Parents: a2cc66ce41
> Author: Sheng Yang 
> Date: 17 december 2011 03:52:59 CET
> Commit Date: 19 december 2011 22:29:48 CET
> bug 12608: NaaS: Don't shutdown elements if cleanup=false
> We can use the restartNetwork mechanism to recover the disconnected redundant
> router.
> Also disable HA for redundant router. Admin would take responsibilty to 
> recover
> the failure router, because redundant routers themselves are one layer HA.
> status 12608: resolved fixed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9134) ip and router are not applied to the right ethernet in VR after restarting a VPC tier

[Wei Zhou (JIRA)]

Wei Zhou created CLOUDSTACK-9134:


 Summary: ip and router are not applied to the right ethernet in VR 
after restarting a VPC tier
 Key: CLOUDSTACK-9134
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9134
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Wei Zhou
Assignee: Wei Zhou


I created three tiers: tier1 /tier 2/ tier3 with corresponding network:

tier1: 192.168.0.0/24
tier2: 192.168.1.0/24
tier3: 192.168.2.0/24

when I restart the tier 2 (in network tab, choose the tier, restart it with 
cleanup), the ip and router are wrong:

root@r-7587-VM:~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:03:1a brd ff:ff:ff:ff:ff:ff
inet 169.254.3.26/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:1b:30:00:00:1e brd ff:ff:ff:ff:ff:ff
inet 10.11.115.119/24 brd 10.11.115.255 scope global eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:01:59:00:0b brd ff:ff:ff:ff:ff:ff
inet 192.168.0.49/24 brd 192.168.0.255 scope global eth2
inet 192.168.0.1/24 brd 192.168.0.255 scope global secondary eth2
6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:64:46:00:04 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.104/24 brd 192.168.2.255 scope global eth4
inet 192.168.1.49/24 brd 192.168.1.255 scope global eth4
inet 192.168.2.254/24 brd 192.168.2.255 scope global secondary eth4
inet 192.168.1.254/24 brd 192.168.1.255 scope global secondary eth4
8: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:30:af:00:10 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.254/24 brd 192.168.1.255 scope global eth3

root@r-7587-VM:~# ip route
default via 10.11.115.254 dev eth1
10.11.115.0/24 dev eth1  proto kernel  scope link  src 10.11.115.119
169.254.0.0/16 dev eth0  proto kernel  scope link  src 169.254.3.26
192.168.0.0/24 dev eth2  proto kernel  scope link  src 192.168.0.49
192.168.1.0/24 dev eth4  proto kernel  scope link  src 192.168.1.49
192.168.1.0/24 dev eth3  proto kernel  scope link  src 192.168.1.254
192.168.2.0/24 dev eth4  proto kernel  scope link  src 192.168.2.104



the ip and router of tier2 should be applied to eth3, but sometimes it is 
applied to eth4.

--

if I restart the tier1 after that, the issue continues:


root@r-7587-VM:~# ip a;ip route
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:03:1a brd ff:ff:ff:ff:ff:ff
inet 169.254.3.26/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:1b:30:00:00:1e brd ff:ff:ff:ff:ff:ff
inet 10.11.115.119/24 brd 10.11.115.255 scope global eth1
6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:64:46:00:04 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.104/24 brd 192.168.2.255 scope global eth4
inet 192.168.1.49/24 brd 192.168.1.255 scope global eth4
inet 192.168.2.254/24 brd 192.168.2.255 scope global secondary eth4
inet 192.168.1.254/24 brd 192.168.1.255 scope global secondary eth4
8: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:30:af:00:10 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.254/24 brd 192.168.1.255 scope global eth3
9: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:07:4c:00:0d brd ff:ff:ff:ff:ff:ff
default via 10.11.115.254 dev eth1
10.11.115.0/24 dev eth1  proto kernel  scope link  src 10.11.115.119
169.254.0.0/16 dev eth0  proto kernel  scope link  src 169.254.3.26
192.168.1.0/24 dev eth4  proto kernel  scope link  src 192.168.1.49
192.168.1.0/24 dev eth3  proto kernel  scope link  src 192.168.1.254
192.168.2.0/24 dev eth4  proto kernel  scope link  src 192.168.2.104




this also happenes if we change the network offering of vpc tier (the tier will 
restart)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9134) ip and route are not applied to the right NIC in VR after restarting a VPC tier

[Wei Zhou (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wei Zhou updated CLOUDSTACK-9134:
-
Summary: ip and route are not applied to the right NIC in VR after 
restarting a VPC tier  (was: ip and router are not applied to the right 
ethernet in VR after restarting a VPC tier)

> ip and route are not applied to the right NIC in VR after restarting a VPC 
> tier
> ---
>
> Key: CLOUDSTACK-9134
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9134
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> I created three tiers: tier1 /tier 2/ tier3 with corresponding network:
> tier1: 192.168.0.0/24
> tier2: 192.168.1.0/24
> tier3: 192.168.2.0/24
> when I restart the tier 2 (in network tab, choose the tier, restart it with 
> cleanup), the ip and router are wrong:
> root@r-7587-VM:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:03:1a brd ff:ff:ff:ff:ff:ff
> inet 169.254.3.26/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:1b:30:00:00:1e brd ff:ff:ff:ff:ff:ff
> inet 10.11.115.119/24 brd 10.11.115.255 scope global eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:01:59:00:0b brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.49/24 brd 192.168.0.255 scope global eth2
> inet 192.168.0.1/24 brd 192.168.0.255 scope global secondary eth2
> 6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:64:46:00:04 brd ff:ff:ff:ff:ff:ff
> inet 192.168.2.104/24 brd 192.168.2.255 scope global eth4
> inet 192.168.1.49/24 brd 192.168.1.255 scope global eth4
> inet 192.168.2.254/24 brd 192.168.2.255 scope global secondary eth4
> inet 192.168.1.254/24 brd 192.168.1.255 scope global secondary eth4
> 8: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:30:af:00:10 brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.254/24 brd 192.168.1.255 scope global eth3
> root@r-7587-VM:~# ip route
> default via 10.11.115.254 dev eth1
> 10.11.115.0/24 dev eth1  proto kernel  scope link  src 10.11.115.119
> 169.254.0.0/16 dev eth0  proto kernel  scope link  src 169.254.3.26
> 192.168.0.0/24 dev eth2  proto kernel  scope link  src 192.168.0.49
> 192.168.1.0/24 dev eth4  proto kernel  scope link  src 192.168.1.49
> 192.168.1.0/24 dev eth3  proto kernel  scope link  src 192.168.1.254
> 192.168.2.0/24 dev eth4  proto kernel  scope link  src 192.168.2.104
> the ip and router of tier2 should be applied to eth3, but sometimes it is 
> applied to eth4.
> --
> if I restart the tier1 after that, the issue continues:
> root@r-7587-VM:~# ip a;ip route
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:03:1a brd ff:ff:ff:ff:ff:ff
> inet 169.254.3.26/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:1b:30:00:00:1e brd ff:ff:ff:ff:ff:ff
> inet 10.11.115.119/24 brd 10.11.115.255 scope global eth1
> 6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:64:46:00:04 brd ff:ff:ff:ff:ff:ff
> inet 192.168.2.104/24 brd 192.168.2.255 scope global eth4
> inet 192.168.1.49/24 brd 192.168.1.255 scope global eth4
> inet 192.168.2.254/24 brd 192.168.2.255 scope global secondary eth4
> inet 192.168.1.254/24 brd 192.168.1.255 scope global secondary eth4
> 8: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:30:af:00:10 brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.254/24 brd 192.168.1.255 scope global eth3
> 9: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:07:4c:00:0d brd ff:ff:ff:ff:ff:ff
> default via 10.11.115.254 dev eth1
> 10.11.115.0/24 dev eth1  proto kernel  scope link  src 10.11.115.119
> 169.254.0.0/16 dev eth0  proto kernel  scope link  src 169.254.3.26
> 192.168.1.0/24 dev eth4  proto kernel  scope link  src 192.168.1.49
> 192.168.1.0/24 dev eth3  proto kernel  scope link  src 192.168.1.254
> 192.168.2.0/24 dev eth4  proto kernel  scope link  src 192.168.2.104
> 
> this also happenes if we change the network offering of vpc tier (the tier 
> will restart)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9131) User/Domain admin cannot login to UI

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050621#comment-15050621
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9131:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/1201#issuecomment-163583068
  
... slightly late, LGTM (did code review)


> User/Domain admin cannot login to UI
> 
>
> Key: CLOUDSTACK-9131
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9131
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Abhinandan Prateek
>Priority: Blocker
> Attachments: Screen Shot 2015-12-09 at 11.08.47.png
>
>
> The Quota plugin checks whether the plugin is enabled but the call it uses it 
> only available for root admins. As a result, no one can login except for root 
> admins.
> Pinging [~bhaisaab]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9125) Add Brazilian translation for quota labels

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050628#comment-15050628
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9125:


Github user GabrielBrascher commented on the pull request:

https://github.com/apache/cloudstack/pull/1194#issuecomment-163584797
  
I think it would be better to change “Quota” by “cota”. Both are correct, 
but Brazilians are used with “cota”.

It seems that the Jenkins had a problem. You should try forcing push it and 
see if the Jenkins build finishes it properly.


> Add Brazilian translation for quota labels
> --
>
> Key: CLOUDSTACK-9125
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9125
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
>Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050635#comment-15050635
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9074:


Github user miguelaferreira commented on the pull request:

https://github.com/apache/cloudstack/pull/1094#issuecomment-163586170
  
@nvazquez I suggested to add the config to the test itself, but I gave it 
some more thought and I agree with you that the test should just assume the 
config is in place. 

Thanks for the documents, but it is still a lot to digest. What about 
step-wise instructions on what to create and in which order?


> Support shared networking in NiciraNVP Plugin
> -
>
> Key: CLOUDSTACK-9074
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.7.0
>Reporter: Nicolas Vazquez
> Fix For: 4.7.0
>
>
> h3. Introduction
> Currently NiciraNVP plugin supports only Isolated networking. In this mode of 
> operations networks are assigned to individual Cloudstack accounts and on NSX 
> side are completely isolated on the L3 level. Many use cases especially in 
> corporate environment call for shared networking mode support. In some 
> circumstances there also may be a need to translate shared NSX network over 
> to a physical VLAN via L2 NSX gateway.
> Features that will be introduced to support Cloudstack shared networks in two 
> modes of NiciraNVP plugin:
> * Shared networks mapped to a physical VLAN with L2 NSX gateway
> * Shared networks within the same L3 NSX domain. Multiple L3 NSX domains will 
> be supported.
> h3. Features
> h4. 1) Shared networking model support
> # Support native Cloudstack shared network in NiciraNVP plugin.
> # Current code that implements isolated networking mode support will stay 
> intact.
> # Designate network service offering by configuring VirtualNetworking 
> provider with NiciraNVP.
> # Static/Source NAT is not used and ignored if defined in the network 
> offering.
> # Nicira_vvp_router_map table will support non-unique logical routers to 
> implement L3 NSX routing domains where multiple Cloudstack networks are 
> attached to the same logical router.
> # Shared network with NSX based Virtual networking will go through the 
> following states:
> ## Allocated
> ## Implementing
> ## Implemented
> ## Destroy
> h4. 2) Support NSX L2 gateways for L2 based VLANs mapped to a physical network
> # Optional L2gatewayserviceuuid parameter for NiciraNVP controller
> # VLAN ID of a Shared network represents VLAN to pass through L2 gateway 
> similar to native Cloudstack shared networking
> # NSX workflow for network allocation
> ## Check if l2gatewayservice defined
> ## Create record in networks table
> ### NiciraNvpGuestNetworkGuru as Guru_name
> ### Lswitch as broadcast_doamin
> ### Vlan://vlan_id as broadcast_uri
> ## Create record in VLAN table
> # NSX workflow for network implementation
> ## Check if l2gatewayservice defined and valid
> ## Create logical switch
> ## Map logical switch to L2gateway service assigning shared network VLAN ID
> # NSX workflow for NIC management and/or hypervisor support
> ## No changes from current implementation
> h4. 3) Support NSX L3 multiple routing domains
> # VLAN ID of a Shared network represents an UUID of a NSX virtual router of a 
> particular routing domain. We will support UUID style notation for VLAN ID. 
> l3gatewayservice option is not used in shared networking
> # It is assumed that if connectivity to the physical networking is required 
> then logical router is configured and connected to the physical network in 
> advance. NiciraNVP plugin will not perform any task beyond basic connectivity 
> to the logical router
> # Support NSX L3 multiple routing domains
> # NSX workflow for network allocation
> ## Create record in networks table
> ### NiciraNvpGuestNetworkGuru as Guru_name
> ### Lswitch as broadcast_domain
> ### NULL as broadcast_uri
> ## Create record in VLAN table
> ## Create record in nicira_nvp_router_map table
> # NSX workflow for network implementation
> ## Check if logical router exists on NSX side which UUID matches the one 
> defined during shared network creation. This mode is activated if VLAN ID 
> supplied in UUID style notation
> ## Create logical switch
> ## Attach logical switch to the logical router
> ## Assign shared network default gateway to the inside port of the logical 
> router
> # NSX workflow for NIC management and/or hypervisor support
> ## No changes from current implementation
> h4. 4) API Changes
> # Existing API addNiciraNvpDevices will be updated
> ## Adding 1 new optional parameter – l2gatewayserviceuuid
> ## Adding 1 n

[jira] [Commented] (CLOUDSTACK-9125) Add Brazilian translation for quota labels

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050636#comment-15050636
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9125:


Github user agneya2001 commented on the pull request:

https://github.com/apache/cloudstack/pull/1194#issuecomment-163586496
  
@GabrielBrascher Noted, I think I need to submit translation via Transfix. 
I am working on it.


> Add Brazilian translation for quota labels
> --
>
> Key: CLOUDSTACK-9125
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9125
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
>Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[Wilder Rodrigues (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues resolved CLOUDSTACK-9123.
--
Resolution: Fixed

done and merged!

> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0, 4.6.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[Wilder Rodrigues (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues updated CLOUDSTACK-9123:
-
Affects Version/s: 4.6.1
   4.6.0

> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0, 4.6.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[Wilder Rodrigues (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues updated CLOUDSTACK-9123:
-
Fix Version/s: 4.6.2
   4.7.0

> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0, 4.6.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9135) As a Developer I want the test_internal_lb.py to test Redundant VPCs

[Wilder Rodrigues (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues updated CLOUDSTACK-9135:
-
Affects Version/s: 4.6.1
   4.6.0

> As a Developer I want the test_internal_lb.py to test Redundant VPCs
> 
>
> Key: CLOUDSTACK-9135
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9135
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> The current test covers only single VPCs, we have to extend it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9135) As a Developer I want the test_internal_lb.py to test Redundant VPCs

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9135:


 Summary: As a Developer I want the test_internal_lb.py to test 
Redundant VPCs
 Key: CLOUDSTACK-9135
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9135
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues


The current test covers only single VPCs, we have to extend it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9135) As a Developer I want the test_internal_lb.py to test Redundant VPCs

[Wilder Rodrigues (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues updated CLOUDSTACK-9135:
-
Fix Version/s: 4.6.2
   4.7.0

> As a Developer I want the test_internal_lb.py to test Redundant VPCs
> 
>
> Key: CLOUDSTACK-9135
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9135
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> The current test covers only single VPCs, we have to extend it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9135) As a Developer I want the test_internal_lb.py to test Redundant VPCs

[Wilder Rodrigues (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues updated CLOUDSTACK-9135:
-
Fix Version/s: (was: 4.6.2)

> As a Developer I want the test_internal_lb.py to test Redundant VPCs
> 
>
> Key: CLOUDSTACK-9135
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9135
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> The current test covers only single VPCs, we have to extend it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9129) Cannot list vpc routers by keyword in Infrastructure -> Virtual Routers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050939#comment-15050939
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9129:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1197#issuecomment-163604337
  
That's odd! :(

Same test was executed by @remibergsma and I this week and everything went 
fine.

But if that was rebased, the test should now be under ```smoke``` instead 
of ```component```. Although it would not change anything in the test itself.

@remibergsma: could you please put one of you 8 bubble to run the 
test_network_ops.py ? You have your one-liner! ;)

The MCT-Shared has also changed. The run tests script is getting the tests 
from smoke instead of component. 

Cheers,
Wilder


> Cannot list vpc routers by keyword in Infrastructure -> Virtual Routers
> ---
>
> Key: CLOUDSTACK-9129
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9129
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> when search by keyword  in Infrastructure -> Virtual Routers page, it lists 
> only the routers searched by name/instancename/networkname, but not vpc name.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9134) ip and route are not applied to the right NIC in VR after restarting a VPC tier

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050941#comment-15050941
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9134:


GitHub user ustcweizhou opened a pull request:

https://github.com/apache/cloudstack/pull/1209

CLOUDSTACK-9134: set device_id as the first device_id not in use instead of 
nic count


when we restart vpc tiers, the old nics will be removed, and create a new 
nic.
however, the device_id was set to the nic count, which may be already used.
this commit get the first device_id not in use as the device_id of new nic.

This issue also happen when we add multiple networks to a vm and remove 
them.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ustcweizhou/cloudstack free-deviceid

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1209.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1209


commit acfc19dc8285a07412ee0078fbc13d7319d5be8b
Author: Wei Zhou 
Date:   2015-12-10T12:26:02Z

CLOUDSTACK-9134: set device_id as the first device_id not in use instead of 
nic count

when we restart vpc tiers, the old nics will be removed, and create a new 
nic.
however, the device_id was set to the nic count, which may be already used.
this commit get the first device_id not in use as the device_id of new nic.

This issue also happen when we add multiple networks to a vm and remove 
them.




> ip and route are not applied to the right NIC in VR after restarting a VPC 
> tier
> ---
>
> Key: CLOUDSTACK-9134
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9134
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> I created three tiers: tier1 /tier 2/ tier3 with corresponding network:
> tier1: 192.168.0.0/24
> tier2: 192.168.1.0/24
> tier3: 192.168.2.0/24
> when I restart the tier 2 (in network tab, choose the tier, restart it with 
> cleanup), the ip and router are wrong:
> root@r-7587-VM:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:03:1a brd ff:ff:ff:ff:ff:ff
> inet 169.254.3.26/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:1b:30:00:00:1e brd ff:ff:ff:ff:ff:ff
> inet 10.11.115.119/24 brd 10.11.115.255 scope global eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:01:59:00:0b brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.49/24 brd 192.168.0.255 scope global eth2
> inet 192.168.0.1/24 brd 192.168.0.255 scope global secondary eth2
> 6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:64:46:00:04 brd ff:ff:ff:ff:ff:ff
> inet 192.168.2.104/24 brd 192.168.2.255 scope global eth4
> inet 192.168.1.49/24 brd 192.168.1.255 scope global eth4
> inet 192.168.2.254/24 brd 192.168.2.255 scope global secondary eth4
> inet 192.168.1.254/24 brd 192.168.1.255 scope global secondary eth4
> 8: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:30:af:00:10 brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.254/24 brd 192.168.1.255 scope global eth3
> root@r-7587-VM:~# ip route
> default via 10.11.115.254 dev eth1
> 10.11.115.0/24 dev eth1  proto kernel  scope link  src 10.11.115.119
> 169.254.0.0/16 dev eth0  proto kernel  scope link  src 169.254.3.26
> 192.168.0.0/24 dev eth2  proto kernel  scope link  src 192.168.0.49
> 192.168.1.0/24 dev eth4  proto kernel  scope link  src 192.168.1.49
> 192.168.1.0/24 dev eth3  proto kernel  scope link  src 192.168.1.254
> 192.168.2.0/24 dev eth4  proto kernel  scope link  src 192.168.2.104
> the ip and router of tier2 should be applied to eth3, but sometimes it is 
> applied to eth4.
> --
> if I restart the tier1 after that, the issue continues:
> root@r-7587-VM:~# ip a;ip route
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:03:1a brd ff:ff:ff:ff:ff:ff
> inet 169.254.3.26/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:1b:30:00:00:1e brd f

[jira] [Created] (CLOUDSTACK-9136) SSH keypairs are left and cannot be removed after removing account

[Wei Zhou (JIRA)]

Wei Zhou created CLOUDSTACK-9136:


 Summary: SSH keypairs are left and cannot be removed after 
removing account
 Key: CLOUDSTACK-9136
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9136
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Wei Zhou
Assignee: Wei Zhou


When we remove an account who have some ssh keypairs created/registered, the 
keypairs are left in cloudstack, we can still list it in Account->SSH Keypair 
page, but cannot remove them.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9136) SSH keypairs are left and cannot be removed after removing account

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050962#comment-15050962
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9136:


GitHub user ustcweizhou opened a pull request:

https://github.com/apache/cloudstack/pull/1212

CLOUDSTACK-9136: remove ssh keypairs along with removing account

We also allow ROOT Admin to remove remained ssh keypairs of removed account

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ustcweizhou/cloudstack remove-ssh-keypairs

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1212.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1212


commit 67e5e4719f7840753db6764f7e2205cbcdc8b7c2
Author: Wei Zhou 
Date:   2015-12-10T13:25:22Z

CLOUDSTACK-9136: remove ssh keypairs along with removing account

We also allow ROOT Admin to remove remained ssh keypairs of removed account




> SSH keypairs are left and cannot be removed after removing account
> --
>
> Key: CLOUDSTACK-9136
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9136
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> When we remove an account who have some ssh keypairs created/registered, the 
> keypairs are left in cloudstack, we can still list it in Account->SSH Keypair 
> page, but cannot remove them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9137) Domain admins cannot create nor delete a private gateway

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9137:


 Summary: Domain admins cannot create nor delete a private gateway
 Key: CLOUDSTACK-9137
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9137
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Remi Bergsma
Assignee: Remi Bergsma
Priority: Critical


To create a private gateway you need a root admin account. This does not make 
sense, as you can do a lot more with such a powerful account. Other network 
related API calls can be made by a domain admin.

Let's change it so domain admins can create their own private gateways.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9137) Domain admins cannot create nor delete a private gateway

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051107#comment-15051107
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9137:


GitHub user remibergsma opened a pull request:

https://github.com/apache/cloudstack/pull/1213

CLOUDSTACK-9137 Allow domain admin to manage private gw

To create a private gateway you need a root admin account. This does not 
make sense, as you can do a lot more with such a powerful account. Other 
network related API calls can be made by a domain admin.

This PR allows domain admins to create their own private gateways.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/remibergsma/cloudstack private_gw_domain_admin

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1213.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1213


commit e9b5b8f55d100f67146bd03b6b7577bd0660d155
Author: Remi Bergsma 
Date:   2015-12-10T15:09:26Z

CLOUDSTACK-9137 Allow domain admin to manage priv gw




> Domain admins cannot create nor delete a private gateway
> 
>
> Key: CLOUDSTACK-9137
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9137
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
>
> To create a private gateway you need a root admin account. This does not make 
> sense, as you can do a lot more with such a powerful account. Other network 
> related API calls can be made by a domain admin.
> Let's change it so domain admins can create their own private gateways.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere

[Rohit Yadav (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051108#comment-15051108
 ] 

Rohit Yadav commented on CLOUDSTACK-4787:
-

Related FS:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Granular+SCSI+Controller+support+in+CloudStack+over+VMware+deployments

Related PRs:
https://github.com/apache/cloudstack/pull/1131
https://github.com/apache/cloudstack/pull/1132

In the APIs, allowed root or data disk controller options are:
ide,
scsi,
osdefault,
lsilogic,
lsisas1068,
buslogic,
pvscsi


Test cases:

1. VMware disk controller options for both VMs and templates:

(a) Register an OVA template for VMware with a rootdisk controller selected 
from the dropdown, and deploy a VM. Check in vCenter that in the VM's 
properties the disk controller matches the one you had selected while 
registering the template. Test updating and deploying a new VM using the update 
template command, example:
  > update template details[0].rootDiskController=lsilogicsas 
id=some-uuid

(b) Deploy a Virtual Machine via cloudmonkey, passing rootDiskController 
detail. And, after the VM is launched check if diskcontroller on vCenter side 
matches the one being configured. For example: 
  > deploy virtualmachine details[0].rootDiskController=lsilogicsas 
templateid=some-thing zoneid=so-me-uuid

(c) Stop a VM, and run update virtualmachine API to update its 
rootDiskController detail. Start the VM, and check if the update disk 
controller matches the disk controller property on the vCenter side. 
CloudMonkey example:
 > update virtualmachine id=some-uuid 
details[0].rootDiskController=lsilogicsas

2. Recommended regression testing: Test disk lifecycles (create/allocated, 
attach/detach, remove, take snapshot, use snapshot to create template, download 
volume), Test VM lifecycles (deploy, start, stop, update, restart, destroy), 
Test template lifecycles (register, download, update template, copy template 
across zones).

> Allow selection of scsi controller type in vSphere
> --
>
> Key: CLOUDSTACK-4787
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, UI, VMware
>Affects Versions: 4.2.0, 4.3.0
> Environment: vSphere 5.1
>Reporter: Chris Sciarrino
>Assignee: Rohit Yadav
>Priority: Critical
> Fix For: 4.5.3, 4.7.0, 4.6.1
>
> Attachments: screenshot-1.png
>
>
> When adding an OVA template for a vSphere environment allow the selection of 
> the scsi controller type. 
> Currently the instances are deployed with the the LSI Parallel controller 
> type. This results in a blue screen on boot when attempting to deploy 
> templates that use the LSI SAS controller.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere

[Eric Neumann (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Neumann updated CLOUDSTACK-4787:
-
Attachment: aodsiga68edf


Please be advised I am currently out of the office until Tuesday 15th December 
and email response times may be longer than usual.

For any urgent enquries please contact AOD Support via supp...@aod-cloud.com or 
call us on +61 8 9204 7111.

Kind regards,

[cid:aodsiga68edf]

Eric Neumann   Cloud Services Manager

P +61 8 9204 7111

5/19 Wotan Street, Innaloo WA 6018
www.aod-cloud.com




> Allow selection of scsi controller type in vSphere
> --
>
> Key: CLOUDSTACK-4787
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, UI, VMware
>Affects Versions: 4.2.0, 4.3.0
> Environment: vSphere 5.1
>Reporter: Chris Sciarrino
>Assignee: Rohit Yadav
>Priority: Critical
> Fix For: 4.5.3, 4.7.0, 4.6.1
>
> Attachments: aodsiga68edf, screenshot-1.png
>
>
> When adding an OVA template for a vSphere environment allow the selection of 
> the scsi controller type. 
> Currently the instances are deployed with the the LSI Parallel controller 
> type. This results in a blue screen on boot when attempting to deploy 
> templates that use the LSI SAS controller.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051124#comment-15051124
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9123:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1204#issuecomment-163660061
  
FYI: my tests also succeeded.

```
[root@cs1 integration]# cat  
/tmp//MarvinLogs/test_internal_lb_88R1S8/results.txt 
Test to verify access to loadbalancer haproxy admin stats page ... === 
TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS 
===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic 
to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 
| Status : SUCCESS ===
ok

--
Ran 2 tests in 1733.573s

OK
```


> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0, 4.6.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9137) Domain admins cannot create nor delete a private gateway

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051164#comment-15051164
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9137:


Github user koushik-das commented on the pull request:

https://github.com/apache/cloudstack/pull/1213#issuecomment-163674707
  
@remibergsma Can domain admin1 delete gateway created by domain admin2? If 
the existing code is properly handling these scenarios then fine.


> Domain admins cannot create nor delete a private gateway
> 
>
> Key: CLOUDSTACK-9137
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9137
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
>
> To create a private gateway you need a root admin account. This does not make 
> sense, as you can do a lot more with such a powerful account. Other network 
> related API calls can be made by a domain admin.
> Let's change it so domain admins can create their own private gateways.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9035) Password file is stored only with Master when we Reset Password on the VM.

[David Amorim Faria (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051165#comment-15051165
 ] 

David Amorim Faria commented on CLOUDSTACK-9035:


Created redundant VPC and deployed VM there. The VM root password was not 
correct.
Went to the VR to check the logs.

VR master /var/log/cloud.log: {noformat}
2015-12-10 10:16:52,779  merge.py load:56 Creating data bag type vmpassword
2015-12-10 10:16:52,780  merge.py process:99 Command of type vmpassword received
2015-12-10 10:16:52,780  merge.py save:70 Writing data bag type vmpassword
2015-12-10 10:16:52,780  merge.py save:71 {u'172.16.0.152': u'AABs3A', 'id': 
u'vmpassword'}
(...)
2015-12-10 10:16:52,825  configure.py main:889 Configuring vmpassword
2015-12-10 10:16:52,825  merge.py load:59 Loading data bag type vmpassword
2015-12-10 10:16:52,826  CsHelper.py execute:160 Executing: ip addr show | grep 
inet | awk '{print $2}'
2015-12-10 10:16:52,829  CsHelper.py execute:160 Executing: ps aux
2015-12-10 10:16:52,837  CsProcess.py find_pid:50 CsProcess:: Searching for 
process ==> ['/opt/cloud/bin/passwd_server_ip.py', '127.0.0.1'] and found PIDs 
==> []
2015-12-10 10:16:52,838  CsHelper.py execute:160 Executing: ps aux
2015-12-10 10:16:52,845  CsProcess.py find_pid:50 CsProcess:: Searching for 
process ==> ['/opt/cloud/bin/passwd_server_ip.py', '169.254.1.22'] and found 
PIDs ==> []
2015-12-10 10:16:52,845  CsHelper.py execute:160 Executing: ps aux
2015-12-10 10:16:52,853  CsProcess.py find_pid:50 CsProcess:: Searching for 
process ==> ['/opt/cloud/bin/passwd_server_ip.py', '5.79.101.133'] and found 
PIDs ==> []
2015-12-10 10:16:52,853  CsHelper.py execute:160 Executing: ps aux
2015-12-10 10:16:52,860  CsProcess.py find_pid:50 CsProcess:: Searching for 
process ==> ['/opt/cloud/bin/passwd_server_ip.py', '172.16.0.142'] and found 
PIDs ==> []
2015-12-10 10:16:52,861  CsHelper.py execute:160 Executing: ps aux
2015-12-10 10:16:52,868  CsProcess.py find_pid:50 CsProcess:: Searching for 
process ==> ['/opt/cloud/bin/passwd_server_ip.py', '172.16.0.254'] and found 
PIDs ==> ['7754']
2015-12-10 10:16:52,874  CsHelper.py execute:160 Executing: curl --header 
"DomU_Request: save_password" "http://172.16.0.254:8080/"; -F "ip=172.16.0.152" 
-F "password=AABs3A" -F "token=22009a29a516ca5bfd3ded46318180f0" >/dev/null 
2>/dev/null &
2015-12-10 10:16:52,882  configure.py __update:74 Update password server result 
==> []
(...)
2015-12-10 10:17:00,517  configure.py main:889 Configuring vmpassword
2015-12-10 10:17:00,517  merge.py load:59 Loading data bag type vmpassword
2015-12-10 10:17:00,517  CsHelper.py execute:160 Executing: ip addr show | grep 
inet | awk '{print $2}'
2015-12-10 10:17:00,521  CsHelper.py execute:160 Executing: ps aux
2015-12-10 10:17:00,533  CsProcess.py find_pid:50 CsProcess:: Searching for 
process ==> ['/opt/cloud/bin/passwd_server_ip.py', '127.0.0.1'] and found PIDs 
==> []
2015-12-10 10:17:00,533  CsHelper.py execute:160 Executing: ps aux
2015-12-10 10:17:00,541  CsProcess.py find_pid:50 CsProcess:: Searching for 
process ==> ['/opt/cloud/bin/passwd_server_ip.py', '169.254.1.22'] and found 
PIDs ==> []
2015-12-10 10:17:00,541  CsHelper.py execute:160 Executing: ps aux
2015-12-10 10:17:00,549  CsProcess.py find_pid:50 CsProcess:: Searching for 
process ==> ['/opt/cloud/bin/passwd_server_ip.py', '5.79.101.133'] and found 
PIDs ==> []
2015-12-10 10:17:00,549  CsHelper.py execute:160 Executing: ps aux
2015-12-10 10:17:00,556  CsProcess.py find_pid:50 CsProcess:: Searching for 
process ==> ['/opt/cloud/bin/passwd_server_ip.py', '172.16.0.142'] and found 
PIDs ==> []
2015-12-10 10:17:00,556  CsHelper.py execute:160 Executing: ps aux
2015-12-10 10:17:00,564  CsProcess.py find_pid:50 CsProcess:: Searching for 
process ==> ['/opt/cloud/bin/passwd_server_ip.py', '172.16.0.254'] and found 
PIDs ==> ['7754']
2015-12-10 10:17:00,564  CsHelper.py execute:160 Executing: curl --header 
"DomU_Request: save_password" "http://172.16.0.254:8080/"; -F "ip=172.16.0.152" 
-F "password=AABs3A" -F "token=22009a29a516ca5bfd3ded46318180f0" >/dev/null 
2>/dev/null &
2015-12-10 10:17:00,565  configure.py __update:74 Update password server result 
==> []
{noformat}

VR slave /var/log/cloud.log: {noformat}
2015-12-10 10:16:59,974  merge.py load:56 Creating data bag type vmpassword
2015-12-10 10:16:59,975  merge.py process:99 Command of type vmpassword received
2015-12-10 10:16:59,975  merge.py save:70 Writing data bag type vmpassword
2015-12-10 10:16:59,975  merge.py save:71 {u'172.16.0.152': u'AABs3A', 'id': 
u'vmpassword'}
(...)
2015-12-10 10:17:00,043  configure.py main:889 Configuring vmpassword
2015-12-10 10:17:00,043  merge.py load:59 Loading data bag type vmpassword
2015-12-10 10:17:00,043  configure.py __update:63 File /tmp/passwdsrvrtoken 
does not exist
2015-12-10 10:17:00,043  CsHelper.py execute:160 Executing: ip addr show | grep 
inet |

[jira] [Commented] (CLOUDSTACK-9035) Password file is stored only with Master when we Reset Password on the VM.

[David Amorim Faria (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051176#comment-15051176
 ] 

David Amorim Faria commented on CLOUDSTACK-9035:


restarted vpc with cleanup, and both VRs went down within a couple of seconds, 
so there is service outage.

VR master:
Broadcast message from root@r-45-VM (Thu Dec 10 16:18:47 2015):

VR slave:
Broadcast message from root@r-46-VM (Thu Dec 10 16:18:53 2015):


> Password file is stored only with Master when we Reset Password on the VM.
> --
>
> Key: CLOUDSTACK-9035
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9035
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.0
>Reporter: Bharat Kumar
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.1
>
>
> we send the save password command to both the VRs in a rvr enabled network, 
> But the password gets saved only in the master VR. This happens because the 
> password server is not running in the backup. 
> Because of this if someone resets the password of a VM and starts it when the 
> backup becomes master. Then the password of the user VM will not change, 
> because the save password command was not successful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9035) Password file is stored only with Master when we Reset Password on the VM.

[David Amorim Faria (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051182#comment-15051182
 ] 

David Amorim Faria commented on CLOUDSTACK-9035:


Reset password again:

VR master: {noformat}
2015-12-10 16:26:48,728  merge.py load:56 Creating data bag type vmpassword
2015-12-10 16:26:48,730  merge.py process:99 Command of type vmpassword received
2015-12-10 16:26:48,731  merge.py save:70 Writing data bag type vmpassword
2015-12-10 16:26:48,733  merge.py save:71 {u'172.16.0.152': u'5wQpTK', 'id': 
u'vmpassword'}
2015-12-10 16:26:48,777  configure.py main:889 Configuring vmpassword
2015-12-10 16:26:48,777  merge.py load:59 Loading data bag type vmpassword
2015-12-10 16:26:48,822  CsHelper.py execute:160 Executing: curl --header 
"DomU_Request: save_password" "http://172.16.0.254:8080/"; -F "ip=172.16.0.152" 
-F "password=5wQpTK" -F "token=115ce552217e1830d1ef2ccf85db9b50" >/dev/null 
2>/dev/null &
2015-12-10 16:26:48,832  configure.py __update:74 Update password server result 
==> []
{noformat}

VR slave: {noformat}
2015-12-10 16:26:50,287  merge.py load:56 Creating data bag type vmpassword
2015-12-10 16:26:50,288  merge.py process:99 Command of type vmpassword received
2015-12-10 16:26:50,290  merge.py save:70 Writing data bag type vmpassword
2015-12-10 16:26:50,291  merge.py save:71 {u'172.16.0.152': u'5wQpTK', 'id': 
u'vmpassword'}
2015-12-10 16:26:50,343  configure.py main:889 Configuring vmpassword
2015-12-10 16:26:50,343  merge.py load:59 Loading data bag type vmpassword
{noformat}


> Password file is stored only with Master when we Reset Password on the VM.
> --
>
> Key: CLOUDSTACK-9035
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9035
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.0
>Reporter: Bharat Kumar
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.1
>
>
> we send the save password command to both the VRs in a rvr enabled network, 
> But the password gets saved only in the master VR. This happens because the 
> password server is not running in the backup. 
> Because of this if someone resets the password of a VM and starts it when the 
> backup becomes master. Then the password of the user VM will not change, 
> because the save password command was not successful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9035) Password file is stored only with Master when we Reset Password on the VM.

[David Amorim Faria (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051191#comment-15051191
 ] 

David Amorim Faria commented on CLOUDSTACK-9035:


Start instance.

VR master: {noformat}
2015-12-10 16:28:20,579  configure.py main:889 Configuring vmpassword
2015-12-10 16:28:20,579  merge.py load:59 Loading data bag type vmpassword
2015-12-10 16:28:20,625  CsHelper.py execute:160 Executing: curl --header 
"DomU_Request: save_password" "http://172.16.0.254:8080/"; -F "ip=172.16.0.152" 
-F "password=5wQpTK" -F "token=115ce552217e1830d1ef2ccf85db9b50" >/dev/null 
2>/dev/null &
2015-12-10 16:28:20,630  configure.py __update:74 Update password server result 
==> []
(...)
2015-12-10 16:28:25,888  configure.py main:889 Configuring vmpassword
2015-12-10 16:28:25,889  merge.py load:59 Loading data bag type vmpassword
2015-12-10 16:28:25,934  CsHelper.py execute:160 Executing: curl --header 
"DomU_Request: save_password" "http://172.16.0.254:8080/"; -F "ip=172.16.0.152" 
-F "password=5wQpTK" -F "token=115ce552217e1830d1ef2ccf85db9b50" >/dev/null 
2>/dev/null &
2015-12-10 16:28:25,939  configure.py __update:74 Update password server result 
==> []
{noformat}

VR slave: {noformat}
2015-12-10 16:26:50,343  configure.py main:889 Configuring vmpassword
2015-12-10 16:26:50,343  merge.py load:59 Loading data bag type vmpassword
(...)
2015-12-10 16:28:22,164  configure.py main:889 Configuring vmpassword
2015-12-10 16:28:22,164  merge.py load:59 Loading data bag type vmpassword
(...)
2015-12-10 16:28:27,482  configure.py main:889 Configuring vmpassword
2015-12-10 16:28:27,482  merge.py load:59 Loading data bag type vmpassword
{noformat}

> Password file is stored only with Master when we Reset Password on the VM.
> --
>
> Key: CLOUDSTACK-9035
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9035
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.0
>Reporter: Bharat Kumar
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.1
>
>
> we send the save password command to both the VRs in a rvr enabled network, 
> But the password gets saved only in the master VR. This happens because the 
> password server is not running in the backup. 
> Because of this if someone resets the password of a VM and starts it when the 
> backup becomes master. Then the password of the user VM will not change, 
> because the save password command was not successful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9035) Password file is stored only with Master when we Reset Password on the VM.

[David Amorim Faria (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051196#comment-15051196
 ] 

David Amorim Faria commented on CLOUDSTACK-9035:


Password is still not updated in the VM.

> Password file is stored only with Master when we Reset Password on the VM.
> --
>
> Key: CLOUDSTACK-9035
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9035
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.0
>Reporter: Bharat Kumar
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.1
>
>
> we send the save password command to both the VRs in a rvr enabled network, 
> But the password gets saved only in the master VR. This happens because the 
> password server is not running in the backup. 
> Because of this if someone resets the password of a VM and starts it when the 
> backup becomes master. Then the password of the user VM will not change, 
> because the save password command was not successful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9035) Password file is stored only with Master when we Reset Password on the VM.

[David Amorim Faria (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Amorim Faria updated CLOUDSTACK-9035:
---
Affects Version/s: 4.6.1

> Password file is stored only with Master when we Reset Password on the VM.
> --
>
> Key: CLOUDSTACK-9035
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9035
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Bharat Kumar
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.1
>
>
> we send the save password command to both the VRs in a rvr enabled network, 
> But the password gets saved only in the master VR. This happens because the 
> password server is not running in the backup. 
> Because of this if someone resets the password of a VM and starts it when the 
> backup becomes master. Then the password of the user VM will not change, 
> because the save password command was not successful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9035) [rVR] Password file is stored only with Master when we Reset Password on the VM

[David Amorim Faria (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Amorim Faria updated CLOUDSTACK-9035:
---
Summary: [rVR] Password file is stored only with Master when we Reset 
Password on the VM  (was: Password file is stored only with Master when we 
Reset Password on the VM.)

> [rVR] Password file is stored only with Master when we Reset Password on the 
> VM
> ---
>
> Key: CLOUDSTACK-9035
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9035
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Bharat Kumar
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.1
>
>
> we send the save password command to both the VRs in a rvr enabled network, 
> But the password gets saved only in the master VR. This happens because the 
> password server is not running in the backup. 
> Because of this if someone resets the password of a VM and starts it when the 
> backup becomes master. Then the password of the user VM will not change, 
> because the save password command was not successful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9137) Domain admins cannot create nor delete a private gateway

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051215#comment-15051215
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9137:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1213#issuecomment-163683468
  
It seems this is more complex than it seemed. Since we've to put in a 
'physical network id' (which is obviously owned by ROOT domain, this does not 
work yet.

Creating fails:
```
(admin) 🐵 > create privategateway gateway=1.2.3.4 ipaddress=4.3.2.1 
netmask=255.255.255.0 vpcid=cc80ae2c-c3ad-4ea3-96f4-dc40970c81e4 
vlan="lswitch://uuid"
Error 531: Acct[74caa349-7f41-4e1a-b4b1-d386c0c2a1a2-rbergsma] does not 
have permission to operate within domain id=9c2baf29-9846-11e5-9afa-525400b8977a
cserrorcode = 4365
errorcode = 531
errortext = Acct[74caa349-7f41-4e1a-b4b1-d386c0c2a1a2-rbergsma] does not 
have permission to operate within domain id=9c2baf29-9846-11e5-9afa-525400b8977a
uuidList:
```

This is the mentioned domain id:

```
(admin) 🐵 > set profile root
(root) 🐵 > list domains id=9c2baf29-9846-11e5-9afa-525400b8977a filter=name
count = 1
domain:
name = ROOT
```

Most likely due to the physical network id. Hmm..


> Domain admins cannot create nor delete a private gateway
> 
>
> Key: CLOUDSTACK-9137
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9137
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
>
> To create a private gateway you need a root admin account. This does not make 
> sense, as you can do a lot more with such a powerful account. Other network 
> related API calls can be made by a domain admin.
> Let's change it so domain admins can create their own private gateways.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9074) Support shared networking in NiciraNVP Plugin

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051223#comment-15051223
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9074:


Github user serg38 commented on the pull request:

https://github.com/apache/cloudstack/pull/1094#issuecomment-163684761
  
Assuming everything else is ready e.g. service controllers, transport zone, 
management server, STT tunnels in-between then to create L2 gateway (page 89 of 
the User guide):
1. Create new gateway transport node
1.1. Download and install either OVA or ISO for your hypervisor (available 
on Vmware site). You need at least 2 separate vSwitches. If tunneling traffic 
follows a different path, then 3 interface might be needed for the appliance
1.2 Login with admin/admin
1.3 Configure
set hostname 
add network dns-server 
add network ntp-server 0.pool.ntp.org
set network interface breth1 ip config static  
   .it could be breth0 in some cases and in some cases more than one 
bridge
add switch manager 
1.4. Obtain gateway certificate
show switch certificate 
1.5 Add gateway node to NSX
  Transport Node->Add->Gateway->Display Name->Admin Status 
Enabled->Security Credentials - Certificate. Paste from section 
1.4->Connection->Add->STT->IP of the bridge used for tunneling traffic
1.6. Create L2 Gateway Service and publish it on created Gateway transport 
node




> Support shared networking in NiciraNVP Plugin
> -
>
> Key: CLOUDSTACK-9074
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9074
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.7.0
>Reporter: Nicolas Vazquez
> Fix For: 4.7.0
>
>
> h3. Introduction
> Currently NiciraNVP plugin supports only Isolated networking. In this mode of 
> operations networks are assigned to individual Cloudstack accounts and on NSX 
> side are completely isolated on the L3 level. Many use cases especially in 
> corporate environment call for shared networking mode support. In some 
> circumstances there also may be a need to translate shared NSX network over 
> to a physical VLAN via L2 NSX gateway.
> Features that will be introduced to support Cloudstack shared networks in two 
> modes of NiciraNVP plugin:
> * Shared networks mapped to a physical VLAN with L2 NSX gateway
> * Shared networks within the same L3 NSX domain. Multiple L3 NSX domains will 
> be supported.
> h3. Features
> h4. 1) Shared networking model support
> # Support native Cloudstack shared network in NiciraNVP plugin.
> # Current code that implements isolated networking mode support will stay 
> intact.
> # Designate network service offering by configuring VirtualNetworking 
> provider with NiciraNVP.
> # Static/Source NAT is not used and ignored if defined in the network 
> offering.
> # Nicira_vvp_router_map table will support non-unique logical routers to 
> implement L3 NSX routing domains where multiple Cloudstack networks are 
> attached to the same logical router.
> # Shared network with NSX based Virtual networking will go through the 
> following states:
> ## Allocated
> ## Implementing
> ## Implemented
> ## Destroy
> h4. 2) Support NSX L2 gateways for L2 based VLANs mapped to a physical network
> # Optional L2gatewayserviceuuid parameter for NiciraNVP controller
> # VLAN ID of a Shared network represents VLAN to pass through L2 gateway 
> similar to native Cloudstack shared networking
> # NSX workflow for network allocation
> ## Check if l2gatewayservice defined
> ## Create record in networks table
> ### NiciraNvpGuestNetworkGuru as Guru_name
> ### Lswitch as broadcast_doamin
> ### Vlan://vlan_id as broadcast_uri
> ## Create record in VLAN table
> # NSX workflow for network implementation
> ## Check if l2gatewayservice defined and valid
> ## Create logical switch
> ## Map logical switch to L2gateway service assigning shared network VLAN ID
> # NSX workflow for NIC management and/or hypervisor support
> ## No changes from current implementation
> h4. 3) Support NSX L3 multiple routing domains
> # VLAN ID of a Shared network represents an UUID of a NSX virtual router of a 
> particular routing domain. We will support UUID style notation for VLAN ID. 
> l3gatewayservice option is not used in shared networking
> # It is assumed that if connectivity to the physical networking is required 
> then logical router is configured and connected to the physical network in 
> advance. NiciraNVP plugin will not perform any task beyond basic connectivity 
> to the logical router
> # Support NSX L3 multiple routing domains
> # NSX workflow for network allocation
> ## Create record in networks table
> ### NiciraNvpGuestNetworkG

[jira] [Commented] (CLOUDSTACK-9137) Domain admins cannot create nor delete a private gateway

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051418#comment-15051418
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9137:


Github user remibergsma closed the pull request at:

https://github.com/apache/cloudstack/pull/1213


> Domain admins cannot create nor delete a private gateway
> 
>
> Key: CLOUDSTACK-9137
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9137
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
>
> To create a private gateway you need a root admin account. This does not make 
> sense, as you can do a lot more with such a powerful account. Other network 
> related API calls can be made by a domain admin.
> Let's change it so domain admins can create their own private gateways.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9138) As a Developer I want the createVpcOffering to allow multiple provider per service

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9138:


 Summary: As a Developer I want the createVpcOffering to allow 
multiple provider per service
 Key: CLOUDSTACK-9138
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9138
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.6.1
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues
 Fix For: 4.7.0, 4.6.2


The default offerings already have multiple providers per service (e.g. Lb with 
VpcRouterProvider and InternalLbVm)

It's very important that we can do the same from a developer/user point of view.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-4374) Enable HA for routers that are part or a redundant network or VPC

[Wilder Rodrigues (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues updated CLOUDSTACK-4374:
-
Fix Version/s: (was: 4.6.2)

> Enable HA for routers that are part or a redundant network or VPC
> -
>
> Key: CLOUDSTACK-4374
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4374
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.1.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1
>Reporter: Roeland Kuipers
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> We provide redundant routers with HA functionality through a special service 
> offering.
> However these router pairs are provisioned with ha_enabled=0, so when one or 
> both of them fail they will never be restarted by CS. 
> 2013-08-16 15:51:16,101 DEBUG [cloud.ha.HighAvailabilityManagerImpl] 
> (HA-Worker-0:work-4335) VM is not HA enabled so we're done.
> This is currently hardcoded in VirtualNetworkApplianceManagerImpl.java @ 1633
>boolean offerHA = routerOffering.getOfferHA();
> /* We don't provide HA to redundant router VMs, admin should 
> own it all, and redundant router themselves are HA */
> if (isRedundant) {
> offerHA = false;
> }
> We like redundancy and like to have HA on our redundant routers. We like to 
> configure this ourselves through service offerings and do not like being helt 
> hostage by these lines of codes:) We do like to own it all in our admin role 
> :)
> Besides this, this is also very counter-intuitive as we were expecting HA on 
> our redundant routers, since it was configured on their service offering.
> So can we get rid of these lines of code? And have this controlled through 
> service offerings as it should IMHO.? Unless this has negative impact which 
> we are not aware off?
> Cheers & Thanks,
> Roeland
> Details of the original commit which injected this code:
> Commit: a269b089ae38d0d04db2fa0f4c8e839480476ddc [a269b08]
> Parents: a2cc66ce41
> Author: Sheng Yang 
> Date: 17 december 2011 03:52:59 CET
> Commit Date: 19 december 2011 22:29:48 CET
> bug 12608: NaaS: Don't shutdown elements if cleanup=false
> We can use the restartNetwork mechanism to recover the disconnected redundant
> router.
> Also disable HA for redundant router. Admin would take responsibilty to 
> recover
> the failure router, because redundant routers themselves are one layer HA.
> status 12608: resolved fixed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9138) As a Developer I want the createVpcOffering to allow multiple provider per service

[Wilder Rodrigues (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues updated CLOUDSTACK-9138:
-
Fix Version/s: (was: 4.6.2)

> As a Developer I want the createVpcOffering to allow multiple provider per 
> service
> --
>
> Key: CLOUDSTACK-9138
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9138
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> The default offerings already have multiple providers per service (e.g. Lb 
> with VpcRouterProvider and InternalLbVm)
> It's very important that we can do the same from a developer/user point of 
> view.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9138) As a Developer I want the createVpcOffering to allow multiple provider per service

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051484#comment-15051484
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9138:


GitHub user wilderrodrigues opened a pull request:

https://github.com/apache/cloudstack/pull/1215

CLOUDSTACK-9138 - Adds multiple providers back to VPC implementation

   - It is need and already allowed/used in the current implementation. For 
example, the Default [redundant] VPC offerings use two LB providers. If we 
cannot create offerings with 2 LB providers, the whole internal loadbalancer 
implementation won't work.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ekholabs/cloudstack 
improve/mult-providers-CLOUDSTACK-9138

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1215.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1215


commit 51c9f0e3b524f978eadb6a6ba630c3f7281b1a11
Author: Wilder Rodrigues 
Date:   2015-12-10T18:51:28Z

CLOUDSTACK-9138 - Adds multiple providers back to VPC implementation

   - It is need and already allowed/used in the current implementation. For 
example, the Default [redundant] VPC offerings use
 two LB providers. If we cannot create offerings with 2 LB providers, 
the whole internal loadbalancer implementation won't work




> As a Developer I want the createVpcOffering to allow multiple provider per 
> service
> --
>
> Key: CLOUDSTACK-9138
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9138
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> The default offerings already have multiple providers per service (e.g. Lb 
> with VpcRouterProvider and InternalLbVm)
> It's very important that we can do the same from a developer/user point of 
> view.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9138) As a Developer I want the createVpcOffering to allow multiple provider per service

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051489#comment-15051489
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9138:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1215#issuecomment-163723768
  
Ping @remibergsma @DaanHoogland @miguelaferreira @michaelandersen @bhaisaab 

* Environment
  - 1 KVM host on CentOS 7.1
  - Management Server on CentOS 7.1
  - Cloudmonkey

* Tests
  - Executed cloudmonkey in order to create the offerings

* With only 1 provider

```
create vpcoffering name=test2 displaytext=testtest2 
supportedservices=PortForwarding,StaticNat,SourceNat,Vpn,Dhcp,Connectivity,Dns,UserData,NetworkACL,Lb
 serviceproviderlist[0].service=PortForwarding 
serviceproviderlist[0].provider=VpcVirtualRouter  
serviceproviderlist[1].service=StaticNat 
serviceproviderlist[1].provider=VpcVirtualRouter  
serviceproviderlist[2].service=SourceNat 
serviceproviderlist[2].provider=VpcVirtualRouter  
serviceproviderlist[3].service=Vpn 
serviceproviderlist[3].provider=VpcVirtualRouter  
serviceproviderlist[4].service=Dhcp 
serviceproviderlist[4].provider=VpcVirtualRouter 
serviceproviderlist[5].service=Connectivity 
serviceproviderlist[5].provider=NiciraNvp  serviceproviderlist[6].service=Dns 
serviceproviderlist[6].provider=VpcVirtualRouter  
serviceproviderlist[7].service=UserData 
serviceproviderlist[7].provider=VpcVirtualRouter 
serviceproviderlist[8].service=NetworkACL 
serviceproviderlist[8].provider=VpcVirtualRouter 
serviceproviderlist[9].service=Lb 
serviceproviderlist[9].provider=VpcVirtualRouter 
servicecapabilitylist[0].capabilitytype=RedundantRouter 
servicecapabilitylist[0].service=SourceNat 
servicecapabilitylist[0].capabilityvalue=true
```

*  With 2 providers

```
create vpcoffering name=test displaytext=testtest 
supportedservices=PortForwarding,StaticNat,SourceNat,Vpn,Dhcp,Connectivity,Dns,UserData,NetworkACL,Lb
 serviceproviderlist[0].service=PortForwarding 
serviceproviderlist[0].provider=VpcVirtualRouter  
serviceproviderlist[1].service=StaticNat 
serviceproviderlist[1].provider=VpcVirtualRouter  
serviceproviderlist[2].service=SourceNat 
serviceproviderlist[2].provider=VpcVirtualRouter  
serviceproviderlist[3].service=Vpn 
serviceproviderlist[3].provider=VpcVirtualRouter  
serviceproviderlist[4].service=Dhcp 
serviceproviderlist[4].provider=VpcVirtualRouter 
serviceproviderlist[5].service=Connectivity 
serviceproviderlist[5].provider=NiciraNvp  serviceproviderlist[6].service=Dns 
serviceproviderlist[6].provider=VpcVirtualRouter  
serviceproviderlist[7].service=UserData 
serviceproviderlist[7].provider=VpcVirtualRouter 
serviceproviderlist[8].service=NetworkACL 
serviceproviderlist[8].provider=VpcVirtualRouter 
serviceproviderlist[9].service=Lb 
serviceproviderlist[9].provider=VpcVirtualRouter 
serviceproviderlist[10].service=Lb 
serviceproviderlist[10].provider=InternalLbVm 
servicecapabilitylist[0].capabilitytype=RedundantRouter 
servicecapabilitylist[0].service=SourceNat 
servicecapabilitylist[0].capabilityvalue=true
```

If that's hard to see, in the second test I added the following:

```
serviceproviderlist[10].service=Lb 
serviceproviderlist[10].provider=InternalLbVm
```

* Screenshots
  - Offerings

![image](https://cloud.githubusercontent.com/assets/5129209/11725664/180234d2-9f7b-11e5-91a6-6bf42579aad8.png)

  - 2 Providers

![image](https://cloud.githubusercontent.com/assets/5129209/11725675/265541be-9f7b-11e5-8c00-124e5a9df1ac.png)

  - 1 Provider

![image](https://cloud.githubusercontent.com/assets/5129209/11725695/40d67800-9f7b-11e5-8add-15ad38bb26ce.png)




> As a Developer I want the createVpcOffering to allow multiple provider per 
> service
> --
>
> Key: CLOUDSTACK-9138
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9138
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> The default offerings already have multiple providers per service (e.g. Lb 
> with VpcRouterProvider and InternalLbVm)
> It's very important that we can do the same from a developer/user point of 
> view.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9103) Missing OS Mappings for VMware 6.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052095#comment-15052095
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9103:


Github user maneesha-p closed the pull request at:

https://github.com/apache/cloudstack/pull/1159


> Missing OS Mappings for VMware 6.0
> --
>
> Key: CLOUDSTACK-9103
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9103
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Maneesha
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9103) Missing OS Mappings for VMware 6.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052112#comment-15052112
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9103:


GitHub user maneesha-p opened a pull request:

https://github.com/apache/cloudstack/pull/1216

CLOUDSTACK-9103 : Missing OS Mappings for VMware 6.0

Added suitable db entries in tables hypervisor_capabilities and 
guest_os_hypervisor to support VMware 6.0 by copying from 5.5 and excluding few 
depricated guest os.And also entries for guest os RHEL 7 for vmware 5.5 and 6.0.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/maneesha-p/cloudstack BUG-9103

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1216.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1216


commit 59ab097429528becdd6c7d143296f3bf48da4bd2
Author: Maneesha.P 
Date:   2015-12-11T03:41:21Z

CLOUDSTACK-9103 : Missing OS Mappings for VMware 6.0




> Missing OS Mappings for VMware 6.0
> --
>
> Key: CLOUDSTACK-9103
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9103
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Maneesha
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9103) Missing OS Mappings for VMware 6.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052114#comment-15052114
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9103:


Github user maneesha-p commented on the pull request:

https://github.com/apache/cloudstack/pull/1159#issuecomment-163831485
  
@jburwell @DaanHoogland Raised a new PR(1216) with changes suggested .
@bhaisaab As master is in 4.7 we dont need the change in every upgrade path 
before 4.6 as we can pull the changes required.
Please review pr-1216.


> Missing OS Mappings for VMware 6.0
> --
>
> Key: CLOUDSTACK-9103
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9103
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Maneesha
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8847) ListServiceOfferings is returning incompatible tagged offerings when called with VM id

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052126#comment-15052126
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8847:


Github user agneya2001 commented on the pull request:

https://github.com/apache/cloudstack/pull/823#issuecomment-163834017
  
@nitin-maharana The current way was to move the service offering to a 
similar or a more flexible one in terms of deployment. While this change will 
make the new service offering more restrictive and may result in change of 
deployment. This does not sound very reasonable. cc @DaanHoogland 


> ListServiceOfferings is returning incompatible tagged offerings when called 
> with VM id
> --
>
> Key: CLOUDSTACK-8847
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8847
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> When calling listServiceOfferings with VM id as parameter. It is returning 
> incompatible tagged offerings. It should only list all compatible tagged 
> offerings. The new service offering should contain all the tags of the 
> existing service offering. If that is the case It should list in the result.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)