[jira] [Commented] (CLOUDSTACK-9653) listCapacity API shows incorrect output when sortBy=usage option is added

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9653:
-

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1819
  
@blueorangutan test


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> listCapacity API shows incorrect output when sortBy=usage option is added
> -
>
> Key: CLOUDSTACK-9653
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9653
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.6.0, 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.9.1.0
>
>
> listCapacity API does not sum up values correctly when used with sortBy=usage 
> option.



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

[jira] [Commented] (CLOUDSTACK-9653) listCapacity API shows incorrect output when sortBy=usage option is added

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9653:
-

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1819
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> listCapacity API shows incorrect output when sortBy=usage option is added
> -
>
> Key: CLOUDSTACK-9653
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9653
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.6.0, 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.9.1.0
>
>
> listCapacity API does not sum up values correctly when used with sortBy=usage 
> option.



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

[jira] [Commented] (CLOUDSTACK-9653) listCapacity API shows incorrect output when sortBy=usage option is added

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9653:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1819
  
@blueorangutan test


> listCapacity API shows incorrect output when sortBy=usage option is added
> -
>
> Key: CLOUDSTACK-9653
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9653
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.6.0, 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.9.1.0
>
>
> listCapacity API does not sum up values correctly when used with sortBy=usage 
> option.



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

[jira] [Commented] (CLOUDSTACK-9653) listCapacity API shows incorrect output when sortBy=usage option is added

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9653:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1819
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


> listCapacity API shows incorrect output when sortBy=usage option is added
> -
>
> Key: CLOUDSTACK-9653
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9653
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.6.0, 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.9.1.0
>
>
> listCapacity API does not sum up values correctly when used with sortBy=usage 
> option.



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

[jira] [Commented] (CLOUDSTACK-9736) Incoherent validation and error message when you change the vm.password.length configuration parameter

[Sachin (JIRA)]

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

Sachin commented on CLOUDSTACK-9736:


I tried to change the  vm.password.length  parameter to 8 the output was

"Please restart your management server(s) for your new settings to take effect."
Can you please tell me how did you get the error??

