[jira] [Commented] (CLOUDSTACK-10043) Egress Rule in VPC ACL broken

[JIRA]

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

Rafael Weingärtner commented on CLOUDSTACK-10043:
-

I use ACS 4.9.2 and so far I have not seen this error.
Have you re-created the VR using the new template?
when you say, "Creating a Deny All rule", are you talking about using ACS API? 
or creating the rule directly in the VR?

>  Egress Rule in VPC ACL broken
> --
>
> Key: CLOUDSTACK-10043
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10043
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router, VPC
>Affects Versions: 4.9.2.0
> Environment: CS 4.9.2 with XenServer 6.5SP1
>Reporter: Francois Scheurer
>Priority: Blocker
>
> The Network Offering of the VPC Tier has a Default Egress Policy = Deny.
> Some Allow Rules exist in the ACL, but _ALL_ egress connections are possible.
> Creating a Deny All rule explicit at the end of the rules is actually 
> blocking ALL traffic (should not, because of the Allow rules).
> The Iptables in the VR are wrong:
> 1)the allow rules are in wrong order.
> 2)some rules are in mangle table instead of filter
> Do you know how to fix this?
> Thank you for your help.
> Francois Scheurer



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CLOUDSTACK-10044) Update rule permission of a role permission

[Nicolas Vazquez (JIRA)]

Nicolas Vazquez created CLOUDSTACK-10044:


 Summary: Update rule permission of a role permission
 Key: CLOUDSTACK-10044
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10044
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API
Affects Versions: 4.11.0.0
Reporter: Nicolas Vazquez
Assignee: Nicolas Vazquez
 Fix For: 4.11.0.0
 Attachments: UpdateRolePermissionUI.jpg

h3. Introduction
This feature allows to change permission for existing role permissions, as 
those were static and could not be changed once created. It also provides the 
ability to change these permissions in the UI using a drop down menu for each 
permission rule, in which admin can select ‘Allow’ or ‘Deny’ permission.

h3. Changes in the API:
This feature modifies behaviour of {{updateRolePermission}} API method: 
* New optional parameters ‘ruleid’ and ‘permission’ are introduced, they are 
mutual exclusive to ‘ruleorder’ parameter. This defines two use cases:
** Update role permission: ‘ruleid’ and ‘permission’ parameters needed
** Update rules order: ‘ruleorder’ parameter needed
* Parameter ‘ruleorder’ is now optional
* updateRolePermission providing ‘ruleorder’ parameter should be sent via POST

h3. Changes in the UI:
Drop down menu added for role rule-permissions as seen in attached picture
!UpdateRolePermissionUI.jpg|UI!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9994) Changing default network in multihomed VM

[Rohit Yadav (JIRA)]

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

Rohit Yadav commented on CLOUDSTACK-9994:
-

A fix already exists in 4.9 now.

> Changing default network in multihomed VM
> -
>
> Key: CLOUDSTACK-9994
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9994
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM, Virtual Router
>Affects Versions: 4.9.2.0
>Reporter: Alireza Eskandari
>  Labels: gateway, network, systemvm, virtual-router, vmware
>
> Environment:
>  - vCenter 6.0u3
>  - CloudStack 4.9.2.0 (Shapeblue)
> Steps to reproduce:
>  - Create a new VM on a single network
>  - Attach a new NIC from other network
>  - Change default network to new NIC
> Expected result:
> I expect that the default gateway of VM changes to new network.
> Actual result:
> The default gateway of VM remains unchanged.
> Rebooting VM doesn't help.
> Removing of non-default NIC (former default NIC) results in connection loss 
> because of lack of default route on new default NIC.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CLOUDSTACK-8349) Implement a general purpose VR-UserVM Agents Framework

[Rohit Yadav (JIRA)]

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

Rohit Yadav reassigned CLOUDSTACK-8349:
---

Assignee: (was: Rohit Yadav)

> Implement a general purpose VR-UserVM Agents Framework
> --
>
> Key: CLOUDSTACK-8349
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8349
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
> Fix For: Future
>
>
> Scope and Design Doc:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Agents+Framework
> Aims to:
> - Refactor VR codebase, provide better test-ability and scalability in 
> developing features in VR and for user VMs
> - Provide user VM based granular orchestration such as reset password, reset 
> SSH key, installation of software such as monitoring and backup etc.
> - Secure/TLS based connection between VR and user VMs
> - Easy to use orchestration based on Ansible, Chef or Puppet and recipes 
> based on that
> - Provides a way to monitor VR and do VR VM maintenance such as upgrade 
> packages and apply security patches (such as openssl packages), cleanup 
> /var/log files and monitor VR health
> - Available in Isolated, VPC and Shared networks
> - Make it easier for sys admins to debug issues



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (CLOUDSTACK-9429) Local User Password can not be changed if LDAP is configured

[Rohit Yadav (JIRA)]

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

Rohit Yadav closed CLOUDSTACK-9429.
---
Resolution: Fixed

Fixed in recent branches.

