[jira] [Commented] (CLOUDSTACK-8799) fix CsRedundant.py to handle public interfaces and default routes when changing state.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8799:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/784#issuecomment-138818591
  
Hi @bvbharat ,

Any news on this PR? 

Cheers,
Wilder


> fix CsRedundant.py to handle public interfaces and default routes when 
> changing state.
> --
>
> Key: CLOUDSTACK-8799
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8799
> 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: Bharat Kumar
>Priority: Critical
>
> When the Vr changes state to backup we need bring all the public interfaces 
> down. Similarly when it changes state to master we have bring all the public 
> interfaces up and add the default routes.



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

[jira] [Commented] (CLOUDSTACK-8799) fix CsRedundant.py to handle public interfaces and default routes when changing state.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8799:


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

https://github.com/apache/cloudstack/pull/784#discussion_r39018553
  
--- Diff: systemvm/patches/debian/config/opt/cloud/bin/cs/CsAddress.py ---
@@ -95,9 +95,17 @@ def get_control_if(self):
 return ip
 return None
 
+def check_if_link_up(self,dev):
+cmd="ip link show dev %s | tr '\n' ' ' | cut -d ' ' -f 9"%dev
--- End diff --

Indeed and also use the -o flag for 'ip':

 ip -o link show dev 

Then split the string using Python.


> fix CsRedundant.py to handle public interfaces and default routes when 
> changing state.
> --
>
> Key: CLOUDSTACK-8799
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8799
> 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: Bharat Kumar
>Priority: Critical
>
> When the Vr changes state to backup we need bring all the public interfaces 
> down. Similarly when it changes state to master we have bring all the public 
> interfaces up and add the default routes.



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

[jira] [Commented] (CLOUDSTACK-8814) Order of nics in non-VPC router changed resulting in services to fail

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8814:


Github user nlivens commented on the pull request:

https://github.com/apache/cloudstack/pull/788#issuecomment-138851642
  
I've tested the patch as well since I was hitting the exact same issue. All 
is working fine, and interfaces are configured correctly. :+1:


