[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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-9204) Delete static route fails when it's already gone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-6485) [vpc] new private gateway network is registered wrong in network table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-6485) [vpc] new private gateway network is registered wrong in network table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Created] (CLOUDSTACK-9205) api: addCluster should not return a list as result
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-9099) SecretKey is returned from the APIs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (CLOUDSTACK-9099) SecretKey is returned from the APIs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Closed] (CLOUDSTACK-7783) Blank page after login
[ 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] [Commented] (CLOUDSTACK-1986) Key translation fails for the Japanese keyboard keys ¥_,\ |, Muhenkan, Henkan, Hiragana/Katakana, Kanji Key & Caps Loc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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-6448) VPC router won't be created when a private gateway is defined.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > Acct[5083d876-e429-
[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-9186) Root admin cannot see VPC created by Domain admin user
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-9203) [API] extend updateVirtualMachine to support updating security groups
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-9203) [API] extend updateVirtualMachine to support updating security groups
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-9132) API createVolume takes empty string for name parameter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-9192) UpdateVpnCustomerGateway is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-9186) Root admin cannot see VPC created by Domain admin user
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-9186) Root admin cannot see VPC created by Domain admin user
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)