> Local User Password can not be changed if LDAP is configured
> 
>
> Key: CLOUDSTACK-9429
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9429
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.5.2
>Reporter: René Moser
>Assignee: Rohit Yadav
>Priority: Minor
> Fix For: Future
>
>
> As discussed with Rohit
> We noticed that a user password can not be changed in the UI if LDAP is 
> configured. However the API allows to change the password.
> Steps to reproduce:
> * LDAP is configured to be used.
> * Try to change password of user john --> Error could not change your 
> password because LDAP is enabled. 
> As an improvement the following message should be shown before we allow to 
> change the password, e.g.: 
> {quote}
> Note: You will change the local user password and this may not have any 
> affect for authentification if the user exists in LDAP or SAML. Are you sure 
> you want to change the password?
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (CLOUDSTACK-9361) Implement framework level API arg checks

[Rohit Yadav (JIRA)]

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

Rohit Yadav closed CLOUDSTACK-9361.
---
Resolution: Fixed

> Implement framework level API arg checks
> 
>
> Key: CLOUDSTACK-9361
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9361
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>
> We do a lot of npe and id > 0 checks in api cmds, the aim of this ticket is 
> to do such validations at api-server level in ProcessParamWorker and 
> introduce validators in api parameters annotations



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CLOUDSTACK-1309) Large guest subnets downgrade performance

[Rohit Yadav (JIRA)]

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

Rohit Yadav reassigned CLOUDSTACK-1309:
---

Assignee: (was: Rohit Yadav)

> Large guest subnets downgrade performance
> -
>
> Key: CLOUDSTACK-1309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1309
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: pre-4.0.0
> Environment: CloudStack version: 3.0.5.20120904142539
> MySQL server version: 5.1.61-4.el6
>Reporter: Vladimir Ostrovsky
> Fix For: Future
>
> Attachments: Large guest subnets in CloudStack.jpg
>
>
> When guest network / VLAN is defined in CloudStack, a separate record is 
> created in the cloud.user_ip_address table for each address in the range, 
> even if it isn't really allocated.
> As a result, if a very wide subnet is defined (say, Class B), then the table 
> contains at least 65534 records.
> On a system with 5 such Class B VLANs defined, the size of the table grew to 
> more than 327670 records. This caused mysqld to spend about 95-99% of its 
> time in Waiting state and efficiently stuck the CloudStack.
> top - 11:58:43 up  2:25,  3 users,  load average: 2.91, 2.71, 2.21
> Tasks: 145 total,   1 running, 144 sleeping,   0 stopped,   0 zombie
> Cpu0  :  1.8%us,  0.4%sy,  0.0%ni,  1.8%id, 95.7%wa,  0.0%hi,  0.4%si,  0.0%st
> When I tried to delete such network, the operation lasted about an hour.
> It obviously doesn't seem to be limitation of MySQL itself; I suspect that 
> CloudStack's algorythms working with this table are pretty inefficient and 
> aren't built to the case of huge number of addresses. Am I right?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-9531) Fix tearDown issue in test_vpc_vpn.py

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-9531.
-
Resolution: Fixed

> Fix tearDown issue in test_vpc_vpn.py
> -
>
> Key: CLOUDSTACK-9531
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9531
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>
> After running the test, delete template command may fail due to template that 
> is not properly setup/downloaded and other reasons. The tearDown failure is 
> frivolous, on account deletion all resources of the account are expunged so 
> any template deletion failure may be retried when account is removed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-9564) Fix memory leak in VmwareContextPool

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-9564.
-
Resolution: Fixed

> Fix memory leak in VmwareContextPool
> 
>
> Key: CLOUDSTACK-9564
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9564
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>
> In a recent management server crash, it was found that the largest 
> contributor to memory leak was in VmwareContextPool where a registry is held 
> (arraylist) that grows indefinitely. The list itself is not used anywhere or 
> consumed. There exists a hashmap (pool) that returns a list of contexts for 
> existing poolkey (address/username) that is used instead. The fix would be to 
> get rid of the registry and limit the hashmap context list length for any 
> poolkey.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-9904) HyperV plugin created logs @AGENTLOG@

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-9904.
-
Resolution: Fixed

> HyperV plugin created logs @AGENTLOG@
> -
>
> Key: CLOUDSTACK-9904
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9904
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.1.0, 4.9.3.0
>
>
> Spurious log files with names such as @AGENTLOG@ are seen by the hyperv 
> plugin. In the log4j specific xml files, the variable is not properly 
> replaced by maven.
> PR: https://github.com/apache/cloudstack/pull/2070



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-9805) Show VRs in a tab for a network in network detail view

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-9805.
-
Resolution: Fixed

> Show VRs in a tab for a network in network detail view
> --
>
> Key: CLOUDSTACK-9805
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9805
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (CLOUDSTACK-9860) CloudStack should be able to pass 'hard' shutdown instruction to hosts to force a guest instance shutdown

[Rohit Yadav (JIRA)]

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

Rohit Yadav closed CLOUDSTACK-9860.
---
Resolution: Fixed

