[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406828#comment-16406828 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-374707349 Trillian test result (tid-2396) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 32771 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2486-t2396-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_certauthority_root.py Intermitten failure detected: /marvin/tests/smoke/test_volumes.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py Smoke tests completed. 64 look OK, 3 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_11_migrate_volume_and_change_offering | `Error` | 131.28 | test_volumes.py test_04_rvpc_network_garbage_collector_nics | `Failure` | 537.61 | test_vpc_redundant.py test_hostha_enable_ha_when_host_in_maintenance | `Error` | 2.96 | test_hostha_kvm.py test_hostha_kvm_host_fencing | `Error` | 7.97 | test_hostha_kvm.py This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10332) Users are not able to change/edit the protocol of an ACL rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406822#comment-16406822 ] ASF GitHub Bot commented on CLOUDSTACK-10332: - blueorangutan commented on issue #2496: [CLOUDSTACK-10332] Users are not able to change/edit the protocol of an ACL rule URL: https://github.com/apache/cloudstack/pull/2496#issuecomment-374706769 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1800 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Users are not able to change/edit the protocol of an ACL rule > -- > > Key: CLOUDSTACK-10332 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10332 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > Users should be able to edit an ACL rule completely. Therefore, they must be > able to change the protocol type and others configs of an ACL rules. > Right now users are not able to execute the following. > * Create an ACL for ICMP > * Click on edit and change the protocol to TCP > * An error will happen when saving the rule. > Users should be able to execute the protocol changes without problem. > In addition, it is not just the protocol that users are not able to change. > For instance, after defining ports, or reason/description for the rule, users > are not able to set those values back to null. The same happens for ICMP code > and type. > We will introduce a new parameter called "partialUpdate", which will have its > default value as true to maintain backward compatibility. When this parameter > is set to false, we will consider only the parameters sent, and not the > parameters we already have in the database to change and validate the ACL > rule data. This allows us to update parameters already set back to null, and > to completely change an ACL rule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10331) Error 404 for /client/scripts/vm_snapshots.js
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406815#comment-16406815
]
ASF GitHub Bot commented on CLOUDSTACK-10331:
-
rafaelweingartner commented on issue #2497: CLOUDSTACK-10331: Remove reference
to deleted script vm_snapshots.js
URL: https://github.com/apache/cloudstack/pull/2497#issuecomment-374704362
Thanks @olivierlemasle for the fix.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Error 404 for /client/scripts/vm_snapshots.js
> -
>
> Key: CLOUDSTACK-10331
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10331
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.10.0.0, 4.10.1.0, 4.11.0.0
>Reporter: Olivier Lemasle
>Assignee: Olivier Lemasle
>Priority: Minor
>
> CloudStack main page requests a script "client/scripts/vm_snapshots.js",
> which does exist since ACS 4.10, causing a HTTP 404 error.
> The script {{vm_snapshots.js}} was removed here:
> https://github.com/apache/cloudstack/pull/977/commits/a2428508e2969e89577ba29e4cf43ce28ba11704
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10331) Error 404 for /client/scripts/vm_snapshots.js
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406802#comment-16406802
]
ASF GitHub Bot commented on CLOUDSTACK-10331:
-
olivierlemasle opened a new pull request #2497: CLOUDSTACK-10331: Remove
reference to deleted script vm_snapshots.js
URL: https://github.com/apache/cloudstack/pull/2497
## Description
CloudStack main page requests a script "client/scripts/vm_snapshots.js",
which does exist since ACS 4.10, causing a HTTP 404 error.
This commit remove the references to this deleted file (deleted in commit
a2428508e29)
## Types of changes
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] New feature (non-breaking change which adds functionality)
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] Enhancement (improves an existing feature and functionality)
- [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
## How Has This Been Tested?
Run CloudStack and access to UI.
## Checklist:
- [x] I have read the
[CONTRIBUTING](https://github.com/apache/cloudstack/blob/master/CONTRIBUTING.md)
document.
- [x] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Error 404 for /client/scripts/vm_snapshots.js
> -
>
> Key: CLOUDSTACK-10331
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10331
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.10.0.0, 4.10.1.0, 4.11.0.0
>Reporter: Olivier Lemasle
>Assignee: Olivier Lemasle
>Priority: Minor
>
> CloudStack main page requests a script "client/scripts/vm_snapshots.js",
> which does exist since ACS 4.10, causing a HTTP 404 error.
> The script {{vm_snapshots.js}} was removed here:
> https://github.com/apache/cloudstack/pull/977/commits/a2428508e2969e89577ba29e4cf43ce28ba11704
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10332) Users are not able to change/edit the protocol of an ACL rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406775#comment-16406775 ] ASF GitHub Bot commented on CLOUDSTACK-10332: - rafaelweingartner opened a new pull request #2496: [CLOUDSTACK-10332] Users are not able to change/edit the protocol of an ACL rule URL: https://github.com/apache/cloudstack/pull/2496 ## Description Users should be able to edit an ACL rule completely. Therefore, they must be able to change the protocol type and others configs of an ACL rules. In addition, it is not just the protocol that users are not able to change. For instance, after defining ports, or reason/description for the rule, users are not able to set those values back to null. The same happens for ICMP code and type. We will introduce a new parameter called "partialUpdate", which will have its default value as true to maintain backward compatibility. When this parameter is set to false, we will consider only the parameters sent, and not the parameters we already have in the database to change and validate the ACL rule data. This allows us to update parameters already set back to null, and to completely change an ACL rule. https://issues.apache.org/jira/browse/CLOUDSTACK-10332 * Create an ACL for ICMP * Click on edit and change the protocol to TCP * An error will happen when saving the rule. ## Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [X] Bug fix (non-breaking change which fixes an issue) - [ ] Enhancement (improves an existing feature and functionality) - [ ] Cleanup (Code refactoring and cleanup, that may add test cases) ## How Has This Been Tested? Compile, and deployed ACS with the proposed changes and verified them manually. Moreover, I have unit tests covering this issue, which are able to catch the problem. used Unit testing and a test ACS environment running with XenServer 6.5, and NFS server as primary and secondary storage. ## Checklist: - [x] I have read the [CONTRIBUTING](https://github.com/apache/cloudstack/blob/master/CONTRIBUTING.md) document. - [x] My code follows the code style of this project. - [ ] My change requires a change to the documentation. - [ ] I have updated the documentation accordingly. - [x] I have added tests to cover my changes. - [x] All new and existing tests passed. @blueorangutan package This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Users are not able to change/edit the protocol of an ACL rule > -- > > Key: CLOUDSTACK-10332 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10332 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > Users should be able to edit an ACL rule completely. Therefore, they must be > able to change the protocol type and others configs of an ACL rules. > Right now users are not able to execute the following. > * Create an ACL for ICMP > * Click on edit and change the protocol to TCP > * An error will happen when saving the rule. > Users should be able to execute the protocol changes without problem. > In addition, it is not just the protocol that users are not able to change. > For instance, after defining ports, or reason/description for the rule, users > are not able to set those values back to null. The same happens for ICMP code > and type. > We will introduce a new parameter called "partialUpdate", which will have its > default value as true to maintain backward compatibility. When this parameter > is set to false, we will consider only the parameters sent, and not the > parameters we already have in the database to change and validate the ACL > rule data. This allows us to update parameters already set back to null, and > to completely change an ACL rule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10332) Users are not able to change/edit the protocol of an ACL rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406778#comment-16406778 ] ASF GitHub Bot commented on CLOUDSTACK-10332: - blueorangutan commented on issue #2496: [CLOUDSTACK-10332] Users are not able to change/edit the protocol of an ACL rule URL: https://github.com/apache/cloudstack/pull/2496#issuecomment-374697189 @rafaelweingartner a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Users are not able to change/edit the protocol of an ACL rule > -- > > Key: CLOUDSTACK-10332 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10332 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > Users should be able to edit an ACL rule completely. Therefore, they must be > able to change the protocol type and others configs of an ACL rules. > Right now users are not able to execute the following. > * Create an ACL for ICMP > * Click on edit and change the protocol to TCP > * An error will happen when saving the rule. > Users should be able to execute the protocol changes without problem. > In addition, it is not just the protocol that users are not able to change. > For instance, after defining ports, or reason/description for the rule, users > are not able to set those values back to null. The same happens for ICMP code > and type. > We will introduce a new parameter called "partialUpdate", which will have its > default value as true to maintain backward compatibility. When this parameter > is set to false, we will consider only the parameters sent, and not the > parameters we already have in the database to change and validate the ACL > rule data. This allows us to update parameters already set back to null, and > to completely change an ACL rule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10332) Users are not able to change/edit the protocol of an ACL rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner updated CLOUDSTACK-10332: Status: Reviewable (was: In Progress) > Users are not able to change/edit the protocol of an ACL rule > -- > > Key: CLOUDSTACK-10332 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10332 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > Users should be able to edit an ACL rule completely. Therefore, they must be > able to change the protocol type and others configs of an ACL rules. > Right now users are not able to execute the following. > * Create an ACL for ICMP > * Click on edit and change the protocol to TCP > * An error will happen when saving the rule. > Users should be able to execute the protocol changes without problem. > In addition, it is not just the protocol that users are not able to change. > For instance, after defining ports, or reason/description for the rule, users > are not able to set those values back to null. The same happens for ICMP code > and type. > We will introduce a new parameter called "partialUpdate", which will have its > default value as true to maintain backward compatibility. When this parameter > is set to false, we will consider only the parameters sent, and not the > parameters we already have in the database to change and validate the ACL > rule data. This allows us to update parameters already set back to null, and > to completely change an ACL rule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10332) Users are not able to change/edit the protocol of an ACL rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner updated CLOUDSTACK-10332: Description: Users should be able to edit an ACL rule completely. Therefore, they must be able to change the protocol type and others configs of an ACL rules. Right now users are not able to execute the following. * Create an ACL for ICMP * Click on edit and change the protocol to TCP * An error will happen when saving the rule. Users should be able to execute the protocol changes without problem. In addition, it is not just the protocol that users are not able to change. For instance, after defining ports, or reason/description for the rule, users are not able to set those values back to null. The same happens for ICMP code and type. We will introduce a new parameter called "partialUpdate", which will have its default value as true to maintain backward compatibility. When this parameter is set to false, we will consider only the parameters sent, and not the parameters we already have in the database to change and validate the ACL rule data. This allows us to update parameters already set back to null, and to completely change an ACL rule. was: Users should be able to edit an ACL rule completely. Therefore, they must be able to change the protocol type and others configs of an ACL rules. Right now users are not able to execute the following. * Create an ACL for ICMP * Click on edit and change the protocol to TCP * An error will happen when saving the rule. Users should be able to execute the protocol changes without problem. > Users are not able to change/edit the protocol of an ACL rule > -- > > Key: CLOUDSTACK-10332 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10332 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > Users should be able to edit an ACL rule completely. Therefore, they must be > able to change the protocol type and others configs of an ACL rules. > Right now users are not able to execute the following. > * Create an ACL for ICMP > * Click on edit and change the protocol to TCP > * An error will happen when saving the rule. > Users should be able to execute the protocol changes without problem. > In addition, it is not just the protocol that users are not able to change. > For instance, after defining ports, or reason/description for the rule, users > are not able to set those values back to null. The same happens for ICMP code > and type. > We will introduce a new parameter called "partialUpdate", which will have its > default value as true to maintain backward compatibility. When this parameter > is set to false, we will consider only the parameters sent, and not the > parameters we already have in the database to change and validate the ACL > rule data. This allows us to update parameters already set back to null, and > to completely change an ACL rule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10332) Users are not able to change/edit the protocol of an ACL rule
Rafael Weingärtner created CLOUDSTACK-10332: --- Summary: Users are not able to change/edit the protocol of an ACL rule Key: CLOUDSTACK-10332 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10332 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Reporter: Rafael Weingärtner Assignee: Rafael Weingärtner Fix For: 4.12 Users should be able to edit an ACL rule completely. Therefore, they must be able to change the protocol type and others configs of an ACL rules. Right now users are not able to execute the following. * Create an ACL for ICMP * Click on edit and change the protocol to TCP * An error will happen when saving the rule. Users should be able to execute the protocol changes without problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10226) CloudStack is not importing Local storage properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406758#comment-16406758 ] ASF GitHub Bot commented on CLOUDSTACK-10226: - blueorangutan commented on issue #2401: [CLOUDSTACK-10226] CloudStack is not importing Local storage properly URL: https://github.com/apache/cloudstack/pull/2401#issuecomment-374691568 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1797 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > CloudStack is not importing Local storage properly > --- > > Key: CLOUDSTACK-10226 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10226 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > CloudStack is importing as Local storage any XenServer SR that is of type LVM > or EXT. This causes a problem when one wants to use both Direct attach > storage and local storage. Moreover, CloudStack was not importing all of the > local storage that a host has available when local storage is enabled. It was > only importing the First SR it sees. > To fix the first problem we started ignoring SRs that have the flag > shared=true when discovering local storages. SRs configured to be shared are > used as direct attached storage, and therefore should not be imported again > as local ones. > To fix the second problem, we started loading all Local storage and importing > them accordingly to ACS. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10230) User is able to change to “Guest OS type” that has been removed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406759#comment-16406759 ] ASF GitHub Bot commented on CLOUDSTACK-10230: - blueorangutan commented on issue #2404: [CLOUDSTACK-10230] User should not be able to use removed “Guest OS type” URL: https://github.com/apache/cloudstack/pull/2404#issuecomment-374691569 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1798 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > User is able to change to “Guest OS type” that has been removed > > > Key: CLOUDSTACK-10230 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10230 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Critical > > Users are able to change the OS type of VMs to “Guest OS type” that has been > removed. This becomes a security issue when we try to force users to use HVM > VMs (Meltdown/Spectre thing). A removed “guest os type” should not be usable > by any users in the cloud. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10214) Unable to remove local primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406757#comment-16406757 ] ASF GitHub Bot commented on CLOUDSTACK-10214: - blueorangutan commented on issue #2390: [CLOUDSTACK-10214] Unable to remove local primary storage URL: https://github.com/apache/cloudstack/pull/2390#issuecomment-374691567 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1799 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Unable to remove local primary storage > --- > > Key: CLOUDSTACK-10214 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10214 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0, 4.9.3.0 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > When enabling the use of local storage ACS will automatically load all local > storage configured in the Host and start using them as primary storage to > deploy user VMs (if the service offering allows to do so). However, if the > operator wants to remove the local storage ACS will throw an exception saying > that the removal of local storage is not allowed.Therefore, if one wants to > remove a local storage, he/she needs to do a manual intervention in the > database and hosts. > This limitation was removed, as it was only a logical restriction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10331) Error 404 for /client/scripts/vm_snapshots.js
Olivier Lemasle created CLOUDSTACK-10331:
Summary: Error 404 for /client/scripts/vm_snapshots.js
Key: CLOUDSTACK-10331
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10331
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: UI
Affects Versions: 4.10.0.0, 4.10.1.0, 4.11.0.0
Reporter: Olivier Lemasle
Assignee: Olivier Lemasle
CloudStack main page requests a script "client/scripts/vm_snapshots.js", which
does exist since ACS 4.10, causing a HTTP 404 error.
The script {{vm_snapshots.js}} was removed here:
https://github.com/apache/cloudstack/pull/977/commits/a2428508e2969e89577ba29e4cf43ce28ba11704
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10301) Allow updating the network ACL list name and Description
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406743#comment-16406743 ] ASF GitHub Bot commented on CLOUDSTACK-10301: - blueorangutan commented on issue #2462: [CLOUDSTACK-10301] Allow updating the network ACL list name and Description URL: https://github.com/apache/cloudstack/pull/2462#issuecomment-374687567 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1796 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Allow updating the network ACL list name and Description > - > > Key: CLOUDSTACK-10301 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10301 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Currently, it is not possible to update the Network ACL name or Description > of an ACL after it has been created. It might be interesting to expose this > option via API and to add this feature to the UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10311) Agent Log Rotate variable replace bug
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406570#comment-16406570
]
ASF GitHub Bot commented on CLOUDSTACK-10311:
-
Slair1 commented on issue #2471: CLOUDSTACK-10311 Agent Log Rotate variable
replace bug
URL: https://github.com/apache/cloudstack/pull/2471#issuecomment-374656688
@rafaelweingartner sure, just did
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Agent Log Rotate variable replace bug
> -
>
> Key: CLOUDSTACK-10311
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10311
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: cloudstack-agent
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Sean Lair
>Priority: Major
>
> The cloudstack-agent was modified to use the @AGENTLOG@ variable entry, but
> the pom.xml file was not correct to do the replacement of the @AGENTLOG@.
> {{@AGENTLOG@}}
> {{/var/log/cloudstack/agent/security_group.log}}
> {{{}}
> {{ copytruncate}}
> {{ daily}}
> {{ rotate 5}}
> {{ compress}}
> {{ missingok}}
> {{}}}
> PR coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10230) User is able to change to “Guest OS type” that has been removed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406566#comment-16406566 ] ASF GitHub Bot commented on CLOUDSTACK-10230: - blueorangutan commented on issue #2404: [CLOUDSTACK-10230] User should not be able to use removed “Guest OS type” URL: https://github.com/apache/cloudstack/pull/2404#issuecomment-374655597 @rafaelweingartner a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > User is able to change to “Guest OS type” that has been removed > > > Key: CLOUDSTACK-10230 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10230 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Critical > > Users are able to change the OS type of VMs to “Guest OS type” that has been > removed. This becomes a security issue when we try to force users to use HVM > VMs (Meltdown/Spectre thing). A removed “guest os type” should not be usable > by any users in the cloud. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10214) Unable to remove local primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406567#comment-16406567 ] ASF GitHub Bot commented on CLOUDSTACK-10214: - blueorangutan commented on issue #2390: [CLOUDSTACK-10214] Unable to remove local primary storage URL: https://github.com/apache/cloudstack/pull/2390#issuecomment-374655944 @rafaelweingartner a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Unable to remove local primary storage > --- > > Key: CLOUDSTACK-10214 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10214 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0, 4.9.3.0 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > When enabling the use of local storage ACS will automatically load all local > storage configured in the Host and start using them as primary storage to > deploy user VMs (if the service offering allows to do so). However, if the > operator wants to remove the local storage ACS will throw an exception saying > that the removal of local storage is not allowed.Therefore, if one wants to > remove a local storage, he/she needs to do a manual intervention in the > database and hosts. > This limitation was removed, as it was only a logical restriction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10226) CloudStack is not importing Local storage properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406565#comment-16406565 ] ASF GitHub Bot commented on CLOUDSTACK-10226: - blueorangutan commented on issue #2401: [CLOUDSTACK-10226] CloudStack is not importing Local storage properly URL: https://github.com/apache/cloudstack/pull/2401#issuecomment-374655583 @rafaelweingartner a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > CloudStack is not importing Local storage properly > --- > > Key: CLOUDSTACK-10226 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10226 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > CloudStack is importing as Local storage any XenServer SR that is of type LVM > or EXT. This causes a problem when one wants to use both Direct attach > storage and local storage. Moreover, CloudStack was not importing all of the > local storage that a host has available when local storage is enabled. It was > only importing the First SR it sees. > To fix the first problem we started ignoring SRs that have the flag > shared=true when discovering local storages. SRs configured to be shared are > used as direct attached storage, and therefore should not be imported again > as local ones. > To fix the second problem, we started loading all Local storage and importing > them accordingly to ACS. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10214) Unable to remove local primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406564#comment-16406564 ] ASF GitHub Bot commented on CLOUDSTACK-10214: - rafaelweingartner commented on issue #2390: [CLOUDSTACK-10214] Unable to remove local primary storage URL: https://github.com/apache/cloudstack/pull/2390#issuecomment-374655563 @blueorangutan package This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Unable to remove local primary storage > --- > > Key: CLOUDSTACK-10214 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10214 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0, 4.9.3.0 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > When enabling the use of local storage ACS will automatically load all local > storage configured in the Host and start using them as primary storage to > deploy user VMs (if the service offering allows to do so). However, if the > operator wants to remove the local storage ACS will throw an exception saying > that the removal of local storage is not allowed.Therefore, if one wants to > remove a local storage, he/she needs to do a manual intervention in the > database and hosts. > This limitation was removed, as it was only a logical restriction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10226) CloudStack is not importing Local storage properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406563#comment-16406563 ] ASF GitHub Bot commented on CLOUDSTACK-10226: - rafaelweingartner commented on issue #2401: [CLOUDSTACK-10226] CloudStack is not importing Local storage properly URL: https://github.com/apache/cloudstack/pull/2401#issuecomment-374655519 @blueorangutan package This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > CloudStack is not importing Local storage properly > --- > > Key: CLOUDSTACK-10226 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10226 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > CloudStack is importing as Local storage any XenServer SR that is of type LVM > or EXT. This causes a problem when one wants to use both Direct attach > storage and local storage. Moreover, CloudStack was not importing all of the > local storage that a host has available when local storage is enabled. It was > only importing the First SR it sees. > To fix the first problem we started ignoring SRs that have the flag > shared=true when discovering local storages. SRs configured to be shared are > used as direct attached storage, and therefore should not be imported again > as local ones. > To fix the second problem, we started loading all Local storage and importing > them accordingly to ACS. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10230) User is able to change to “Guest OS type” that has been removed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406561#comment-16406561 ] ASF GitHub Bot commented on CLOUDSTACK-10230: - rafaelweingartner commented on issue #2404: [CLOUDSTACK-10230] User should not be able to use removed “Guest OS type” URL: https://github.com/apache/cloudstack/pull/2404#issuecomment-374655440 @blueorangutan package This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > User is able to change to “Guest OS type” that has been removed > > > Key: CLOUDSTACK-10230 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10230 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Critical > > Users are able to change the OS type of VMs to “Guest OS type” that has been > removed. This becomes a security issue when we try to force users to use HVM > VMs (Meltdown/Spectre thing). A removed “guest os type” should not be usable > by any users in the cloud. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10301) Allow updating the network ACL list name and Description
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406557#comment-16406557 ] ASF GitHub Bot commented on CLOUDSTACK-10301: - rafaelweingartner commented on issue #2462: [CLOUDSTACK-10301] Allow updating the network ACL list name and Description URL: https://github.com/apache/cloudstack/pull/2462#issuecomment-374654888 @blueorangutan package This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Allow updating the network ACL list name and Description > - > > Key: CLOUDSTACK-10301 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10301 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Currently, it is not possible to update the Network ACL name or Description > of an ACL after it has been created. It might be interesting to expose this > option via API and to add this feature to the UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10301) Allow updating the network ACL list name and Description
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406560#comment-16406560 ] ASF GitHub Bot commented on CLOUDSTACK-10301: - blueorangutan commented on issue #2462: [CLOUDSTACK-10301] Allow updating the network ACL list name and Description URL: https://github.com/apache/cloudstack/pull/2462#issuecomment-374655161 @rafaelweingartner a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Allow updating the network ACL list name and Description > - > > Key: CLOUDSTACK-10301 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10301 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Currently, it is not possible to update the Network ACL name or Description > of an ACL after it has been created. It might be interesting to expose this > option via API and to add this feature to the UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10311) Agent Log Rotate variable replace bug
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406552#comment-16406552
]
ASF GitHub Bot commented on CLOUDSTACK-10311:
-
rafaelweingartner commented on issue #2471: CLOUDSTACK-10311 Agent Log Rotate
variable replace bug
URL: https://github.com/apache/cloudstack/pull/2471#issuecomment-374654055
Can you rebase? I have fixed a code that was causing travis errors.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Agent Log Rotate variable replace bug
> -
>
> Key: CLOUDSTACK-10311
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10311
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: cloudstack-agent
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Sean Lair
>Priority: Major
>
> The cloudstack-agent was modified to use the @AGENTLOG@ variable entry, but
> the pom.xml file was not correct to do the replacement of the @AGENTLOG@.
> {{@AGENTLOG@}}
> {{/var/log/cloudstack/agent/security_group.log}}
> {{{}}
> {{ copytruncate}}
> {{ daily}}
> {{ rotate 5}}
> {{ compress}}
> {{ missingok}}
> {{}}}
> PR coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10311) Agent Log Rotate variable replace bug
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406547#comment-16406547
]
ASF GitHub Bot commented on CLOUDSTACK-10311:
-
Slair1 commented on issue #2471: CLOUDSTACK-10311 Agent Log Rotate variable
replace bug
URL: https://github.com/apache/cloudstack/pull/2471#issuecomment-374653420
Travis errors look unrelated?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Agent Log Rotate variable replace bug
> -
>
> Key: CLOUDSTACK-10311
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10311
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: cloudstack-agent
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Sean Lair
>Priority: Major
>
> The cloudstack-agent was modified to use the @AGENTLOG@ variable entry, but
> the pom.xml file was not correct to do the replacement of the @AGENTLOG@.
> {{@AGENTLOG@}}
> {{/var/log/cloudstack/agent/security_group.log}}
> {{{}}
> {{ copytruncate}}
> {{ daily}}
> {{ rotate 5}}
> {{ compress}}
> {{ missingok}}
> {{}}}
> PR coming
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10231) Asserted fixes for Direct Download on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Vazquez resolved CLOUDSTACK-10231. -- Resolution: Fixed > Asserted fixes for Direct Download on KVM > - > > Key: CLOUDSTACK-10231 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10231 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez >Priority: Major > Labels: direct-download,, kvm > Fix For: 4.11.1.0 > > > Several fixes addressed: > * Dettach ISO fails when trying to detach a direct download ISO > * Fix for metalink support on SSVM agents (this closes CLOUDSTACK-10238) > * Reinstall VM from bypassed registered template (this closes > CLOUDSTACK-10250) > * Fix upload certificate error message even though operation was successful > * Fix metalink download, checksum retry logic and metalink SSVM downloader -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10315) Inconsistent debugging info in catch block
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhenhao Li updated CLOUDSTACK-10315:
Description:
We found that some logging statements have same log message, but one of them
has stack trace info, the other one of them doesn't have. Maybe a possible
reason is that they are code clone, developers changed one of them(add stack
trace info) but forgot to change the other one. Here's the details of those
logging statements we found:
1.*"Moving on to the next host because " + h.toString() + " is unavailable"*,
_com.cloud.hypervisor.ovm3.resources.Ovm3FenceBuilder.*fenceOff()*,_
_com.cloud.ha.*SimulatorFencer()*_,
There are two identical log messages in these two places, the latter one logged
stack trace but the previous one did not.
!image-2018-03-05-09-59-19-369.png!
We can see that they are in different type of catch block, but when checking
the logs they generated, maybe it's impossible to know the difference of them
without stack trace. So maybe the stack traces info should also be added here?
2.*"Network rule Conflict"*
_org.apache.cloudstack.api.command.user.firewall.CreatePortForwardingRuleCmd.*create()*,_
_org.apache.cloudstack.api.command.user.firewall.CreateFirewallRuleCmd.*create()*_
The previous one has these two logging statements:
s_logger.info("Network rule conflict: ", ex);
s_logger.trace("Network Rule Conflict: ", ex);
Comparing to the latter one which contains:
s_logger.info("Network rule conflict: " + ex.getMessage());
s_logger.trace("Network Rule Conflict: ", ex);
Maybe it's better to have consistent exception handling here?
3.*"Failed to take snapshot: "*
_org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.*takeSnapshot()*,_
_org.apache.cloudstack.storage.datastore.driver.ElastistorPrimaryDataStoreDriver.*takeSnapshot()*_
The previous one has catch block:
!image-2018-03-05-10-14-00-552.png!
and the latter one:
!image-2018-03-05-10-14-25-802.png!
We can see that the code snippers are almost the same except the logging
statements.
Will it be better to change the latter one, to be consistent with the previous
one?
was:
We found that some logging statements have same log message, but one of them
has stack trace info, the other one of them doesn't have. Maybe a possible
reason is that they are code clone, developers changed one of them(add stack
trace info) but forgot to change the other one. Here's the details of those
logging statements we found:
1.*"Moving on to the next host because " + h.toString() + " is unavailable"*,
_com.cloud.hypervisor.ovm3.resources.Ovm3FenceBuilder.*fenceOff()*,_
_com.cloud.ha.*SimulatorFencer()*_,
There are two identical log messages in these two places, the latter one logged
stack trace but the previous one did not.
!image-2018-03-05-09-59-19-369.png!
We can see that they are in different type of catch block, but when checking
the logs they generated, maybe it's impossible to know the difference of them
without stack trace. So maybe the stack traces info should also be added here?
2.*"Network rule Conflict"*
_org.apache.cloudstack.api.command.user.firewall.CreatePortForwardingRuleCmd.*create()*,_
_org.apache.cloudstack.api.command.user.firewall.CreateFirewallRuleCmd.*create()*_
The previous one has these two logging statements:
s_logger.info("Network rule conflict: ", ex);
s_logger.trace("Network Rule Conflict: ", ex);
Comparing to the latter one which contains:
s_logger.info("Network rule conflict: " + ex.getMessage());
s_logger.trace("Network Rule Conflict: ", ex);
Maybe it's better to have consistent exception handling here?
3.*"Failed to take snapshot: "*
_org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.*takeSnapshot()*,_
_org.apache.cloudstack.storage.datastore.driver.ElastistorPrimaryDataStoreDriver.*takeSnapshot()*_
The previous one has catch block:
!image-2018-03-05-10-14-00-552.png!
and the latter one:
!image-2018-03-05-10-14-25-802.png!
We can see that the code snippers are almost the same except the logging
statements.
Will it be better to change the latter one, to be consistent with the previous
one?
> Inconsistent debugging info in catch block
> --
>
> Key: CLOUDSTACK-10315
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10315
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Zhenhao Li
>Priority: Minor
> Labels: easyfix
> Attachments: image-2018-03-05-09-59-19-369.png,
> image-2018-03-05-10-14-00-552.png, image-2018-03-05-10-14-25-802.png
>
>
> We found that some logging statements have same log message, but one of them
> has stack trace info, the other one of them
[jira] [Commented] (CLOUDSTACK-7982) Storage live migration support for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406418#comment-16406418 ] ASF GitHub Bot commented on CLOUDSTACK-7982: wido commented on issue #1709: CLOUDSTACK-7982: KVM live migration with local storage URL: https://github.com/apache/cloudstack/pull/1709#issuecomment-374621278 How are we on this one? I'd really like to see this in master. Anything we can do to assist? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Storage live migration support for KVM > -- > > Key: CLOUDSTACK-7982 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7982 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Marc-Aurèle Brothier >Priority: Major > Fix For: Future > > > Currently it supports Xenserver, Vmware, Hyper-V, but not KVM. > We need to add the implementation for KVM. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10231) Asserted fixes for Direct Download on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406359#comment-16406359 ] ASF GitHub Bot commented on CLOUDSTACK-10231: - rhtyd commented on issue #2408: CLOUDSTACK-10231: Asserted fixes for Direct Download on KVM URL: https://github.com/apache/cloudstack/pull/2408#issuecomment-374606161 Merged based on tests and reviews. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Asserted fixes for Direct Download on KVM > - > > Key: CLOUDSTACK-10231 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10231 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez >Priority: Major > Labels: direct-download,, kvm > Fix For: 4.11.1.0 > > > Several fixes addressed: > * Dettach ISO fails when trying to detach a direct download ISO > * Fix for metalink support on SSVM agents (this closes CLOUDSTACK-10238) > * Reinstall VM from bypassed registered template (this closes > CLOUDSTACK-10250) > * Fix upload certificate error message even though operation was successful > * Fix metalink download, checksum retry logic and metalink SSVM downloader -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10231) Asserted fixes for Direct Download on KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406354#comment-16406354
]
ASF GitHub Bot commented on CLOUDSTACK-10231:
-
rhtyd closed pull request #2408: CLOUDSTACK-10231: Asserted fixes for Direct
Download on KVM
URL: https://github.com/apache/cloudstack/pull/2408
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/agent/src/com/cloud/agent/direct/download/DirectTemplateDownloaderImpl.java
b/agent/src/com/cloud/agent/direct/download/DirectTemplateDownloaderImpl.java
index e120d847b17..419ab7d1bbd 100644
---
a/agent/src/com/cloud/agent/direct/download/DirectTemplateDownloaderImpl.java
+++
b/agent/src/com/cloud/agent/direct/download/DirectTemplateDownloaderImpl.java
@@ -22,6 +22,7 @@
import com.cloud.utils.script.Script;
import org.apache.cloudstack.utils.security.DigestHelper;
import org.apache.commons.lang.StringUtils;
+import org.apache.log4j.Logger;
import java.io.File;
import java.io.FileInputStream;
@@ -37,6 +38,8 @@
private String downloadedFilePath;
private String installPath;
private String checksum;
+private boolean redownload = false;
+public static final Logger s_logger =
Logger.getLogger(DirectTemplateDownloaderImpl.class.getName());
protected DirectTemplateDownloaderImpl(final String url, final String
destPoolPath, final Long templateId, final String checksum) {
this.url = url;
@@ -70,6 +73,10 @@ public String getUrl() {
return url;
}
+public void setUrl(String url) {
+this.url = url;
+}
+
public String getDestPoolPath() {
return destPoolPath;
}
@@ -86,6 +93,18 @@ public void setDownloadedFilePath(String filePath) {
this.downloadedFilePath = filePath;
}
+public String getChecksum() {
+return checksum;
+}
+
+public void setChecksum(String checksum) {
+this.checksum = checksum;
+}
+
+public boolean isRedownload() {
+return redownload;
+}
+
/**
* Return filename from url
*/
@@ -155,14 +174,47 @@ public DirectTemplateInformation getTemplateInformation()
{
@Override
public boolean validateChecksum() {
if (StringUtils.isNotBlank(checksum)) {
+int retry = 3;
+boolean valid = false;
try {
-return DigestHelper.check(checksum, new
FileInputStream(downloadedFilePath));
+while (!valid && retry > 0) {
+retry--;
+s_logger.info("Performing checksum validation for
downloaded template " + templateId + " using " + checksum + ", retries left: "
+ retry);
+valid = DigestHelper.check(checksum, new
FileInputStream(downloadedFilePath));
+if (!valid && retry > 0) {
+s_logger.info("Checksum validation failded,
re-downloading template");
+redownload = true;
+resetDownloadFile();
+downloadTemplate();
+}
+}
+s_logger.info("Checksum validation for template " + templateId
+ ": " + (valid ? "succeeded" : "failed"));
+return valid;
} catch (IOException e) {
-throw new CloudRuntimeException("could not check sum for file:
" + downloadedFilePath,e);
+throw new CloudRuntimeException("could not check sum for file:
" + downloadedFilePath, e);
} catch (NoSuchAlgorithmException e) {
throw new CloudRuntimeException("Unknown checksum algorithm: "
+ checksum, e);
}
}
+s_logger.info("No checksum provided, skipping checksum validation");
return true;
}
+
+/**
+ * Delete and create download file
+ */
+private void resetDownloadFile() {
+File f = new File(getDownloadedFilePath());
+s_logger.info("Resetting download file: " + getDownloadedFilePath() +
", in order to re-download and persist template " + templateId + " on it");
+try {
+if (f.exists()) {
+f.delete();
+}
+f.createNewFile();
+} catch (IOException e) {
+s_logger.error("Error creating file to download on: " +
getDownloadedFilePath() + " due to: " + e.getMessage());
+throw new CloudRuntimeException("Failed to create download file
for direct download");
+}
+}
+
}
diff --git
a/agent/src/com/cloud/agent/direct/download/HttpDirectTemplateDownloader.java
b/agent/src/com/cloud/agent/direct/download/HttpDirectTemplateDownloader.java
index
[jira] [Commented] (CLOUDSTACK-10231) Asserted fixes for Direct Download on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406355#comment-16406355 ] ASF subversion and git services commented on CLOUDSTACK-10231: -- Commit 6a754237797a9d2f084674da83929f66fd402368 in cloudstack's branch refs/heads/4.11 from [~nicolas.vazquez] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=6a75423 ] CLOUDSTACK-10231: Asserted fixes for Direct Download on KVM (#2408) Several fixes addressed: - Dettach ISO fails when trying to detach a direct download ISO - Fix for metalink support on SSVM agents (this closes CLOUDSTACK-10238) - Reinstall VM from bypassed registered template (this closes CLOUDSTACK-10250) - Fix upload certificate error message even though operation was successful - Fix metalink download, checksum retry logic and metalink SSVM downloader > Asserted fixes for Direct Download on KVM > - > > Key: CLOUDSTACK-10231 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10231 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez >Priority: Major > Labels: direct-download,, kvm > Fix For: 4.11.1.0 > > > Several fixes addressed: > * Dettach ISO fails when trying to detach a direct download ISO > * Fix for metalink support on SSVM agents (this closes CLOUDSTACK-10238) > * Reinstall VM from bypassed registered template (this closes > CLOUDSTACK-10250) > * Fix upload certificate error message even though operation was successful > * Fix metalink download, checksum retry logic and metalink SSVM downloader -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10238) Fix for metalink support on SSVM agents
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406356#comment-16406356 ] ASF subversion and git services commented on CLOUDSTACK-10238: -- Commit 6a754237797a9d2f084674da83929f66fd402368 in cloudstack's branch refs/heads/4.11 from [~nicolas.vazquez] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=6a75423 ] CLOUDSTACK-10231: Asserted fixes for Direct Download on KVM (#2408) Several fixes addressed: - Dettach ISO fails when trying to detach a direct download ISO - Fix for metalink support on SSVM agents (this closes CLOUDSTACK-10238) - Reinstall VM from bypassed registered template (this closes CLOUDSTACK-10250) - Fix upload certificate error message even though operation was successful - Fix metalink download, checksum retry logic and metalink SSVM downloader > Fix for metalink support on SSVM agents > --- > > Key: CLOUDSTACK-10238 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10238 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.0 > > > Fix for metalink support -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10250) Reinstall VM from bypassed registered template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406357#comment-16406357 ] ASF subversion and git services commented on CLOUDSTACK-10250: -- Commit 6a754237797a9d2f084674da83929f66fd402368 in cloudstack's branch refs/heads/4.11 from [~nicolas.vazquez] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=6a75423 ] CLOUDSTACK-10231: Asserted fixes for Direct Download on KVM (#2408) Several fixes addressed: - Dettach ISO fails when trying to detach a direct download ISO - Fix for metalink support on SSVM agents (this closes CLOUDSTACK-10238) - Reinstall VM from bypassed registered template (this closes CLOUDSTACK-10250) - Fix upload certificate error message even though operation was successful - Fix metalink download, checksum retry logic and metalink SSVM downloader > Reinstall VM from bypassed registered template > -- > > Key: CLOUDSTACK-10250 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10250 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.0 > > > This fix allows users to restore a VM from a previously registered template > using the Direct Download option (only for KVM currently) > NOTE: As Reinstall VM button prompts only featured templates, to be able to > restore a vm to a Direct Download template, it should be registered as > Featured -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10320) Invalid pair for response object breaking response parsing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406243#comment-16406243
]
ASF GitHub Bot commented on CLOUDSTACK-10320:
-
marcaurele commented on issue #2481: CLOUDSTACK-10320 - Invalid pair for
response object breaking response parsing
URL: https://github.com/apache/cloudstack/pull/2481#issuecomment-374577255
I don't think we're in a hurry to fix the problem. I will investigate on our
platform and maybe try to narrow down the isolation level to those queries
only. It will take one or two weeks to get the result. Anyway, I don't see
another option to fix the problem with the same requirements (total count,
pagination).
The other solution would be to get rid of the count value in the API
response, making this change obsolete. It should be a point to keep in mind for
the next API version.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Invalid pair for response object breaking response parsing
> --
>
> Key: CLOUDSTACK-10320
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10320
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Reporter: Marc-Aurèle Brothier
>Assignee: Marc-Aurèle Brothier
>Priority: Major
>
> Under some circumstances, the API is returning an invalid response, for
> simplicity I will expose the JSON case. The API response on a
> listVirtualMachines can be this string:
> {code:java}
> { "listvirtualmachinesresponse" : ] } }{code}
> To understand how this is possible, assume you have more than one management
> server and one is processing the destroy of a virtual machine in the account
> X which is the only one it has. Another process is returning the result of
> listVirtualMachines for that same account X. During the listVM command, the
> result set is fetch with a searchAndDistinctCount due to the view
> ([https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/query/QueryManagerImpl.java#L1024).]
> This is done through 2 queries in the GenericDao
> [https://github.com/apache/cloudstack/blob/master/framework/db/src/main/java/com/cloud/utils/db/GenericDaoBase.java#L1323]
> and if you encounter the _right_ conditions, the VM will be marked as
> removed in between those 2 queries. This results in having a Pair result with
> at least one object but a count of 0. Then following how is done the
> serialization of the response at
> [https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/response/ApiResponseSerializer.java#L86]
> you will reach the case where your output is the one previously mentioned.
> To overcome this issue, there isn't a true fix but only a better pair
> response to ensure a correct response formatting. If the result set contains
> at least something, the count cannot be 0 but we cannot guess the correct
> answer, but only state it has at least one element.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10231) Asserted fixes for Direct Download on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406193#comment-16406193 ] ASF GitHub Bot commented on CLOUDSTACK-10231: - nvazquez commented on issue #2408: CLOUDSTACK-10231: Asserted fixes for Direct Download on KVM URL: https://github.com/apache/cloudstack/pull/2408#issuecomment-374566994 @borisstoyanov @rhtyd @DaanHoogland hi guys, can we merge this one? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Asserted fixes for Direct Download on KVM > - > > Key: CLOUDSTACK-10231 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10231 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez >Priority: Major > Labels: direct-download,, kvm > Fix For: 4.11.1.0 > > > Several fixes addressed: > * Dettach ISO fails when trying to detach a direct download ISO > * Fix for metalink support on SSVM agents (this closes CLOUDSTACK-10238) > * Reinstall VM from bypassed registered template (this closes > CLOUDSTACK-10250) > * Fix upload certificate error message even though operation was successful > * Fix metalink download, checksum retry logic and metalink SSVM downloader -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (CLOUDSTACK-10231) Asserted fixes for Direct Download on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Vazquez reopened CLOUDSTACK-10231: -- > Asserted fixes for Direct Download on KVM > - > > Key: CLOUDSTACK-10231 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10231 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez >Priority: Major > Labels: direct-download,, kvm > Fix For: 4.11.1.0 > > > Several fixes addressed: > * Dettach ISO fails when trying to detach a direct download ISO > * Fix for metalink support on SSVM agents (this closes CLOUDSTACK-10238) > * Reinstall VM from bypassed registered template (this closes > CLOUDSTACK-10250) > * Fix upload certificate error message even though operation was successful > * Fix metalink download, checksum retry logic and metalink SSVM downloader -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10329) Button in ACL rules page to export all rules as a CSV file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-10329. - Resolution: Fixed > Button in ACL rules page to export all rules as a CSV file > --- > > Key: CLOUDSTACK-10329 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10329 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > It is interesting to create a button in the ACL rule listing page to export > all rules in a CSV file. This file can facilitate the auditing and reporting > of rules. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10329) Button in ACL rules page to export all rules as a CSV file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406099#comment-16406099 ] ASF subversion and git services commented on CLOUDSTACK-10329: -- Commit cd3a128090626d4afb991d7b7667d25da8ee950f in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=cd3a128 ] [CLOUDSTACK-10329] Button in ACL rules page to export all rules as a CSV file (#2494) > Button in ACL rules page to export all rules as a CSV file > --- > > Key: CLOUDSTACK-10329 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10329 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > It is interesting to create a button in the ACL rule listing page to export > all rules in a CSV file. This file can facilitate the auditing and reporting > of rules. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10329) Button in ACL rules page to export all rules as a CSV file
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406098#comment-16406098
]
ASF GitHub Bot commented on CLOUDSTACK-10329:
-
rafaelweingartner closed pull request #2494: [CLOUDSTACK-10329] Button in ACL
rules page to export all rules as a CSV file
URL: https://github.com/apache/cloudstack/pull/2494
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/ui/css/cloudstack3.css b/ui/css/cloudstack3.css
index 2acabdbfc79..1ef2d84f7b4 100644
--- a/ui/css/cloudstack3.css
+++ b/ui/css/cloudstack3.css
@@ -3241,6 +3241,7 @@ div.toolbar div.button.main-action,
height: 12px;
}
+div.toolbar div.button.export:hover,
div.toolbar div.button.add:hover,
div.toolbar div.button.refresh:hover,
div.toolbar div.button.main-action:hover,
@@ -13414,3 +13415,32 @@ div.panel.copy-template-destination-list div.list-view
div.fixed-header{
.multi-edit-add-list .ui-button.copytemplatecancel {
left: 310px;
}
+
+div.button.export {
+ position: relative;
+ left: 0px;
+ top: 5px;
+ font-size: 12px;
+ font-weight: 100;
+ color: #00;
+ margin: 0 10px 0 0;
+ cursor: pointer;
+ text-shadow: 0px 1px 1px #DEE5EA;
+ padding: 5px 5px 5px 5px;
+ background: linear-gradient(to bottom, rgba(247,247,247,1)
1%,rgba(234,234,234,1) 100%);
+ border: 1px solid #B7B7B7;
+ float: right;
+ border-radius: 4px 4px 4px 4px;
+ height: 12px;
+}
+
+div.button.export a {
+ padding: 0px 0 3px 20px;
+ background: url(../images/exportCsvIcon.png) no-repeat;
+ position: relative;
+ left: 0px;
+ top: 0px;
+ background-size: 15.5px;
+ text-decoration: none;
+ color: black;
+}
\ No newline at end of file
diff --git a/ui/images/exportCsvIcon.png b/ui/images/exportCsvIcon.png
new file mode 100644
index 000..cc486ec1735
Binary files /dev/null and b/ui/images/exportCsvIcon.png differ
diff --git a/ui/l10n/ar.js b/ui/l10n/ar.js
index f6927437017..db0dab01ce0 100644
--- a/ui/l10n/ar.js
+++ b/ui/l10n/ar.js
@@ -101,6 +101,7 @@ var dictionary = {
"label.accounts": "Accounts",
"label.acl": "ACL",
"label.acl.id": "ACL ID",
+"label.acl.export": "Export ACLs",
"label.acl.list.rules": "ACL List Rules",
"label.acl.name": "ACL Name",
"label.acl.replaced": "ACL replaced",
diff --git a/ui/l10n/ca.js b/ui/l10n/ca.js
index 276b3e51bfc..5d9846723be 100644
--- a/ui/l10n/ca.js
+++ b/ui/l10n/ca.js
@@ -101,6 +101,7 @@ var dictionary = {
"label.accounts": "Accounts",
"label.acl": "ACL",
"label.acl.id": "ACL ID",
+"label.acl.export": "Export ACLs",
"label.acl.list.rules": "ACL List Rules",
"label.acl.name": "ACL Name",
"label.acl.replaced": "ACL replaced",
diff --git a/ui/l10n/de_DE.js b/ui/l10n/de_DE.js
index 76374f63459..4decf808448 100644
--- a/ui/l10n/de_DE.js
+++ b/ui/l10n/de_DE.js
@@ -101,6 +101,7 @@ var dictionary = {
"label.accounts": "Benutzerkonten",
"label.acl": "ACL",
"label.acl.id": "ACL-Kennung",
+"label.acl.export": "Export ACLs",
"label.acl.list.rules": "ACL-Listenregeln",
"label.acl.name": "ACL-Name",
"label.acl.replaced": "ACL ersetzt",
diff --git a/ui/l10n/en.js b/ui/l10n/en.js
index 6d994303f1a..ae7ca7ba866 100644
--- a/ui/l10n/en.js
+++ b/ui/l10n/en.js
@@ -102,6 +102,7 @@ var dictionary = {
"label.accounts":"Accounts",
"label.acl":"ACL",
"label.acl.id":"ACL ID",
+"label.acl.export": "Export ACLs",
"label.acl.list.rules":"ACL List Rules",
"label.acl.name":"ACL Name",
"label.acl.replaced":"ACL replaced",
diff --git a/ui/l10n/es.js b/ui/l10n/es.js
index 37f8425ac05..cbdf7878844 100644
--- a/ui/l10n/es.js
+++ b/ui/l10n/es.js
@@ -101,6 +101,7 @@ var dictionary = {
"label.accounts": "Cuentas",
"label.acl": "ACL",
"label.acl.id": "ID de ACL",
+"label.acl.export": "Export ACLs",
"label.acl.list.rules": "Lista de Reglas ACL",
"label.acl.name": "Nombre de ACL",
"label.acl.replaced": "ACL reemplazada",
diff --git a/ui/l10n/fr_FR.js b/ui/l10n/fr_FR.js
index 2d03b64dcaa..42f93c0534b 100644
--- a/ui/l10n/fr_FR.js
+++ b/ui/l10n/fr_FR.js
@@ -101,6 +101,7 @@ var dictionary = {
"label.accounts": "Comptes",
"label.acl": "ACL",
"label.acl.id": "ID ACL",
+"label.acl.export": "Export ACLs",
"label.acl.list.rules": "Liste règles ACL",
"label.acl.name": "Nom ACL",
"label.acl.replaced": "ACL remplacée",
diff --git a/ui/l10n/hu.js b/ui/l10n/hu.js
index f4d20e5be1c..41edd47fdc7 100644
--- a/ui/l10n/hu.js
+++ b/ui/l10n/hu.js
@@ -101,6 +101,7 @@ var dictionary = {
"label.accounts": "Számlák",
[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16405969#comment-16405969 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-374519572 @blueorangutan test This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16405970#comment-16405970 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-374519699 @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10320) Invalid pair for response object breaking response parsing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16405923#comment-16405923
]
ASF GitHub Bot commented on CLOUDSTACK-10320:
-
DaanHoogland commented on issue #2481: CLOUDSTACK-10320 - Invalid pair for
response object breaking response parsing
URL: https://github.com/apache/cloudstack/pull/2481#issuecomment-374505072
Good experiment @marcaurele , I have no stress test env at my disposal so i
can not verify. I am worried that my question is blocking your fix. Let's try
to separate the fix and the improvement.
Is the transaction failing as a solution to the bug if the isolation level
isn't changed as well?
* If it is, let's merge as is.
* If it isn't (but performing badly) let's merge it as transaction.
In both cases we can create a ticket to track it further, ok?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Invalid pair for response object breaking response parsing
> --
>
> Key: CLOUDSTACK-10320
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10320
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Reporter: Marc-Aurèle Brothier
>Assignee: Marc-Aurèle Brothier
>Priority: Major
>
> Under some circumstances, the API is returning an invalid response, for
> simplicity I will expose the JSON case. The API response on a
> listVirtualMachines can be this string:
> {code:java}
> { "listvirtualmachinesresponse" : ] } }{code}
> To understand how this is possible, assume you have more than one management
> server and one is processing the destroy of a virtual machine in the account
> X which is the only one it has. Another process is returning the result of
> listVirtualMachines for that same account X. During the listVM command, the
> result set is fetch with a searchAndDistinctCount due to the view
> ([https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/query/QueryManagerImpl.java#L1024).]
> This is done through 2 queries in the GenericDao
> [https://github.com/apache/cloudstack/blob/master/framework/db/src/main/java/com/cloud/utils/db/GenericDaoBase.java#L1323]
> and if you encounter the _right_ conditions, the VM will be marked as
> removed in between those 2 queries. This results in having a Pair result with
> at least one object but a count of 0. Then following how is done the
> serialization of the response at
> [https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/response/ApiResponseSerializer.java#L86]
> you will reach the case where your output is the one previously mentioned.
> To overcome this issue, there isn't a true fix but only a better pair
> response to ensure a correct response formatting. If the result set contains
> at least something, the count cannot be 0 but we cannot guess the correct
> answer, but only state it has at least one element.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
