date:20151231

[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9192:


Github user ustcweizhou commented on the pull request:

https://github.com/apache/cloudstack/pull/1264#issuecomment-168148620
  
LGTM.
This is same to the fix in our internal branch.


> UpdateVpnCustomerGateway is failing
> ---
>
> Key: CLOUDSTACK-9192
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9192
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Reproducible Steps:
> 
> 1.Create a customer gateway for a VPC.
> 2.Edit it using UI(API call is UpdateVpnCustomerGateway).
> 3.When we try to update the customer vpn gateway with connection state is not 
> in "Error", we see the API error but that won't be reflected to the user in 
> UI.



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

[jira] [Created] (CLOUDSTACK-9204) Delete static route fails when it's already gone

2015-12-31 Thread Remi Bergsma (JIRA)

Remi Bergsma created CLOUDSTACK-9204:


 Summary: Delete static route fails when it's already gone
 Key: CLOUDSTACK-9204
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9204
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: SystemVM
Affects Versions: 4.7.0
Reporter: Remi Bergsma
Assignee: Remi Bergsma
Priority: Critical
 Fix For: 4.7.1


When you try to delete a static route, this fails when it's no longer there on 
the router (not sure why that happens).

Error seen:
[INFO] update_config.py :: Processing incoming file => 
static_routes.json.1451560145
[INFO] Processing JSON file static_routes.json.1451560145
Traceback (most recent call last):
  File "/opt/cloud/bin/update_config.py", line 140, in 
process_file()
  File "/opt/cloud/bin/update_config.py", line 52, in process_file
qf.load(None)
  File "/opt/cloud/bin/merge.py", line 258, in load
proc = updateDataBag(self)
  File "/opt/cloud/bin/merge.py", line 91, in __init__
self.process()
  File "/opt/cloud/bin/merge.py", line 131, in process
dbag = self.process_staticroutes(self.db.getDataBag())
  File "/opt/cloud/bin/merge.py", line 179, in process_staticroutes
return cs_staticroutes.merge(dbag, self.qFile.data)
  File "/opt/cloud/bin/cs_staticroutes.py", line 26, in merge
del dbag[key]
KeyError: u'192.168.0.3'

When deleting fails because it isn't there any more, it should succeed ;-)




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

[jira] [Commented] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-6485:


GitHub user remibergsma opened a pull request:

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

CLOUDSTACK-6485 prevent ip asignment of private gw iface

Prevent ipaddress asignment of gateway to gateway-interface on vpc router 
by setting vpcid to null in network. This was fixed in 4.4 by 
1f209ff226a24979cf3a43ce0c02e05c84dd4dc2, reimplemented for 4.7

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

$ git pull https://github.com/remibergsma/cloudstack CLOUDSTACK-6485

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

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


commit 2c07ce590d9763033aff2ee895915eefe8a16030
Author: Remi Bergsma 
Date:   2015-12-31T13:20:52Z

CLOUDSTACK-6485 prevent ip asignment of private gw iface

Prevent ipaddress asignment of gateway to gateway-interface on vpc router 
by setting vpcid to null in network

Was fixed in 4.4 by 1f209ff226a24979cf3a43ce0c02e05c84dd4dc2
Reimplemented for 4.7




> [vpc] new private gateway network is registered wrong in network table
> --
>
> Key: CLOUDSTACK-6485
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6485
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1
>Reporter: Anton Opgenoort
>Assignee: Daan Hoogland
>
> When creating a private gateway for a VPC router on a network not yet known 
> to Cloudstack, Cloudstack ‘documents’ this network in the networks table.
> For normal guest networks, which should be associated with a single VPC, 
> Cloudstack includes the VPC_ID in the database. The VPC_ID field is used to 
> provision all networks and nics on a VPC router when it is created. Since 
> this table is all about network provisioning it makes sense to ‘document’ the 
> network cidr and gateway present in that nework. For guest tiers this usually 
> is the VPC router itself, so the interface IP’s on a VPC router are the 
> gateway IP’s found in the networks table.
> Unfortunately the VPC_ID is also recorded for the private gateway network 
> when it is first created. So the first VPC to be plugged on the private 
> gateway network also has that same network associated as a guest network 
> tier, instead of just a private gateway network.
> This by itself will not quickly become a problem, because private gateways 
> are first plugged on a running vpc router which is not likely to be recreated 
> any time soon after that.
> But as soon as this first ever VPC router on the private gateway network is 
> recreated due to a destroy of the VPC Router, all associated networks are 
> looked up in the networks table. 
> Because the private gateway network is ‘documented’ with the actual upstream 
> gateway used by the VPC router defintion, the VPC router provisions a NIC on 
> the private gateway network using the IP address of the actual upstream 
> gateway creating an IP conflict on the private gateway network, effectively 
> breaking down the upstream gateway functionality for all attached private 
> gateways of other vpc's.



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

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

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9099:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1152#issuecomment-168200764
  
@kansal when you say 'I have deprecated that as many regressions were using 
the secret key from those APIs for authentication', I think we should adjust 
those regression test to set the setting to true. Let's not do consessions to 
security for the sake of testing.


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



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

[jira] [Commented] (CLOUDSTACK-9204) Delete static route fails when it's already gone

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9204:


GitHub user remibergsma opened a pull request:

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

CLOUDSTACK-9204 Do not error when staticroute is already gone

When deleting a static route fails because it isn't there any morei 
(KeyError), it should succeed instead.

Error seen:
```
[INFO] Processing JSON file static_routes.json.1451560145
Traceback (most recent call last):
File "/opt/cloud/bin/update_config.py", line 140, in 
process_file()
File "/opt/cloud/bin/update_config.py", line 52, in process_file
qf.load(None)
File "/opt/cloud/bin/merge.py", line 258, in load
proc = updateDataBag(self)
File "/opt/cloud/bin/merge.py", line 91, in _init_
self.process()
File "/opt/cloud/bin/merge.py", line 131, in process
dbag = self.process_staticroutes(self.db.getDataBag())
File "/opt/cloud/bin/merge.py", line 179, in process_staticroutes
return cs_staticroutes.merge(dbag, self.qFile.data)
File "/opt/cloud/bin/cs_staticroutes.py", line 26, in merge
del dbag[key]
KeyError: u'192.168.0.3'
```

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

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

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

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


commit 779f4b36e03738a9eb1ffa4c474e9b4968cd7b72
Author: Remi Bergsma 
Date:   2015-12-31T13:08:14Z

CLOUDSTACK-9204 Do not error when staticroute is already gone

When deleting fails because it isn't there any morei (KeyError), it should 
succeed instead.




> Delete static route fails when it's already gone
> 
>
> Key: CLOUDSTACK-9204
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9204
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.1
>
>
> When you try to delete a static route, this fails when it's no longer there 
> on the router (not sure why that happens).
> Error seen:
> [INFO] update_config.py :: Processing incoming file => 
> static_routes.json.1451560145
> [INFO] Processing JSON file static_routes.json.1451560145
> Traceback (most recent call last):
>   File "/opt/cloud/bin/update_config.py", line 140, in 
> process_file()
>   File "/opt/cloud/bin/update_config.py", line 52, in process_file
> qf.load(None)
>   File "/opt/cloud/bin/merge.py", line 258, in load
> proc = updateDataBag(self)
>   File "/opt/cloud/bin/merge.py", line 91, in __init__
> self.process()
>   File "/opt/cloud/bin/merge.py", line 131, in process
> dbag = self.process_staticroutes(self.db.getDataBag())
>   File "/opt/cloud/bin/merge.py", line 179, in process_staticroutes
> return cs_staticroutes.merge(dbag, self.qFile.data)
>   File "/opt/cloud/bin/cs_staticroutes.py", line 26, in merge
> del dbag[key]
> KeyError: u'192.168.0.3'
> When deleting fails because it isn't there any more, it should succeed ;-)



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

[jira] [Commented] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-6485:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1299#issuecomment-168193893
  
Pinging @DaanHoogland remember this one? It's fixed in `4.4` but I hit it 
again today in `4.7`.


> [vpc] new private gateway network is registered wrong in network table
> --
>
> Key: CLOUDSTACK-6485
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6485
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1
>Reporter: Anton Opgenoort
>Assignee: Daan Hoogland
>
> When creating a private gateway for a VPC router on a network not yet known 
> to Cloudstack, Cloudstack ‘documents’ this network in the networks table.
> For normal guest networks, which should be associated with a single VPC, 
> Cloudstack includes the VPC_ID in the database. The VPC_ID field is used to 
> provision all networks and nics on a VPC router when it is created. Since 
> this table is all about network provisioning it makes sense to ‘document’ the 
> network cidr and gateway present in that nework. For guest tiers this usually 
> is the VPC router itself, so the interface IP’s on a VPC router are the 
> gateway IP’s found in the networks table.
> Unfortunately the VPC_ID is also recorded for the private gateway network 
> when it is first created. So the first VPC to be plugged on the private 
> gateway network also has that same network associated as a guest network 
> tier, instead of just a private gateway network.
> This by itself will not quickly become a problem, because private gateways 
> are first plugged on a running vpc router which is not likely to be recreated 
> any time soon after that.
> But as soon as this first ever VPC router on the private gateway network is 
> recreated due to a destroy of the VPC Router, all associated networks are 
> looked up in the networks table. 
> Because the private gateway network is ‘documented’ with the actual upstream 
> gateway used by the VPC router defintion, the VPC router provisions a NIC on 
> the private gateway network using the IP address of the actual upstream 
> gateway creating an IP conflict on the private gateway network, effectively 
> breaking down the upstream gateway functionality for all attached private 
> gateways of other vpc's.



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

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

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9099:


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

https://github.com/apache/cloudstack/pull/1152#discussion_r48657695
  
--- Diff: server/src/com/cloud/user/AccountManager.java ---
@@ -198,4 +200,11 @@ void buildACLViewSearchCriteria(SearchCriteria s
 public static final String MESSAGE_ADD_ACCOUNT_EVENT = 
"Message.AddAccount.Event";
 
 public static final String MESSAGE_REMOVE_ACCOUNT_EVENT = 
"Message.RemoveAccount.Event";
+public static final ConfigKey UseSecretKeyInResponse = new 
ConfigKey(
+"Advanced",
+Boolean.class,
+"use.secret.key.in.response",
+"true",
--- End diff --

default should be false! this is a security issue.


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



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

[jira] [Closed] (CLOUDSTACK-7783) Blank page after login

2015-12-31 Thread Dag Sonstebo (JIRA)


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

Dag Sonstebo closed CLOUDSTACK-7783.

   Resolution: Fixed
Fix Version/s: 4.3.0

Old issue, not observed in later versions of ACS (4.3 onwards) hence assume 
fixed.

> Blank page after login
> --
>
> Key: CLOUDSTACK-7783
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7783
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.0.0
> Environment: Linux Firefox 32.0.3 and Linux Chrome 38.0.2125.101
>Reporter: Sergio Soto Núñez
>Assignee: Dag Sonstebo
>Priority: Critical
>  Labels: language, web
> Fix For: 4.3.0
>
>
> Access to http://:8080/client, set user and passwod. 
> Blank page appears after logging if you don't select a language.
> Only a message is shown in js console:
> ReferenceError: dictionary is not defined



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

[jira] [Created] (CLOUDSTACK-9205) api: addCluster should not return a list as result

2015-12-31 Thread JIRA

René Moser created CLOUDSTACK-9205:
--

 Summary: api: addCluster should not return a list as result
 Key: CLOUDSTACK-9205
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9205
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API
Reporter: René Moser
Priority: Trivial
 Fix For: Future


{{addCluster}} should not return a *list* (containing always one item, which 
was just created) as a result.

h2. Actual: 
{code}
 $ cs addCluster clustername=foo hypervisor=Simulator 
podid=11de114b-733a-4826-ae73-e9fe7f2656db 
zoneid=720e3192-4453-4c92-8423-204549e1844a clustertype=CloudManaged
{
  "cluster": [
{
  "allocationstate": "Enabled", 
  "clustertype": "CloudManaged", 
  "cpuovercommitratio": "1.0", 
  "hypervisortype": "Simulator", 
  "id": "0d8929f3-9f8e-491a-839b-c2ceea375557", 
  "managedstate": "Managed", 
  "memoryovercommitratio": "1.0", 
  "name": "foo", 
  "podid": "11de114b-733a-4826-ae73-e9fe7f2656db", 
  "podname": "cs--pod", 
  "zoneid": "720e3192-4453-4c92-8423-204549e1844a", 
  "zonename": "cs--zone"
}
  ], 
  "count": 1
}
{code}

h2. Expected:

{code}
 $ cs addCluster clustername=foo hypervisor=Simulator 
podid=11de114b-733a-4826-ae73-e9fe7f2656db 
zoneid=720e3192-4453-4c92-8423-204549e1844a clustertype=CloudManaged
{
  "cluster": {
  "allocationstate": "Enabled", 
  "clustertype": "CloudManaged", 
  "cpuovercommitratio": "1.0", 
  "hypervisortype": "Simulator", 
  "id": "0d8929f3-9f8e-491a-839b-c2ceea375557", 
  "managedstate": "Managed", 
  "memoryovercommitratio": "1.0", 
  "name": "foo", 
  "podid": "11de114b-733a-4826-ae73-e9fe7f2656db", 
  "podname": "cs--pod", 
  "zoneid": "720e3192-4453-4c92-8423-204549e1844a", 
  "zonename": "cs--zone"
}
}
{code}

e.g. pod example

{code}
cs createPod name=podfoo zoneid=720e3192-4453-4c92-8423-204549e1844a 
startip=10.100.100.101 gateway=10.100.100.1 netmask=255.255.255.0
{
  "pod": {
"allocationstate": "Enabled", 
"endip": "10.100.100.254", 
"gateway": "10.100.100.1", 
"id": "15599249-c32c-4f82-84fa-96c6e31d8705", 
"name": "podfoo", 
"netmask": "255.255.255.0", 
"startip": "10.100.100.101", 
"zoneid": "720e3192-4453-4c92-8423-204549e1844a", 
"zonename": "cs--zone"
  }
}
{code}



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

[jira] [Commented] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-6485:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1299#issuecomment-168196828
  
@remibergsma I looked it up but the commit is present in 4.7. Let's find 
the breaking commit.


> [vpc] new private gateway network is registered wrong in network table
> --
>
> Key: CLOUDSTACK-6485
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6485
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1
>Reporter: Anton Opgenoort
>Assignee: Daan Hoogland
>
> When creating a private gateway for a VPC router on a network not yet known 
> to Cloudstack, Cloudstack ‘documents’ this network in the networks table.
> For normal guest networks, which should be associated with a single VPC, 
> Cloudstack includes the VPC_ID in the database. The VPC_ID field is used to 
> provision all networks and nics on a VPC router when it is created. Since 
> this table is all about network provisioning it makes sense to ‘document’ the 
> network cidr and gateway present in that nework. For guest tiers this usually 
> is the VPC router itself, so the interface IP’s on a VPC router are the 
> gateway IP’s found in the networks table.
> Unfortunately the VPC_ID is also recorded for the private gateway network 
> when it is first created. So the first VPC to be plugged on the private 
> gateway network also has that same network associated as a guest network 
> tier, instead of just a private gateway network.
> This by itself will not quickly become a problem, because private gateways 
> are first plugged on a running vpc router which is not likely to be recreated 
> any time soon after that.
> But as soon as this first ever VPC router on the private gateway network is 
> recreated due to a destroy of the VPC Router, all associated networks are 
> looked up in the networks table. 
> Because the private gateway network is ‘documented’ with the actual upstream 
> gateway used by the VPC router defintion, the VPC router provisions a NIC on 
> the private gateway network using the IP address of the actual upstream 
> gateway creating an IP conflict on the private gateway network, effectively 
> breaking down the upstream gateway functionality for all attached private 
> gateways of other vpc's.



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

[jira] [Commented] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-6485:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1299#issuecomment-168197900
  
LGTM, this is a regression from a code reformat in 
a51690be4b07bea5208344b9b07a3d38fb0cbc60.


> [vpc] new private gateway network is registered wrong in network table
> --
>
> Key: CLOUDSTACK-6485
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6485
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1
>Reporter: Anton Opgenoort
>Assignee: Daan Hoogland
>
> When creating a private gateway for a VPC router on a network not yet known 
> to Cloudstack, Cloudstack ‘documents’ this network in the networks table.
> For normal guest networks, which should be associated with a single VPC, 
> Cloudstack includes the VPC_ID in the database. The VPC_ID field is used to 
> provision all networks and nics on a VPC router when it is created. Since 
> this table is all about network provisioning it makes sense to ‘document’ the 
> network cidr and gateway present in that nework. For guest tiers this usually 
> is the VPC router itself, so the interface IP’s on a VPC router are the 
> gateway IP’s found in the networks table.
> Unfortunately the VPC_ID is also recorded for the private gateway network 
> when it is first created. So the first VPC to be plugged on the private 
> gateway network also has that same network associated as a guest network 
> tier, instead of just a private gateway network.
> This by itself will not quickly become a problem, because private gateways 
> are first plugged on a running vpc router which is not likely to be recreated 
> any time soon after that.
> But as soon as this first ever VPC router on the private gateway network is 
> recreated due to a destroy of the VPC Router, all associated networks are 
> looked up in the networks table. 
> Because the private gateway network is ‘documented’ with the actual upstream 
> gateway used by the VPC router defintion, the VPC router provisions a NIC on 
> the private gateway network using the IP address of the actual upstream 
> gateway creating an IP conflict on the private gateway network, effectively 
> breaking down the upstream gateway functionality for all attached private 
> gateways of other vpc's.



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

[jira] [Commented] (CLOUDSTACK-1986) Key translation fails for the Japanese keyboard keys ¥_,\ |, Muhenkan, Henkan, Hiragana/Katakana, Kanji Key & Caps Loc

2015-12-31 Thread Dag Sonstebo (JIRA)


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

Dag Sonstebo commented on CLOUDSTACK-1986:
--

Karthikeyan / all - is this still an issue or has it been resolved? No update 
on tickets for 2.5 years.

> Key translation fails for the Japanese keyboard keys ¥_,\ |, Muhenkan, 
> Henkan, Hiragana/Katakana, Kanji Key & Caps Loc
> --
>
> Key: CLOUDSTACK-1986
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1986
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VNC Proxy
>Affects Versions: 4.0.2, 4.2.0
> Environment: Build No.#133 
> (CloudStack-non-OSS-MASTER-133-rhel6.3.tar.gz)
> XenServer6.1 for Host Server, CentOS6.3 for NFS server and CloudStack-Mgr 
> Server, Win7-x86 for Client machine.
>Reporter: Karthikeyan Ravichandran
>Priority: Critical
> Fix For: Future
>
>
> Steps
> 1. Setup the CloudStack environments with build 4.2#133.
> 2. Bring Japanese Win-7 x86 VM.
> 3. Access the VM via Console Proxy from the Japanese client machine connected 
> to Japanese Keyboard. 
> 4. Hit all the keys with Japanese localized keyboard.
> Expected Result
> All the keys should work fine. 
> Actual Result
> The Japanese keyboard keys ¥_,\ |, Muhenkan, Henkan, & Hiragana/Katakana are 
> not working even after possible key translations tried. 
> Note: Caps Lock & Kanji key works well in IE browser after key translation, 
> but not working well in Firefox browser. 



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

[jira] [Assigned] (CLOUDSTACK-597) Management Server Restart loses hosts

2015-12-31 Thread Dag Sonstebo (JIRA)


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

Dag Sonstebo reassigned CLOUDSTACK-597:
---

Assignee: Dag Sonstebo

> Management Server Restart loses hosts
> -
>
> Key: CLOUDSTACK-597
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-597
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.0.0
> Environment: Ubuntu 12.04 ~ 4.0.0-incubating.20121024195401
> NFS Primary Storage, Ceph Primary Storage, Local Storage
>Reporter: Trevor Francis
>Assignee: Dag Sonstebo
>Priority: Critical
> Attachments: cloud.sql
>
>
> A cloud-management restart looses hosts. Hosts show "Disconnected" and are 
> unable to reconnect. A Force Reconnect give me a : Command failed due to 
> Internal Server Error :
> Agents are showing that they are connected to the management server.



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

[jira] [Closed] (CLOUDSTACK-597) Management Server Restart loses hosts

2015-12-31 Thread Dag Sonstebo (JIRA)


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

Dag Sonstebo closed CLOUDSTACK-597.
---
   Resolution: Fixed
Fix Version/s: 4.3.0

Closing due to outdated issue (no update for ~3 years) and history points to 
localised issue.

> Management Server Restart loses hosts
> -
>
> Key: CLOUDSTACK-597
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-597
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.0.0
> Environment: Ubuntu 12.04 ~ 4.0.0-incubating.20121024195401
> NFS Primary Storage, Ceph Primary Storage, Local Storage
>Reporter: Trevor Francis
>Assignee: Dag Sonstebo
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: cloud.sql
>
>
> A cloud-management restart looses hosts. Hosts show "Disconnected" and are 
> unable to reconnect. A Force Reconnect give me a : Command failed due to 
> Internal Server Error :
> Agents are showing that they are connected to the management server.



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

[jira] [Updated] (CLOUDSTACK-9203) [API] extend updateVirtualMachine to support updating security groups

2015-12-31 Thread Daan Hoogland (JIRA)


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

Daan Hoogland updated CLOUDSTACK-9203:
--
Status: Reviewable  (was: In Progress)

> [API] extend updateVirtualMachine to support updating security groups
> -
>
> Key: CLOUDSTACK-9203
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9203
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: René Moser
>Assignee: Daan Hoogland
>Priority: Minor
> Fix For: Future
>
>
> There is currently no way to change security groups on exisitng VMs.
> {{updateVirtualMachine}} should be extended in a similar way as 
> {{deployVirtualMachine}} which should allow passing a list of IDs or names to 
> update the security groups as passed:
> {{securitygroupids}} parameter
> comma separated list of security groups id that going to be applied to the 
> virtual machine. Should be passed only when vm is created from a zone with 
> Basic Network support. Mutually exclusive with securitygroupnames parameter, 
> default: false
> {{securitygroupnames}} parameter
> comma separated list of security groups names that going to be applied to the 
> virtual machine. Should be passed only when vm is created from a zone with 
> Basic Network support. Mutually exclusive with securitygroupids parameter. 
> default: false
> Exoscale did already some work in their branch which we are 
> [allowed|https://twitter.com/resmo79/status/681428989018267648] to use, see 
> [https://github.com/exoscale/cloudstack/pull/6/]



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

[jira] [Commented] (CLOUDSTACK-9186) Root admin cannot see VPC created by Domain admin user

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9186:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1258#issuecomment-168245371
  
@nitin-maharana This fix should be against 4.7 IMHO. Can you make a PR for 
that please? We can still refer to the reviews that have been done. This way 
both 4.7 and 4.8 will have this fix. Thanks!


> Root admin cannot see VPC created by Domain admin user
> --
>
> Key: CLOUDSTACK-9186
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9186
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Issue:
> =
> Root admin cannot see LB rules and Public LB IP addresses created by 
> domain-admin in UI therefore root admin cannot manage those.
> Reproducible Steps: 
>  
> 1.Log in as a Domain-Admin account and create a VPC with vpc virtual 
> router as public load balancer provider 
> 2.click on the newly created VPC -> click on the VPC tier -> click 
> internal LB 
> 3.Add internal LB, 
> 4.Logoff domain-admin and login as root admin 
> 5.Navigate the VPC created previously and click internal LB, internal lb 
> is not showing up.
> Same steps for Public LB IP addresses except select the correct Network 
> offering while creating a tier.
> Expected Behaviour: 
> = 
> Root admin should be able to manage VPC created by Domain admin user .
> Actual Behaviour:
> == 
> Root admin cannot see VPC created by Domain admin user and hence not able to 
> manage it.



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

[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9192:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1264#issuecomment-168244857
  
@nitin-maharana Thanks for the fix! I'd suggest making this PR against 4.7 
(it will end up on master as well).


> UpdateVpnCustomerGateway is failing
> ---
>
> Key: CLOUDSTACK-9192
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9192
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Reproducible Steps:
> 
> 1.Create a customer gateway for a VPC.
> 2.Edit it using UI(API call is UpdateVpnCustomerGateway).
> 3.When we try to update the customer vpn gateway with connection state is not 
> in "Error", we see the API error but that won't be reflected to the user in 
> UI.



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

[jira] [Commented] (CLOUDSTACK-9203) [API] extend updateVirtualMachine to support updating security groups

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9203:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1297#issuecomment-168254041
  
done some testing:

![screen shot 2015-12-31 at 22 55 
55](https://cloud.githubusercontent.com/assets/2486961/12068663/38964556-b012-11e5-83a3-efd0e5be58e7.png)
![screen shot 2015-12-31 at 22 56 
20](https://cloud.githubusercontent.com/assets/2486961/12068665/3d2464ae-b012-11e5-8fb8-41fb7fb71cfb.png)
with cloudmonkey:
```
 > update virtualmachine id=39f058ad-3021-4753-9c96-1aa922a74632 
securitygroupnames=exceptional
Error 431: Virtual machine must be stopped prior to update security groups

 > stop virtualmachine id=39f058ad-3021-4753-9c96-1aa922a74632
...
 > update virtualmachine id=39f058ad-3021-4753-9c96-1aa922a74632 
securitygroupnames=exceptional
...
```
resulting in
![screen shot 2015-12-31 at 22 58 
54](https://cloud.githubusercontent.com/assets/2486961/12068669/6b2f229e-b012-11e5-8111-2b0f669aebfa.png)



> [API] extend updateVirtualMachine to support updating security groups
> -
>
> Key: CLOUDSTACK-9203
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9203
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: René Moser
>Assignee: Daan Hoogland
>Priority: Minor
> Fix For: Future
>
>
> There is currently no way to change security groups on exisitng VMs.
> {{updateVirtualMachine}} should be extended in a similar way as 
> {{deployVirtualMachine}} which should allow passing a list of IDs or names to 
> update the security groups as passed:
> {{securitygroupids}} parameter
> comma separated list of security groups id that going to be applied to the 
> virtual machine. Should be passed only when vm is created from a zone with 
> Basic Network support. Mutually exclusive with securitygroupnames parameter, 
> default: false
> {{securitygroupnames}} parameter
> comma separated list of security groups names that going to be applied to the 
> virtual machine. Should be passed only when vm is created from a zone with 
> Basic Network support. Mutually exclusive with securitygroupids parameter. 
> default: false
> Exoscale did already some work in their branch which we are 
> [allowed|https://twitter.com/resmo79/status/681428989018267648] to use, see 
> [https://github.com/exoscale/cloudstack/pull/6/]



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

[jira] [Commented] (CLOUDSTACK-6448) VPC router won't be created when a private gateway is defined.

2015-12-31 Thread Remi Bergsma (JIRA)


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

Remi Bergsma commented on CLOUDSTACK-6448:
--

Error seen on 4.7:

2015-12-31 18:38:20,653 WARN  [c.c.n.v.VpcManagerImpl] 
(API-Job-Executor-10:ctx-5dc3a60a job-44358 ctx-c7ad79a8) Failed to start vpc 
[VPC [732-vpctest] due to
java.lang.NullPointerException
at 
com.cloud.network.router.NicProfileHelperImpl.createPrivateNicProfileForGateway(NicProfileHelperImpl.java:74)
at 
com.cloud.network.router.VpcNetworkHelperImpl.reallocateRouterNetworks(VpcNetworkHelperImpl.java:96)
at 
com.cloud.network.router.NetworkHelperImpl.deployRouter(NetworkHelperImpl.java:497)
at 
org.cloud.network.router.deployment.VpcRouterDeploymentDefinition.deployAllVirtualRouters(VpcRouterDeploymentDefinition.java:173)
at 
org.cloud.network.router.deployment.RouterDeploymentDefinition.executeDeployment(RouterDeploymentDefinition.java:351)
at 
org.cloud.network.router.deployment.RouterDeploymentDefinition.findOrDeployVirtualRouter(RouterDeploymentDefinition.java:214)
at 
org.cloud.network.router.deployment.VpcRouterDeploymentDefinition.findOrDeployVirtualRouter(VpcRouterDeploymentDefinition.java:138)
at 
org.cloud.network.router.deployment.RouterDeploymentDefinition.deployVirtualRouter(RouterDeploymentDefinition.java:197)
at 
com.cloud.network.element.VpcVirtualRouterElement.implementVpc(VpcVirtualRouterElement.java:159)
at 
com.cloud.network.vpc.VpcManagerImpl.startVpc(VpcManagerImpl.java:1202)
at 
com.cloud.network.vpc.VpcManagerImpl.startVpc(VpcManagerImpl.java:1174)
at 
com.cloud.network.vpc.VpcManagerImpl.restartVpc(VpcManagerImpl.java:1530)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)


NicProfileHelperImpl.java:
 74 final Nic privateNic = 
_nicDao.findByIp4AddressAndNetworkId(ipVO.getIpAddress(), 
privateNetwork.getId());


privateNetwork.getId() is used above so cannot be NULL. So, ipVO.getIpAddress() 
must be NULL



> VPC router won't be created when a private gateway is defined. 
> ---
>
> Key: CLOUDSTACK-6448
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6448
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices, Virtual Router
>Affects Versions: 4.3.0, 4.4.0, 4.3.1, 4.5.2, 4.6.0, 4.7.0, 4.7.1
>Reporter: Anton Opgenoort
>Assignee: Saksham Srivastava
>
> Reproduce by creating a VPC, adding a gateway, and destroy the associated 
> virtual router. Then try to start a VM in one of the VPC network tiers; this 
> results in message below, and routerVM is not started for VPC network. 
> Then remove the private gateway, and start a VM again. Now the routerVM is 
> started normally, and the VM is being provisioned. 
> 2014-04-18 10:35:04,895 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) VM is being created in podId: 1
> 2014-04-18 10:35:04,907 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Network id=1143 is already 
> implemented
> 2014-04-18 10:35:04,943 DEBUG [c.c.n.NetworkModelImpl] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Service SecurityGroup is not 
> supported in the network id=1143
> 2014-04-18 10:35:04,958 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Changing active number of nics 
> for network id=1143 on 1
> 2014-04-18 10:35:04,973 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Asking VpcVirtualRouter to 
> prepare for Nic[98879-15684-e51a9969-e1f1-4c45-ad65-761e51435b90-10.1.1.98]
> 2014-04-18 10:35:04,979 DEBUG [c.c.n.r.VpcVirtualNetworkApplianceManagerImpl] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Deploying Virtual Router in VPC 
> [VPC [313-mccoat1]
> 2014-04-18 10:35:05,006 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Adding nic for Virtual Router in 
> Control network 
> 2014-04-18 10:35:05,014 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Found existing network 
> configuration for offering [Network Offering 
> [5-Control-System-Control-Network]: Ntwk[202|Control|5]
> 2014-04-18 10:35:05,014 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
> (Job-Executor-74:ctx-37d3b587 ctx-641440ee) Releasing lock for 
>

[jira] [Commented] (CLOUDSTACK-9203) [API] extend updateVirtualMachine to support updating security groups

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9203:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1297#issuecomment-168254105
  
pinging every badoy again: @borisroman @wido @resmo @llambiel @pyr 
@bhaisaab @wilderrodrigues 


> [API] extend updateVirtualMachine to support updating security groups
> -
>
> Key: CLOUDSTACK-9203
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9203
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: René Moser
>Assignee: Daan Hoogland
>Priority: Minor
> Fix For: Future
>
>
> There is currently no way to change security groups on exisitng VMs.
> {{updateVirtualMachine}} should be extended in a similar way as 
> {{deployVirtualMachine}} which should allow passing a list of IDs or names to 
> update the security groups as passed:
> {{securitygroupids}} parameter
> comma separated list of security groups id that going to be applied to the 
> virtual machine. Should be passed only when vm is created from a zone with 
> Basic Network support. Mutually exclusive with securitygroupnames parameter, 
> default: false
> {{securitygroupnames}} parameter
> comma separated list of security groups names that going to be applied to the 
> virtual machine. Should be passed only when vm is created from a zone with 
> Basic Network support. Mutually exclusive with securitygroupids parameter. 
> default: false
> Exoscale did already some work in their branch which we are 
> [allowed|https://twitter.com/resmo79/status/681428989018267648] to use, see 
> [https://github.com/exoscale/cloudstack/pull/6/]



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

[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9192:


Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/1264#issuecomment-168282637
  
Sure @remibergsma. I will a PR against 4.7. Thanks.


> UpdateVpnCustomerGateway is failing
> ---
>
> Key: CLOUDSTACK-9192
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9192
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Reproducible Steps:
> 
> 1.Create a customer gateway for a VPC.
> 2.Edit it using UI(API call is UpdateVpnCustomerGateway).
> 3.When we try to update the customer vpn gateway with connection state is not 
> in "Error", we see the API error but that won't be reflected to the user in 
> UI.



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

[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9192:


Github user nitin-maharana closed the pull request at:

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


> UpdateVpnCustomerGateway is failing
> ---
>
> Key: CLOUDSTACK-9192
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9192
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Reproducible Steps:
> 
> 1.Create a customer gateway for a VPC.
> 2.Edit it using UI(API call is UpdateVpnCustomerGateway).
> 3.When we try to update the customer vpn gateway with connection state is not 
> in "Error", we see the API error but that won't be reflected to the user in 
> UI.



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

[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9192:


Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/1264#issuecomment-168289642
  
Closing this PR as made a new PR #1300 (Against 4.7 which will be merged in 
master later).


> UpdateVpnCustomerGateway is failing
> ---
>
> Key: CLOUDSTACK-9192
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9192
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Reproducible Steps:
> 
> 1.Create a customer gateway for a VPC.
> 2.Edit it using UI(API call is UpdateVpnCustomerGateway).
> 3.When we try to update the customer vpn gateway with connection state is not 
> in "Error", we see the API error but that won't be reflected to the user in 
> UI.



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

[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9192:


Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/1300#issuecomment-168289311
  
Reference #1264 (The PR against master).


> UpdateVpnCustomerGateway is failing
> ---
>
> Key: CLOUDSTACK-9192
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9192
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Reproducible Steps:
> 
> 1.Create a customer gateway for a VPC.
> 2.Edit it using UI(API call is UpdateVpnCustomerGateway).
> 3.When we try to update the customer vpn gateway with connection state is not 
> in "Error", we see the API error but that won't be reflected to the user in 
> UI.



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

[jira] [Commented] (CLOUDSTACK-9186) Root admin cannot see VPC created by Domain admin user

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9186:


Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/1258#issuecomment-168290892
  
Closing this PR as made a new PR #1301 (Against 4.7 which will be merged in 
master later).


> Root admin cannot see VPC created by Domain admin user
> --
>
> Key: CLOUDSTACK-9186
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9186
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Issue:
> =
> Root admin cannot see LB rules and Public LB IP addresses created by 
> domain-admin in UI therefore root admin cannot manage those.
> Reproducible Steps: 
>  
> 1.Log in as a Domain-Admin account and create a VPC with vpc virtual 
> router as public load balancer provider 
> 2.click on the newly created VPC -> click on the VPC tier -> click 
> internal LB 
> 3.Add internal LB, 
> 4.Logoff domain-admin and login as root admin 
> 5.Navigate the VPC created previously and click internal LB, internal lb 
> is not showing up.
> Same steps for Public LB IP addresses except select the correct Network 
> offering while creating a tier.
> Expected Behaviour: 
> = 
> Root admin should be able to manage VPC created by Domain admin user .
> Actual Behaviour:
> == 
> Root admin cannot see VPC created by Domain admin user and hence not able to 
> manage it.



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

[jira] [Commented] (CLOUDSTACK-9186) Root admin cannot see VPC created by Domain admin user

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9186:


Github user nitin-maharana closed the pull request at:

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


> Root admin cannot see VPC created by Domain admin user
> --
>
> Key: CLOUDSTACK-9186
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9186
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Issue:
> =
> Root admin cannot see LB rules and Public LB IP addresses created by 
> domain-admin in UI therefore root admin cannot manage those.
> Reproducible Steps: 
>  
> 1.Log in as a Domain-Admin account and create a VPC with vpc virtual 
> router as public load balancer provider 
> 2.click on the newly created VPC -> click on the VPC tier -> click 
> internal LB 
> 3.Add internal LB, 
> 4.Logoff domain-admin and login as root admin 
> 5.Navigate the VPC created previously and click internal LB, internal lb 
> is not showing up.
> Same steps for Public LB IP addresses except select the correct Network 
> offering while creating a tier.
> Expected Behaviour: 
> = 
> Root admin should be able to manage VPC created by Domain admin user .
> Actual Behaviour:
> == 
> Root admin cannot see VPC created by Domain admin user and hence not able to 
> manage it.



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

[jira] [Commented] (CLOUDSTACK-9186) Root admin cannot see VPC created by Domain admin user

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9186:


GitHub user nitin-maharana opened a pull request:

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

CLOUDSTACK-9186: Root admin cannot see VPC created by Domain admin user

Issue:
=
Root admin cannot see LB rules and Public LB IP addresses created by 
domain-admin in UI therefore root admin cannot manage those.

Reproducible Steps:

Log in as a Domain-Admin account and create a VPC with vpc virtual router 
as public load balancer provider
click on the newly created VPC -> click on the VPC tier -> click internal LB
Add internal LB,
Logoff domain-admin and login as root admin
Navigate the VPC created previously and click internal LB, internal lb is 
not showing up.
Same steps for Public LB IP addresses except select the correct Network 
offering while creating a tier.

Expected Behaviour:

Root admin should be able to manage VPC created by Domain admin user .

Actual Behaviour:
==
Root admin cannot see VPC created by Domain admin user and hence not able 
to manage it.

Fix:
===
Added the parameter listAll=true in case of Internal LB as well as Public 
LB IP addresses.

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

$ git pull https://github.com/nitin-maharana/CloudStack 
CloudStack-Nitin3_4.7

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

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


commit 223c5b933848eede4e0b4aaaf2bcd7ff745aea9d
Author: Nitin Kumar Maharana 
Date:   2015-12-18T07:53:50Z

CLOUDSTACK-9186: Root admin cannot see VPC created by Domain admin user

Added the parameter listAll=true in case of Internal LB as well as Public 
LB IP addresses.




> Root admin cannot see VPC created by Domain admin user
> --
>
> Key: CLOUDSTACK-9186
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9186
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Issue:
> =
> Root admin cannot see LB rules and Public LB IP addresses created by 
> domain-admin in UI therefore root admin cannot manage those.
> Reproducible Steps: 
>  
> 1.Log in as a Domain-Admin account and create a VPC with vpc virtual 
> router as public load balancer provider 
> 2.click on the newly created VPC -> click on the VPC tier -> click 
> internal LB 
> 3.Add internal LB, 
> 4.Logoff domain-admin and login as root admin 
> 5.Navigate the VPC created previously and click internal LB, internal lb 
> is not showing up.
> Same steps for Public LB IP addresses except select the correct Network 
> offering while creating a tier.
> Expected Behaviour: 
> = 
> Root admin should be able to manage VPC created by Domain admin user .
> Actual Behaviour:
> == 
> Root admin cannot see VPC created by Domain admin user and hence not able to 
> manage it.



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

[jira] [Commented] (CLOUDSTACK-9186) Root admin cannot see VPC created by Domain admin user

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9186:


Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/1301#issuecomment-168290875
  
Reference PR #1258 (Against master).


> Root admin cannot see VPC created by Domain admin user
> --
>
> Key: CLOUDSTACK-9186
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9186
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Issue:
> =
> Root admin cannot see LB rules and Public LB IP addresses created by 
> domain-admin in UI therefore root admin cannot manage those.
> Reproducible Steps: 
>  
> 1.Log in as a Domain-Admin account and create a VPC with vpc virtual 
> router as public load balancer provider 
> 2.click on the newly created VPC -> click on the VPC tier -> click 
> internal LB 
> 3.Add internal LB, 
> 4.Logoff domain-admin and login as root admin 
> 5.Navigate the VPC created previously and click internal LB, internal lb 
> is not showing up.
> Same steps for Public LB IP addresses except select the correct Network 
> offering while creating a tier.
> Expected Behaviour: 
> = 
> Root admin should be able to manage VPC created by Domain admin user .
> Actual Behaviour:
> == 
> Root admin cannot see VPC created by Domain admin user and hence not able to 
> manage it.



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

[jira] [Commented] (CLOUDSTACK-9132) API createVolume takes empty string for name parameter

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9132:


Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/1273#issuecomment-168284288
  
@remibergsma : Shall I make this one against 4.7. I mean, should I make all 
pending PRs against 4.7?
Is it not going to be merged?


> API createVolume takes empty string for name parameter
> --
>
> Key: CLOUDSTACK-9132
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9132
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Nitin Kumar Maharana
>
> Steps to Reproduce:
> 
> Create a volume using createVolume API where parameter name is empty.
> It creates a volume with empty name.
> But the name parameter is mandatory.(Issue)
> Expected Behaviour:
> 
> It shouldn't create a volume with an empty name. Error should be returned.



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

[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing

2015-12-31 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on CLOUDSTACK-9192:


GitHub user nitin-maharana opened a pull request:

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

CLOUDSTACK-9192: UpdateVpnCustomerGateway is failing

Reproducible Steps:

1.Create a customer gateway for a VPC.
2.Edit it using UI(API call is UpdateVpnCustomerGateway).
3.When we try to update the customer vpn gateway with connection state is 
not in "Error", we see the API error but that won't be reflected to the user in 
UI.

Actual Behaviour:
==
The API throws error. But UI doesn't show it to user.

Expected Behaviour:

The UI should show the error to user.

Fix:
===
TypeError: json.updatecustomergatewayresponse is undefined
The response name was wrong so corrected it.
It should be json.updatevpncustomergatewayresponse.
Added the error function.

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

$ git pull https://github.com/nitin-maharana/CloudStack 
CloudStack-Nitin10_4.7

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

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


commit c4669fa4f8b320fd5ec2ba6a78bab37498115fa9
Author: Nitin Kumar Maharana 
Date:   2015-12-21T10:34:17Z

CLOUDSTACK-9192: UpdateVpnCustomerGateway is failing

The response name was wrong so corrected it.
Added the error function.




> UpdateVpnCustomerGateway is failing
> ---
>
> Key: CLOUDSTACK-9192
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9192
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Reproducible Steps:
> 
> 1.Create a customer gateway for a VPC.
> 2.Edit it using UI(API call is UpdateVpnCustomerGateway).
> 3.When we try to update the customer vpn gateway with connection state is not 
> in "Error", we see the API error but that won't be reflected to the user in 
> UI.



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

[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing

[jira] [Created] (CLOUDSTACK-9204) Delete static route fails when it's already gone

[jira] [Commented] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table

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

[jira] [Commented] (CLOUDSTACK-9204) Delete static route fails when it's already gone

[jira] [Commented] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table

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

[jira] [Closed] (CLOUDSTACK-7783) Blank page after login

[jira] [Created] (CLOUDSTACK-9205) api: addCluster should not return a list as result

[jira] [Commented] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table

[jira] [Commented] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table

[jira] [Commented] (CLOUDSTACK-1986) Key translation fails for the Japanese keyboard keys ¥_,\ |, Muhenkan, Henkan, Hiragana/Katakana, Kanji Key & Caps Loc

[jira] [Assigned] (CLOUDSTACK-597) Management Server Restart loses hosts

[jira] [Closed] (CLOUDSTACK-597) Management Server Restart loses hosts

[jira] [Updated] (CLOUDSTACK-9203) [API] extend updateVirtualMachine to support updating security groups

[jira] [Commented] (CLOUDSTACK-9186) Root admin cannot see VPC created by Domain admin user

[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing

[jira] [Commented] (CLOUDSTACK-9203) [API] extend updateVirtualMachine to support updating security groups

[jira] [Commented] (CLOUDSTACK-6448) VPC router won't be created when a private gateway is defined.

[jira] [Commented] (CLOUDSTACK-9203) [API] extend updateVirtualMachine to support updating security groups

[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing

[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing

[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing

[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing

[jira] [Commented] (CLOUDSTACK-9186) Root admin cannot see VPC created by Domain admin user

[jira] [Commented] (CLOUDSTACK-9186) Root admin cannot see VPC created by Domain admin user

[jira] [Commented] (CLOUDSTACK-9186) Root admin cannot see VPC created by Domain admin user

[jira] [Commented] (CLOUDSTACK-9186) Root admin cannot see VPC created by Domain admin user

[jira] [Commented] (CLOUDSTACK-9132) API createVolume takes empty string for name parameter

[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing

30 matches

Site Navigation

Mail list logo

Footer information