> CloudStack should be able to pass 'hard' shutdown instruction to hosts to 
> force a guest instance shutdown
> -
>
> Key: CLOUDSTACK-9860
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9860
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Hypervisor Controller, Management Server
>Reporter: Paul Angus
>Assignee: Rohit Yadav
>
> The 'force' option provided with the stopVirtualMachine API command is often 
> assumed to be a hard shutdown sent to the hypervisor, when in fact it is for 
> CloudStacks' internal use.
> CloudStack should be able to send the 'hard' power-off request to the hosts.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-9904) HyperV plugin created logs @AGENTLOG@

[Rohit Yadav (JIRA)]

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

Rohit Yadav updated CLOUDSTACK-9904:

Status: Reviewable  (was: In Progress)

> HyperV plugin created logs @AGENTLOG@
> -
>
> Key: CLOUDSTACK-9904
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9904
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.1.0, 4.9.3.0
>
>
> Spurious log files with names such as @AGENTLOG@ are seen by the hyperv 
> plugin. In the log4j specific xml files, the variable is not properly 
> replaced by maven.
> PR: https://github.com/apache/cloudstack/pull/2070



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-9584) Increase component tests coverage in Travis run

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-9584.
-
Resolution: Fixed

> Increase component tests coverage in Travis run
> ---
>
> Key: CLOUDSTACK-9584
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9584
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>
> Increase component tests in Travis for PRs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (CLOUDSTACK-9792) Add 4.9.3.0 Upgrade path

[Rohit Yadav (JIRA)]

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

Rohit Yadav closed CLOUDSTACK-9792.
---
Resolution: Fixed

> Add 4.9.3.0 Upgrade path
> 
>
> Key: CLOUDSTACK-9792
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9792
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.9.3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-9900) Fix high CPU deviation seen in Zone/Cluster metrics view

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-9900.
-
Resolution: Fixed

> Fix high CPU deviation seen in Zone/Cluster metrics view
> 
>
> Key: CLOUDSTACK-9900
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9900
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.1.0, 4.9.3.0
>
>
> High CPU deviation (100-400%) is seen in the metrics view. The regression was 
> caused becase HostStats returns CPU usage in percentage and memory usage in 
> bytes, while the deviation calculation method did not assume that passed 
> values are in percentage and multiples the ratios by 100 resulting in 100x 
> the actual values.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (CLOUDSTACK-9986) Consider overcommit ratios with total/threshold values in Metrics View

[Rohit Yadav (JIRA)]

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

Rohit Yadav closed CLOUDSTACK-9986.
---
Resolution: Fixed

> Consider overcommit ratios with total/threshold values in Metrics View
> --
>
> Key: CLOUDSTACK-9986
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9986
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.9.3.0
>
>
> On code analysis and discussions, I found that overcommit ratios are used 
> with the allocated values, instead they should be used/compared with the 
> total/threshold values during comparison for determining where the allocated 
> values have gone beyond the thresholds (considering overcommit ratios) or not.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-9632) Upgrade bountycastle to 1.55+

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-9632.
-
Resolution: Fixed

> Upgrade bountycastle to 1.55+
> -
>
> Key: CLOUDSTACK-9632
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9632
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.1.0
>
>
> Upgrade bountycastle library to latest versions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-9710) Switch to JDK 1.8

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-9710.
-
Resolution: Fixed

> Switch to JDK 1.8
> -
>
> Key: CLOUDSTACK-9710
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9710
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.1.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-9783) Improve metrics view performance

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-9783.
-
Resolution: Fixed

> Improve metrics view performance
> 
>
> Key: CLOUDSTACK-9783
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9783
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.1.0, 4.9.3.0
>
>
> Metrics view is a pure frontend feature, where several API calls are made to 
> generate the metrics view tabular data. In very large environments, rendering 
> of these tables can take a lot of time, especially when there is high 
> latency. The improvement task is to reimplement this feature by moving the 
> logic to backend so metrics calculations happen at the backend and final 
> result can be served by a single API request.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (CLOUDSTACK-9648) Checkstyle module version fails to update by build_asf.sh

[Rohit Yadav (JIRA)]

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

Rohit Yadav closed CLOUDSTACK-9648.
---
Resolution: Fixed

> Checkstyle module version fails to update by build_asf.sh
> -
>
> Key: CLOUDSTACK-9648
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9648
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.9.1.0, 4.8.2.0, 4.10.1.0
>
>
> As reported on users@, the build_asf.sh fails to update checkstyle module's 
> pom.xml that fails builds when build from source tarballs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-9900) Fix high CPU deviation seen in Zone/Cluster metrics view

[Rohit Yadav (JIRA)]

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

Rohit Yadav updated CLOUDSTACK-9900:

Status: Reviewable  (was: In Progress)