> Order of nics in non-VPC router changed resulting in services to fail
> -
>
> Key: CLOUDSTACK-8814
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8814
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When testing a non-vpc setup, CloudStack was not able to ssh to 169.254.x.y 
> because it was not listening on this ip:
> Isolated network, single router doesn't listen on link_local:3922
> tcp0  0 192.168.23.25:3922  0.0.0.0:*   LISTEN
>   0  68283487/sshd   
> Redundant isolated router:
> tcp0  0 10.20.1.10:3922 0.0.0.0:*   LISTEN
>   0  64343068/sshd   
> The reason for this, is that the naming of the interfaces now seems to be the 
> same (same order) as on VPC routers. This used to be different. 
> cloud-early-config uses hard-coded eth devices that seem not to have 
> reflected to these changes.
> setup_vpcrouter() {
> ...
>   setup_sshd $ETH0_IP "eth0"
> ...
> ==> That works!
> setup_router() {
> ..
> setup_sshd $ETH1_IP "eth1"
> ==> That goes wrong now.
> If we keep this new order, all nics need to be checked. Apache settings, 
> keepalived etc etc
> Here you see the difference:
> non-vpc router in 4.4:
> root@r-17809-VM:~# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 02:00:1c:e5:00:16  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:251172 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:223685 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:22836300 (21.7 MiB)  TX bytes:106769179 (101.8 MiB)
>   Interrupt:24 
> eth1  Link encap:Ethernet  HWaddr 0e:00:a9:fe:01:44  
>   inet addr:169.254.1.68  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:13052283 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:16557626 errors:0 dropped:16 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:7051380496 (6.5 GiB)  TX bytes:3279800734 (3.0 GiB)
>   Interrupt:25 
> eth2  Link encap:Ethernet  HWaddr 06:ab:30:00:00:30  
>   inet addr:178.y.x.22  Bcast:178.y.x.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:308293122 errors:0 dropped:540 overruns:0 frame:0
>   TX packets:364798 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:16920767106 (15.7 GiB)  TX bytes:33871999 (32.3 MiB)
>   Interrupt:26 
> non-vpc router in 4.6
> root@r-9-VM:/opt/cloud/bin/cs# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:04  
>   inet addr:169.254.3.4  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:1018 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:788 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:163208 (159.3 KiB)  TX bytes:110389 (107.8 KiB)
> eth1  Link encap:Ethernet  HWaddr 06:c3:88:00:00:19  
>   inet addr:192.168.23.25  Bcast:192.168.23.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:20 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:1344 (1.3 KiB)  TX bytes:606 (606.0 B)
> eth2  Link encap:Ethernet  HWaddr 02:00:6d:bd:00:02  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:40 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:4308 (4.2 KiB)  TX bytes:294 

[jira] [Commented] (CLOUDSTACK-8816) rabbitMQ: generated events have wrong or missing uuids

[Rajani Karuturi (JIRA)]

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

Rajani Karuturi commented on CLOUDSTACK-8816:
-

CreateNetworkEvent
*Before*

|  routing_key   | exchange  | 
message_count | 
  payload   

| payload_bytes | payload_encoding | 
redelivered |
| management-server.ActionEvent.NETWORK-CREATE.Network.* | cloudstack-events | 
0 | {"eventDateTime":"2015-09-09 09:35:02 
+0530","status":"Completed","description":"Successfully completed creating 
network. Network Id: 
206","event":"NETWORK.CREATE","account":"bd73dc2e-35c0-11e5-b094-d4ae52cb9af0","user":"bd7ea748-35c0-11e5-b094-d4ae52cb9af0"}
 | 259   | string   | False   |

*After*

|routing_key
| exchange  | message_count |   


payload 

   | payload_bytes | payload_encoding | redelivered |
| 
management-server.ActionEvent.NETWORK-CREATE.Network.c9ed8d0d-6e58-456e-be58-28bb809f0b3a
 | cloudstack-events | 52| 
{"eventDateTime":"2015-09-09 10:12:37 
+0530","status":"Completed","description":"Successfully completed creating 
network. Network Id: 
210","event":"NETWORK.CREATE","entityuuid":"c9ed8d0d-6e58-456e-be58-28bb809f0b3a","entity":"com.cloud.network.Network","account":"bd73dc2e-35c0-11e5-b094-d4ae52cb9af0","user":"bd7ea748-35c0-11e5-b094-d4ae52cb9af0"}
 | 348   | string   | False   |

> rabbitMQ: generated events have wrong or missing uuids
> --
>
> Key: CLOUDSTACK-8816
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8816
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.2, 4.4.4, 4.5.2
>Reporter: sadhu suresh
>Assignee: Rajani Karuturi
>Priority: Critical
>
> 1. create an account ppp
> 2,create few users under ppp account
> 3.delete the "ppp" account
> 4.check the rabbit mq  for generated events
> actual result:
> Therecieved event has admin user uuid instead of deleted account uuid
> The server reported 0 messages remaining.
> Exchange  cloudstack-events
> Routing Key   management-server.AsyncJobEvent.complete.Account.*
> Redelivered   ●
> Properties
> priority: 0
> delivery_mode:2
> content_type: text/plain
> Payload 885 bytes Encoding: string
> {"cmdInfo":"{\"id\":\"d08d73a5-b577-4082-a959-114b433979f1\",\"response\":\"json\",\"sessionkey\":\"bYp8fdaTPgTYLtuVlSPxnHj9Iuk\\u003d\",\"ctxDetails\":\"{\\\"com.cloud.user.Account\\\":\\\"d08d73a5-b577-4082-a959-114b433979f1\\\"}\",\"cmdEventType\":\"ACCOUNT.DELETE\",\"ctxUserId\":\"2\",\"httpmethod\":\"GET\",\"_\":\"1416046428981\",\"uuid\":\"d08d73a5-b577-4082-a959-114b433979f1\",\"ctxAccountId\":\"2\",\"ctxStartEventId\":\"271\"}","instanceType":"Account","instanceUuid":"","jobId":"0749f13f-517b-4cba-81f2-c9a9d23445cd","status":"SUCCEEDED","processStatus":"0","commandEventType":"ACCOUNT.DELETE","resultCode":"0","command":"org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd","jobResult":"org.apache.cloudstack.api.response.SuccessResponse/null/{\"success\":true}","account":"fcf6dd7e-6983-11e4-bb12-066294db","user":"fcf71ae6-6983-11e4-bb12-066294db"



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

[jira] [Commented] (CLOUDSTACK-8690) VR remote access vpn config is not applied

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-8690:Added remote access vpn and vpn users configuration


> VR remote access vpn config is not applied
> --
>
> Key: CLOUDSTACK-8690
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8690
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.6.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.6.0
>
>
> Enabling remote access vpn on the network source nat ip address is not 
> configuring the VR ipsec for remote access vpn. But the command is returning 
> success.
> The below are the logs shown in the VR /var/log/cloud.log
> 2015-07-30 02:00:20,788 Error I do not know what to do with file of type 
> remoteaccessvpn
> 2015-07-30 02:00:20,788 Loading data bag type ips
> 2015-07-30 02:00:20,789 Loading data bag type cmdline



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

[jira] [Commented] (CLOUDSTACK-8690) VR remote access vpn config is not applied

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #772 from jayapalu/rvpn

CLOUDSTACK-8690:Added remote access vpn and vpn users configuration@remibergsma 
 @wilderrodrigues
Added the VR configuration changes for
1. Remote access vpn
2. Remote access vpn users.

* pr/772:
  CLOUDSTACK-8690: Updated the iptables order
  CLOUDSTACK-8690:Added remote access vpn and vpn users configuration

Signed-off-by: wilderrodrigues 


> VR remote access vpn config is not applied
> --
>
> Key: CLOUDSTACK-8690
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8690
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.6.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.6.0
>
>
> Enabling remote access vpn on the network source nat ip address is not 
> configuring the VR ipsec for remote access vpn. But the command is returning 
> success.
> The below are the logs shown in the VR /var/log/cloud.log
> 2015-07-30 02:00:20,788 Error I do not know what to do with file of type 
> remoteaccessvpn
> 2015-07-30 02:00:20,788 Loading data bag type ips
> 2015-07-30 02:00:20,789 Loading data bag type cmdline



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

[jira] [Commented] (CLOUDSTACK-8690) VR remote access vpn config is not applied

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #772 from jayapalu/rvpn

CLOUDSTACK-8690:Added remote access vpn and vpn users configuration@remibergsma 
 @wilderrodrigues
Added the VR configuration changes for
1. Remote access vpn
2. Remote access vpn users.

* pr/772:
  CLOUDSTACK-8690: Updated the iptables order
  CLOUDSTACK-8690:Added remote access vpn and vpn users configuration

Signed-off-by: wilderrodrigues 


> VR remote access vpn config is not applied
> --
>
> Key: CLOUDSTACK-8690
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8690
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.6.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.6.0
>
>
> Enabling remote access vpn on the network source nat ip address is not 
> configuring the VR ipsec for remote access vpn. But the command is returning 
> success.
> The below are the logs shown in the VR /var/log/cloud.log
> 2015-07-30 02:00:20,788 Error I do not know what to do with file of type 
> remoteaccessvpn
> 2015-07-30 02:00:20,788 Loading data bag type ips
> 2015-07-30 02:00:20,789 Loading data bag type cmdline



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

[jira] [Commented] (CLOUDSTACK-8827) VM snapshot stuck in Creating state when management service is stopped

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8827:


GitHub user anshul1886 opened a pull request:

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

CLOUDSTACK-8827: Move the VM snapshots stuck in transitional states to 
stable states during managment server restart


i.e. If snapshot in creating state move it to Error state and if it is in 
reverting state move it to Ready state.

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

$ git pull https://github.com/anshul1886/cloudstack-1 CLOUDSTACK-8827

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

https://github.com/apache/cloudstack/pull/793.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 #793


commit c19bdcaf0847d23e3a5ee1daf374bf9173d86290
Author: Anshul Gangwar 
Date:   2015-09-09T08:51:15Z

CLOUDSTACK-8827: Move the VM snapshots stuck in transitional states to 
stable state during managment server restart
i.e. If snapshot in creating state move it to Error state and if it is in 
reverting state move it to Ready state.




> VM snapshot stuck in Creating state when management service is stopped
> --
>
> Key: CLOUDSTACK-8827
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8827
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
> Fix For: 4.6.0
>
>
> If we stop cloudstack-managment service while a VM snapshot is in progress, 
> the snapshot will be stuck in "Creating" state forever, even after the 
> service is started.
> This will leave the snapshot in unusable state (we can't delete it or it 
> won't go into Error state etc).
> Repro steps:
> ==
> Create an instance.
> Take a VM snapshot and stop the cloudstack-managment service while the 
> snapshot is in progress.
> Check the snapshot state in DB and it will be creating.
> Start the management service and check the snapshot state.
> It will be creating forever.



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

[jira] [Commented] (CLOUDSTACK-8690) VR remote access vpn config is not applied

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-8690:Added remote access vpn and vpn users configuration


> VR remote access vpn config is not applied
> --
>
> Key: CLOUDSTACK-8690
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8690
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.6.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.6.0
>
>
> Enabling remote access vpn on the network source nat ip address is not 
> configuring the VR ipsec for remote access vpn. But the command is returning 
> success.
> The below are the logs shown in the VR /var/log/cloud.log
> 2015-07-30 02:00:20,788 Error I do not know what to do with file of type 
> remoteaccessvpn
> 2015-07-30 02:00:20,788 Loading data bag type ips
> 2015-07-30 02:00:20,789 Loading data bag type cmdline



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

[jira] [Commented] (CLOUDSTACK-8690) VR remote access vpn config is not applied

[ASF subversion and git services (JIRA)]

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

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

Commit 33f4f952cf0cbec83c6f2195bd8e94d628215040 in cloudstack's branch 
refs/heads/master from Jayapal
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=33f4f95 ]

CLOUDSTACK-8690: Updated the iptables order


> VR remote access vpn config is not applied
> --
>
> Key: CLOUDSTACK-8690
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8690
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.6.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.6.0
>
>
> Enabling remote access vpn on the network source nat ip address is not 
> configuring the VR ipsec for remote access vpn. But the command is returning 
> success.
> The below are the logs shown in the VR /var/log/cloud.log
> 2015-07-30 02:00:20,788 Error I do not know what to do with file of type 
> remoteaccessvpn
> 2015-07-30 02:00:20,788 Loading data bag type ips
> 2015-07-30 02:00:20,789 Loading data bag type cmdline



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

[jira] [Resolved] (CLOUDSTACK-8690) VR remote access vpn config is not applied

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy resolved CLOUDSTACK-8690.
---
Resolution: Fixed

> VR remote access vpn config is not applied
> --
>
> Key: CLOUDSTACK-8690
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8690
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.6.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.6.0
>
>
> Enabling remote access vpn on the network source nat ip address is not 
> configuring the VR ipsec for remote access vpn. But the command is returning 
> success.
> The below are the logs shown in the VR /var/log/cloud.log
> 2015-07-30 02:00:20,788 Error I do not know what to do with file of type 
> remoteaccessvpn
> 2015-07-30 02:00:20,788 Loading data bag type ips
> 2015-07-30 02:00:20,789 Loading data bag type cmdline



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

[jira] [Commented] (CLOUDSTACK-8821) Provide appropriate message in the UI when configuring the Firewall rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8821:


GitHub user nitin-maharana opened a pull request:

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

CLOUDSTACK-8821: UI Change while configuring firewall rule.

It provides appropriate message in the UI when configuring the firewall 
rules in Network page.
If the default egress policy is allow, then it says to block traffic. If 
the default egress policy is deny, then it says to allow traffic.

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

$ git pull https://github.com/nitin-maharana/cloudstack CloudStack-Nitin3

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

https://github.com/apache/cloudstack/pull/791.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 #791


commit 93ed525c00ae809ce813f120b6c260fd197ca311
Author: Nitin Kumar Maharana 
Date:   2015-09-09T07:12:15Z

CLOUDSTACK-8821: Provide appropriate message in the UI when configuring the 
Firewall rules.




> Provide appropriate message in the UI when configuring the Firewall rules
> -
>
> Key: CLOUDSTACK-8821
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8821
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Nitin Kumar Maharana
>
> While adding Firewall rules, the egress rules can be to configure Allow / 
> Deny rules based on the Default egress policy in the network offering.
> It should provide a clear message in the UI: such as if Allow – “Configure 
> the rules below to Block Traffic” – If Deny – “Configure the rules below to 
> Allow Traffic”



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

[jira] [Commented] (CLOUDSTACK-8690) VR remote access vpn config is not applied

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-8690: Updated the iptables order


> VR remote access vpn config is not applied
> --
>
> Key: CLOUDSTACK-8690
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8690
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.6.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.6.0
>
>
> Enabling remote access vpn on the network source nat ip address is not 
> configuring the VR ipsec for remote access vpn. But the command is returning 
> success.
> The below are the logs shown in the VR /var/log/cloud.log
> 2015-07-30 02:00:20,788 Error I do not know what to do with file of type 
> remoteaccessvpn
> 2015-07-30 02:00:20,788 Loading data bag type ips
> 2015-07-30 02:00:20,789 Loading data bag type cmdline



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

[jira] [Commented] (CLOUDSTACK-8690) VR remote access vpn config is not applied

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8690:


Github user asfgit closed the pull request at:

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


> VR remote access vpn config is not applied
> --
>
> Key: CLOUDSTACK-8690
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8690
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.6.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.6.0
>
>
> Enabling remote access vpn on the network source nat ip address is not 
> configuring the VR ipsec for remote access vpn. But the command is returning 
> success.
> The below are the logs shown in the VR /var/log/cloud.log
> 2015-07-30 02:00:20,788 Error I do not know what to do with file of type 
> remoteaccessvpn
> 2015-07-30 02:00:20,788 Loading data bag type ips
> 2015-07-30 02:00:20,789 Loading data bag type cmdline



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

[jira] [Commented] (CLOUDSTACK-8690) VR remote access vpn config is not applied

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #772 from jayapalu/rvpn

CLOUDSTACK-8690:Added remote access vpn and vpn users configuration@remibergsma 
 @wilderrodrigues
Added the VR configuration changes for
1. Remote access vpn
2. Remote access vpn users.

* pr/772:
  CLOUDSTACK-8690: Updated the iptables order
  CLOUDSTACK-8690:Added remote access vpn and vpn users configuration

Signed-off-by: wilderrodrigues 


> VR remote access vpn config is not applied
> --
>
> Key: CLOUDSTACK-8690
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8690
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.6.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.6.0
>
>
> Enabling remote access vpn on the network source nat ip address is not 
> configuring the VR ipsec for remote access vpn. But the command is returning 
> success.
> The below are the logs shown in the VR /var/log/cloud.log
> 2015-07-30 02:00:20,788 Error I do not know what to do with file of type 
> remoteaccessvpn
> 2015-07-30 02:00:20,788 Loading data bag type ips
> 2015-07-30 02:00:20,789 Loading data bag type cmdline



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

[jira] [Commented] (CLOUDSTACK-8826) XenServer - Use device id passed as part of attach volume API properly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8826:


Github user koushik-das commented on the pull request:

https://github.com/apache/cloudstack/pull/792#issuecomment-138819369
  
I had to undo changes from PR https://github.com/apache/cloudstack/pull/773 
to run the tests.


> XenServer - Use device id passed as part of attach volume API properly
> --
>
> Key: CLOUDSTACK-8826
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8826
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
>Affects Versions: 4.6.0
>Reporter: Koushik Das
>Assignee: Koushik Das
> Fix For: 4.6.0
>
>
> Random failures were seen in XS attach/detach volume test scenarios (many 
> attach/detach were performed on the same VM over a span of 24 hrs).
> The failures happened as the device id for attaching volume wasn't available 
> in HV. Some detached volume didn't got cleaned up properly and so the device 
> id wasn't released.
> The fix would be clean up stale volumes before attaching new ones so the 
> device slots are released. Also using the device id should be best effort and 
> if that particular id is not available in XS, it should fallback on using an 
> id that is available and automatically assigned.



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

[jira] [Commented] (CLOUDSTACK-8816) rabbitMQ: generated events have wrong or missing uuids

[Rajani Karuturi (JIRA)]

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

Rajani Karuturi commented on CLOUDSTACK-8816:
-

account, user are for the caller in an event. entityUuid is the field for the 
actioned entity which will be matched by corresponding class(either 
VirtualMachine or Account or user etc.) 
In the below event, entityUuid is missing which is the cause of confusion. That 
needs to be fixed.

Current


 routing_key: management-server.ActionEvent.ACCOUNT-DELETE.Account.*
exchange: cloudstack-events
   message_count: 2
 payload: {"eventDateTime":"2015-09-04 17:59:24 
+0530","status":"Scheduled","description":"deleting User test4 (id: 28) and 
accountId \u003d 
28","event":"ACCOUNT.DELETE","Account":"c09e2e81-8edc-4c27-b072-25005b522b63","account":"bd73dc2e-35c0-11e5-b094-d4ae52cb9af0","user":"bd7ea748-35c0-11e5-b094-d4ae52cb9af0"}
   payload_bytes: 304
payload_encoding: string
 redelivered: False


Actual


 routing_key: 
management-server.ActionEvent.ACCOUNT-DELETE.Account.5e45aa20-85e0-430c-95d2-75d531291625
exchange: cloudstack-events
   message_count: 2
 payload: {"eventDateTime":"2015-09-04 17:55:41 
+0530","status":"Scheduled","description":"deleting User test (id: 31) and 
accountId \u003d 
31","event":"ACCOUNT.DELETE","entityuuid":"5e45aa20-85e0-430c-95d2-75d531291625","Account":"5e45aa20-85e0-430c-95d2-75d531291625","account":"bd73dc2e-35c0-11e5-b094-d4ae52cb9af0","user":"bd7ea748-35c0-11e5-b094-d4ae52cb9af0"}
   payload_bytes: 355
payload_encoding: string
 redelivered: True

> rabbitMQ: generated events have wrong or missing uuids
> --
>
> Key: CLOUDSTACK-8816
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8816
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.2, 4.4.4, 4.5.2
>Reporter: sadhu suresh
>Assignee: Rajani Karuturi
>Priority: Critical
>
> 1. create an account ppp
> 2,create few users under ppp account
> 3.delete the "ppp" account
> 4.check the rabbit mq  for generated events
> actual result:
> Therecieved event has admin user uuid instead of deleted account uuid
> The server reported 0 messages remaining.
> Exchange  cloudstack-events
> Routing Key   management-server.AsyncJobEvent.complete.Account.*
> Redelivered   ●
> Properties
> priority: 0
> delivery_mode:2
> content_type: text/plain
> Payload 885 bytes Encoding: string
> {"cmdInfo":"{\"id\":\"d08d73a5-b577-4082-a959-114b433979f1\",\"response\":\"json\",\"sessionkey\":\"bYp8fdaTPgTYLtuVlSPxnHj9Iuk\\u003d\",\"ctxDetails\":\"{\\\"com.cloud.user.Account\\\":\\\"d08d73a5-b577-4082-a959-114b433979f1\\\"}\",\"cmdEventType\":\"ACCOUNT.DELETE\",\"ctxUserId\":\"2\",\"httpmethod\":\"GET\",\"_\":\"1416046428981\",\"uuid\":\"d08d73a5-b577-4082-a959-114b433979f1\",\"ctxAccountId\":\"2\",\"ctxStartEventId\":\"271\"}","instanceType":"Account","instanceUuid":"","jobId":"0749f13f-517b-4cba-81f2-c9a9d23445cd","status":"SUCCEEDED","processStatus":"0","commandEventType":"ACCOUNT.DELETE","resultCode":"0","command":"org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd","jobResult":"org.apache.cloudstack.api.response.SuccessResponse/null/{\"success\":true}","account":"fcf6dd7e-6983-11e4-bb12-066294db","user":"fcf71ae6-6983-11e4-bb12-066294db"



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

[jira] [Commented] (CLOUDSTACK-8816) rabbitMQ: generated events have wrong or missing uuids

[Rajani Karuturi (JIRA)]

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

Rajani Karuturi commented on CLOUDSTACK-8816:
-

WRT async job events

current


 routing_key: management-server.AsyncJobEvent.complete.Account.*
exchange: cloudstack-events
   message_count: 0
 payload: 
{"cmdInfo":"{\"id\":\"9dd3abc2-3f8b-4852-aa60-a74b234acb13\",\"response\":\"json\",\"sessionkey\":\"5ig1ItP2_5v-mgY4cVJbJN5hw_w\",\"ctxDetails\":\"{\\\"interface
 
com.cloud.user.Account\\\":\\\"9dd3abc2-3f8b-4852-aa60-a74b234acb13\\\"}\",\"cmdEventType\":\"ACCOUNT.DELETE\",\"expires\":\"2015-09-07T11:11:56+\",\"ctxUserId\":\"2\",\"signatureversion\":\"3\",\"httpmethod\":\"GET\",\"uuid\":\"9dd3abc2-3f8b-4852-aa60-a74b234acb13\",\"ctxAccountId\":\"2\",\"ctxStartEventId\":\"447\"}","instanceType":"Account","jobId":"5004989d-0cde-4922-8afa-66bf38b75ea7","status":"SUCCEEDED","processStatus":"0","commandEventType":"ACCOUNT.DELETE","resultCode":"0","command":"org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd","jobResult":"org.apache.cloudstack.api.response.SuccessResponse/null/{\"success\":true}","account":"bd73dc2e-35c0-11e5-b094-d4ae52cb9af0","user":"bd7ea748-35c0-11e5-b094-d4ae52cb9af0"}
   payload_bytes: 914
payload_encoding: string
 redelivered: False



actual



 routing_key: 
management-server.AsyncJobEvent.complete.Account.0e171f4d-98f5-46c3-8099-fd08402b8f0d
exchange: cloudstack-events
   message_count: 0
 payload: 
{"cmdInfo":"{\"id\":\"0e171f4d-98f5-46c3-8099-fd08402b8f0d\",\"response\":\"json\",\"sessionkey\":\"U9HVbOWsaj-0lZJKPBETZ6qH-IU\",\"ctxDetails\":\"{\\\"interface
 
com.cloud.user.Account\\\":\\\"0e171f4d-98f5-46c3-8099-fd08402b8f0d\\\"}\",\"cmdEventType\":\"ACCOUNT.DELETE\",\"expires\":\"2015-09-07T11:42:10+\",\"ctxUserId\":\"2\",\"signatureversion\":\"3\",\"httpmethod\":\"GET\",\"uuid\":\"0e171f4d-98f5-46c3-8099-fd08402b8f0d\",\"ctxAccountId\":\"2\",\"ctxStartEventId\":\"461\"}","instanceType":"Account","instanceUuid":"0e171f4d-98f5-46c3-8099-fd08402b8f0d","jobId":"297534ce-d2b8-4f6f-a0ba-c102d6cd219e","status":"SUCCEEDED","processStatus":"0","commandEventType":"ACCOUNT.DELETE","resultCode":"0","command":"org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd","jobResult":"org.apache.cloudstack.api.response.SuccessResponse/null/{\"success\":true}","account":"bd73dc2e-35c0-11e5-b094-d4ae52cb9af0","user":"bd7ea748-35c0-11e5-b094-d4ae52cb9af0"}
   payload_bytes: 968
payload_encoding: string
 redelivered: False



> rabbitMQ: generated events have wrong or missing uuids
> --
>
> Key: CLOUDSTACK-8816
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8816
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.2, 4.4.4, 4.5.2
>Reporter: sadhu suresh
>Assignee: Rajani Karuturi
>Priority: Critical
>
> 1. create an account ppp
> 2,create few users under ppp account
> 3.delete the "ppp" account
> 4.check the rabbit mq  for generated events
> actual result:
> Therecieved event has admin user uuid instead of deleted account uuid
> The server reported 0 messages remaining.
> Exchange  cloudstack-events
> Routing Key   management-server.AsyncJobEvent.complete.Account.*
> Redelivered   ●
> Properties
> priority: 0
> delivery_mode:2
> content_type: text/plain
> Payload 885 bytes Encoding: string
> {"cmdInfo":"{\"id\":\"d08d73a5-b577-4082-a959-114b433979f1\",\"response\":\"json\",\"sessionkey\":\"bYp8fdaTPgTYLtuVlSPxnHj9Iuk\\u003d\",\"ctxDetails\":\"{\\\"com.cloud.user.Account\\\":\\\"d08d73a5-b577-4082-a959-114b433979f1\\\"}\",\"cmdEventType\":\"ACCOUNT.DELETE\",\"ctxUserId\":\"2\",\"httpmethod\":\"GET\",\"_\":\"1416046428981\",\"uuid\":\"d08d73a5-b577-4082-a959-114b433979f1\",\"ctxAccountId\":\"2\",\"ctxStartEventId\":\"271\"}","instanceType":"Account","instanceUuid":"","jobId":"0749f13f-517b-4cba-81f2-c9a9d23445cd","status":"SUCCEEDED","processStatus":"0","commandEventType":"ACCOUNT.DELETE","resultCode":"0","command":"org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd","jobResult":"org.apache.cloudstack.api.response.SuccessResponse/null/{\"success\":true}","account":"fcf6dd7e-6983-11e4-bb12-066294db","user":"fcf71ae6-6983-11e4-bb12-066294db"



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

[jira] [Commented] (CLOUDSTACK-8814) Order of nics in non-VPC router changed resulting in services to fail

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8814:


Github user koushik-das commented on the pull request:

https://github.com/apache/cloudstack/pull/788#issuecomment-138846797
  
I tested the patch, now isolated network VR is coming up and the interfaces 
are configured in correct order.

eth0 - guest
eth1 - link local
eth2 - public



> Order of nics in non-VPC router changed resulting in services to fail
> -
>
> Key: CLOUDSTACK-8814
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8814
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When testing a non-vpc setup, CloudStack was not able to ssh to 169.254.x.y 
> because it was not listening on this ip:
> Isolated network, single router doesn't listen on link_local:3922
> tcp0  0 192.168.23.25:3922  0.0.0.0:*   LISTEN
>   0  68283487/sshd   
> Redundant isolated router:
> tcp0  0 10.20.1.10:3922 0.0.0.0:*   LISTEN
>   0  64343068/sshd   
> The reason for this, is that the naming of the interfaces now seems to be the 
> same (same order) as on VPC routers. This used to be different. 
> cloud-early-config uses hard-coded eth devices that seem not to have 
> reflected to these changes.
> setup_vpcrouter() {
> ...
>   setup_sshd $ETH0_IP "eth0"
> ...
> ==> That works!
> setup_router() {
> ..
> setup_sshd $ETH1_IP "eth1"
> ==> That goes wrong now.
> If we keep this new order, all nics need to be checked. Apache settings, 
> keepalived etc etc
> Here you see the difference:
> non-vpc router in 4.4:
> root@r-17809-VM:~# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 02:00:1c:e5:00:16  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:251172 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:223685 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:22836300 (21.7 MiB)  TX bytes:106769179 (101.8 MiB)
>   Interrupt:24 
> eth1  Link encap:Ethernet  HWaddr 0e:00:a9:fe:01:44  
>   inet addr:169.254.1.68  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:13052283 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:16557626 errors:0 dropped:16 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:7051380496 (6.5 GiB)  TX bytes:3279800734 (3.0 GiB)
>   Interrupt:25 
> eth2  Link encap:Ethernet  HWaddr 06:ab:30:00:00:30  
>   inet addr:178.y.x.22  Bcast:178.y.x.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:308293122 errors:0 dropped:540 overruns:0 frame:0
>   TX packets:364798 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:16920767106 (15.7 GiB)  TX bytes:33871999 (32.3 MiB)
>   Interrupt:26 
> non-vpc router in 4.6
> root@r-9-VM:/opt/cloud/bin/cs# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:04  
>   inet addr:169.254.3.4  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:1018 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:788 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:163208 (159.3 KiB)  TX bytes:110389 (107.8 KiB)
> eth1  Link encap:Ethernet  HWaddr 06:c3:88:00:00:19  
>   inet addr:192.168.23.25  Bcast:192.168.23.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:20 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:1344 (1.3 KiB)  TX bytes:606 (606.0 B)
> eth2  Link encap:Ethernet  HWaddr 02:00:6d:bd:00:02  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:40 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX 

[jira] [Commented] (CLOUDSTACK-8821) Provide appropriate message in the UI when configuring the Firewall rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8821:


Github user nitin-maharana commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/786#discussion_r39011419
  
--- Diff: ui/scripts/network.js ---
@@ -1612,6 +1613,36 @@
 });
 }
 });
+
+if (!isConfigRulesMsgShown) {
+isConfigRulesMsgShown = 
true;
+$.ajax({
+url: 
createURL('listNetworkOfferings'),
+data: {
+id: 
args.context.networks[0].networkofferingid
+},
+dataType: 'json',
+async: true,
+success: 
function(json) {
+var response = 
json.listnetworkofferingsresponse.networkoffering ?
+
json.listnetworkofferingsresponse.networkoffering[0] : null;
+
+if (response != 
null) {
+var 
egressdefaultpolicy;
+
+if 
(response.egressdefaultpolicy == true) {
+
egressdefaultpolicy = 'Block';
+} else {
+
egressdefaultpolicy = 'Allow';
+}
+
+
cloudStack.dialog.notice({
+message: 
_l('Configure the rules to ' + egressdefaultpolicy + ' Traffic.')
--- End diff --

I am making one more pull request with the change from a different branch. 
Thanks.


> Provide appropriate message in the UI when configuring the Firewall rules
> -
>
> Key: CLOUDSTACK-8821
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8821
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Nitin Kumar Maharana
>
> While adding Firewall rules, the egress rules can be to configure Allow / 
> Deny rules based on the Default egress policy in the network offering.
> It should provide a clear message in the UI: such as if Allow – “Configure 
> the rules below to Block Traffic” – If Deny – “Configure the rules below to 
> Allow Traffic”



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

[jira] [Commented] (CLOUDSTACK-8805) Domains become inactive automatically.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8805:


Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/775#issuecomment-138810904
  
Yes, It can be possible. But I have not hard-coded this change, I followed 
the way sql queries are generated everywhere. This way of generating SQL query 
is followed in entire code. I think we have to come up with a generic way to 
resolve this vulnerability issue in entire code. 



> Domains become inactive automatically.
> --
>
> Key: CLOUDSTACK-8805
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8805
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> If there is a domain with name '%', if we force delete the '%' domain then 
> all the other domains become inactive except Root domain.



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

[jira] [Commented] (CLOUDSTACK-8826) XenServer - Use device id passed as part of attach volume API properly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8826:


GitHub user koushik-das opened a pull request:

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

CLOUDSTACK-8826: XenServer - Use device id passed as part of attach v…

…olume API properly

If device id passed as part of API and available then use it otherwise 
fallback on XS to automatically assign one.
For ISO device id used is 3 and it is processed before any other entry to 
avoid conflict.

This is only specific to XS, ran the following tests:

BVT: test/integration/smoke/test_volumes.py

Test Volume creation for all Disk Offerings (incl. custom) ... === 
TestName: test_01_create_volume | Status : SUCCESS ===
ok
Attach a created Volume to a Running VM ... === TestName: 
test_02_attach_volume | Status : SUCCESS ===
ok
Download a Volume attached to a VM ... === TestName: 
test_03_download_attached_volume | Status : SUCCESS ===
ok
Delete a Volume attached to a VM ... === TestName: 
test_04_delete_attached_volume | Status : SUCCESS ===
ok
Detach a Volume attached to a VM ... === TestName: test_05_detach_volume | 
Status : SUCCESS ===
ok
Download a Volume unattached to an VM ... === TestName: 
test_06_download_detached_volume | Status : SUCCESS ===
ok
Test resize (negative) non-existent volume ... === TestName: 
test_07_resize_fail | Status : SUCCESS ===
ok
Test resize a volume ... === TestName: test_08_resize_volume | Status : 
SUCCESS ===
ok
Delete a Volume unattached to an VM ... === TestName: 
test_09_delete_detached_volume | Status : SUCCESS ===
ok

--
Ran 9 tests in 1116.972s

OK



Regression: test/integration/component/test_volumes.py

Test Volume attach/detach to VM (5 data volumes) ... === TestName: 
test_01_volume_attach_detach | Status : SUCCESS ===
ok
Test Attach volumes (max capacity) ... === TestName: test_01_volume_attach 
| Status : SUCCESS ===
ok
Test attach volumes (more than max) to an instance ... === TestName: 
test_02_volume_attach_max | Status : SUCCESS ===
ok
Test Volumes and ISO attach ... === TestName: test_01_volume_iso_attach | 
Status : SUCCESS ===
ok
Test custom disk sizes beyond range ... === TestName: 
test_deployVmWithCustomDisk | Status : SUCCESS ===
ok
@Desc:Volume is not retaining same uuid when migrating from one ... SKIP: 
No suitable storage pools found for volume migration.
Skipping
Attach a created Volume to a Running VM ... === TestName: 
test_01_attach_volume | Status : SUCCESS ===
ok
Detach a Volume attached to a VM ... === TestName: test_02_detach_volume | 
Status : SUCCESS ===
ok
Delete a Volume unattached to an VM ... === TestName: 
test_03_delete_detached_volume | Status : SUCCESS ===
ok
Create a volume under a non-root domain as non-root-domain user ... === 
TestName: test_create_volume_under_domain | Status : SUCCESS ===
ok

--
Ran 10 tests in 1750.686s

OK (SKIP=1)


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

$ git pull https://github.com/koushik-das/cloudstack CLOUDSTACK-8826

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

https://github.com/apache/cloudstack/pull/792.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 #792


commit 1dd27bd449a8e3d70b011e66af431e866c7627c2
Author: Koushik Das 
Date:   2015-09-09T07:30:17Z

CLOUDSTACK-8826: XenServer - Use device id passed as part of attach volume 
API properly
If device id passed as part of API and available then use it otherwise 
fallback on XS to automatically assign one.
For ISO device id used is 3 and it is processed before any other entry to 
avoid conflict.




> XenServer - Use device id passed as part of attach volume API properly
> --
>
> Key: CLOUDSTACK-8826
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8826
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
>Affects Versions: 4.6.0
>Reporter: Koushik Das
>Assignee: Koushik Das
> Fix For: 4.6.0
>
>
> Random failures were seen in XS attach/detach volume test scenarios (many 
> attach/detach were performed on the same VM over a 

[jira] [Created] (CLOUDSTACK-8827) VM snapshot stuck in Creating state when management service is stopped

[Anshul Gangwar (JIRA)]

Anshul Gangwar created CLOUDSTACK-8827:
--

 Summary: VM snapshot stuck in Creating state when management 
service is stopped
 Key: CLOUDSTACK-8827
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8827
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Anshul Gangwar
Assignee: Anshul Gangwar
 Fix For: 4.6.0


If we stop cloudstack-managment service while a VM snapshot is in progress, the 
snapshot will be stuck in "Creating" state forever, even after the service is 
started.
This will leave the snapshot in unusable state (we can't delete it or it won't 
go into Error state etc).
Repro steps:
==
Create an instance.
Take a VM snapshot and stop the cloudstack-managment service while the snapshot 
is in progress.
Check the snapshot state in DB and it will be creating.
Start the management service and check the snapshot state.
It will be creating forever.



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

[jira] [Commented] (CLOUDSTACK-8816) rabbitMQ: generated events have wrong or missing uuids

[Rajani Karuturi (JIRA)]

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

Rajani Karuturi commented on CLOUDSTACK-8816:
-

System vm Alert events will not have uuids. Fixed uuids in the other events 
that occur during systemvm reboot.

*Events After the fix*
*ConsoleProxy*

| routing_key| exchange | message_count | payload | payload_bytes | 
payload_encoding | redelivered |
| 
management-server.ActionEvent.PROXY-REBOOT.VirtualMachine.955e785a-9b25-4ade-aa1b-65fd9617a4e6
 | cloudstack-events | 4 | {"eventDateTime":"2015-09-09 14:02:53 
+0530","status":"Scheduled","description":"rebooting system vm: 
2","event":"PROXY.REBOOT","entityuuid":"955e785a-9b25-4ade-aa1b-65fd9617a4e6","entity":"com.cloud.vm.VirtualMachine","account":"bd73dc2e-35c0-11e5-b094-d4ae52cb9af0","user":"bd7ea748-35c0-11e5-b094-d4ae52cb9af0"}


















| 314   | string   | True|
| 
management-server.AsyncJobEvent.submit.SystemVm.955e785a-9b25-4ade-aa1b-65fd9617a4e6
   | cloudstack-events | 3 |{noformat} 
{"cmdInfo":"{\"id\":\"955e785a-9b25-4ade-aa1b-65fd9617a4e6\",\"response\":\"json\",\"ctxDetails\":\"{\\\"interface
 
com.cloud.vm.VirtualMachine\\\":\\\"955e785a-9b25-4ade-aa1b-65fd9617a4e6\\\"}\",\"cmdEventType\":\"PROXY.REBOOT\",\"ctxUserId\":\"2\",\"httpmethod\":\"GET\",\"_\":\"1441787903337\",\"uuid\":\"955e785a-9b25-4ade-aa1b-65fd9617a4e6\",\"ctxAccountId\":\"2\",\"ctxStartEventId\":\"744\"}","instanceType":"SystemVm","instanceUuid":"955e785a-9b25-4ade-aa1b-65fd9617a4e6","jobId":"baa9dfa0-2500-4ada-9a19-a47f3de6b076","status":"IN_PROGRESS","processStatus":"0","commandEventType":"PROXY.REBOOT","resultCode":"0","command":"org.apache.cloudstack.api.command.admin.systemvm.RebootSystemVmCmd","account":"bd73dc2e-35c0-11e5-b094-d4ae52cb9af0","user":"bd7ea748-35c0-11e5-b094-d4ae52cb9af0"}
  {noformat}











  | 794   | string   | True|
| 
management-server.ActionEvent.PROXY-REBOOT.VirtualMachine.955e785a-9b25-4ade-aa1b-65fd9617a4e6
 | cloudstack-events | 2 | {"eventDateTime":"2015-09-09 14:02:55 
+0530","status":"Started","description":"rebooting console proxy 
Vm","event":"PROXY.REBOOT","entityuuid":"955e785a-9b25-4ade-aa1b-65fd9617a4e6","entity":"com.cloud.vm.VirtualMachine","account":"bd73dc2e-35c0-11e5-b094-d4ae52cb9af0","user":"bd7ea748-35c0-11e5-b094-d4ae52cb9af0"}

   

[jira] [Commented] (CLOUDSTACK-8814) Order of nics in non-VPC router changed resulting in services to fail

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8814:


Github user koushik-das commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/788#discussion_r39025559
  
--- Diff: server/src/com/cloud/network/router/NetworkHelperImpl.java ---
@@ -610,20 +608,22 @@ protected HypervisorType 
getClusterToStartDomainRouterForOvm(final long podId) {
 throw new CloudRuntimeException(errMsg);
 }
 
-@Override
-public LinkedHashMap 
configureDefaultNics(final RouterDeploymentDefinition 
routerDeploymentDefinition) throws ConcurrentOperationException, 
InsufficientAddressCapacityException {
-
-final LinkedHashMap networks 
= new LinkedHashMap(3);
+protected LinkedHashMap 
configureControlNic(final RouterDeploymentDefinition 
routerDeploymentDefinition) {
+final LinkedHashMap 
controlConfig = new LinkedHashMap(3);
 
-// 1) Control network
 s_logger.debug("Adding nic for Virtual Router in Control network 
");
 final List offerings = 
_networkModel.getSystemAccountNetworkOfferings(NetworkOffering.SystemControlNetwork);
 final NetworkOffering controlOffering = offerings.get(0);
-final Network controlConfig = 
_networkMgr.setupNetwork(s_systemAccount, controlOffering, 
routerDeploymentDefinition.getPlan(), null, null, false).get(0);
+final Network controlNic = 
_networkMgr.setupNetwork(s_systemAccount, controlOffering, 
routerDeploymentDefinition.getPlan(), null, null, false).get(0);
 
-networks.put(controlConfig, new ArrayList());
+controlConfig.put(controlNic, new ArrayList());
+
+return controlConfig;
+}
+
+protected LinkedHashMap 
configurePublicNic(final RouterDeploymentDefinition routerDeploymentDefinition, 
final boolean hasGuestNic) {
+final LinkedHashMap 
publicConfig = new LinkedHashMap(3);
--- End diff --

In the individual configure methods, why is the initial size of the hash 
map 3? :)


> Order of nics in non-VPC router changed resulting in services to fail
> -
>
> Key: CLOUDSTACK-8814
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8814
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When testing a non-vpc setup, CloudStack was not able to ssh to 169.254.x.y 
> because it was not listening on this ip:
> Isolated network, single router doesn't listen on link_local:3922
> tcp0  0 192.168.23.25:3922  0.0.0.0:*   LISTEN
>   0  68283487/sshd   
> Redundant isolated router:
> tcp0  0 10.20.1.10:3922 0.0.0.0:*   LISTEN
>   0  64343068/sshd   
> The reason for this, is that the naming of the interfaces now seems to be the 
> same (same order) as on VPC routers. This used to be different. 
> cloud-early-config uses hard-coded eth devices that seem not to have 
> reflected to these changes.
> setup_vpcrouter() {
> ...
>   setup_sshd $ETH0_IP "eth0"
> ...
> ==> That works!
> setup_router() {
> ..
> setup_sshd $ETH1_IP "eth1"
> ==> That goes wrong now.
> If we keep this new order, all nics need to be checked. Apache settings, 
> keepalived etc etc
> Here you see the difference:
> non-vpc router in 4.4:
> root@r-17809-VM:~# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 02:00:1c:e5:00:16  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:251172 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:223685 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:22836300 (21.7 MiB)  TX bytes:106769179 (101.8 MiB)
>   Interrupt:24 
> eth1  Link encap:Ethernet  HWaddr 0e:00:a9:fe:01:44  
>   inet addr:169.254.1.68  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:13052283 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:16557626 errors:0 dropped:16 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:7051380496 (6.5 GiB)  

[jira] [Commented] (CLOUDSTACK-8805) Domains become inactive automatically.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8805:


Github user rafaelweingartner commented on the pull request:

https://github.com/apache/cloudstack/pull/775#issuecomment-138872339
  
@nitin-maharana, when I said that the String concatenation there might make 
ACS vulnerable to SQL injection attacks, I did not mean that your PR did that. 
What I meant was that the code that is there, even before your PR, is making 
ACs vulnerable.

I just mentioned about the vulnerability here to register the thought, so 
others can also think about the problem that might exist.

I do not know much of ACS DAOs, but if in other places such as VM API (in 
which users have access), the same String concatenations are used that can be a 
huge problem.
Besides that the code LGTM.



> Domains become inactive automatically.
> --
>
> Key: CLOUDSTACK-8805
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8805
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> If there is a domain with name '%', if we force delete the '%' domain then 
> all the other domains become inactive except Root domain.



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

[jira] [Created] (CLOUDSTACK-8828) secstorage.proxy is not setting proxy configuration on SSVM

[Anshul Gangwar (JIRA)]

Anshul Gangwar created CLOUDSTACK-8828:
--

 Summary: secstorage.proxy is not setting proxy configuration on 
SSVM
 Key: CLOUDSTACK-8828
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8828
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Anshul Gangwar
Assignee: Anshul Gangwar



It seems like that the bug in previous versions of CloudStack, that the proxy 
settings are not passed to SSVM, is still not solved.



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

[jira] [Commented] (CLOUDSTACK-8814) Order of nics in non-VPC router changed resulting in services to fail

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8814:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/788#issuecomment-138887396
  
My issue is also gone, so LGTM from me as well. Thanks for fixing this.


> Order of nics in non-VPC router changed resulting in services to fail
> -
>
> Key: CLOUDSTACK-8814
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8814
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When testing a non-vpc setup, CloudStack was not able to ssh to 169.254.x.y 
> because it was not listening on this ip:
> Isolated network, single router doesn't listen on link_local:3922
> tcp0  0 192.168.23.25:3922  0.0.0.0:*   LISTEN
>   0  68283487/sshd   
> Redundant isolated router:
> tcp0  0 10.20.1.10:3922 0.0.0.0:*   LISTEN
>   0  64343068/sshd   
> The reason for this, is that the naming of the interfaces now seems to be the 
> same (same order) as on VPC routers. This used to be different. 
> cloud-early-config uses hard-coded eth devices that seem not to have 
> reflected to these changes.
> setup_vpcrouter() {
> ...
>   setup_sshd $ETH0_IP "eth0"
> ...
> ==> That works!
> setup_router() {
> ..
> setup_sshd $ETH1_IP "eth1"
> ==> That goes wrong now.
> If we keep this new order, all nics need to be checked. Apache settings, 
> keepalived etc etc
> Here you see the difference:
> non-vpc router in 4.4:
> root@r-17809-VM:~# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 02:00:1c:e5:00:16  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:251172 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:223685 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:22836300 (21.7 MiB)  TX bytes:106769179 (101.8 MiB)
>   Interrupt:24 
> eth1  Link encap:Ethernet  HWaddr 0e:00:a9:fe:01:44  
>   inet addr:169.254.1.68  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:13052283 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:16557626 errors:0 dropped:16 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:7051380496 (6.5 GiB)  TX bytes:3279800734 (3.0 GiB)
>   Interrupt:25 
> eth2  Link encap:Ethernet  HWaddr 06:ab:30:00:00:30  
>   inet addr:178.y.x.22  Bcast:178.y.x.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:308293122 errors:0 dropped:540 overruns:0 frame:0
>   TX packets:364798 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:16920767106 (15.7 GiB)  TX bytes:33871999 (32.3 MiB)
>   Interrupt:26 
> non-vpc router in 4.6
> root@r-9-VM:/opt/cloud/bin/cs# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:04  
>   inet addr:169.254.3.4  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:1018 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:788 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:163208 (159.3 KiB)  TX bytes:110389 (107.8 KiB)
> eth1  Link encap:Ethernet  HWaddr 06:c3:88:00:00:19  
>   inet addr:192.168.23.25  Bcast:192.168.23.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:20 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:1344 (1.3 KiB)  TX bytes:606 (606.0 B)
> eth2  Link encap:Ethernet  HWaddr 02:00:6d:bd:00:02  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:40 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:4308 (4.2 KiB)  TX bytes:294 (294.0 B)
> loLink encap:Local Loopback  
>   inet 

[jira] [Commented] (CLOUDSTACK-8814) Order of nics in non-VPC router changed resulting in services to fail

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8814:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/788#issuecomment-138887313
  
@koushik-das They have been different for a long time. I think when VPC was 
invented, they reordered the nics so that the tiers came last (because you can 
have N of them). Recently in a refactor, the order was also changed in VR. This 
restores it. If we want the same order, we need to look at all the scripts 
(cloud-early-config and friends) that use hardcoded nic names. I think this was 
faster to do.


> Order of nics in non-VPC router changed resulting in services to fail
> -
>
> Key: CLOUDSTACK-8814
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8814
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When testing a non-vpc setup, CloudStack was not able to ssh to 169.254.x.y 
> because it was not listening on this ip:
> Isolated network, single router doesn't listen on link_local:3922
> tcp0  0 192.168.23.25:3922  0.0.0.0:*   LISTEN
>   0  68283487/sshd   
> Redundant isolated router:
> tcp0  0 10.20.1.10:3922 0.0.0.0:*   LISTEN
>   0  64343068/sshd   
> The reason for this, is that the naming of the interfaces now seems to be the 
> same (same order) as on VPC routers. This used to be different. 
> cloud-early-config uses hard-coded eth devices that seem not to have 
> reflected to these changes.
> setup_vpcrouter() {
> ...
>   setup_sshd $ETH0_IP "eth0"
> ...
> ==> That works!
> setup_router() {
> ..
> setup_sshd $ETH1_IP "eth1"
> ==> That goes wrong now.
> If we keep this new order, all nics need to be checked. Apache settings, 
> keepalived etc etc
> Here you see the difference:
> non-vpc router in 4.4:
> root@r-17809-VM:~# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 02:00:1c:e5:00:16  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:251172 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:223685 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:22836300 (21.7 MiB)  TX bytes:106769179 (101.8 MiB)
>   Interrupt:24 
> eth1  Link encap:Ethernet  HWaddr 0e:00:a9:fe:01:44  
>   inet addr:169.254.1.68  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:13052283 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:16557626 errors:0 dropped:16 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:7051380496 (6.5 GiB)  TX bytes:3279800734 (3.0 GiB)
>   Interrupt:25 
> eth2  Link encap:Ethernet  HWaddr 06:ab:30:00:00:30  
>   inet addr:178.y.x.22  Bcast:178.y.x.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:308293122 errors:0 dropped:540 overruns:0 frame:0
>   TX packets:364798 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:16920767106 (15.7 GiB)  TX bytes:33871999 (32.3 MiB)
>   Interrupt:26 
> non-vpc router in 4.6
> root@r-9-VM:/opt/cloud/bin/cs# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:04  
>   inet addr:169.254.3.4  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:1018 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:788 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:163208 (159.3 KiB)  TX bytes:110389 (107.8 KiB)
> eth1  Link encap:Ethernet  HWaddr 06:c3:88:00:00:19  
>   inet addr:192.168.23.25  Bcast:192.168.23.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:20 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:1344 (1.3 KiB)  TX bytes:606 (606.0 B)
> eth2  Link encap:Ethernet  HWaddr 02:00:6d:bd:00:02  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP 

[jira] [Commented] (CLOUDSTACK-8814) Order of nics in non-VPC router changed resulting in services to fail

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #788 from ekholabs/fix/iso_net-CLOUDSTACK-8814

CLOUDSTACK-8814 - Refactoring the configuration of Routers and VPC routers 
nicsHi there,

I refactored the configureDefaultNics() method in order to split the 
implementations for Routers and VPC Routers.

The following tests were executed:

* test_vm_life_cycle
* test_routers
* test_vpc_router_nics
* test_vpc_routers
* test_vpc_offerings

@remibergsma @bhaisaab @koushik-das @miguelaferreira @DaanHoogland @karuturi , 
could you please have a look/test this PR?

Thanks in advance.

Cheers,
Wilder

* pr/788:
  CLOUDSTACK-8814 - Refactoring the configuration of Routers and VPC routers 
nics

Signed-off-by: wilderrodrigues 


> Order of nics in non-VPC router changed resulting in services to fail
> -
>
> Key: CLOUDSTACK-8814
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8814
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When testing a non-vpc setup, CloudStack was not able to ssh to 169.254.x.y 
> because it was not listening on this ip:
> Isolated network, single router doesn't listen on link_local:3922
> tcp0  0 192.168.23.25:3922  0.0.0.0:*   LISTEN
>   0  68283487/sshd   
> Redundant isolated router:
> tcp0  0 10.20.1.10:3922 0.0.0.0:*   LISTEN
>   0  64343068/sshd   
> The reason for this, is that the naming of the interfaces now seems to be the 
> same (same order) as on VPC routers. This used to be different. 
> cloud-early-config uses hard-coded eth devices that seem not to have 
> reflected to these changes.
> setup_vpcrouter() {
> ...
>   setup_sshd $ETH0_IP "eth0"
> ...
> ==> That works!
> setup_router() {
> ..
> setup_sshd $ETH1_IP "eth1"
> ==> That goes wrong now.
> If we keep this new order, all nics need to be checked. Apache settings, 
> keepalived etc etc
> Here you see the difference:
> non-vpc router in 4.4:
> root@r-17809-VM:~# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 02:00:1c:e5:00:16  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:251172 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:223685 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:22836300 (21.7 MiB)  TX bytes:106769179 (101.8 MiB)
>   Interrupt:24 
> eth1  Link encap:Ethernet  HWaddr 0e:00:a9:fe:01:44  
>   inet addr:169.254.1.68  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:13052283 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:16557626 errors:0 dropped:16 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:7051380496 (6.5 GiB)  TX bytes:3279800734 (3.0 GiB)
>   Interrupt:25 
> eth2  Link encap:Ethernet  HWaddr 06:ab:30:00:00:30  
>   inet addr:178.y.x.22  Bcast:178.y.x.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:308293122 errors:0 dropped:540 overruns:0 frame:0
>   TX packets:364798 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:16920767106 (15.7 GiB)  TX bytes:33871999 (32.3 MiB)
>   Interrupt:26 
> non-vpc router in 4.6
> root@r-9-VM:/opt/cloud/bin/cs# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:04  
>   inet addr:169.254.3.4  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:1018 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:788 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:163208 (159.3 KiB)  TX bytes:110389 (107.8 KiB)
> eth1  Link encap:Ethernet  HWaddr 06:c3:88:00:00:19  
>   inet addr:192.168.23.25  Bcast:192.168.23.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING 

[jira] [Commented] (CLOUDSTACK-8814) Order of nics in non-VPC router changed resulting in services to fail

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-8814 - Refactoring the configuration of Routers and VPC routers nics


> Order of nics in non-VPC router changed resulting in services to fail
> -
>
> Key: CLOUDSTACK-8814
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8814
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When testing a non-vpc setup, CloudStack was not able to ssh to 169.254.x.y 
> because it was not listening on this ip:
> Isolated network, single router doesn't listen on link_local:3922
> tcp0  0 192.168.23.25:3922  0.0.0.0:*   LISTEN
>   0  68283487/sshd   
> Redundant isolated router:
> tcp0  0 10.20.1.10:3922 0.0.0.0:*   LISTEN
>   0  64343068/sshd   
> The reason for this, is that the naming of the interfaces now seems to be the 
> same (same order) as on VPC routers. This used to be different. 
> cloud-early-config uses hard-coded eth devices that seem not to have 
> reflected to these changes.
> setup_vpcrouter() {
> ...
>   setup_sshd $ETH0_IP "eth0"
> ...
> ==> That works!
> setup_router() {
> ..
> setup_sshd $ETH1_IP "eth1"
> ==> That goes wrong now.
> If we keep this new order, all nics need to be checked. Apache settings, 
> keepalived etc etc
> Here you see the difference:
> non-vpc router in 4.4:
> root@r-17809-VM:~# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 02:00:1c:e5:00:16  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:251172 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:223685 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:22836300 (21.7 MiB)  TX bytes:106769179 (101.8 MiB)
>   Interrupt:24 
> eth1  Link encap:Ethernet  HWaddr 0e:00:a9:fe:01:44  
>   inet addr:169.254.1.68  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:13052283 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:16557626 errors:0 dropped:16 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:7051380496 (6.5 GiB)  TX bytes:3279800734 (3.0 GiB)
>   Interrupt:25 
> eth2  Link encap:Ethernet  HWaddr 06:ab:30:00:00:30  
>   inet addr:178.y.x.22  Bcast:178.y.x.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:308293122 errors:0 dropped:540 overruns:0 frame:0
>   TX packets:364798 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:16920767106 (15.7 GiB)  TX bytes:33871999 (32.3 MiB)
>   Interrupt:26 
> non-vpc router in 4.6
> root@r-9-VM:/opt/cloud/bin/cs# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:04  
>   inet addr:169.254.3.4  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:1018 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:788 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:163208 (159.3 KiB)  TX bytes:110389 (107.8 KiB)
> eth1  Link encap:Ethernet  HWaddr 06:c3:88:00:00:19  
>   inet addr:192.168.23.25  Bcast:192.168.23.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:20 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:1344 (1.3 KiB)  TX bytes:606 (606.0 B)
> eth2  Link encap:Ethernet  HWaddr 02:00:6d:bd:00:02  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:40 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:4308 

[jira] [Commented] (CLOUDSTACK-8814) Order of nics in non-VPC router changed resulting in services to fail

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #788 from ekholabs/fix/iso_net-CLOUDSTACK-8814

CLOUDSTACK-8814 - Refactoring the configuration of Routers and VPC routers 
nicsHi there,

I refactored the configureDefaultNics() method in order to split the 
implementations for Routers and VPC Routers.

The following tests were executed:

* test_vm_life_cycle
* test_routers
* test_vpc_router_nics
* test_vpc_routers
* test_vpc_offerings

@remibergsma @bhaisaab @koushik-das @miguelaferreira @DaanHoogland @karuturi , 
could you please have a look/test this PR?

Thanks in advance.

Cheers,
Wilder

* pr/788:
  CLOUDSTACK-8814 - Refactoring the configuration of Routers and VPC routers 
nics

Signed-off-by: wilderrodrigues 


> Order of nics in non-VPC router changed resulting in services to fail
> -
>
> Key: CLOUDSTACK-8814
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8814
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When testing a non-vpc setup, CloudStack was not able to ssh to 169.254.x.y 
> because it was not listening on this ip:
> Isolated network, single router doesn't listen on link_local:3922
> tcp0  0 192.168.23.25:3922  0.0.0.0:*   LISTEN
>   0  68283487/sshd   
> Redundant isolated router:
> tcp0  0 10.20.1.10:3922 0.0.0.0:*   LISTEN
>   0  64343068/sshd   
> The reason for this, is that the naming of the interfaces now seems to be the 
> same (same order) as on VPC routers. This used to be different. 
> cloud-early-config uses hard-coded eth devices that seem not to have 
> reflected to these changes.
> setup_vpcrouter() {
> ...
>   setup_sshd $ETH0_IP "eth0"
> ...
> ==> That works!
> setup_router() {
> ..
> setup_sshd $ETH1_IP "eth1"
> ==> That goes wrong now.
> If we keep this new order, all nics need to be checked. Apache settings, 
> keepalived etc etc
> Here you see the difference:
> non-vpc router in 4.4:
> root@r-17809-VM:~# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 02:00:1c:e5:00:16  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:251172 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:223685 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:22836300 (21.7 MiB)  TX bytes:106769179 (101.8 MiB)
>   Interrupt:24 
> eth1  Link encap:Ethernet  HWaddr 0e:00:a9:fe:01:44  
>   inet addr:169.254.1.68  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:13052283 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:16557626 errors:0 dropped:16 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:7051380496 (6.5 GiB)  TX bytes:3279800734 (3.0 GiB)
>   Interrupt:25 
> eth2  Link encap:Ethernet  HWaddr 06:ab:30:00:00:30  
>   inet addr:178.y.x.22  Bcast:178.y.x.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:308293122 errors:0 dropped:540 overruns:0 frame:0
>   TX packets:364798 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:16920767106 (15.7 GiB)  TX bytes:33871999 (32.3 MiB)
>   Interrupt:26 
> non-vpc router in 4.6
> root@r-9-VM:/opt/cloud/bin/cs# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:04  
>   inet addr:169.254.3.4  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:1018 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:788 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:163208 (159.3 KiB)  TX bytes:110389 (107.8 KiB)
> eth1  Link encap:Ethernet  HWaddr 06:c3:88:00:00:19  
>   inet addr:192.168.23.25  Bcast:192.168.23.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING 

[jira] [Commented] (CLOUDSTACK-8814) Order of nics in non-VPC router changed resulting in services to fail

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #788 from ekholabs/fix/iso_net-CLOUDSTACK-8814

CLOUDSTACK-8814 - Refactoring the configuration of Routers and VPC routers 
nicsHi there,

I refactored the configureDefaultNics() method in order to split the 
implementations for Routers and VPC Routers.

The following tests were executed:

* test_vm_life_cycle
* test_routers
* test_vpc_router_nics
* test_vpc_routers
* test_vpc_offerings

@remibergsma @bhaisaab @koushik-das @miguelaferreira @DaanHoogland @karuturi , 
could you please have a look/test this PR?

Thanks in advance.

Cheers,
Wilder

* pr/788:
  CLOUDSTACK-8814 - Refactoring the configuration of Routers and VPC routers 
nics

Signed-off-by: wilderrodrigues 


> Order of nics in non-VPC router changed resulting in services to fail
> -
>
> Key: CLOUDSTACK-8814
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8814
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When testing a non-vpc setup, CloudStack was not able to ssh to 169.254.x.y 
> because it was not listening on this ip:
> Isolated network, single router doesn't listen on link_local:3922
> tcp0  0 192.168.23.25:3922  0.0.0.0:*   LISTEN
>   0  68283487/sshd   
> Redundant isolated router:
> tcp0  0 10.20.1.10:3922 0.0.0.0:*   LISTEN
>   0  64343068/sshd   
> The reason for this, is that the naming of the interfaces now seems to be the 
> same (same order) as on VPC routers. This used to be different. 
> cloud-early-config uses hard-coded eth devices that seem not to have 
> reflected to these changes.
> setup_vpcrouter() {
> ...
>   setup_sshd $ETH0_IP "eth0"
> ...
> ==> That works!
> setup_router() {
> ..
> setup_sshd $ETH1_IP "eth1"
> ==> That goes wrong now.
> If we keep this new order, all nics need to be checked. Apache settings, 
> keepalived etc etc
> Here you see the difference:
> non-vpc router in 4.4:
> root@r-17809-VM:~# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 02:00:1c:e5:00:16  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:251172 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:223685 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:22836300 (21.7 MiB)  TX bytes:106769179 (101.8 MiB)
>   Interrupt:24 
> eth1  Link encap:Ethernet  HWaddr 0e:00:a9:fe:01:44  
>   inet addr:169.254.1.68  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:13052283 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:16557626 errors:0 dropped:16 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:7051380496 (6.5 GiB)  TX bytes:3279800734 (3.0 GiB)
>   Interrupt:25 
> eth2  Link encap:Ethernet  HWaddr 06:ab:30:00:00:30  
>   inet addr:178.y.x.22  Bcast:178.y.x.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:308293122 errors:0 dropped:540 overruns:0 frame:0
>   TX packets:364798 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:16920767106 (15.7 GiB)  TX bytes:33871999 (32.3 MiB)
>   Interrupt:26 
> non-vpc router in 4.6
> root@r-9-VM:/opt/cloud/bin/cs# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:04  
>   inet addr:169.254.3.4  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:1018 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:788 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:163208 (159.3 KiB)  TX bytes:110389 (107.8 KiB)
> eth1  Link encap:Ethernet  HWaddr 06:c3:88:00:00:19  
>   inet addr:192.168.23.25  Bcast:192.168.23.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING 

[jira] [Commented] (CLOUDSTACK-8814) Order of nics in non-VPC router changed resulting in services to fail

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8814:


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

https://github.com/apache/cloudstack/pull/788#discussion_r39034047
  
--- Diff: server/src/com/cloud/network/router/NetworkHelperImpl.java ---
@@ -610,20 +608,22 @@ protected HypervisorType 
getClusterToStartDomainRouterForOvm(final long podId) {
 throw new CloudRuntimeException(errMsg);
 }
 
-@Override
-public LinkedHashMap 
configureDefaultNics(final RouterDeploymentDefinition 
routerDeploymentDefinition) throws ConcurrentOperationException, 
InsufficientAddressCapacityException {
-
-final LinkedHashMap networks 
= new LinkedHashMap(3);
+protected LinkedHashMap 
configureControlNic(final RouterDeploymentDefinition 
routerDeploymentDefinition) {
+final LinkedHashMap 
controlConfig = new LinkedHashMap(3);
 
-// 1) Control network
 s_logger.debug("Adding nic for Virtual Router in Control network 
");
 final List offerings = 
_networkModel.getSystemAccountNetworkOfferings(NetworkOffering.SystemControlNetwork);
 final NetworkOffering controlOffering = offerings.get(0);
-final Network controlConfig = 
_networkMgr.setupNetwork(s_systemAccount, controlOffering, 
routerDeploymentDefinition.getPlan(), null, null, false).get(0);
+final Network controlNic = 
_networkMgr.setupNetwork(s_systemAccount, controlOffering, 
routerDeploymentDefinition.getPlan(), null, null, false).get(0);
 
-networks.put(controlConfig, new ArrayList());
+controlConfig.put(controlNic, new ArrayList());
+
+return controlConfig;
+}
+
+protected LinkedHashMap 
configurePublicNic(final RouterDeploymentDefinition routerDeploymentDefinition, 
final boolean hasGuestNic) {
+final LinkedHashMap 
publicConfig = new LinkedHashMap(3);
--- End diff --

Hi @koushik-das ,

I just refactored the code and did not bother about the initial size - it 
was there before. It actually won't change anything in terms of performance.

Cheers,
Wilder


> Order of nics in non-VPC router changed resulting in services to fail
> -
>
> Key: CLOUDSTACK-8814
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8814
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When testing a non-vpc setup, CloudStack was not able to ssh to 169.254.x.y 
> because it was not listening on this ip:
> Isolated network, single router doesn't listen on link_local:3922
> tcp0  0 192.168.23.25:3922  0.0.0.0:*   LISTEN
>   0  68283487/sshd   
> Redundant isolated router:
> tcp0  0 10.20.1.10:3922 0.0.0.0:*   LISTEN
>   0  64343068/sshd   
> The reason for this, is that the naming of the interfaces now seems to be the 
> same (same order) as on VPC routers. This used to be different. 
> cloud-early-config uses hard-coded eth devices that seem not to have 
> reflected to these changes.
> setup_vpcrouter() {
> ...
>   setup_sshd $ETH0_IP "eth0"
> ...
> ==> That works!
> setup_router() {
> ..
> setup_sshd $ETH1_IP "eth1"
> ==> That goes wrong now.
> If we keep this new order, all nics need to be checked. Apache settings, 
> keepalived etc etc
> Here you see the difference:
> non-vpc router in 4.4:
> root@r-17809-VM:~# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 02:00:1c:e5:00:16  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:251172 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:223685 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:22836300 (21.7 MiB)  TX bytes:106769179 (101.8 MiB)
>   Interrupt:24 
> eth1  Link encap:Ethernet  HWaddr 0e:00:a9:fe:01:44  
>   inet addr:169.254.1.68  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:13052283 errors:0 dropped:0 overruns:0 frame:0
>   TX 

[jira] [Commented] (CLOUDSTACK-8814) Order of nics in non-VPC router changed resulting in services to fail

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8814:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/788#issuecomment-138889015
  
Will proceed with the merge.

Thanks, guys!


> Order of nics in non-VPC router changed resulting in services to fail
> -
>
> Key: CLOUDSTACK-8814
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8814
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When testing a non-vpc setup, CloudStack was not able to ssh to 169.254.x.y 
> because it was not listening on this ip:
> Isolated network, single router doesn't listen on link_local:3922
> tcp0  0 192.168.23.25:3922  0.0.0.0:*   LISTEN
>   0  68283487/sshd   
> Redundant isolated router:
> tcp0  0 10.20.1.10:3922 0.0.0.0:*   LISTEN
>   0  64343068/sshd   
> The reason for this, is that the naming of the interfaces now seems to be the 
> same (same order) as on VPC routers. This used to be different. 
> cloud-early-config uses hard-coded eth devices that seem not to have 
> reflected to these changes.
> setup_vpcrouter() {
> ...
>   setup_sshd $ETH0_IP "eth0"
> ...
> ==> That works!
> setup_router() {
> ..
> setup_sshd $ETH1_IP "eth1"
> ==> That goes wrong now.
> If we keep this new order, all nics need to be checked. Apache settings, 
> keepalived etc etc
> Here you see the difference:
> non-vpc router in 4.4:
> root@r-17809-VM:~# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 02:00:1c:e5:00:16  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:251172 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:223685 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:22836300 (21.7 MiB)  TX bytes:106769179 (101.8 MiB)
>   Interrupt:24 
> eth1  Link encap:Ethernet  HWaddr 0e:00:a9:fe:01:44  
>   inet addr:169.254.1.68  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:13052283 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:16557626 errors:0 dropped:16 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:7051380496 (6.5 GiB)  TX bytes:3279800734 (3.0 GiB)
>   Interrupt:25 
> eth2  Link encap:Ethernet  HWaddr 06:ab:30:00:00:30  
>   inet addr:178.y.x.22  Bcast:178.y.x.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:308293122 errors:0 dropped:540 overruns:0 frame:0
>   TX packets:364798 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:16920767106 (15.7 GiB)  TX bytes:33871999 (32.3 MiB)
>   Interrupt:26 
> non-vpc router in 4.6
> root@r-9-VM:/opt/cloud/bin/cs# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:04  
>   inet addr:169.254.3.4  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:1018 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:788 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:163208 (159.3 KiB)  TX bytes:110389 (107.8 KiB)
> eth1  Link encap:Ethernet  HWaddr 06:c3:88:00:00:19  
>   inet addr:192.168.23.25  Bcast:192.168.23.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:20 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:1344 (1.3 KiB)  TX bytes:606 (606.0 B)
> eth2  Link encap:Ethernet  HWaddr 02:00:6d:bd:00:02  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:40 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:4308 (4.2 KiB)  TX bytes:294 (294.0 B)
> loLink encap:Local Loopback  
>   inet addr:127.0.0.1  

[jira] [Resolved] (CLOUDSTACK-8727) API call listVirtualMachines returns same keypair

[Kshitij Kansal (JIRA)]

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

Kshitij Kansal resolved CLOUDSTACK-8727.

Resolution: Fixed

> API call listVirtualMachines returns same keypair
> -
>
> Key: CLOUDSTACK-8727
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8727
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kshitij Kansal
>
> If you register 2 SSH keypairs with the same public key then 
> listVirtualMachines API call will only return the first keypair. Although its 
> a very rare case and generally don't make much sense by registering the same 
> key with different name, still it can be fixed. 



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

[jira] [Commented] (CLOUDSTACK-8814) Order of nics in non-VPC router changed resulting in services to fail

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8814:


Github user asfgit closed the pull request at:

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


> Order of nics in non-VPC router changed resulting in services to fail
> -
>
> Key: CLOUDSTACK-8814
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8814
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When testing a non-vpc setup, CloudStack was not able to ssh to 169.254.x.y 
> because it was not listening on this ip:
> Isolated network, single router doesn't listen on link_local:3922
> tcp0  0 192.168.23.25:3922  0.0.0.0:*   LISTEN
>   0  68283487/sshd   
> Redundant isolated router:
> tcp0  0 10.20.1.10:3922 0.0.0.0:*   LISTEN
>   0  64343068/sshd   
> The reason for this, is that the naming of the interfaces now seems to be the 
> same (same order) as on VPC routers. This used to be different. 
> cloud-early-config uses hard-coded eth devices that seem not to have 
> reflected to these changes.
> setup_vpcrouter() {
> ...
>   setup_sshd $ETH0_IP "eth0"
> ...
> ==> That works!
> setup_router() {
> ..
> setup_sshd $ETH1_IP "eth1"
> ==> That goes wrong now.
> If we keep this new order, all nics need to be checked. Apache settings, 
> keepalived etc etc
> Here you see the difference:
> non-vpc router in 4.4:
> root@r-17809-VM:~# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 02:00:1c:e5:00:16  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:251172 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:223685 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:22836300 (21.7 MiB)  TX bytes:106769179 (101.8 MiB)
>   Interrupt:24 
> eth1  Link encap:Ethernet  HWaddr 0e:00:a9:fe:01:44  
>   inet addr:169.254.1.68  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:13052283 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:16557626 errors:0 dropped:16 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:7051380496 (6.5 GiB)  TX bytes:3279800734 (3.0 GiB)
>   Interrupt:25 
> eth2  Link encap:Ethernet  HWaddr 06:ab:30:00:00:30  
>   inet addr:178.y.x.22  Bcast:178.y.x.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:308293122 errors:0 dropped:540 overruns:0 frame:0
>   TX packets:364798 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:16920767106 (15.7 GiB)  TX bytes:33871999 (32.3 MiB)
>   Interrupt:26 
> non-vpc router in 4.6
> root@r-9-VM:/opt/cloud/bin/cs# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:04  
>   inet addr:169.254.3.4  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:1018 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:788 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:163208 (159.3 KiB)  TX bytes:110389 (107.8 KiB)
> eth1  Link encap:Ethernet  HWaddr 06:c3:88:00:00:19  
>   inet addr:192.168.23.25  Bcast:192.168.23.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:20 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:1344 (1.3 KiB)  TX bytes:606 (606.0 B)
> eth2  Link encap:Ethernet  HWaddr 02:00:6d:bd:00:02  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:40 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:4308 (4.2 KiB)  TX bytes:294 (294.0 B)
> loLink encap:Local Loopback  
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   UP LOOPBACK RUNNING  MTU:16436  Metric:1
>   RX packets:1 

[jira] [Resolved] (CLOUDSTACK-8814) Order of nics in non-VPC router changed resulting in services to fail

[Wilder Rodrigues (JIRA)]

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

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

done!

> Order of nics in non-VPC router changed resulting in services to fail
> -
>
> Key: CLOUDSTACK-8814
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8814
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When testing a non-vpc setup, CloudStack was not able to ssh to 169.254.x.y 
> because it was not listening on this ip:
> Isolated network, single router doesn't listen on link_local:3922
> tcp0  0 192.168.23.25:3922  0.0.0.0:*   LISTEN
>   0  68283487/sshd   
> Redundant isolated router:
> tcp0  0 10.20.1.10:3922 0.0.0.0:*   LISTEN
>   0  64343068/sshd   
> The reason for this, is that the naming of the interfaces now seems to be the 
> same (same order) as on VPC routers. This used to be different. 
> cloud-early-config uses hard-coded eth devices that seem not to have 
> reflected to these changes.
> setup_vpcrouter() {
> ...
>   setup_sshd $ETH0_IP "eth0"
> ...
> ==> That works!
> setup_router() {
> ..
> setup_sshd $ETH1_IP "eth1"
> ==> That goes wrong now.
> If we keep this new order, all nics need to be checked. Apache settings, 
> keepalived etc etc
> Here you see the difference:
> non-vpc router in 4.4:
> root@r-17809-VM:~# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 02:00:1c:e5:00:16  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:251172 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:223685 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:22836300 (21.7 MiB)  TX bytes:106769179 (101.8 MiB)
>   Interrupt:24 
> eth1  Link encap:Ethernet  HWaddr 0e:00:a9:fe:01:44  
>   inet addr:169.254.1.68  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:13052283 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:16557626 errors:0 dropped:16 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:7051380496 (6.5 GiB)  TX bytes:3279800734 (3.0 GiB)
>   Interrupt:25 
> eth2  Link encap:Ethernet  HWaddr 06:ab:30:00:00:30  
>   inet addr:178.y.x.22  Bcast:178.y.x.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:308293122 errors:0 dropped:540 overruns:0 frame:0
>   TX packets:364798 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:16920767106 (15.7 GiB)  TX bytes:33871999 (32.3 MiB)
>   Interrupt:26 
> non-vpc router in 4.6
> root@r-9-VM:/opt/cloud/bin/cs# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:04  
>   inet addr:169.254.3.4  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:1018 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:788 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:163208 (159.3 KiB)  TX bytes:110389 (107.8 KiB)
> eth1  Link encap:Ethernet  HWaddr 06:c3:88:00:00:19  
>   inet addr:192.168.23.25  Bcast:192.168.23.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:20 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:1344 (1.3 KiB)  TX bytes:606 (606.0 B)
> eth2  Link encap:Ethernet  HWaddr 02:00:6d:bd:00:02  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:40 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:4308 (4.2 KiB)  TX bytes:294 (294.0 B)
> loLink encap:Local Loopback  
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   UP LOOPBACK RUNNING  MTU:16436  Metric:1
>   RX packets:1 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
> 

[jira] [Commented] (CLOUDSTACK-8800) Improve the listVirtualMachines API call to include memory utilization information for a VM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8800:


Github user maneesha-p commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/780#discussion_r39034863
  
--- Diff: 
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
 ---
@@ -4751,7 +4760,7 @@ private VirtualMachineGuestOsIdentifier 
translateGuestOsIdentifier(String cpuArc
 }
 }
 }
-vmResponseMap.put(name, new 
VmStatsEntry(Integer.parseInt(maxCpuUsage), networkReadKBs, networkWriteKBs, 
Integer.parseInt(numberCPUs), "vm"));
+vmResponseMap.put(name, new 
VmStatsEntry(Double.parseDouble(memkb)*1000,Double.parseDouble(guestMemusage)*1000,Double.parseDouble(memlimit)*1000,
 Double.parseDouble(maxCpuUsage), networkReadKBs, networkWriteKBs, 
Integer.parseInt(numberCPUs), "vm"));
--- End diff --

@karuturi  Incorporated the changes.Thanks.


> Improve the listVirtualMachines API call to include memory utilization 
> information for a VM
> ---
>
> Key: CLOUDSTACK-8800
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8800
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2
>Reporter: Maneesha
>Assignee: Maneesha
> Fix For: 4.6.0
>
>
> Currently the feature of memory utilization is not available via API call 
> (listVirtualMachines).
> https://cloudstack.apache.org/api/apidocs-4.5/root_admin/listVirtualMachines.html
>  
> The listVirtualMachine get its values from the "user_vm_view" table in the 
> database. Currently it shows the CPU utilization of the VM's.
> The only way to find out the memory utilization of VM's running on XenServer, 
> is to run the "xentop" command on the pool master of the cluster.



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

[jira] [Commented] (CLOUDSTACK-8814) Order of nics in non-VPC router changed resulting in services to fail

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8814:


Github user koushik-das commented on the pull request:

https://github.com/apache/cloudstack/pull/788#issuecomment-138865017
  
One more doubt. Why the ordering of interfaces are different in regular VR 
and VPC VR? Has it changed recently or was like this since the beginning? And 
will it cause more issues down the line when VR or VPC VR scripts are modified?


> Order of nics in non-VPC router changed resulting in services to fail
> -
>
> Key: CLOUDSTACK-8814
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8814
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When testing a non-vpc setup, CloudStack was not able to ssh to 169.254.x.y 
> because it was not listening on this ip:
> Isolated network, single router doesn't listen on link_local:3922
> tcp0  0 192.168.23.25:3922  0.0.0.0:*   LISTEN
>   0  68283487/sshd   
> Redundant isolated router:
> tcp0  0 10.20.1.10:3922 0.0.0.0:*   LISTEN
>   0  64343068/sshd   
> The reason for this, is that the naming of the interfaces now seems to be the 
> same (same order) as on VPC routers. This used to be different. 
> cloud-early-config uses hard-coded eth devices that seem not to have 
> reflected to these changes.
> setup_vpcrouter() {
> ...
>   setup_sshd $ETH0_IP "eth0"
> ...
> ==> That works!
> setup_router() {
> ..
> setup_sshd $ETH1_IP "eth1"
> ==> That goes wrong now.
> If we keep this new order, all nics need to be checked. Apache settings, 
> keepalived etc etc
> Here you see the difference:
> non-vpc router in 4.4:
> root@r-17809-VM:~# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 02:00:1c:e5:00:16  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:251172 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:223685 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:22836300 (21.7 MiB)  TX bytes:106769179 (101.8 MiB)
>   Interrupt:24 
> eth1  Link encap:Ethernet  HWaddr 0e:00:a9:fe:01:44  
>   inet addr:169.254.1.68  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:13052283 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:16557626 errors:0 dropped:16 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:7051380496 (6.5 GiB)  TX bytes:3279800734 (3.0 GiB)
>   Interrupt:25 
> eth2  Link encap:Ethernet  HWaddr 06:ab:30:00:00:30  
>   inet addr:178.y.x.22  Bcast:178.y.x.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:308293122 errors:0 dropped:540 overruns:0 frame:0
>   TX packets:364798 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:16920767106 (15.7 GiB)  TX bytes:33871999 (32.3 MiB)
>   Interrupt:26 
> non-vpc router in 4.6
> root@r-9-VM:/opt/cloud/bin/cs# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:04  
>   inet addr:169.254.3.4  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:1018 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:788 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:163208 (159.3 KiB)  TX bytes:110389 (107.8 KiB)
> eth1  Link encap:Ethernet  HWaddr 06:c3:88:00:00:19  
>   inet addr:192.168.23.25  Bcast:192.168.23.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:20 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:1344 (1.3 KiB)  TX bytes:606 (606.0 B)
> eth2  Link encap:Ethernet  HWaddr 02:00:6d:bd:00:02  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:40 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:7 errors:0 dropped:0 overruns:0 

[jira] [Commented] (CLOUDSTACK-8821) Provide appropriate message in the UI when configuring the Firewall rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8821:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/791#issuecomment-138880396
  
LGTM


> Provide appropriate message in the UI when configuring the Firewall rules
> -
>
> Key: CLOUDSTACK-8821
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8821
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Nitin Kumar Maharana
>
> While adding Firewall rules, the egress rules can be to configure Allow / 
> Deny rules based on the Default egress policy in the network offering.
> It should provide a clear message in the UI: such as if Allow – “Configure 
> the rules below to Block Traffic” – If Deny – “Configure the rules below to 
> Allow Traffic”



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

[jira] [Commented] (CLOUDSTACK-8799) fix CsRedundant.py to handle public interfaces and default routes when changing state.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8799:


Github user bvbharatk commented on the pull request:

https://github.com/apache/cloudstack/pull/784#issuecomment-138885057
  
Hi @wilderrodrigues 

will update once i am done testing against vpc networks.


> fix CsRedundant.py to handle public interfaces and default routes when 
> changing state.
> --
>
> Key: CLOUDSTACK-8799
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8799
> 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: Bharat Kumar
>Priority: Critical
>
> When the Vr changes state to backup we need bring all the public interfaces 
> down. Similarly when it changes state to master we have bring all the public 
> interfaces up and add the default routes.



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

[jira] [Commented] (CLOUDSTACK-8814) Order of nics in non-VPC router changed resulting in services to fail

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8814:


Github user koushik-das commented on the pull request:

https://github.com/apache/cloudstack/pull/788#issuecomment-138861606
  
Other than one minor comment, LGTM


> Order of nics in non-VPC router changed resulting in services to fail
> -
>
> Key: CLOUDSTACK-8814
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8814
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.6.0
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When testing a non-vpc setup, CloudStack was not able to ssh to 169.254.x.y 
> because it was not listening on this ip:
> Isolated network, single router doesn't listen on link_local:3922
> tcp0  0 192.168.23.25:3922  0.0.0.0:*   LISTEN
>   0  68283487/sshd   
> Redundant isolated router:
> tcp0  0 10.20.1.10:3922 0.0.0.0:*   LISTEN
>   0  64343068/sshd   
> The reason for this, is that the naming of the interfaces now seems to be the 
> same (same order) as on VPC routers. This used to be different. 
> cloud-early-config uses hard-coded eth devices that seem not to have 
> reflected to these changes.
> setup_vpcrouter() {
> ...
>   setup_sshd $ETH0_IP "eth0"
> ...
> ==> That works!
> setup_router() {
> ..
> setup_sshd $ETH1_IP "eth1"
> ==> That goes wrong now.
> If we keep this new order, all nics need to be checked. Apache settings, 
> keepalived etc etc
> Here you see the difference:
> non-vpc router in 4.4:
> root@r-17809-VM:~# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 02:00:1c:e5:00:16  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:251172 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:223685 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:22836300 (21.7 MiB)  TX bytes:106769179 (101.8 MiB)
>   Interrupt:24 
> eth1  Link encap:Ethernet  HWaddr 0e:00:a9:fe:01:44  
>   inet addr:169.254.1.68  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:13052283 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:16557626 errors:0 dropped:16 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:7051380496 (6.5 GiB)  TX bytes:3279800734 (3.0 GiB)
>   Interrupt:25 
> eth2  Link encap:Ethernet  HWaddr 06:ab:30:00:00:30  
>   inet addr:178.y.x.22  Bcast:178.y.x.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:308293122 errors:0 dropped:540 overruns:0 frame:0
>   TX packets:364798 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:16920767106 (15.7 GiB)  TX bytes:33871999 (32.3 MiB)
>   Interrupt:26 
> non-vpc router in 4.6
> root@r-9-VM:/opt/cloud/bin/cs# ifconfig 
> eth0  Link encap:Ethernet  HWaddr 0e:00:a9:fe:03:04  
>   inet addr:169.254.3.4  Bcast:169.254.255.255  Mask:255.255.0.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:1018 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:788 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:163208 (159.3 KiB)  TX bytes:110389 (107.8 KiB)
> eth1  Link encap:Ethernet  HWaddr 06:c3:88:00:00:19  
>   inet addr:192.168.23.25  Bcast:192.168.23.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:20 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:1344 (1.3 KiB)  TX bytes:606 (606.0 B)
> eth2  Link encap:Ethernet  HWaddr 02:00:6d:bd:00:02  
>   inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:40 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000 
>   RX bytes:4308 (4.2 KiB)  TX bytes:294 (294.0 B)
> loLink encap:Local Loopback  
>   inet addr:127.0.0.1  Mask:255.0.0.0
>

[jira] [Commented] (CLOUDSTACK-8781) Superfluous field during VPC creation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8781:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/756#issuecomment-138889654
  
Hi @nlivens 

Okay... I will have a look at the code. Very weird to have it there and not 
use it. :)

Cheers,
Wilder


> Superfluous field during VPC creation
> -
>
> Key: CLOUDSTACK-8781
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8781
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.6.0
>Reporter: Nick Livens
>Assignee: Nick Livens
>Priority: Trivial
> Fix For: 4.6.0
>
> Attachments: addVpc.png
>
>
> When creating a VPC, there is a superfluous field "Public Load Balancer 
> Provider" which is being ignored since the LB Provider is specified in the 
> VPC offering. This might confuse the users whether they can use a different 
> LB provider than the one specified in the VPC offering.



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

[jira] [Commented] (CLOUDSTACK-8799) fix CsRedundant.py to handle public interfaces and default routes when changing state.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8799:


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

https://github.com/apache/cloudstack/pull/784#discussion_r39033655
  
--- Diff: systemvm/patches/debian/config/opt/cloud/bin/cs/CsAddress.py ---
@@ -95,9 +95,17 @@ def get_control_if(self):
 return ip
 return None
 
+def check_if_link_up(self,dev):
+cmd="ip link show dev %s | tr '\n' ' ' | cut -d ' ' -f 9"%dev
--- End diff --

Hi, 

the output of Ip link show command is not expected to changes so in this 
case i think hardcoding the limiters is not an issue. 


> fix CsRedundant.py to handle public interfaces and default routes when 
> changing state.
> --
>
> Key: CLOUDSTACK-8799
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8799
> 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: Bharat Kumar
>Priority: Critical
>
> When the Vr changes state to backup we need bring all the public interfaces 
> down. Similarly when it changes state to master we have bring all the public 
> interfaces up and add the default routes.



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

[jira] [Commented] (CLOUDSTACK-8800) Improve the listVirtualMachines API call to include memory utilization information for a VM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8800:


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

https://github.com/apache/cloudstack/pull/780#discussion_r39122432
  
--- Diff: 
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
 ---
@@ -4662,8 +4663,14 @@ private VirtualMachineGuestOsIdentifier 
translateGuestOsIdentifier(String cpuArc
 }
 String instanceNameCustomField = "value[" + key + "]";
 
+String numCpuStr = "summary.config.numCpu";
+String cpuUseStr = "summary.quickStats.overallCpuUsage";
+String guestMemUseStr = "summary.quickStats.guestMemoryUsage";
+String memLimitStr = "resourceConfig.memoryAllocation.limit";
+String memMbStr = "config.hardware.memoryMB";
+
--- End diff --

same here. private static final and caps


> Improve the listVirtualMachines API call to include memory utilization 
> information for a VM
> ---
>
> Key: CLOUDSTACK-8800
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8800
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2
>Reporter: Maneesha
>Assignee: Maneesha
> Fix For: 4.6.0
>
>
> Currently the feature of memory utilization is not available via API call 
> (listVirtualMachines).
> https://cloudstack.apache.org/api/apidocs-4.5/root_admin/listVirtualMachines.html
>  
> The listVirtualMachine get its values from the "user_vm_view" table in the 
> database. Currently it shows the CPU utilization of the VM's.
> The only way to find out the memory utilization of VM's running on XenServer, 
> is to run the "xentop" command on the pool master of the cluster.



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

[jira] [Commented] (CLOUDSTACK-8800) Improve the listVirtualMachines API call to include memory utilization information for a VM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8800:


Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/780#issuecomment-139109578
  
I see tests only for LibrvirtResource. They are missing for StatsCollector, 
CitrixResourceBase, VmwareResource


> Improve the listVirtualMachines API call to include memory utilization 
> information for a VM
> ---
>
> Key: CLOUDSTACK-8800
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8800
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2
>Reporter: Maneesha
>Assignee: Maneesha
> Fix For: 4.6.0
>
>
> Currently the feature of memory utilization is not available via API call 
> (listVirtualMachines).
> https://cloudstack.apache.org/api/apidocs-4.5/root_admin/listVirtualMachines.html
>  
> The listVirtualMachine get its values from the "user_vm_view" table in the 
> database. Currently it shows the CPU utilization of the VM's.
> The only way to find out the memory utilization of VM's running on XenServer, 
> is to run the "xentop" command on the pool master of the cluster.



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

[jira] [Commented] (CLOUDSTACK-8800) Improve the listVirtualMachines API call to include memory utilization information for a VM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8800:


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

https://github.com/apache/cloudstack/pull/780#discussion_r39122397
  
--- Diff: 
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 ---
@@ -189,6 +190,7 @@
 private long _hvVersion;
 private long _kernelVersion;
 private int _timeout;
+private int _nummemstats =2;
--- End diff --

Can you make this private static final and probably use caps for the 
constants?


> Improve the listVirtualMachines API call to include memory utilization 
> information for a VM
> ---
>
> Key: CLOUDSTACK-8800
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8800
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2
>Reporter: Maneesha
>Assignee: Maneesha
> Fix For: 4.6.0
>
>
> Currently the feature of memory utilization is not available via API call 
> (listVirtualMachines).
> https://cloudstack.apache.org/api/apidocs-4.5/root_admin/listVirtualMachines.html
>  
> The listVirtualMachine get its values from the "user_vm_view" table in the 
> database. Currently it shows the CPU utilization of the VM's.
> The only way to find out the memory utilization of VM's running on XenServer, 
> is to run the "xentop" command on the pool master of the cluster.



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

[jira] [Commented] (CLOUDSTACK-8819) Virtual Template size is not correct when using S3 as image store.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8819:


Github user borisroman commented on the pull request:

https://github.com/apache/cloudstack/pull/795#issuecomment-139001500
  
Tested manually. Virtual size is correctly returned now.


> Virtual Template size is not correct when using S3 as image store.
> --
>
> Key: CLOUDSTACK-8819
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8819
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage
>Reporter: Boris Schrijver
>Assignee: Boris Schrijver
>
> The virtual size is the same as the physical size of the template. See: 
> https://github.com/apache/cloudstack/blob/master/services/secondary-storage/server/src/org/apache/cloudstack/storage/template/DownloadManagerImpl.java#L300



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

[jira] [Commented] (CLOUDSTACK-8819) Virtual Template size is not correct when using S3 as image store.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8819:


GitHub user borisroman opened a pull request:

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

CLOUDSTACK-8819: Added QCOW2 virtual size checking for S3.

- Cleaned up S3TemplateDownloader
- Created static QCOW2 utils class.
- Reformatted some parts of DownloadManagerImpl

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

$ git pull https://github.com/borisroman/cloudstack CLOUDSTACK-8819

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

https://github.com/apache/cloudstack/pull/795.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 #795


commit 7ceb1cdbff5b84d41fc06fd04aee7b9a269b
Author: Boris Schrijver 
Date:   2015-09-09T15:53:35Z

Added QCOW2 virtual size checking for S3.

- Cleaned up S3TemplateDownloader
- Created static QCOW2 utils class.
- Reformatted some parts of DownloadManagerImpl




> Virtual Template size is not correct when using S3 as image store.
> --
>
> Key: CLOUDSTACK-8819
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8819
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage
>Reporter: Boris Schrijver
>Assignee: Boris Schrijver
>
> The virtual size is the same as the physical size of the template. See: 
> https://github.com/apache/cloudstack/blob/master/services/secondary-storage/server/src/org/apache/cloudstack/storage/template/DownloadManagerImpl.java#L300



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