> Incoherent validation and error message when you change the 
> vm.password.length configuration parameter
> --
>
> Key: CLOUDSTACK-9736
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9736
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.7.0, 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Milamber
>Assignee: Milamber
>Priority: Minor
> Fix For: 4.10.0.0
>
>
> When you try to change the value of vm.password.length parameters, if the 
> value is < 10 the error message says:
> "Please enter a value greater than 6 for the configuration parameter"
> In the code server/src/com/cloud/configuration/ConfigurationManagerImpl.java 
> the validation use 10 as length and the message says 6 for length:
> if ("vm.password.length".equalsIgnoreCase(name) && val < 10) {
> throw new InvalidParameterValueException("Please enter a 
> value greater than 6 for the configuration parameter:" + name);



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

[jira] [Commented] (CLOUDSTACK-9653) listCapacity API shows incorrect output when sortBy=usage option is added

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9653:
-

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1819
  
Packaging result: ✔centos6 ✔centos7 ✖debian. JID-458


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> listCapacity API shows incorrect output when sortBy=usage option is added
> -
>
> Key: CLOUDSTACK-9653
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9653
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.6.0, 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.9.1.0
>
>
> listCapacity API does not sum up values correctly when used with sortBy=usage 
> option.



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

[jira] [Commented] (CLOUDSTACK-9653) listCapacity API shows incorrect output when sortBy=usage option is added

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9653:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1819
  
Packaging result: ✔centos6 ✔centos7 ✖debian. JID-458


> listCapacity API shows incorrect output when sortBy=usage option is added
> -
>
> Key: CLOUDSTACK-9653
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9653
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.6.0, 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.9.1.0
>
>
> listCapacity API does not sum up values correctly when used with sortBy=usage 
> option.



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

[jira] [Commented] (CLOUDSTACK-9653) listCapacity API shows incorrect output when sortBy=usage option is added

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9653:
-

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1819
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> listCapacity API shows incorrect output when sortBy=usage option is added
> -
>
> Key: CLOUDSTACK-9653
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9653
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.6.0, 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.9.1.0
>
>
> listCapacity API does not sum up values correctly when used with sortBy=usage 
> option.



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

[jira] [Commented] (CLOUDSTACK-9653) listCapacity API shows incorrect output when sortBy=usage option is added

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9653:
-

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1819
  
@blueorangutan package


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> listCapacity API shows incorrect output when sortBy=usage option is added
> -
>
> Key: CLOUDSTACK-9653
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9653
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.6.0, 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.9.1.0
>
>
> listCapacity API does not sum up values correctly when used with sortBy=usage 
> option.



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

[jira] [Commented] (CLOUDSTACK-9653) listCapacity API shows incorrect output when sortBy=usage option is added

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9653:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1819
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> listCapacity API shows incorrect output when sortBy=usage option is added
> -
>
> Key: CLOUDSTACK-9653
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9653
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.6.0, 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.9.1.0
>
>
> listCapacity API does not sum up values correctly when used with sortBy=usage 
> option.



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

[jira] [Commented] (CLOUDSTACK-9653) listCapacity API shows incorrect output when sortBy=usage option is added

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9653:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1819
  
@blueorangutan package


> listCapacity API shows incorrect output when sortBy=usage option is added
> -
>
> Key: CLOUDSTACK-9653
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9653
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.6.0, 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.9.1.0
>
>
> listCapacity API does not sum up values correctly when used with sortBy=usage 
> option.



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

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

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9710:
-

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1888
  
@swill I use these docker images for building packages, they have jenv and 
everything else setup: https://hub.docker.com/u/bhaisaab

Don't use jenv's initialization in .bashrc or .profile, but do that in your 
Jenkins script:

export PATH="$HOME/.jenv/bin:$PATH"
eval "$(jenv init -)"
java -version
mvn -version

For using my CentOS6 image, you'll need to export this:
# Enable maven on bash
export 
PATH=/opt/rh/maven30/root/usr/bin:/opt/rh/rh-java-common/root/usr/bin:$PATH



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> 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.0.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9710:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1888
  
@swill I use these docker images for building packages, they have jenv and 
everything else setup: https://hub.docker.com/u/bhaisaab

Don't use jenv's initialization in .bashrc or .profile, but do that in your 
Jenkins script:

export PATH="$HOME/.jenv/bin:$PATH"
eval "$(jenv init -)"
java -version
mvn -version

For using my CentOS6 image, you'll need to export this:
# Enable maven on bash
export 
PATH=/opt/rh/maven30/root/usr/bin:/opt/rh/rh-java-common/root/usr/bin:$PATH



> 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.0.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



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

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

[Will Stevens (JIRA)]

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

Will Stevens commented on CLOUDSTACK-9710:
--

I have that on my dev environment, but not on my jenkins slaves...  It
works great in dev once you figure out how to get the JAVA_HOME to get set
correctly.

I had to create a file: ~./mavenrc
With the following in it to get everything working.

JAVA_HOME=$(/usr/libexec/java_home -v $(jenv version-name))

*Will STEVENS*
Lead Developer






> 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.0.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



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

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

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9710:
-

Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1888
  
@swill yes, please install both jdk7 and jdk8, and setup `jenv` 
http://www.jenv.be


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> 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.0.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9710:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1888
  
@swill yes, please install both jdk7 and jdk8, and setup `jenv` 
http://www.jenv.be


> 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.0.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9710:


Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1888
  
BTW, something that is worth noting is that even if you use a new system vm 
template, but the box that the vm template was built on is running Java 7, you 
will get the same error that @syed just reported.  I forgot to update my 
Jenkins slave to use Java 8 and I was able to reproduce the problem that @syed 
experienced with new builds of the system vm template.  Maybe we should try to 
put a check or something if you try to build the system vm template with the 
wrong version.  I am sure people will run into this because almost everyone 
will be using Java 7 in their Jenkins for previous ACS builds and I am sure 
others will forget to make the change to use Java 8 for those builds.  

Building the ACS RPMs will fail if you don't have Java 8 installed, but the 
system VM build will succeed even though the resulting template will not be 
functional...


> 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.0.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



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

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

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9710:
-

Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1888
  
BTW, something that is worth noting is that even if you use a new system vm 
template, but the box that the vm template was built on is running Java 7, you 
will get the same error that @syed just reported.  I forgot to update my 
Jenkins slave to use Java 8 and I was able to reproduce the problem that @syed 
experienced with new builds of the system vm template.  Maybe we should try to 
put a check or something if you try to build the system vm template with the 
wrong version.  I am sure people will run into this because almost everyone 
will be using Java 7 in their Jenkins for previous ACS builds and I am sure 
others will forget to make the change to use Java 8 for those builds.  

Building the ACS RPMs will fail if you don't have Java 8 installed, but the 
system VM build will succeed even though the resulting template will not be 
functional...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> 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.0.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9710:


Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1888
  
@syed if you have not built the system vm templates yet, here are a couple 
built from master today for XenServer and KVM.

**XenServer**
Name: systemvm-xenserver-4.10.0
Description: systemvm-xenserver-4.10.0
URL: 
http://objects-east.cloud.ca/v1/29a3d8ee6d4048b7b20d3ca820146a35/systemvm/build-systemvm64-PR_42/systemvm64template-master-4.10.0-xen.vhd.bz2
Zone: Choose the zone where this hypervisor is used
Hypervisor: XenServer
Format: VHD
OS Type: Debian GNU/Linux 7.x (64-bit)
Extractable: no
Password Enabled: no
Public: no
Featured: no
Routing: no

**KVM**
Name: systemvm-kvm-4.10.0
Description: systemvm-kvm-4.10.0
URL: 
http://objects-east.cloud.ca/v1/29a3d8ee6d4048b7b20d3ca820146a35/systemvm/build-systemvm64-PR_42/systemvm64template-master-4.10.0-kvm.qcow2.bz2
Zone: Choose the zone where this hypervisor is used
Hypervisor: KVM
Format: QCOW2
OS Type: Debian GNU/Linux 7.x (64-bit)
Extractable: no
Password Enabled: no
Public: no
Featured: no
Routing: no


> 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.0.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



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

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

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9710:
-

Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1888
  
@syed if you have not built the system vm templates yet, here are a couple 
built from master today for XenServer and KVM.

**XenServer**
Name: systemvm-xenserver-4.10.0
Description: systemvm-xenserver-4.10.0
URL: 
http://objects-east.cloud.ca/v1/29a3d8ee6d4048b7b20d3ca820146a35/systemvm/build-systemvm64-PR_42/systemvm64template-master-4.10.0-xen.vhd.bz2
Zone: Choose the zone where this hypervisor is used
Hypervisor: XenServer
Format: VHD
OS Type: Debian GNU/Linux 7.x (64-bit)
Extractable: no
Password Enabled: no
Public: no
Featured: no
Routing: no

**KVM**
Name: systemvm-kvm-4.10.0
Description: systemvm-kvm-4.10.0
URL: 
http://objects-east.cloud.ca/v1/29a3d8ee6d4048b7b20d3ca820146a35/systemvm/build-systemvm64-PR_42/systemvm64template-master-4.10.0-kvm.qcow2.bz2
Zone: Choose the zone where this hypervisor is used
Hypervisor: KVM
Format: QCOW2
OS Type: Debian GNU/Linux 7.x (64-bit)
Extractable: no
Password Enabled: no
Public: no
Featured: no
Routing: no


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> 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.0.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



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

[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9729:
-

Github user krissterckx commented on the issue:

https://github.com/apache/cloudstack/pull/1904
  
LGTM


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to 
> com.amazonaws.util.json.JSONException
> ---
>
> Key: CLOUDSTACK-9729
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Kris Sterckx
>Assignee: Frank Maximus
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> https://github.com/apache/cloudstack/pull/1638 has moved from
> {noformat}
> 1.10.64
> {noformat}
> to
> {noformat}
> 1.11.61
> {noformat}
> which breaks the use of com.amazonaws.util.json.JSONException
> This breaks Nuage VSP network plugin as of its dependency to 
> {noformat}
>   net.nuagenetworks.vsp
>   nuage-vsp-acs-client
>   1.0.0
> {noformat} 
>  
> We need to fix that.



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

[jira] [Commented] (CLOUDSTACK-9729) Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to com.amazonaws.util.json.JSONException

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9729:


Github user krissterckx commented on the issue:

https://github.com/apache/cloudstack/pull/1904
  
LGTM


> Spring 4.x support PR-1638 broke Nuage VSP plugin as of dependency to 
> com.amazonaws.util.json.JSONException
> ---
>
> Key: CLOUDSTACK-9729
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9729
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Kris Sterckx
>Assignee: Frank Maximus
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> https://github.com/apache/cloudstack/pull/1638 has moved from
> {noformat}
> 1.10.64
> {noformat}
> to
> {noformat}
> 1.11.61
> {noformat}
> which breaks the use of com.amazonaws.util.json.JSONException
> This breaks Nuage VSP network plugin as of its dependency to 
> {noformat}
>   net.nuagenetworks.vsp
>   nuage-vsp-acs-client
>   1.0.0
> {noformat} 
>  
> We need to fix that.



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

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

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9710:
-

Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1888
  
This is supposed to do it @syed: 
https://github.com/apache/cloudstack/pull/1888/files#diff-e8e4d31bb5d860c8e7ada3120f758ee9R98

You built a new system VM template or used a new one provided by one of the 
mirrors?  You have to change the global config to make the new template the 
default and restart ACS in order for it to be used by default.

Here are the global configs for the different hypervisors:
router.template.hyperv
router.template.kvm
router.template.lxc
router.template.ovm3
router.template.vmware
router.template.xenserver

Let us know...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> 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.0.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9710:


Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1888
  
This is supposed to do it @syed: 
https://github.com/apache/cloudstack/pull/1888/files#diff-e8e4d31bb5d860c8e7ada3120f758ee9R98

You built a new system VM template or used a new one provided by one of the 
mirrors?  You have to change the global config to make the new template the 
default and restart ACS in order for it to be used by default.

Here are the global configs for the different hypervisors:
router.template.hyperv
router.template.kvm
router.template.lxc
router.template.ovm3
router.template.vmware
router.template.xenserver

Let us know...


> 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.0.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



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

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

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9710:
-

Github user milamberspace commented on the issue:

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

Yes you need a new systemvm with Java 8 too.

See: http://markmail.org/thread/lj7simcdfynti2ml

(you can build your own systemvm, see:
https://github.com/apache/cloudstack/blob/master/tools/appliance/README.md )


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> 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.0.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9710:


Github user milamberspace commented on the issue:

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

Yes you need a new systemvm with Java 8 too.

See: http://markmail.org/thread/lj7simcdfynti2ml

(you can build your own systemvm, see:
https://github.com/apache/cloudstack/blob/master/tools/appliance/README.md )


> 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.0.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



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

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

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9710:
-

Github user syed commented on the issue:

https://github.com/apache/cloudstack/pull/1888
  
@rhtyd I tried building the latest master I have problems getting the SSVM 
and the console proxy up. I get the following error 

```
4 localgw=172.31.0.1 private.network.device=eth1 internaldns1=8.8.8.8 
dns1=8.8.8.8 nfsVersion=null
Exception in thread "main" java.lang.UnsupportedClassVersionError: 
com/cloud/agent/AgentShell : Unsupported major.minor version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at 
sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
```

The management server is running Java 8 but it looks like the systemvms are 
still running java 7. How can I upgrade the java version there? 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> 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.0.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9710:


Github user syed commented on the issue:

https://github.com/apache/cloudstack/pull/1888
  
@rhtyd I tried building the latest master I have problems getting the SSVM 
and the console proxy up. I get the following error 

```
4 localgw=172.31.0.1 private.network.device=eth1 internaldns1=8.8.8.8 
dns1=8.8.8.8 nfsVersion=null
Exception in thread "main" java.lang.UnsupportedClassVersionError: 
com/cloud/agent/AgentShell : Unsupported major.minor version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at 
sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
```

The management server is running Java 8 but it looks like the systemvms are 
still running java 7. How can I upgrade the java version there? 


> 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.0.0
>
>
> Switch to using JDK1.8 by default for building and running CloudStack.



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

[jira] [Commented] (CLOUDSTACK-9405) listDomains API call takes an extremely long time to respond

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9405:
-

Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1901
  
Thanks @ustcweizhou LGTM for code review


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> listDomains API call takes an extremely long time to respond
> 
>
> Key: CLOUDSTACK-9405
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9405
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.8.0
>Reporter: dsclose
>  Labels: performance
>
> We recently upgraded from Cloudstack 4.5.2 to Cloudstack 4.8.0. Since this 
> update, the listDomains API call has started taking an extremely long time to 
> respond. This has caused issues with our services that rely on this API call. 
> Initially they simply timed out until we increased the thresholds. Now we 
> have processes that used to take a few seconds taking many minutes.
> This is so problematic for us that our organisation has put a halt on further 
> updates of Cloudstack 4.5.2 installations. If reversing the update of zones 
> already on 4.8.0 was feasible, we would have reverted back to 4.5.2.
> Here is a table of the times we're seeing:
> ||CS Version||Domain Count||API Response Time||
> |4.5.2|251|~3s|
> |4.8.0|182|~26s|
> |4.8.0|<10|<1s|
> This small data sample indicates that the response time for zones with a 
> larger amount of domains is significantly worse after the update to 4.8.0. 
> Zones with few domains aren't able to reproduce this issue.
> I recall a bug being resolved recently that concerned reducing the response 
> time for list* API calls. I also recall [~remibergsma] resolving a bug 
> concerning the sorting of the listDomains response. Is it possible that these 
> issues are connected?



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

[jira] [Commented] (CLOUDSTACK-9405) listDomains API call takes an extremely long time to respond

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9405:


Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1901
  
Thanks @ustcweizhou LGTM for code review


> listDomains API call takes an extremely long time to respond
> 
>
> Key: CLOUDSTACK-9405
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9405
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.8.0
>Reporter: dsclose
>  Labels: performance
>
> We recently upgraded from Cloudstack 4.5.2 to Cloudstack 4.8.0. Since this 
> update, the listDomains API call has started taking an extremely long time to 
> respond. This has caused issues with our services that rely on this API call. 
> Initially they simply timed out until we increased the thresholds. Now we 
> have processes that used to take a few seconds taking many minutes.
> This is so problematic for us that our organisation has put a halt on further 
> updates of Cloudstack 4.5.2 installations. If reversing the update of zones 
> already on 4.8.0 was feasible, we would have reverted back to 4.5.2.
> Here is a table of the times we're seeing:
> ||CS Version||Domain Count||API Response Time||
> |4.5.2|251|~3s|
> |4.8.0|182|~26s|
> |4.8.0|<10|<1s|
> This small data sample indicates that the response time for zones with a 
> larger amount of domains is significantly worse after the update to 4.8.0. 
> Zones with few domains aren't able to reproduce this issue.
> I recall a bug being resolved recently that concerned reducing the response 
> time for list* API calls. I also recall [~remibergsma] resolving a bug 
> concerning the sorting of the listDomains response. Is it possible that these 
> issues are connected?



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

[jira] [Commented] (CLOUDSTACK-9738) Optimize vm expunge process for instances with vm snapshots

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9738:
-

GitHub user nvazquez opened a pull request:

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

CLOUDSTACK-9738: Optimize vm expunge process for instances with vm snapshots

## Description
It was noticed that expunging instances with many vm snapshots took a look 
of time, as hypervisor received as many tasks as vm snapshots instance had, 
apart from the delete vm task. We propose a way to optimize this process for 
instances with vm snapshots by sending only one delete task to hypervisor, 
which will delete vm and its snapshots

## Use cases

1. deleteVMsnapohsot-> no changes to current behavior
2. destroyVM with expunge=false ->  no actions to VMsnaphsot is performed 
at the moment. When VM cleanup thread is executed it will perform the same 
sequence as (3). If instance is recovered before expunged by the cleanup thread 
it will remain intact with VMSnapshot chain present
3. destroyVM with expunge=true:
   * Vmsnaphsot is marked with removed timestamp and state = Expunging in DB
   * VM is deleted in HW

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

$ git pull https://github.com/nvazquez/cloudstack expungeVmRefactor

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

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


commit f5bebb172c36710a3c795a0df542fe443c71a2c9
Author: nvazquez 
Date:   2017-01-09T20:08:32Z

CLOUDSTACK-9738: Optimize vm expunge process for instances with vm snapshots




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> Optimize vm expunge process for instances with vm snapshots
> ---
>
> Key: CLOUDSTACK-9738
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9738
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Description
> It was noticed that expunging instances with many vm snapshots took a look of 
> time, as hypervisor received as many tasks as vm snapshots instance had, 
> apart from the delete vm task. We propose a way to optimize this process for 
> instances with vm snapshots by sending only one delete task to hypervisor, 
> which will delete vm and its snapshots
> h2. Use cases
> # deleteVMsnapohsot-> no changes to current behavior
> # destroyVM with expunge=false ->  no actions to VMsnaphsot is performed at 
> the moment. When VM cleanup thread is executed it will perform the same 
> sequence as #3. If instance is recovered before expunged by the cleanup 
> thread it will remain intact with VMSnapshot chain present
> # destroyVM with expunge=true:
> #*   Vmsnaphsot is  marked with removed timestamp and state = Expunging 
> in DB
> #*   VM is deleted in HW



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

[jira] [Commented] (CLOUDSTACK-9738) Optimize vm expunge process for instances with vm snapshots

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9738:


GitHub user nvazquez opened a pull request:

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

CLOUDSTACK-9738: Optimize vm expunge process for instances with vm snapshots

## Description
It was noticed that expunging instances with many vm snapshots took a look 
of time, as hypervisor received as many tasks as vm snapshots instance had, 
apart from the delete vm task. We propose a way to optimize this process for 
instances with vm snapshots by sending only one delete task to hypervisor, 
which will delete vm and its snapshots

## Use cases

1. deleteVMsnapohsot-> no changes to current behavior
2. destroyVM with expunge=false ->  no actions to VMsnaphsot is performed 
at the moment. When VM cleanup thread is executed it will perform the same 
sequence as (3). If instance is recovered before expunged by the cleanup thread 
it will remain intact with VMSnapshot chain present
3. destroyVM with expunge=true:
   * Vmsnaphsot is marked with removed timestamp and state = Expunging in DB
   * VM is deleted in HW

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

$ git pull https://github.com/nvazquez/cloudstack expungeVmRefactor

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

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


commit f5bebb172c36710a3c795a0df542fe443c71a2c9
Author: nvazquez 
Date:   2017-01-09T20:08:32Z

CLOUDSTACK-9738: Optimize vm expunge process for instances with vm snapshots




> Optimize vm expunge process for instances with vm snapshots
> ---
>
> Key: CLOUDSTACK-9738
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9738
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Description
> It was noticed that expunging instances with many vm snapshots took a look of 
> time, as hypervisor received as many tasks as vm snapshots instance had, 
> apart from the delete vm task. We propose a way to optimize this process for 
> instances with vm snapshots by sending only one delete task to hypervisor, 
> which will delete vm and its snapshots
> h2. Use cases
> # deleteVMsnapohsot-> no changes to current behavior
> # destroyVM with expunge=false ->  no actions to VMsnaphsot is performed at 
> the moment. When VM cleanup thread is executed it will perform the same 
> sequence as #3. If instance is recovered before expunged by the cleanup 
> thread it will remain intact with VMSnapshot chain present
> # destroyVM with expunge=true:
> #*   Vmsnaphsot is  marked with removed timestamp and state = Expunging 
> in DB
> #*   VM is deleted in HW



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

[jira] [Updated] (CLOUDSTACK-9738) Optimize vm expunge process for instances with vm snapshots

[Nicolas Vazquez (JIRA)]

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

Nicolas Vazquez updated CLOUDSTACK-9738:

Description: 
h2. Description
It was noticed that expunging instances with many vm snapshots took a look of 
time, as hypervisor received as many tasks as vm snapshots instance had, apart 
from the delete vm task. We propose a way to optimize this process for 
instances with vm snapshots by sending only one delete task to hypervisor, 
which will delete vm and its snapshots

h2. Use cases

# deleteVMsnapohsot-> no changes to current behavior
# destroyVM with expunge=false ->  no actions to VMsnaphsot is performed at the 
moment. When VM cleanup thread is executed it will perform the same sequence as 
#3. If instance is recovered before expunged by the cleanup thread it will 
remain intact with VMSnapshot chain present
# destroyVM with expunge=true:
#*   Vmsnaphsot is  marked with removed timestamp and state = Expunging in 
DB
#*   VM is deleted in HW

  was:
h2. Description
It was noticed that expunging instances with many vm snapshots took a look of 
time, as hypervisor received as many tasks as vm snapshots instance had, apart 
from the delete vm task. We propose a way to optimize this process for 
instances with vm snapshots by sending only one delete task to hypervisor, 
which will delete vm and its snapshots

h2. Use cases

- deleteVMsnapohsot-> no changes to current behavior
- destroyVM with expunge=false ->  no actions to VMsnaphsot is performed at the 
moment. When VM cleanup thread is executed it will perform the same sequence as 
#3. If instance is recovered before expunged by the cleanup thread it will 
remain intact with VMSnapshot chain present
3.   If deleteVM is called with expunge=true  , then
a.   Vmsnaphsot is  marked with removed timestamp and state = Expunging in 
DB
b.   VM is deleted in HW


> Optimize vm expunge process for instances with vm snapshots
> ---
>
> Key: CLOUDSTACK-9738
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9738
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Description
> It was noticed that expunging instances with many vm snapshots took a look of 
> time, as hypervisor received as many tasks as vm snapshots instance had, 
> apart from the delete vm task. We propose a way to optimize this process for 
> instances with vm snapshots by sending only one delete task to hypervisor, 
> which will delete vm and its snapshots
> h2. Use cases
> # deleteVMsnapohsot-> no changes to current behavior
> # destroyVM with expunge=false ->  no actions to VMsnaphsot is performed at 
> the moment. When VM cleanup thread is executed it will perform the same 
> sequence as #3. If instance is recovered before expunged by the cleanup 
> thread it will remain intact with VMSnapshot chain present
> # destroyVM with expunge=true:
> #*   Vmsnaphsot is  marked with removed timestamp and state = Expunging 
> in DB
> #*   VM is deleted in HW



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

[jira] [Commented] (CLOUDSTACK-9695) For VM in stopped state, disable "Snapshot Memory" option

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9695:
-

Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1852
  
why not change vmActionfilter in ui/scripts/instances.js ?
it will be much simple.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> For VM in stopped state, disable "Snapshot Memory" option
> -
>
> Key: CLOUDSTACK-9695
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9695
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.6.0, 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
>Priority: Minor
> Fix For: 4.10.0.0
>
>
> For a VM in stopped state, the UI for VM snapshot creation shows an option 
> for 'snapshot memory'. Since this is not a valid option at that point, it 
> should be disabled.



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

[jira] [Updated] (CLOUDSTACK-9738) Optimize vm expunge process for instances with vm snapshots

[Nicolas Vazquez (JIRA)]

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

Nicolas Vazquez updated CLOUDSTACK-9738:

Description: 
h2. Description
It was noticed that expunging instances with many vm snapshots took a look of 
time, as hypervisor received as many tasks as vm snapshots instance had, apart 
from the delete vm task. We propose a way to optimize this process for 
instances with vm snapshots by sending only one delete task to hypervisor, 
which will delete vm and its snapshots

h2. Use cases

- deleteVMsnapohsot-> no changes to current behavior
- destroyVM with expunge=false ->  no actions to VMsnaphsot is performed at the 
moment. When VM cleanup thread is executed it will perform the same sequence as 
#3. If instance is recovered before expunged by the cleanup thread it will 
remain intact with VMSnapshot chain present
3.   If deleteVM is called with expunge=true  , then
a.   Vmsnaphsot is  marked with removed timestamp and state = Expunging in 
DB
b.   VM is deleted in HW

> Optimize vm expunge process for instances with vm snapshots
> ---
>
> Key: CLOUDSTACK-9738
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9738
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Description
> It was noticed that expunging instances with many vm snapshots took a look of 
> time, as hypervisor received as many tasks as vm snapshots instance had, 
> apart from the delete vm task. We propose a way to optimize this process for 
> instances with vm snapshots by sending only one delete task to hypervisor, 
> which will delete vm and its snapshots
> h2. Use cases
> - deleteVMsnapohsot-> no changes to current behavior
> - destroyVM with expunge=false ->  no actions to VMsnaphsot is performed at 
> the moment. When VM cleanup thread is executed it will perform the same 
> sequence as #3. If instance is recovered before expunged by the cleanup 
> thread it will remain intact with VMSnapshot chain present
> 3.   If deleteVM is called with expunge=true  , then
> a.   Vmsnaphsot is  marked with removed timestamp and state = Expunging 
> in DB
> b.   VM is deleted in HW



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

[jira] [Commented] (CLOUDSTACK-9695) For VM in stopped state, disable "Snapshot Memory" option

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9695:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1852
  
why not change vmActionfilter in ui/scripts/instances.js ?
it will be much simple.



> For VM in stopped state, disable "Snapshot Memory" option
> -
>
> Key: CLOUDSTACK-9695
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9695
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.6.0, 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
>Priority: Minor
> Fix For: 4.10.0.0
>
>
> For a VM in stopped state, the UI for VM snapshot creation shows an option 
> for 'snapshot memory'. Since this is not a valid option at that point, it 
> should be disabled.



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

[jira] [Commented] (CLOUDSTACK-9737) Ability to move VM to other project

[Wei Zhou (JIRA)]

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

Wei Zhou commented on CLOUDSTACK-9737:
--

I created a PR long time ago, which includes the fix to this.
https://github.com/apache/cloudstack/pull/844
[4.10] CLOUDSTACK-7985: assignVM in Advanced zone with Security Groups #844


> Ability to move VM to other project
> ---
>
> Key: CLOUDSTACK-9737
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9737
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Projects
>Reporter: Steven Segers
>
> A VM can be created inside a project or outside of a project. It is possible 
> to move a VM to another domain but not to add/remove it to/from a project or 
> move it from one project to another. It would be very practical if it was 
> possible to do this. This issue potentially relates to CLOUDSTACK-3613



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

[jira] [Created] (CLOUDSTACK-9738) Optimize vm expunge process for instances with vm snapshots

[Nicolas Vazquez (JIRA)]

Nicolas Vazquez created CLOUDSTACK-9738:
---

 Summary: Optimize vm expunge process for instances with vm 
snapshots
 Key: CLOUDSTACK-9738
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9738
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.10.0.0
Reporter: Nicolas Vazquez
Assignee: Nicolas Vazquez
 Fix For: 4.10.0.0






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

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

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9136:
-

Github user ustcweizhou closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


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



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

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

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9136:
-

Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1212
  
rebased with apache/4.9, and added unit test


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


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



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

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

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9136:
-

GitHub user ustcweizhou reopened a pull request:

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

CLOUDSTACK-9136: remove ssh keypairs along with removing account

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


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

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

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

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

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

This closes #1212


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

CLOUDSTACK-9136: remove ssh keypairs along with removing account

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




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


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



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9136:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1212
  
rebased with apache/4.9, and added unit test


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



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9136:


GitHub user ustcweizhou reopened a pull request:

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

CLOUDSTACK-9136: remove ssh keypairs along with removing account

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


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

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

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

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

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

This closes #1212


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

CLOUDSTACK-9136: remove ssh keypairs along with removing account

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




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



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9136:


Github user ustcweizhou closed the pull request at:

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


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



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

[jira] [Created] (CLOUDSTACK-9737) Ability to move VM to other project

[Steven Segers (JIRA)]

Steven Segers created CLOUDSTACK-9737:
-

 Summary: Ability to move VM to other project
 Key: CLOUDSTACK-9737
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9737
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Projects
Reporter: Steven Segers


A VM can be created inside a project or outside of a project. It is possible to 
move a VM to another domain but not to add/remove it to/from a project or move 
it from one project to another. It would be very practical if it was possible 
to do this. This issue potentially relates to CLOUDSTACK-3613



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

[jira] [Commented] (CLOUDSTACK-9165) unable to use reserved IP range in a network for external VMs

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9165:
-

Github user SudharmaJain commented on the issue:

https://github.com/apache/cloudstack/pull/1246
  
Moved the getValidNetworkCidr to common class NetworkModel and Rebased with 
master.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> unable to use reserved IP range in a network for external VMs
> -
>
> Key: CLOUDSTACK-9165
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9165
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>




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

[jira] [Commented] (CLOUDSTACK-9165) unable to use reserved IP range in a network for external VMs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9165:


Github user SudharmaJain commented on the issue:

https://github.com/apache/cloudstack/pull/1246
  
Moved the getValidNetworkCidr to common class NetworkModel and Rebased with 
master.


> unable to use reserved IP range in a network for external VMs
> -
>
> Key: CLOUDSTACK-9165
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9165
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>




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

[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9317:
-

Github user jayapalu commented on the issue:

https://github.com/apache/cloudstack/pull/1450
  
@ProjectMoon 
I am working on it. I will be updating the fix.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply 
> IP associations method in the management server. The method is not 
> thread-safe. If it's called from multiple threads, each thread will load up 
> the list of public IPs in different states (add or revoke)--correct for the 
> thread, but not correct overall. Depending on execution order on the virtual 
> router, the router can end up with public IPs assigned to it that are not 
> supposed to be on it anymore. When another account acquires the same IP, this 
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all 
> recently released versions. Affected version is set to 4.7.x because that's 
> what we verified against.



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

[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9317:


Github user jayapalu commented on the issue:

https://github.com/apache/cloudstack/pull/1450
  
@ProjectMoon 
I am working on it. I will be updating the fix.


> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply 
> IP associations method in the management server. The method is not 
> thread-safe. If it's called from multiple threads, each thread will load up 
> the list of public IPs in different states (add or revoke)--correct for the 
> thread, but not correct overall. Depending on execution order on the virtual 
> router, the router can end up with public IPs assigned to it that are not 
> supposed to be on it anymore. When another account acquires the same IP, this 
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all 
> recently released versions. Affected version is set to 4.7.x because that's 
> what we verified against.



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

[jira] [Commented] (CLOUDSTACK-9653) listCapacity API shows incorrect output when sortBy=usage option is added

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9653:
-

Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1819
  
Code changes LGTM


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> listCapacity API shows incorrect output when sortBy=usage option is added
> -
>
> Key: CLOUDSTACK-9653
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9653
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.6.0, 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.9.1.0
>
>
> listCapacity API does not sum up values correctly when used with sortBy=usage 
> option.



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

[jira] [Commented] (CLOUDSTACK-9653) listCapacity API shows incorrect output when sortBy=usage option is added

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9653:


Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1819
  
Code changes LGTM


> listCapacity API shows incorrect output when sortBy=usage option is added
> -
>
> Key: CLOUDSTACK-9653
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9653
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.6.0, 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.9.1.0
>
>
> listCapacity API does not sum up values correctly when used with sortBy=usage 
> option.



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

[jira] [Commented] (CLOUDSTACK-9718) Revamp the dropdown showing lists of hosts available for migration in a Zone

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9718:
-

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

https://github.com/apache/cloudstack/pull/1889#discussion_r95973044
  
--- Diff: 
api/src/org/apache/cloudstack/api/command/admin/host/ListHostsCmd.java ---
@@ -206,7 +206,7 @@ public void execute() {
 } else {
 Pair, Integer> result;
 Ternary, Integer>, List, Map> hostsForMigration =
-_mgr.listHostsForMigrationOfVM(getVirtualMachineId(), 
this.getStartIndex(), this.getPageSizeVal());
+_mgr.listHostsForMigrationOfVM(getVirtualMachineId(), 
this.getStartIndex(), this.getPageSizeVal(), null);
--- End diff --

Why keyword is not used here? All API commands derived from BaseListCmd 
should have keyword.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> Revamp the dropdown showing lists of hosts available for migration in a Zone
> 
>
> Key: CLOUDSTACK-9718
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9718
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.10.0.0
>
> Attachments: MigrateInstance-SeeHosts.PNG, 
> MigrateInstance-SeeHosts-Search.PNG
>
>
> There are a couple of issues:
> 1. When looking for the possible hosts for migration, not all are displayed.
> 2. If there is a large number of hosts, then the drop down showing is not 
> easy to use.
> To fix this, propose to change the view to a list view which will show the 
> hosts in a list view with radio button. Additionally have a search option 
> where the hostname can be searched in this list to make it more usable.



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

[jira] [Commented] (CLOUDSTACK-9718) Revamp the dropdown showing lists of hosts available for migration in a Zone

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9718:
-

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

https://github.com/apache/cloudstack/pull/1889#discussion_r95973392
  
--- Diff: ui/scripts/ui-custom/migrate.js ---
@@ -0,0 +1,127 @@
+// Licensed to the Apache Software Foundation (ASF) under one
--- End diff --

For UI changes please provide UI screenshots


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> Revamp the dropdown showing lists of hosts available for migration in a Zone
> 
>
> Key: CLOUDSTACK-9718
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9718
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.10.0.0
>
> Attachments: MigrateInstance-SeeHosts.PNG, 
> MigrateInstance-SeeHosts-Search.PNG
>
>
> There are a couple of issues:
> 1. When looking for the possible hosts for migration, not all are displayed.
> 2. If there is a large number of hosts, then the drop down showing is not 
> easy to use.
> To fix this, propose to change the view to a list view which will show the 
> hosts in a list view with radio button. Additionally have a search option 
> where the hostname can be searched in this list to make it more usable.



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

[jira] [Commented] (CLOUDSTACK-9718) Revamp the dropdown showing lists of hosts available for migration in a Zone

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9718:


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

https://github.com/apache/cloudstack/pull/1889#discussion_r95973392
  
--- Diff: ui/scripts/ui-custom/migrate.js ---
@@ -0,0 +1,127 @@
+// Licensed to the Apache Software Foundation (ASF) under one
--- End diff --

For UI changes please provide UI screenshots


> Revamp the dropdown showing lists of hosts available for migration in a Zone
> 
>
> Key: CLOUDSTACK-9718
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9718
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.10.0.0
>
> Attachments: MigrateInstance-SeeHosts.PNG, 
> MigrateInstance-SeeHosts-Search.PNG
>
>
> There are a couple of issues:
> 1. When looking for the possible hosts for migration, not all are displayed.
> 2. If there is a large number of hosts, then the drop down showing is not 
> easy to use.
> To fix this, propose to change the view to a list view which will show the 
> hosts in a list view with radio button. Additionally have a search option 
> where the hostname can be searched in this list to make it more usable.



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

[jira] [Commented] (CLOUDSTACK-9718) Revamp the dropdown showing lists of hosts available for migration in a Zone

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9718:


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

https://github.com/apache/cloudstack/pull/1889#discussion_r95973044
  
--- Diff: 
api/src/org/apache/cloudstack/api/command/admin/host/ListHostsCmd.java ---
@@ -206,7 +206,7 @@ public void execute() {
 } else {
 Pair, Integer> result;
 Ternary, Integer>, List, Map> hostsForMigration =
-_mgr.listHostsForMigrationOfVM(getVirtualMachineId(), 
this.getStartIndex(), this.getPageSizeVal());
+_mgr.listHostsForMigrationOfVM(getVirtualMachineId(), 
this.getStartIndex(), this.getPageSizeVal(), null);
--- End diff --

Why keyword is not used here? All API commands derived from BaseListCmd 
should have keyword.


> Revamp the dropdown showing lists of hosts available for migration in a Zone
> 
>
> Key: CLOUDSTACK-9718
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9718
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.10.0.0
>
> Attachments: MigrateInstance-SeeHosts.PNG, 
> MigrateInstance-SeeHosts-Search.PNG
>
>
> There are a couple of issues:
> 1. When looking for the possible hosts for migration, not all are displayed.
> 2. If there is a large number of hosts, then the drop down showing is not 
> easy to use.
> To fix this, propose to change the view to a list view which will show the 
> hosts in a list view with radio button. Additionally have a search option 
> where the hostname can be searched in this list to make it more usable.



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

[jira] [Commented] (CLOUDSTACK-9693) Cluster status of an unmanaged cluster still shows enabled

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9693:
-

Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1848
  
@rashmidixit Please provide screenshots for UI changes (better if you also 
provide screenshot prior to the fix). Also for a cluster enabled/disabled and 
managed/unmanaged are different properties.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> Cluster status of an unmanaged cluster still shows enabled
> --
>
> Key: CLOUDSTACK-9693
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9693
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.1, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.9.1.0
>
>
> If you unmanage a cluster, Cluster view status remains Enabled.
> The status is successfully changed in cluster metrics page.
> It should show as red if the cluster is disabled.



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

[jira] [Commented] (CLOUDSTACK-9693) Cluster status of an unmanaged cluster still shows enabled

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9693:


Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1848
  
@rashmidixit Please provide screenshots for UI changes (better if you also 
provide screenshot prior to the fix). Also for a cluster enabled/disabled and 
managed/unmanaged are different properties.


> Cluster status of an unmanaged cluster still shows enabled
> --
>
> Key: CLOUDSTACK-9693
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9693
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.1, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
> Fix For: 4.9.1.0
>
>
> If you unmanage a cluster, Cluster view status remains Enabled.
> The status is successfully changed in cluster metrics page.
> It should show as red if the cluster is disabled.



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

[jira] [Commented] (CLOUDSTACK-9695) For VM in stopped state, disable "Snapshot Memory" option

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9695:


Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1852
  
@rashmidixit Code LGTM. Please provide screenshots of the changes.


> For VM in stopped state, disable "Snapshot Memory" option
> -
>
> Key: CLOUDSTACK-9695
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9695
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.6.0, 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
>Priority: Minor
> Fix For: 4.10.0.0
>
>
> For a VM in stopped state, the UI for VM snapshot creation shows an option 
> for 'snapshot memory'. Since this is not a valid option at that point, it 
> should be disabled.



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

[jira] [Commented] (CLOUDSTACK-9695) For VM in stopped state, disable "Snapshot Memory" option

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-9695:
-

Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1852
  
@rashmidixit Code LGTM. Please provide screenshots of the changes.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> For VM in stopped state, disable "Snapshot Memory" option
> -
>
> Key: CLOUDSTACK-9695
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9695
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.6.0, 4.7.0, 4.8.0, 4.9.0
>Reporter: Rashmi Dixit
>Assignee: Rashmi Dixit
>Priority: Minor
> Fix For: 4.10.0.0
>
>
> For a VM in stopped state, the UI for VM snapshot creation shows an option 
> for 'snapshot memory'. Since this is not a valid option at that point, it 
> should be disabled.



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

[jira] [Commented] (CLOUDSTACK-8958) add dedicated ips to domain

[rashmidixit (JIRA)]

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

rashmidixit commented on CLOUDSTACK-8958:
-

Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1357
  
rebased with 4.9.3,  and added unit tests (deleteDomain with/without 
cleanup).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


> add dedicated ips to domain
> ---
>
> Key: CLOUDSTACK-8958
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8958
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> add dedicated ips to domain 
> ips are dedicated to Account for now, so other customers and projects in the 
> same domain will use the system ip. this is not what we need.



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

[jira] [Commented] (CLOUDSTACK-8958) add dedicated ips to domain

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8958:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1357
  
rebased with 4.9.3,  and added unit tests (deleteDomain with/without 
cleanup).


> add dedicated ips to domain
> ---
>
> Key: CLOUDSTACK-8958
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8958
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> add dedicated ips to domain 
> ips are dedicated to Account for now, so other customers and projects in the 
> same domain will use the system ip. this is not what we need.



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