> Fix high CPU deviation seen in Zone/Cluster metrics view
> 
>
> Key: CLOUDSTACK-9900
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9900
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.1.0, 4.9.3.0
>
>
> High CPU deviation (100-400%) is seen in the metrics view. The regression was 
> caused becase HostStats returns CPU usage in percentage and memory usage in 
> bytes, while the deviation calculation method did not assume that passed 
> values are in percentage and multiples the ratios by 100 resulting in 100x 
> the actual values.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-9783) Improve metrics view performance

[Rohit Yadav (JIRA)]

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

Rohit Yadav updated CLOUDSTACK-9783:

Status: Reviewable  (was: In Progress)

> Improve metrics view performance
> 
>
> Key: CLOUDSTACK-9783
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9783
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.1.0, 4.9.3.0
>
>
> Metrics view is a pure frontend feature, where several API calls are made to 
> generate the metrics view tabular data. In very large environments, rendering 
> of these tables can take a lot of time, especially when there is high 
> latency. The improvement task is to reimplement this feature by moving the 
> logic to backend so metrics calculations happen at the backend and final 
> result can be served by a single API request.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (CLOUDSTACK-9521) Multiple Failures in the test_vpc_vpn Smoke Test Suite

[Rohit Yadav (JIRA)]

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

Rohit Yadav closed CLOUDSTACK-9521.
---
Resolution: Fixed

> Multiple Failures in the test_vpc_vpn Smoke Test Suite
> --
>
> Key: CLOUDSTACK-9521
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9521
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.8.1
> Environment: CentOS 7.2 + XenServer 6.5 + NFS Primary/Secondary 
> Storage
>Reporter: John Burwell
>Assignee: Rohit Yadav
>Priority: Critical
>  Labels: 4.8.2.0-smoke-test-failure
> Fix For: 4.9.1.0, 4.8.2.0, 4.10.1.0
>
> Attachments: failed_plus_exceptions.txt, results.txt, runinfo.txt
>
>
> The {{test_vpc_vpn}} test case fails with the following errors:
> {code}
> 2016-09-27 22:19:30,562 - CRITICAL - EXCEPTION: 
> test_01_redundant_vpc_site2site_vpn: ['Traceback (most recent call last):\n', 
> '  File "/usr/lib64/python2.7/unittest/case.py", line 369, in run\n
> testMethod()\n', '  File "/marvin/tests/smoke/test_vpc_vpn.py", line 1154, in 
> test_01_redundant_vpc_site2site_vpn\nssh_client = 
> self._get_ssh_client(vm2, self.services, 10)\n', '  File 
> "/marvin/tests/smoke/test_vpc_vpn.py", line 898, in _get_ssh_client\n
> self.fail("Unable to create ssh connection: " % e)\n', 'TypeError: not all 
> arguments converted during string formatting\n']
> 2016-09-27 22:24:04,109 - CRITICAL - EXCEPTION: 
> test_01_vpc_remote_access_vpn: ['Traceback (most recent call last):\n', '  
> File "/usr/lib64/python2.7/unittest/case.py", line 369, in run\n
> testMethod()\n', '  File "/marvin/tests/smoke/test_vpc_vpn.py", line 336, in 
> test_01_vpc_remote_access_vpn\nself.assert_(vpc is not None, "VPC 
> creation failed")\n', "UnboundLocalError: local variable 'vpc' referenced 
> before assignment\n"]
> 2016-09-27 22:32:44,470 - CRITICAL - EXCEPTION: test_01_vpc_site2site_vpn: 
> ['Traceback (most recent call last):\n', '  File 
> "/usr/lib64/python2.7/unittest/case.py", line 369, in run\n
> testMethod()\n', '  File "/marvin/tests/smoke/test_vpc_vpn.py", line 787, in 
> test_01_vpc_site2site_vpn\nssh_client = self._get_ssh_client(vm2, 
> self.services, 10)\n', '  File "/marvin/tests/smoke/test_vpc_vpn.py", line 
> 497, in _get_ssh_client\nself.fail("Unable to create ssh connection: " % 
> e)\n', 'TypeError: not all arguments converted during string formatting\n']
> {code}
> All errors appear to be Python runtime issues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (CLOUDSTACK-9507) Make listVM cmd response's guest os type field consistent with listTemplate reponse's

[Rohit Yadav (JIRA)]

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

Rohit Yadav closed CLOUDSTACK-9507.
---
Resolution: Fixed

> Make listVM cmd response's guest os type field consistent with listTemplate 
> reponse's
> -
>
> Key: CLOUDSTACK-9507
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9507
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.9.2.0, 4.9.1.0, 4.10.1.0
>
>
> list virtualmachines response's ostypeid returned is an integer while, the 
> list templates API returns a uuid in the ostypeid key. The fix would be to 
> make the API consistent for users to only/always return uuids as id/integers 
> may not be consumable.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (CLOUDSTACK-9520) test_01_primary_storage_iscsi Smoke Test Fails

[Rohit Yadav (JIRA)]

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

Rohit Yadav closed CLOUDSTACK-9520.
---
Resolution: Fixed

> test_01_primary_storage_iscsi Smoke Test Fails
> --
>
> Key: CLOUDSTACK-9520
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9520
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin, Storage Controller
>Affects Versions: 4.8.1
> Environment: CentOS 7.2 + XenServer 6.5 + NFS Primary/Secondary 
> Storage
>Reporter: John Burwell
>Assignee: Rohit Yadav
>Priority: Critical
>  Labels: 4.8.2.0-smoke-test-failure
> Fix For: 4.9.1.0, 4.8.2.0, 4.10.1.0
>
> Attachments: failed_plus_exceptions.txt, results.txt, runinfo.txt
>
>
> The {{test_primary_storage}} test case fails with the following error:
> {code}
> 2016-09-27 19:39:42,710 - CRITICAL - EXCEPTION: 
> test_01_primary_storage_iscsi:  ['Traceback (most recent call last):\n', '  
> File "/usr/lib64/python2.7/unittest/case.py", line 369, in run\n
> testMethod()\n', '  File "/marvin/tests/smoke/test_primary_storage.py", line 
> 196, in test_01_primary_storage_iscsi\npodid=self.pod.id\n ', '  File 
> "/usr/lib/python2.7/site-packages/marvin/lib/base.py", line 2732, in create\n 
>return StoragePool(apiclient.createStoragePool(cmd).__dict__)\n', '  File 
> "/ 
> usr/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py", 
> line 2532, in createStoragePool\nresponse = 
> self.connection.marvinRequest(command, response_type=response, 
> method=method)\n', '  File "/usr/lib/python2.7/site-packages/ma 
> rvin/cloudstackConnection.py", line 379, in marvinRequest\nraise e\n', 
> 'Cloudsta ckAPIException: Execute cmd: createstoragepool failed, due to: 
> errorCode: 530, error Text:Failed to add data store: scheme is null , add 
> nfs:// (or cifs://) as a prefix\ n']
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-9524) Some marvin tests don't check hypervisor before executing ssh into VR

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-9524.
-
Resolution: Fixed

> Some marvin tests don't check hypervisor before executing ssh into VR
> -
>
> Key: CLOUDSTACK-9524
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9524
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.9.1.0, 4.8.2.0, 4.10.1.0
>
>
> Some marvin tests dont' check router hypervisor, before trying to ssh to VR 
> by ssh into mgmt server first and then using the default ssh keys.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-9507) Make listVM cmd response's guest os type field consistent with listTemplate reponse's

[Rohit Yadav (JIRA)]

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

Rohit Yadav updated CLOUDSTACK-9507:

Status: Open  (was: Reviewable)

> Make listVM cmd response's guest os type field consistent with listTemplate 
> reponse's
> -
>
> Key: CLOUDSTACK-9507
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9507
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.9.2.0, 4.9.1.0, 4.10.1.0
>
>
> list virtualmachines response's ostypeid returned is an integer while, the 
> list templates API returns a uuid in the ostypeid key. The fix would be to 
> make the API consistent for users to only/always return uuids as id/integers 
> may not be consumable.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-9928) Allow native CloudStack users to change password

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-9928.
-
Resolution: Fixed

> Allow native CloudStack users to change password
> 
>
> Key: CLOUDSTACK-9928
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9928
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.1.0
>
>
> When LDAP is enabled CloudStack UI does not allow changing of user's 
> password. However, user the updateUser API one can change a user's password. 
> The fix would be expose the user source/type via the listUsers response and 
> use that in the UI to determine whether the user whose password is being 
> changed is a CloudStack native user or not.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (CLOUDSTACK-9928) Allow native CloudStack users to change password

[Rohit Yadav (JIRA)]

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

Rohit Yadav closed CLOUDSTACK-9928.
---

> Allow native CloudStack users to change password
> 
>
> Key: CLOUDSTACK-9928
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9928
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.1.0
>
>
> When LDAP is enabled CloudStack UI does not allow changing of user's 
> password. However, user the updateUser API one can change a user's password. 
> The fix would be expose the user source/type via the listUsers response and 
> use that in the UI to determine whether the user whose password is being 
> changed is a CloudStack native user or not.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-9456) Migrate master to use Java8 and Spring4

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-9456.
-
Resolution: Fixed

Done.

> Migrate master to use Java8 and Spring4
> ---
>
> Key: CLOUDSTACK-9456
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9456
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.1.0
>
>
> We need to move master to use Java8 and Spring4.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (CLOUDSTACK-8158) After the host reboots, the system will run out vm management IP, no matter how much.

[Rohit Yadav (JIRA)]

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

Rohit Yadav closed CLOUDSTACK-8158.
---
Resolution: Fixed

not seen in 4.9, reopen when you find it, thanks.

> After the host reboots, the system will run out vm management IP, no matter 
> how much.
> -
>
> Key: CLOUDSTACK-8158
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8158
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.4.0, 4.4.1, 4.4.2
> Environment: All nodes in the system OS: Centos 6.5 x64 are
> Cloudstack Version: 4.4.1 / 4.4.2 / 4.4.0
> All nodes are installed on a single host, use the basic network, installation 
> documentation is installed in accordance with the documentation provided by 
> the official.
>Reporter: liliang
>Assignee: Rohit Yadav
>  Labels: patch
> Fix For: Future
>
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
> cloudstack all nodes installed on a host, all nodes in the system OS are 
> centos6.5 x64. After using basic network build regional success, reboot the 
> host, the system will manage IP vm exhausted. Every restart a host system vm 
> will occupy the new management IP address, the old IP address can not be 
> released. According to the analysis system BUG logs, restart once every host 
> system vm will automatically rebuild destroyed repeatedly, until the system 
> vm system up or manage IP exhausted, the system can start vm, the premise is 
> under the management of IP abundant, management IP consumption when you do 
> not start the system vm, database tables need to manually release the 
> management IP. And under normal circumstances, reboot the system into the 
> production environment is not su, senior network has not been detected this 
> problem,
> cloudstack 所有节点安装在一台资源充沛的宿主机，所有节点系统OS均为 centos6.5 
> x64。安装成功后，使用基本网络搭建区域成功后，重启宿主机后，系统vm会把管理IP耗尽。每重启一次宿主机，系统vm都会占用新的管理IP地址，旧的IP地址无法释放。根据系统BUG日志的分析，每重启一次宿主机，系统vm会自动反复重建销毁，直到系统vm系统起来或管理IP耗尽，系统vm可以正常启动，前提是管理IP充裕的情况下，管理IP耗尽时则无法启动系统vm
>  
> ，需要到数据库表中手动释放管理IP。都未运行任何实例。而在正常的情况下，重启系统宿主机，系统vm不会自动销毁重建，或占用大量IP。而在4.3.1或4.3.0以下，包括（4.3.0/4.3.1）不会出现上述问题，安装方式是按照官方提供的文档进行的安装，安装文档是：http://cloudstack-installation.readthedocs.org/en/latest/qig.html
> 未投入生产环境中，高级网络中尚未检测到这种问题。



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CLOUDSTACK-8355) Create CloudMonkey/Python windows installer

[Rohit Yadav (JIRA)]

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

Rohit Yadav reassigned CLOUDSTACK-8355:
---

Assignee: (was: Rohit Yadav)

> Create CloudMonkey/Python windows installer
> ---
>
> Key: CLOUDSTACK-8355
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8355
> Project: CloudStack
>  Issue Type: Wish
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
> Fix For: Future
>
>
> It's difficult to setup cygwin, python, pip and cloudmonkey on windows in 
> order to use cloudmonkey on windows. The aim is to create an installer for 
> windows which is easy and painless solution to install and use cloudmonkey on 
> windows.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CLOUDSTACK-7529) Make consistent use of CommandType.UUID in api layer

[Rohit Yadav (JIRA)]

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

Rohit Yadav reassigned CLOUDSTACK-7529:
---

Assignee: (was: Rohit Yadav)

> Make consistent use of CommandType.UUID in api layer
> 
>
> Key: CLOUDSTACK-7529
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7529
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
> Fix For: Future
>
>
> CommandType.UUID may not be consistently used, we just need to check it 
> across API layer and try to fix it where ever possible.
> cc Ilia Shakitko 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-8447) CloudMonkey has gone too slow, need to fix it

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-8447.
-
Resolution: Incomplete

> CloudMonkey has gone too slow, need to fix it
> -
>
> Key: CLOUDSTACK-8447
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8447
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>
> Compared to 5.2.0 Geoff reports that the current cloudmonkey is too slow. 
> Need to optimize its network handlers.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CLOUDSTACK-8031) Add mechanism to allow admins to list/remove cloudstack's internal job queue

[Rohit Yadav (JIRA)]

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

Rohit Yadav reassigned CLOUDSTACK-8031:
---

Assignee: (was: Rohit Yadav)

> Add mechanism to allow admins to list/remove cloudstack's internal job queue
> 
>
> Key: CLOUDSTACK-8031
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8031
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
> Fix For: Future
>
>
> Right there is no way to list, monitor or remove any job from CloudStack's 
> internal job orchestrator. We need to figure out best way to provide a high 
> level API to admins that allows them to list/remove a job from internal job 
> queue in a single ofrmulti-mgmt server deployment.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CLOUDSTACK-8209) VM migration fails across KVM hosts if hosts have same hostname even if different libvirt uuid or IPs

[Rohit Yadav (JIRA)]

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

Rohit Yadav reassigned CLOUDSTACK-8209:
---

Assignee: (was: Rohit Yadav)

> VM migration fails across KVM hosts if hosts have same hostname even if 
> different libvirt uuid or IPs
> -
>
> Key: CLOUDSTACK-8209
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8209
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.0
>Reporter: Rohit Yadav
>Priority: Minor
> Fix For: Future
>
>
> In case KVM hosts have same hostname but different libvirtd host uuid or IPs, 
> VM migration fails with:
> 2015-02-04 15:22:18,042 ERROR [c.c.v.VmWorkJobDispatcher] 
> (Work-Job-Executor-13:ctx-ae4c1ba1 job-37/job-38) Unable to complete 
> AsyncJobVO {id:38, userId: 2, accountId: 2, instanceType: null, instanceId: 
> null, cmd: com.cloud.vm.VmWorkMigrate, cmdInfo: 
> rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAA3QAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXNxAH4ABwACcQB-AAlwcQB-AAk,
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 5071960016, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: Wed Feb 04 15:22:15 IST 2015}, job origin:37
> com.cloud.utils.exception.CloudRuntimeException: 
> org.libvirt.LibvirtException: internal error: Attempt to migrate guest to the 
> same host kvm-test 
> >---at 
> >com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1956)
> >---at 
> >com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:1854)
> >---at 
> >com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:4501)
> >---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)   
> > 
> >---at 
> >com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> >---at 
> >com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4633)
> >---at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103)  
> >
> >---at 
> >org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:536)
> >---at 
> >org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> >---at 
> >org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> >---at 
> >org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> >---at 
> >org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> >---at 
> >org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> >---at 
> >org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:493)
> >---at 
> >java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> >---at java.util.concurrent.FutureTask.run(FutureTask.java:262)   
> > 
> >---at 
> >java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> >---at 
> >java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >---at java.lang.Thread.run(Thread.java:745)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CLOUDSTACK-8321) Make Python based password server IPv6 friendly

[Rohit Yadav (JIRA)]

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

Rohit Yadav reassigned CLOUDSTACK-8321:
---

Assignee: (was: Rohit Yadav)

> Make Python based password server IPv6 friendly
> ---
>
> Key: CLOUDSTACK-8321
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8321
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
> Fix For: Future
>
>
> The Python based password server need to support/listen on IPv6 addresses.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CLOUDSTACK-8322) Make Python based password server use SSL cert and listen on secure socket (443, or 4443) if enabled by admin

[Rohit Yadav (JIRA)]

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

Rohit Yadav reassigned CLOUDSTACK-8322:
---

Assignee: (was: Rohit Yadav)

> Make Python based password server use SSL cert and listen on secure socket 
> (443, or 4443) if enabled by admin
> -
>
> Key: CLOUDSTACK-8322
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8322
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
> Fix For: Future
>
>
> VR can pick same SSL cert used for CPVM/SSVM and use that to listen on a 
> secure socket (along with the HTTP port) to serve password.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CLOUDSTACK-7049) APIs return sensitive information which CloudStack does not manage and which caller did not request

[Rohit Yadav (JIRA)]

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

Rohit Yadav reassigned CLOUDSTACK-7049:
---

Assignee: (was: Rohit Yadav)

> APIs return sensitive information which CloudStack does not manage and which 
> caller did not request
> ---
>
> Key: CLOUDSTACK-7049
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7049
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.4.0
>Reporter: Demetrius Tsitrelis
>Priority: Critical
>  Labels: security
> Fix For: 4.5.3
>
>
> CloudStack stores sensitive information such as passwords and keys.  Some of 
> this information it creates such as the users’ secret keys.  Admins configure 
> CloudStack with the other types of sensitive information such as host 
> passwords, S3 secret keys, etc.
>  
> There are two problems with the way the API returns sensitive information:
> 1)  Many of the APIs return the entire state of the modified object on 
> which they operate.  For example, if the API to remove a NIC from a VM is 
> called then the response returns the VM password even though the caller did 
> not ask for it.
> 2)  Some of the APIs return sensitive information which is not created 
> nor managed by CloudStack.  For instance, the listS3s API returns the S3 
> secret key.  There doesn’t seem to be any legitimate use case for returning 
> this category of information; this type of sensitive data could go into 
> CloudStack for its internal use but should not come out via the API (i.e., 
> CloudStack is not a password manager app!).
> Substantial changes cannot be made to the API without bumping the API 
> version.  A near-term mitigation for these problems then is simply to return 
> empty strings in the response for the sensitive information which is not 
> requested or which is not managed by CloudStack.  So for the 
> removeNicFromVirtualMachine API, for instance, return an empty string for the 
> "password" value.  A caller could still use getVMPassword to obtain the 
> password if he needed it since it is CloudStack which generated the VM 
> password.  For the S3 case, ALWAYS return an empty value for the S3 secret 
> key since that key is managed by Amazon and not CloudStack.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CLOUDSTACK-9542) listNics API does not return data as per API documentation

[Rohit Yadav (JIRA)]

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

Rohit Yadav reassigned CLOUDSTACK-9542:
---

Assignee: Daan Hoogland  (was: Rohit Yadav)

> listNics API does not return data as per API documentation
> --
>
> Key: CLOUDSTACK-9542
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9542
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.5.2, 4.6.2
> Environment: ACS
>Reporter: Paul Angus
>Assignee: Daan Hoogland
> Fix For: 4.9.2.0, 4.9.1.0, 4.10.1.0
>
>
> Using both Chrome developer tools ans Cloudmonkey to confirm API responses, 
> listNics returns a subset of the NIC information. (as specified in the API 
> documentation)
> {"listnicsresponse":{"count":1,"nic":[{"id":"fbbe345b-6cbd-495f-8e27-d180d782ccbe","networkid":"30002db2-be52-489f-8307-5c2fbcbea374","netmask":"255.255.255.0","gateway":"10.5.1.254","ipaddress":"10.5.1.107","isdefault":true,"macaddress":"06:39:9c:01:0a:5b","deviceid":"0","virtualmachineid":"c65e6c6a-1d9e-4812-89c7-2af2858af76b"}]}}
> However listVirtualMachines does return the full detail.
> {"listvirtualmachinesresponse":{"count":1,"virtualmachine":[{"id":"c65e6c6a-1d9e-4812-89c7-2af2858af76b","name":"sbjenkins-cattle1","displayname":"sbjenkins-cattle1","account":"ryadav","domainid":"5dfaa086-6a9c-11e6-8ec0-0050568ef122","domain":"ROOT","created":"2016-09-09T01:44:25+0100","state":"Running","haenable":false,"zoneid":"c852110c-e1b5-4c8c-9e3d-f2a6e76b8fc0","zonename":"SBLAB-SW19-1","hostid":"fff7cdce-9d1d-408c-a37a-68e19113c092","hostname":"10.2.0.22","guestosid":"0372db46-6a9d-11e6-8ec0-0050568ef122","securitygroup":[],-->>
> "nic":[{"id":"fbbe345b-6cbd-495f-8e27-d180d782ccbe","networkid":"30002db2-be52-489f-8307-5c2fbcbea374","networkname":"JenkinsNet","netmask":"255.255.255.0","gateway":"10.5.1.254","ipaddress":"10.5.1.107","isolationuri":"vlan://12","broadcasturi":"vlan://12","traffictype":"Guest","type":"Shared","isdefault":true,"macaddress":"06:39:9c:01:0a:5b"}],
> <<--"hypervisor":"VMware","instancename":"i-15-93-VM","tags":[],"affinitygroup":[],"displayvm":true,"isdynamicallyscalable":false,"ostypeid":254}]}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-9952) Impossible to reuse the name of a deleted role

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-9952.
-
Resolution: Fixed

Fixed recently

> Impossible to reuse the name of a deleted role
> --
>
> Key: CLOUDSTACK-9952
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9952
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rohit Yadav
>
> It is impossible to reuse the name of a deleted role.
> Steps to reproduce:
> - create a role called "X"
> - delete "X"
> - create a new role called "X"
> It should be possible to recreate it, but it turns out it is not because in 
> the DB there is a compound key between type and role name. We need to fix 
> that to allow the reuse of names of deleted roles



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-9838) When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP IPs (normal VR)

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-9838.
-
Resolution: Fixed

> When 2 VMs have SNAT IPs assigned, they cannot communicate with each other 
> via the SNAP IPs (normal VR)
> ---
>
> Key: CLOUDSTACK-9838
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9838
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.2, 4.7.1, 4.10.0.0, 4.9.2.0, 4.8.1.1
>Reporter: Paul Angus
>Assignee: Rohit Yadav
>Priority: Minor
>
> When 2 VMs have SNAT IPs (on different public subnets) assigned, they cannot 
> communicate with each other via the SNAP IPs. 
> Traffic flows over the SNAT IPs successfully to/from external networks/IPs
> using iptables -t mangle -vL 
> from ACS 4.5
> established connections are ACCEPTed and are at the top of the order.  RETURN 
> happens later.
> Chain FIREWALL_10.1.35.23 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> 0 0 RETURN icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
> 0 0 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
> 0 0 DROP   all  --  anyany anywhere anywhere
> using ACS 4.9
> the ACCEPT of established connections is at the END after the RETURN and so 
> inspections don't get as far as the ACCEPT
> Chain FIREWALL_10.1.64.9 (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 0 0 ACCEPT icmp --  anyany anywhere anywhere  
>icmptype 8 code 0
>39  3002 RETURN tcp  --  anyany anywhere anywhere  
>tcp dpt:http
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
>   397 40700 DROP   all  --  anyany anywhere anywhere
> moving
>  4921 4906K ACCEPT all  --  anyany anywhere anywhere  
>state RELATED,ESTABLISHED
> to the top of this section resolves the issues and traffic can flow over the 
> SNAT IPs.
> I believe that this only affects 'hairpin nat' traffic as it is in the mangle 
> table



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-9983) Don't return username/password details in the listClusters response

[Rohit Yadav (JIRA)]

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

Rohit Yadav resolved CLOUDSTACK-9983.
-
Resolution: Fixed

> Don't return username/password details in the listClusters response
> ---
>
> Key: CLOUDSTACK-9983
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9983
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.1.0, 4.9.3.0
>
>
> The listClusters API response may contain VMware dc username/password as part 
> of its details. The response should not expose this details.
> https://github.com/apache/cloudstack/pull/2166



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)