[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398104#comment-16398104 ] ASF GitHub Bot commented on CLOUDSTACK-10241: - blueorangutan commented on issue #2414: [CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools URL: https://github.com/apache/cloudstack/pull/2414#issuecomment-372904377 Trillian test result (tid-2355) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 18301 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2414-t2355-kvm-centos7.zip Smoke tests completed. 67 look OK, 0 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- 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 > Duplicated file SRs being created in XenServer pools > > > Key: CLOUDSTACK-10241 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241 > 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 > > Due to a race condition between multiple management servers, in some rare > cases, CloudStack is creating multiple file SRs to the same secondary folder. > This causes a problem when introducing the SR to the XenServer pools, as > “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they > are seen in different SRs, and therefore cause an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10321) CPU Cap for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397989#comment-16397989 ] ASF GitHub Bot commented on CLOUDSTACK-10321: - blueorangutan commented on issue #2482: CLOUDSTACK-10321: CPU Cap for KVM URL: https://github.com/apache/cloudstack/pull/2482#issuecomment-372881724 Trillian test result (tid-2354) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 25459 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2482-t2354-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_deploy_virtio_scsi_vm.py Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py Smoke tests completed. 66 look OK, 1 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_03_vpc_privategw_restart_vpc_cleanup | `Failure` | 152.14 | test_privategw_acl.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 > CPU Cap for KVM > --- > > Key: CLOUDSTACK-10321 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10321 > 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 > -- 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=16397918#comment-16397918 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - rafaelweingartner opened a new pull request #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486 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. Attached is a screenshot to show how the migrate option will look like:  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
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397829#comment-16397829 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - blueorangutan commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-372852799 @DaanHoogland 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 > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397826#comment-16397826 ] ASF GitHub Bot commented on CLOUDSTACK-10241: - DaanHoogland commented on issue #2414: [CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools URL: https://github.com/apache/cloudstack/pull/2414#issuecomment-372852781 @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 > Duplicated file SRs being created in XenServer pools > > > Key: CLOUDSTACK-10241 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241 > 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 > > Due to a race condition between multiple management servers, in some rare > cases, CloudStack is creating multiple file SRs to the same secondary folder. > This causes a problem when introducing the SR to the XenServer pools, as > “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they > are seen in different SRs, and therefore cause an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397827#comment-16397827 ] ASF GitHub Bot commented on CLOUDSTACK-10241: - blueorangutan commented on issue #2414: [CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools URL: https://github.com/apache/cloudstack/pull/2414#issuecomment-372852794 @DaanHoogland 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 > Duplicated file SRs being created in XenServer pools > > > Key: CLOUDSTACK-10241 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241 > 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 > > Due to a race condition between multiple management servers, in some rare > cases, CloudStack is creating multiple file SRs to the same secondary folder. > This causes a problem when introducing the SR to the XenServer pools, as > “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they > are seen in different SRs, and therefore cause an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397825#comment-16397825 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - DaanHoogland commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-372852585 @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 > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10319) Prefer TLSv1.2 and deprecate TLS 1.0/1.1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397680#comment-16397680 ] ASF GitHub Bot commented on CLOUDSTACK-10319: - rafaelweingartner commented on issue #2480: CLOUDSTACK-10319: Prefer TLSv1.2, deprecate TLSv1.0,1.1 URL: https://github.com/apache/cloudstack/pull/2480#issuecomment-372824276 @rhtyd have you tested this one against XenServer 6.5? 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 > Prefer TLSv1.2 and deprecate TLS 1.0/1.1 > > > Key: CLOUDSTACK-10319 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10319 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > TLS 1.0 and 1.1 are both recommended to not be used. The aim would be to make > cloudstack prefer tls 1.2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397587#comment-16397587 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - blueorangutan commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-372804499 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1775 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 > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397585#comment-16397585 ] ASF GitHub Bot commented on CLOUDSTACK-10241: - blueorangutan commented on issue #2414: [CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools URL: https://github.com/apache/cloudstack/pull/2414#issuecomment-372804066 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1774 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 > Duplicated file SRs being created in XenServer pools > > > Key: CLOUDSTACK-10241 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241 > 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 > > Due to a race condition between multiple management servers, in some rare > cases, CloudStack is creating multiple file SRs to the same secondary folder. > This causes a problem when introducing the SR to the XenServer pools, as > “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they > are seen in different SRs, and therefore cause an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10310) KVM hosts reboot if there is a short transient storage error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397555#comment-16397555 ] ASF GitHub Bot commented on CLOUDSTACK-10310: - Slair1 commented on issue #2472: CLOUDSTACK-10310 Fix KVM reboot on storage issue URL: https://github.com/apache/cloudstack/pull/2472#issuecomment-372797350 @wido My opinion is that the ability to start a VM on two hosts in the cluster is a bigger issue. We run KVM and just enabled libvirt's lockd to stop that from being able to happen. Maybe this PR could be changed to be an option, just reboot host or stop agent. https://libvirt.org/locking-lockd.html 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 > KVM hosts reboot if there is a short transient storage error > > > Key: CLOUDSTACK-10310 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10310 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.9.0, 4.10.0.0 >Reporter: Sean Lair >Priority: Major > > If the KVM heartbeat file can't be written to, the host is rebooted, and thus > taking down all VMs running on it. The code does try 5x times before the > reboot, but the there is not a delay between the retires, so they are 5 > simultaneous retries, which doesn't help. Standard SAN storage HA operations > or quick network blip could cause this reboot to occur. > Some discussions on the dev mailing list revealed that some people are just > commenting out the reboot line in their version of the CloudStack source. > A better option (and a new PR is being issued) would be have it sleep between > tries so it isn't 5x almost simultaneous tries. Plus, instead of rebooting, > the cloudstack-agent could just be stopped on the host instead. This will > cause alerts to be issued and if the host is disconnected long-enough, > depending on the HA code in use, VM HA could handle the host failure. > The built-in reboot of the host seemed drastic -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397557#comment-16397557 ] ASF GitHub Bot commented on CLOUDSTACK-10309: - rafaelweingartner commented on issue #2473: CLOUDSTACK-10309 Add option on if to VM HA power-on a OOB-shut-off-VM URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-372797423 I actually meant unit tests. I think they would fit better the method extraction. They would also be easier to develop. Once you get to create them, if you are unsure how to proceed, just ping me. I can help you. 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 > VMs with HA enabled, power back on if shutdown from guest OS > > > Key: CLOUDSTACK-10309 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0, 4.10.0.0 > Environment: KVM >Reporter: Sean Lair >Priority: Minor > > When a user shuts down their VM from the guest OS (and VM HA is enabled), the > VM just powers itself back on. Our environment is on KVM hosts. > CloudStack does not know the difference between a VM failing or being > shutdown from within the guest OS. > This is a major pain point for all our users - especially since they don't > pay for VMs when they are shutoff. It is not intuitive for end-users to > understand why they can't shutdown VMs from within the guest OS. Especially > when they all come from (non-cloudstack) VMware and Hyper-V environments > where this is not an issue. > However, if a host fails, we need VM HA to still work. > This Issue is being tied to a new PR that creates a configuration option > "ha.vm.restart.hostup". With this option set to false, if CloudStack sees a > VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then > it won't power it back on. The logic is that since the host is online, it > was most likely shutdown from the guest OS. > For when a host actually fails, standard VM HA logic takes over and powers on > VMs (with VM HA enabled) if the host they were on fails. > If that "ha.vm.restart.hostup" option is true (the default to match current > functionality), it works like always, and even in-guest shutdowns of VMs > causes CloudStack to power back on the VM. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397551#comment-16397551 ] ASF GitHub Bot commented on CLOUDSTACK-10309: - Slair1 commented on issue #2473: CLOUDSTACK-10309 Add option on if to VM HA power-on a OOB-shut-off-VM URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-372796545 I've never created a Marvin Test before, but can look at test_vm_life_cycle.py to try and figure it out 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 > VMs with HA enabled, power back on if shutdown from guest OS > > > Key: CLOUDSTACK-10309 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0, 4.10.0.0 > Environment: KVM >Reporter: Sean Lair >Priority: Minor > > When a user shuts down their VM from the guest OS (and VM HA is enabled), the > VM just powers itself back on. Our environment is on KVM hosts. > CloudStack does not know the difference between a VM failing or being > shutdown from within the guest OS. > This is a major pain point for all our users - especially since they don't > pay for VMs when they are shutoff. It is not intuitive for end-users to > understand why they can't shutdown VMs from within the guest OS. Especially > when they all come from (non-cloudstack) VMware and Hyper-V environments > where this is not an issue. > However, if a host fails, we need VM HA to still work. > This Issue is being tied to a new PR that creates a configuration option > "ha.vm.restart.hostup". With this option set to false, if CloudStack sees a > VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then > it won't power it back on. The logic is that since the host is online, it > was most likely shutdown from the guest OS. > For when a host actually fails, standard VM HA logic takes over and powers on > VMs (with VM HA enabled) if the host they were on fails. > If that "ha.vm.restart.hostup" option is true (the default to match current > functionality), it works like always, and even in-guest shutdowns of VMs > causes CloudStack to power back on the VM. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397548#comment-16397548
]
ASF GitHub Bot commented on CLOUDSTACK-10309:
-
Slair1 commented on a change in pull request #2473: CLOUDSTACK-10309 Add option
on if to VM HA power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473#discussion_r174262477
##
File path: engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
##
@@ -3853,7 +3856,7 @@ private void
handlePowerOffReportWithNoPendingJobsOnVM(final VMInstanceVO vm) {
case Stopped:
case Migrating:
s_logger.info("VM " + vm.getInstanceName() + " is at " +
vm.getState() + " and we received a power-off report while there is no pending
jobs on it");
-if(vm.isHaEnabled() && vm.getState() == State.Running &&
vm.getHypervisorType() != HypervisorType.VMware && vm.getHypervisorType() !=
HypervisorType.Hyperv) {
+if(vm.isHaEnabled() && vm.getState() == State.Running &&
HaVmRestartHostUp.value() && vm.getHypervisorType() != HypervisorType.VMware &&
vm.getHypervisorType() != HypervisorType.Hyperv) {
Review comment:
Yea, that sounds like a good idea, i am booked up here for a while, but it
sounds like a good idea
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
> VMs with HA enabled, power back on if shutdown from guest OS
>
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the
> VM just powers itself back on. Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't
> pay for VMs when they are shutoff. It is not intuitive for end-users to
> understand why they can't shutdown VMs from within the guest OS. Especially
> when they all come from (non-cloudstack) VMware and Hyper-V environments
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option
> "ha.vm.restart.hostup". With this option set to false, if CloudStack sees a
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then
> it won't power it back on. The logic is that since the host is online, it
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current
> functionality), it works like always, and even in-guest shutdowns of VMs
> causes CloudStack to power back on the VM.
>
--
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=16397547#comment-16397547
]
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-372795650
Since this is the same as #2429, should we just back-merge that?
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-10246) VM HA issues
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397534#comment-16397534 ] ASF GitHub Bot commented on CLOUDSTACK-10246: - Slair1 commented on issue #2474: CLOUDSTACK-10246 Fix Host HA and VM HA issues URL: https://github.com/apache/cloudstack/pull/2474#issuecomment-372794000 Yea, i can work to modularize this, i unfortunately don't have the time at the moment, but can later. On the tests, do you mean Unit Tests? I've never wrote a unit test before, but agree it would be good to have 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 > VM HA issues > > > Key: CLOUDSTACK-10246 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10246 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.11.0.0 > Environment: My setup is CentOS 7 Management server with 3 CentOS 7 > KVM HVs, NFS as primary and secondary storages. >Reporter: Nux >Priority: Major > > VM HA fails to kick in when one of the hypervisors goes down. > It even fails to restart the system VMs which remain down along with the > instances until the affected HV comes back online. > When I crash or power off the HV the system marks it in the hosts list as > "Alert" or "Disconnected" respectively. It should get changed to "Down" after > that, but this never happens. > > I have tried various combinations of setups (Adv, Basic), none succeeded. > > My instances use HA enabled offerings. > Management server DEBUG logs here: > [http://tmp.nux.ro/CW4-vmhafail-411rc1.txt] > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10310) KVM hosts reboot if there is a short transient storage error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397530#comment-16397530 ] ASF GitHub Bot commented on CLOUDSTACK-10310: - Slair1 commented on a change in pull request #2472: CLOUDSTACK-10310 Fix KVM reboot on storage issue URL: https://github.com/apache/cloudstack/pull/2472#discussion_r174260156 ## File path: scripts/vm/hypervisor/kvm/kvmheartbeat.sh ## @@ -155,10 +155,10 @@ then exit 0 elif [ "$cflag" == "1" ] then - /usr/bin/logger -t heartbeat "kvmheartbeat.sh rebooted system because it was unable to write the heartbeat to the storage." + /usr/bin/logger -t heartbeat "kvmheartbeat.sh stopped cloudstack-agent because it was unable to write the heartbeat to the storage." sync & sleep 5 - echo b > /proc/sysrq-trigger + service cloudstack-agent stop Review comment: Sorry for the delayed response, i have been out of town for the last week. Yea, i'm OK with a global parameter. i'd just have to sit down and determine how to do that. I could likely just make it a parameter passed to the script... 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 > KVM hosts reboot if there is a short transient storage error > > > Key: CLOUDSTACK-10310 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10310 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.9.0, 4.10.0.0 >Reporter: Sean Lair >Priority: Major > > If the KVM heartbeat file can't be written to, the host is rebooted, and thus > taking down all VMs running on it. The code does try 5x times before the > reboot, but the there is not a delay between the retires, so they are 5 > simultaneous retries, which doesn't help. Standard SAN storage HA operations > or quick network blip could cause this reboot to occur. > Some discussions on the dev mailing list revealed that some people are just > commenting out the reboot line in their version of the CloudStack source. > A better option (and a new PR is being issued) would be have it sleep between > tries so it isn't 5x almost simultaneous tries. Plus, instead of rebooting, > the cloudstack-agent could just be stopped on the host instead. This will > cause alerts to be issued and if the host is disconnected long-enough, > depending on the HA code in use, VM HA could handle the host failure. > The built-in reboot of the host seemed drastic -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397519#comment-16397519
]
ASF GitHub Bot commented on CLOUDSTACK-10241:
-
DaanHoogland commented on a change in pull request #2414: [CLOUDSTACK-10241]
Duplicated file SRs being created in XenServer pools
URL: https://github.com/apache/cloudstack/pull/2414#discussion_r174258152
##
File path:
plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
##
@@ -65,90 +69,181 @@ public Xenserver625StorageProcessor(final
CitrixResourceBase resource) {
super(resource);
}
-protected boolean mountNfs(final Connection conn, final String remoteDir,
String localDir) {
+private void mountNfs(Connection conn, String remoteDir, String localDir) {
if (localDir == null) {
localDir = "/var/cloud_mount/" +
UUID.nameUUIDFromBytes(remoteDir.getBytes());
}
-
-final String results = hypervisorResource.callHostPluginAsync(conn,
"cloud-plugin-storage", "mountNfsSecondaryStorage", 100 * 1000, "localDir",
localDir, "remoteDir",
-remoteDir);
-
-if (results == null || results.isEmpty()) {
+String result = hypervisorResource.callHostPluginAsync(conn,
"cloud-plugin-storage", "mountNfsSecondaryStorage", 100 * 1000, "localDir",
localDir, "remoteDir", remoteDir);
+if (StringUtils.isBlank(result)) {
final String errMsg = "Could not mount secondary storage " +
remoteDir + " on host " + localDir;
-
s_logger.warn(errMsg);
-
throw new CloudRuntimeException(errMsg);
}
-
-return true;
}
-protected boolean makeDirectory(final Connection conn, final String path) {
-final String result = hypervisorResource.callHostPlugin(conn,
"cloud-plugin-storage", "makeDirectory", "path", path);
+protected boolean makeDirectory(Connection conn, String path) {
Review comment:
:+1:
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
> Duplicated file SRs being created in XenServer pools
>
>
> Key: CLOUDSTACK-10241
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241
> 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
>
> Due to a race condition between multiple management servers, in some rare
> cases, CloudStack is creating multiple file SRs to the same secondary folder.
> This causes a problem when introducing the SR to the XenServer pools, as
> “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they
> are seen in different SRs, and therefore cause an error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397517#comment-16397517
]
ASF GitHub Bot commented on CLOUDSTACK-10241:
-
DaanHoogland commented on a change in pull request #2414: [CLOUDSTACK-10241]
Duplicated file SRs being created in XenServer pools
URL: https://github.com/apache/cloudstack/pull/2414#discussion_r174258066
##
File path:
plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
##
@@ -65,90 +69,181 @@ public Xenserver625StorageProcessor(final
CitrixResourceBase resource) {
super(resource);
}
-protected boolean mountNfs(final Connection conn, final String remoteDir,
String localDir) {
+private void mountNfs(Connection conn, String remoteDir, String localDir) {
if (localDir == null) {
localDir = "/var/cloud_mount/" +
UUID.nameUUIDFromBytes(remoteDir.getBytes());
}
-
-final String results = hypervisorResource.callHostPluginAsync(conn,
"cloud-plugin-storage", "mountNfsSecondaryStorage", 100 * 1000, "localDir",
localDir, "remoteDir",
-remoteDir);
-
-if (results == null || results.isEmpty()) {
+String result = hypervisorResource.callHostPluginAsync(conn,
"cloud-plugin-storage", "mountNfsSecondaryStorage", 100 * 1000, "localDir",
localDir, "remoteDir", remoteDir);
Review comment:
ok, short method with low cyclic complexity; makes sense
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
> Duplicated file SRs being created in XenServer pools
>
>
> Key: CLOUDSTACK-10241
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241
> 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
>
> Due to a race condition between multiple management servers, in some rare
> cases, CloudStack is creating multiple file SRs to the same secondary folder.
> This causes a problem when introducing the SR to the XenServer pools, as
> “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they
> are seen in different SRs, and therefore cause an error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397513#comment-16397513 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - blueorangutan commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-372790381 @DaanHoogland 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 > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397511#comment-16397511 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - DaanHoogland commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-372790077 I'm afraid this is not public and the error is a git clone/fetch problem in this case; ERROR: Timeout after 10 minutes ERROR: Error cloning remote repo 'origin' nothing to do with your change, i suppose. Let's see if insanity helps: @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 > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10321) CPU Cap for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397504#comment-16397504 ] ASF GitHub Bot commented on CLOUDSTACK-10321: - rafaelweingartner commented on issue #2482: CLOUDSTACK-10321: CPU Cap for KVM URL: https://github.com/apache/cloudstack/pull/2482#issuecomment-372788605 Yes! 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 > CPU Cap for KVM > --- > > Key: CLOUDSTACK-10321 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10321 > 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 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397503#comment-16397503
]
ASF GitHub Bot commented on CLOUDSTACK-10241:
-
rafaelweingartner commented on a change in pull request #2414:
[CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools
URL: https://github.com/apache/cloudstack/pull/2414#discussion_r174255133
##
File path:
plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
##
@@ -65,90 +69,181 @@ public Xenserver625StorageProcessor(final
CitrixResourceBase resource) {
super(resource);
}
-protected boolean mountNfs(final Connection conn, final String remoteDir,
String localDir) {
+private void mountNfs(Connection conn, String remoteDir, String localDir) {
if (localDir == null) {
localDir = "/var/cloud_mount/" +
UUID.nameUUIDFromBytes(remoteDir.getBytes());
}
-
-final String results = hypervisorResource.callHostPluginAsync(conn,
"cloud-plugin-storage", "mountNfsSecondaryStorage", 100 * 1000, "localDir",
localDir, "remoteDir",
-remoteDir);
-
-if (results == null || results.isEmpty()) {
+String result = hypervisorResource.callHostPluginAsync(conn,
"cloud-plugin-storage", "mountNfsSecondaryStorage", 100 * 1000, "localDir",
localDir, "remoteDir", remoteDir);
+if (StringUtils.isBlank(result)) {
final String errMsg = "Could not mount secondary storage " +
remoteDir + " on host " + localDir;
-
s_logger.warn(errMsg);
-
throw new CloudRuntimeException(errMsg);
}
-
-return true;
}
-protected boolean makeDirectory(final Connection conn, final String path) {
-final String result = hypervisorResource.callHostPlugin(conn,
"cloud-plugin-storage", "makeDirectory", "path", path);
+protected boolean makeDirectory(Connection conn, String path) {
Review comment:
Because it is useless in this context.
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
> Duplicated file SRs being created in XenServer pools
>
>
> Key: CLOUDSTACK-10241
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241
> 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
>
> Due to a race condition between multiple management servers, in some rare
> cases, CloudStack is creating multiple file SRs to the same secondary folder.
> This causes a problem when introducing the SR to the XenServer pools, as
> “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they
> are seen in different SRs, and therefore cause an error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397502#comment-16397502
]
ASF GitHub Bot commented on CLOUDSTACK-10241:
-
rafaelweingartner commented on a change in pull request #2414:
[CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools
URL: https://github.com/apache/cloudstack/pull/2414#discussion_r174254978
##
File path:
plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
##
@@ -65,90 +69,181 @@ public Xenserver625StorageProcessor(final
CitrixResourceBase resource) {
super(resource);
}
-protected boolean mountNfs(final Connection conn, final String remoteDir,
String localDir) {
+private void mountNfs(Connection conn, String remoteDir, String localDir) {
if (localDir == null) {
localDir = "/var/cloud_mount/" +
UUID.nameUUIDFromBytes(remoteDir.getBytes());
}
-
-final String results = hypervisorResource.callHostPluginAsync(conn,
"cloud-plugin-storage", "mountNfsSecondaryStorage", 100 * 1000, "localDir",
localDir, "remoteDir",
-remoteDir);
-
-if (results == null || results.isEmpty()) {
+String result = hypervisorResource.callHostPluginAsync(conn,
"cloud-plugin-storage", "mountNfsSecondaryStorage", 100 * 1000, "localDir",
localDir, "remoteDir", remoteDir);
Review comment:
Of course, they are. However, here and in a lot of places in ACS, there is
an indiscriminate use of the final keyword. It does not harm, but it is
something I have to read when reviewing/coding, which does not aggregate/help.
So, I remove when they are not needed.
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
> Duplicated file SRs being created in XenServer pools
>
>
> Key: CLOUDSTACK-10241
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241
> 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
>
> Due to a race condition between multiple management servers, in some rare
> cases, CloudStack is creating multiple file SRs to the same secondary folder.
> This causes a problem when introducing the SR to the XenServer pools, as
> “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they
> are seen in different SRs, and therefore cause an error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10321) CPU Cap for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397500#comment-16397500 ] ASF GitHub Bot commented on CLOUDSTACK-10321: - DaanHoogland commented on issue #2482: CLOUDSTACK-10321: CPU Cap for KVM URL: https://github.com/apache/cloudstack/pull/2482#issuecomment-372787909 @rafaelweingartner is this lgty? 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 > CPU Cap for KVM > --- > > Key: CLOUDSTACK-10321 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10321 > 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 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397495#comment-16397495 ] ASF GitHub Bot commented on CLOUDSTACK-10241: - DaanHoogland commented on issue #2414: [CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools URL: https://github.com/apache/cloudstack/pull/2414#issuecomment-372787156 @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 > Duplicated file SRs being created in XenServer pools > > > Key: CLOUDSTACK-10241 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241 > 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 > > Due to a race condition between multiple management servers, in some rare > cases, CloudStack is creating multiple file SRs to the same secondary folder. > This causes a problem when introducing the SR to the XenServer pools, as > “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they > are seen in different SRs, and therefore cause an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397496#comment-16397496 ] ASF GitHub Bot commented on CLOUDSTACK-10241: - blueorangutan commented on issue #2414: [CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools URL: https://github.com/apache/cloudstack/pull/2414#issuecomment-372787213 @DaanHoogland 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 > Duplicated file SRs being created in XenServer pools > > > Key: CLOUDSTACK-10241 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241 > 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 > > Due to a race condition between multiple management servers, in some rare > cases, CloudStack is creating multiple file SRs to the same secondary folder. > This causes a problem when introducing the SR to the XenServer pools, as > “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they > are seen in different SRs, and therefore cause an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397494#comment-16397494
]
ASF GitHub Bot commented on CLOUDSTACK-10241:
-
DaanHoogland commented on a change in pull request #2414: [CLOUDSTACK-10241]
Duplicated file SRs being created in XenServer pools
URL: https://github.com/apache/cloudstack/pull/2414#discussion_r174252867
##
File path:
plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
##
@@ -65,90 +69,181 @@ public Xenserver625StorageProcessor(final
CitrixResourceBase resource) {
super(resource);
}
-protected boolean mountNfs(final Connection conn, final String remoteDir,
String localDir) {
+private void mountNfs(Connection conn, String remoteDir, String localDir) {
if (localDir == null) {
localDir = "/var/cloud_mount/" +
UUID.nameUUIDFromBytes(remoteDir.getBytes());
}
-
-final String results = hypervisorResource.callHostPluginAsync(conn,
"cloud-plugin-storage", "mountNfsSecondaryStorage", 100 * 1000, "localDir",
localDir, "remoteDir",
-remoteDir);
-
-if (results == null || results.isEmpty()) {
+String result = hypervisorResource.callHostPluginAsync(conn,
"cloud-plugin-storage", "mountNfsSecondaryStorage", 100 * 1000, "localDir",
localDir, "remoteDir", remoteDir);
Review comment:
final not allowed?
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
> Duplicated file SRs being created in XenServer pools
>
>
> Key: CLOUDSTACK-10241
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241
> 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
>
> Due to a race condition between multiple management servers, in some rare
> cases, CloudStack is creating multiple file SRs to the same secondary folder.
> This causes a problem when introducing the SR to the XenServer pools, as
> “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they
> are seen in different SRs, and therefore cause an error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397493#comment-16397493
]
ASF GitHub Bot commented on CLOUDSTACK-10241:
-
DaanHoogland commented on a change in pull request #2414: [CLOUDSTACK-10241]
Duplicated file SRs being created in XenServer pools
URL: https://github.com/apache/cloudstack/pull/2414#discussion_r174253018
##
File path:
plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
##
@@ -65,90 +69,181 @@ public Xenserver625StorageProcessor(final
CitrixResourceBase resource) {
super(resource);
}
-protected boolean mountNfs(final Connection conn, final String remoteDir,
String localDir) {
+private void mountNfs(Connection conn, String remoteDir, String localDir) {
if (localDir == null) {
localDir = "/var/cloud_mount/" +
UUID.nameUUIDFromBytes(remoteDir.getBytes());
}
-
-final String results = hypervisorResource.callHostPluginAsync(conn,
"cloud-plugin-storage", "mountNfsSecondaryStorage", 100 * 1000, "localDir",
localDir, "remoteDir",
-remoteDir);
-
-if (results == null || results.isEmpty()) {
+String result = hypervisorResource.callHostPluginAsync(conn,
"cloud-plugin-storage", "mountNfsSecondaryStorage", 100 * 1000, "localDir",
localDir, "remoteDir", remoteDir);
+if (StringUtils.isBlank(result)) {
final String errMsg = "Could not mount secondary storage " +
remoteDir + " on host " + localDir;
-
s_logger.warn(errMsg);
-
throw new CloudRuntimeException(errMsg);
}
-
-return true;
}
-protected boolean makeDirectory(final Connection conn, final String path) {
-final String result = hypervisorResource.callHostPlugin(conn,
"cloud-plugin-storage", "makeDirectory", "path", path);
+protected boolean makeDirectory(Connection conn, String path) {
Review comment:
why removing the final?
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
> Duplicated file SRs being created in XenServer pools
>
>
> Key: CLOUDSTACK-10241
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241
> 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
>
> Due to a race condition between multiple management servers, in some rare
> cases, CloudStack is creating multiple file SRs to the same secondary folder.
> This causes a problem when introducing the SR to the XenServer pools, as
> “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they
> are seen in different SRs, and therefore cause an error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-8855) Improve Error Message for Host Alert State
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397482#comment-16397482
]
ASF GitHub Bot commented on CLOUDSTACK-8855:
DaanHoogland commented on a change in pull request #2387: CLOUDSTACK-8855
Improve Error Message for Host Alert State and reconnect host API.
URL: https://github.com/apache/cloudstack/pull/2387#discussion_r174250100
##
File path:
engine/orchestration/src/main/java/com/cloud/agent/manager/AgentManagerImpl.java
##
@@ -122,7 +122,6 @@
**/
public class AgentManagerImpl extends ManagerBase implements AgentManager,
HandlerFactory, Configurable {
protected static final Logger s_logger =
Logger.getLogger(AgentManagerImpl.class);
-protected static final Logger status_logger =
Logger.getLogger(Status.class);
Review comment:
this seems a functional backwards incompatible change. Did you considder
that?
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
> Improve Error Message for Host Alert State
> --
>
> Key: CLOUDSTACK-8855
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8855
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-8855) Improve Error Message for Host Alert State
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397483#comment-16397483
]
ASF GitHub Bot commented on CLOUDSTACK-8855:
DaanHoogland commented on a change in pull request #2387: CLOUDSTACK-8855
Improve Error Message for Host Alert State and reconnect host API.
URL: https://github.com/apache/cloudstack/pull/2387#discussion_r174251431
##
File path: server/src/main/java/com/cloud/alert/AlertManagerImpl.java
##
@@ -85,10 +80,12 @@
import com.cloud.utils.component.ManagerBase;
import com.cloud.utils.concurrency.NamedThreadFactory;
import com.cloud.utils.db.SearchCriteria;
+import com.sun.mail.smtp.SMTPMessage;
+import com.sun.mail.smtp.SMTPSSLTransport;
+import com.sun.mail.smtp.SMTPTransport;
public class AlertManagerImpl extends ManagerBase implements AlertManager,
Configurable {
private static final Logger s_logger =
Logger.getLogger(AlertManagerImpl.class.getName());
-private static final Logger s_alertsLogger =
Logger.getLogger("org.apache.cloudstack.alerts");
Review comment:
another interface change! Please realise that this is incompatible!
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
> Improve Error Message for Host Alert State
> --
>
> Key: CLOUDSTACK-8855
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8855
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-8855) Improve Error Message for Host Alert State
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397484#comment-16397484
]
ASF GitHub Bot commented on CLOUDSTACK-8855:
DaanHoogland commented on a change in pull request #2387: CLOUDSTACK-8855
Improve Error Message for Host Alert State and reconnect host API.
URL: https://github.com/apache/cloudstack/pull/2387#discussion_r174248061
##
File path:
plugins/network-elements/netscaler/src/main/java/com/cloud/network/element/NetscalerElement.java
##
@@ -759,7 +759,11 @@ public void
doInTransactionWithoutResult(TransactionStatus status) {
});
HostVO host = _hostDao.findById(lbDeviceVo.getHostId());
-_agentMgr.reconnect(host.getId());
+try {
+_agentMgr.reconnect(host.getId());
+} catch (Exception e ) {
Review comment:
Pokemon?
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
> Improve Error Message for Host Alert State
> --
>
> Key: CLOUDSTACK-8855
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8855
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.6.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10321) CPU Cap for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397455#comment-16397455 ] ASF GitHub Bot commented on CLOUDSTACK-10321: - blueorangutan commented on issue #2482: CLOUDSTACK-10321: CPU Cap for KVM URL: https://github.com/apache/cloudstack/pull/2482#issuecomment-372774844 @nvazquez 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 > CPU Cap for KVM > --- > > Key: CLOUDSTACK-10321 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10321 > 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 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10321) CPU Cap for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397452#comment-16397452 ] ASF GitHub Bot commented on CLOUDSTACK-10321: - nvazquez commented on issue #2482: CLOUDSTACK-10321: CPU Cap for KVM URL: https://github.com/apache/cloudstack/pull/2482#issuecomment-372774591 @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 > CPU Cap for KVM > --- > > Key: CLOUDSTACK-10321 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10321 > 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 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10321) CPU Cap for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397426#comment-16397426 ] ASF GitHub Bot commented on CLOUDSTACK-10321: - blueorangutan commented on issue #2482: CLOUDSTACK-10321: CPU Cap for KVM URL: https://github.com/apache/cloudstack/pull/2482#issuecomment-372770183 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1773 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 > CPU Cap for KVM > --- > > Key: CLOUDSTACK-10321 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10321 > 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 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397412#comment-16397412 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - khos2ow commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-372766474 @DaanHoogland is there a way to see the error of packaging? I believe this is related to #2485 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 > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10296) Fix timestamp difference in heartbeat script for rVRs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397407#comment-16397407 ] ASF GitHub Bot commented on CLOUDSTACK-10296: - blueorangutan commented on issue #2458: CLOUDSTACK-10296: Find time different from last timestamp URL: https://github.com/apache/cloudstack/pull/2458#issuecomment-372764753 Trillian test result (tid-2352) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 24890 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2458-t2352-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py Smoke tests completed. 65 look OK, 2 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_04_rvpc_network_garbage_collector_nics | `Failure` | 516.31 | test_vpc_redundant.py test_hostha_enable_ha_when_host_in_maintenance | `Error` | 1.78 | 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 > Fix timestamp difference in heartbeat script for rVRs > - > > Key: CLOUDSTACK-10296 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10296 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0, 4.9.3.0 >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.11.1.1 > > > Raised recently on dev@ ML by Jayakartheek, the difference code in heartbeat > checker script for rVRs wrongly take difference, that will always be less > than or equal to 0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10321) CPU Cap for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397363#comment-16397363 ] ASF GitHub Bot commented on CLOUDSTACK-10321: - blueorangutan commented on issue #2482: CLOUDSTACK-10321: CPU Cap for KVM URL: https://github.com/apache/cloudstack/pull/2482#issuecomment-372756966 @nvazquez 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 > CPU Cap for KVM > --- > > Key: CLOUDSTACK-10321 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10321 > 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 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10321) CPU Cap for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397361#comment-16397361 ] ASF GitHub Bot commented on CLOUDSTACK-10321: - nvazquez commented on issue #2482: CLOUDSTACK-10321: CPU Cap for KVM URL: https://github.com/apache/cloudstack/pull/2482#issuecomment-372756801 @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 > CPU Cap for KVM > --- > > Key: CLOUDSTACK-10321 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10321 > 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 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10303) refactor plugins/nuagevsp tests to run from its own test_data.py file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397353#comment-16397353 ] ASF GitHub Bot commented on CLOUDSTACK-10303: - blueorangutan commented on issue #2483: CLOUDSTACK-10303 : test data to nuage_test_data.py + run all tests against simulator URL: https://github.com/apache/cloudstack/pull/2483#issuecomment-372756102 Packaging result: ✔centos6 ✔centos7 ✖debian. JID-1771 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 > refactor plugins/nuagevsp tests to run from its own test_data.py file > - > > Key: CLOUDSTACK-10303 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10303 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Affects Versions: 4.11.0.0 > Environment: nuagevsp, simulator >Reporter: Raf Smeets >Assignee: Sigert Goeminne >Priority: Major > > refactor plugins/nuagevsp tests to run from its own test_data.py file and > make sure that all nuagevsp tests run with simulator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397355#comment-16397355 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - blueorangutan commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-372756188 Packaging result: ✔centos6 ✔centos7 ✖debian. JID-1772 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 > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397318#comment-16397318 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - khos2ow commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-372748378 @DaanHoogland I see, good to know! 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 > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10147) Disabled Xenserver cluster can still deploy VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397293#comment-16397293 ] ASF GitHub Bot commented on CLOUDSTACK-10147: - DaanHoogland commented on issue #2442: CLOUDSTACK-10147 Disabled Xenserver Cluster can still deploy VM's URL: https://github.com/apache/cloudstack/pull/2442#issuecomment-37273 Hihi, mister Writer pulled into the discussion here once again ;) 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 > Disabled Xenserver cluster can still deploy VMs > > > Key: CLOUDSTACK-10147 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10147 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI >Affects Versions: 4.10.0.0, 4.9.2.0 > Environment: Xenserver 6.2, 7 >Reporter: Glenn Wagner >Assignee: Henko Holtzhausen >Priority: Major > Fix For: 4.12 > > > ENVIRONMENT > = > XenServer Version : 6.2 , 7 > ISSUE > == > Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are > still active > Repro. steps followed > == > Disabled Cluster from UI. > Deploy a new VM > Expected Behavior > === > After disabling the cluster , the hosts should be disabled. and no VM's can > be deployed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397275#comment-16397275 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - blueorangutan commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-372742443 @DaanHoogland 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 > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397274#comment-16397274 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - DaanHoogland commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-372742295 @khos2ow you can do packaging, only test is restricted to us due to resource scheduling/limitations @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 > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10303) refactor plugins/nuagevsp tests to run from its own test_data.py file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397265#comment-16397265 ] ASF GitHub Bot commented on CLOUDSTACK-10303: - blueorangutan commented on issue #2483: CLOUDSTACK-10303 : test data to nuage_test_data.py + run all tests against simulator URL: https://github.com/apache/cloudstack/pull/2483#issuecomment-372741730 @DaanHoogland 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 > refactor plugins/nuagevsp tests to run from its own test_data.py file > - > > Key: CLOUDSTACK-10303 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10303 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Affects Versions: 4.11.0.0 > Environment: nuagevsp, simulator >Reporter: Raf Smeets >Assignee: Sigert Goeminne >Priority: Major > > refactor plugins/nuagevsp tests to run from its own test_data.py file and > make sure that all nuagevsp tests run with simulator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10303) refactor plugins/nuagevsp tests to run from its own test_data.py file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397264#comment-16397264 ] ASF GitHub Bot commented on CLOUDSTACK-10303: - DaanHoogland commented on issue #2483: CLOUDSTACK-10303 : test data to nuage_test_data.py + run all tests against simulator URL: https://github.com/apache/cloudstack/pull/2483#issuecomment-372741426 @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 > refactor plugins/nuagevsp tests to run from its own test_data.py file > - > > Key: CLOUDSTACK-10303 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10303 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Affects Versions: 4.11.0.0 > Environment: nuagevsp, simulator >Reporter: Raf Smeets >Assignee: Sigert Goeminne >Priority: Major > > refactor plugins/nuagevsp tests to run from its own test_data.py file and > make sure that all nuagevsp tests run with simulator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10147) Disabled Xenserver cluster can still deploy VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397258#comment-16397258 ] ASF GitHub Bot commented on CLOUDSTACK-10147: - glennwagner commented on issue #2442: CLOUDSTACK-10147 Disabled Xenserver Cluster can still deploy VM's URL: https://github.com/apache/cloudstack/pull/2442#issuecomment-372739879 LGTM , Thanks guys for the work. 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 > Disabled Xenserver cluster can still deploy VMs > > > Key: CLOUDSTACK-10147 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10147 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI >Affects Versions: 4.10.0.0, 4.9.2.0 > Environment: Xenserver 6.2, 7 >Reporter: Glenn Wagner >Assignee: Henko Holtzhausen >Priority: Major > Fix For: 4.12 > > > ENVIRONMENT > = > XenServer Version : 6.2 , 7 > ISSUE > == > Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are > still active > Repro. steps followed > == > Disabled Cluster from UI. > Deploy a new VM > Expected Behavior > === > After disabling the cluster , the hosts should be disabled. and no VM's can > be deployed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-8855) Improve Error Message for Host Alert State
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397244#comment-16397244 ] ASF GitHub Bot commented on CLOUDSTACK-8855: rafaelweingartner commented on issue #2387: CLOUDSTACK-8855 Improve Error Message for Host Alert State and reconnect host API. URL: https://github.com/apache/cloudstack/pull/2387#issuecomment-372736483 @DaanHoogland done. 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 > Improve Error Message for Host Alert State > -- > > Key: CLOUDSTACK-8855 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8855 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397239#comment-16397239
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
khos2ow commented on issue #2465: CLOUDSTACK-10232: SystemVMs and VR to run as
HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#issuecomment-372735305
@rafaelweingartner I will. The reason for it's not done yet was that we
wanted to partially upgrade Xen cluster and do one round of functional test and
then fully upgrade the cluster and then re-run iperf 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
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
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=16397240#comment-16397240
]
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-372735409
nice find, dirty hack, though maybe justified. Isn't the proper solution to
put both queries in a transaction, @marcaurele ?
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-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397237#comment-16397237 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - khos2ow commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-372734572 @borisstoyanov it might be failing because the last packaging happened long time ago and some part of the PR has been changed since then. We might need to do the BO package once again. 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 > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397232#comment-16397232 ] ASF GitHub Bot commented on CLOUDSTACK-10309: - rafaelweingartner commented on issue #2473: CLOUDSTACK-10309 Add option on if to VM HA power-on a OOB-shut-off-VM URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-372734014 It is ok the code as is. However, it might have been interesting to see the feedback of the author. 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 > VMs with HA enabled, power back on if shutdown from guest OS > > > Key: CLOUDSTACK-10309 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0, 4.10.0.0 > Environment: KVM >Reporter: Sean Lair >Priority: Minor > > When a user shuts down their VM from the guest OS (and VM HA is enabled), the > VM just powers itself back on. Our environment is on KVM hosts. > CloudStack does not know the difference between a VM failing or being > shutdown from within the guest OS. > This is a major pain point for all our users - especially since they don't > pay for VMs when they are shutoff. It is not intuitive for end-users to > understand why they can't shutdown VMs from within the guest OS. Especially > when they all come from (non-cloudstack) VMware and Hyper-V environments > where this is not an issue. > However, if a host fails, we need VM HA to still work. > This Issue is being tied to a new PR that creates a configuration option > "ha.vm.restart.hostup". With this option set to false, if CloudStack sees a > VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then > it won't power it back on. The logic is that since the host is online, it > was most likely shutdown from the guest OS. > For when a host actually fails, standard VM HA logic takes over and powers on > VMs (with VM HA enabled) if the host they were on fails. > If that "ha.vm.restart.hostup" option is true (the default to match current > functionality), it works like always, and even in-guest shutdowns of VMs > causes CloudStack to power back on the VM. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-8855) Improve Error Message for Host Alert State
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397231#comment-16397231 ] ASF GitHub Bot commented on CLOUDSTACK-8855: DaanHoogland commented on issue #2387: CLOUDSTACK-8855 Improve Error Message for Host Alert State and reconnect host API. URL: https://github.com/apache/cloudstack/pull/2387#issuecomment-372733816 @rafaelweingartner sorry for sickness and €dayjob preventing me to review again, can you resolve conflicts? 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 > Improve Error Message for Host Alert State > -- > > Key: CLOUDSTACK-8855 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8855 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397225#comment-16397225 ] ASF GitHub Bot commented on CLOUDSTACK-10309: - DaanHoogland commented on issue #2473: CLOUDSTACK-10309 Add option on if to VM HA power-on a OOB-shut-off-VM URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-372732335 @Slair1 @rafaelweingartner , can you come to agreement (maybe Rafael's sugestion here or in a separate PR?) 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 > VMs with HA enabled, power back on if shutdown from guest OS > > > Key: CLOUDSTACK-10309 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0, 4.10.0.0 > Environment: KVM >Reporter: Sean Lair >Priority: Minor > > When a user shuts down their VM from the guest OS (and VM HA is enabled), the > VM just powers itself back on. Our environment is on KVM hosts. > CloudStack does not know the difference between a VM failing or being > shutdown from within the guest OS. > This is a major pain point for all our users - especially since they don't > pay for VMs when they are shutoff. It is not intuitive for end-users to > understand why they can't shutdown VMs from within the guest OS. Especially > when they all come from (non-cloudstack) VMware and Hyper-V environments > where this is not an issue. > However, if a host fails, we need VM HA to still work. > This Issue is being tied to a new PR that creates a configuration option > "ha.vm.restart.hostup". With this option set to false, if CloudStack sees a > VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then > it won't power it back on. The logic is that since the host is online, it > was most likely shutdown from the guest OS. > For when a host actually fails, standard VM HA logic takes over and powers on > VMs (with VM HA enabled) if the host they were on fails. > If that "ha.vm.restart.hostup" option is true (the default to match current > functionality), it works like always, and even in-guest shutdowns of VMs > causes CloudStack to power back on the VM. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10147) Disabled Xenserver cluster can still deploy VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-10147. - Resolution: Fixed Fix Version/s: 4.12 > Disabled Xenserver cluster can still deploy VMs > > > Key: CLOUDSTACK-10147 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10147 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI >Affects Versions: 4.10.0.0, 4.9.2.0 > Environment: Xenserver 6.2, 7 >Reporter: Glenn Wagner >Assignee: Henko Holtzhausen >Priority: Major > Fix For: 4.12 > > > ENVIRONMENT > = > XenServer Version : 6.2 , 7 > ISSUE > == > Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are > still active > Repro. steps followed > == > Disabled Cluster from UI. > Deploy a new VM > Expected Behavior > === > After disabling the cluster , the hosts should be disabled. and no VM's can > be deployed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10147) Disabled Xenserver cluster can still deploy VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397204#comment-16397204 ] ASF GitHub Bot commented on CLOUDSTACK-10147: - rafaelweingartner commented on issue #2442: CLOUDSTACK-10147 Disabled Xenserver Cluster can still deploy VM's URL: https://github.com/apache/cloudstack/pull/2442#issuecomment-372728437 I will merge then. Thanks @DaanHoogland, @borisroman and @houthuis 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 > Disabled Xenserver cluster can still deploy VMs > > > Key: CLOUDSTACK-10147 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10147 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI >Affects Versions: 4.10.0.0, 4.9.2.0 > Environment: Xenserver 6.2, 7 >Reporter: Glenn Wagner >Assignee: Henko Holtzhausen >Priority: Major > > ENVIRONMENT > = > XenServer Version : 6.2 , 7 > ISSUE > == > Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are > still active > Repro. steps followed > == > Disabled Cluster from UI. > Deploy a new VM > Expected Behavior > === > After disabling the cluster , the hosts should be disabled. and no VM's can > be deployed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10147) Disabled Xenserver cluster can still deploy VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397206#comment-16397206 ] ASF subversion and git services commented on CLOUDSTACK-10147: -- Commit c3488a51db4bce4ec32c09e6fef78193d360cf3f in cloudstack's branch refs/heads/master from [~hholtzhausen] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=c3488a5 ] CLOUDSTACK-10147 Disabled Xenserver Cluster can still deploy VM's. Added code to skip disabled clusters when selecting a host (#2442) > Disabled Xenserver cluster can still deploy VMs > > > Key: CLOUDSTACK-10147 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10147 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI >Affects Versions: 4.10.0.0, 4.9.2.0 > Environment: Xenserver 6.2, 7 >Reporter: Glenn Wagner >Assignee: Henko Holtzhausen >Priority: Major > > ENVIRONMENT > = > XenServer Version : 6.2 , 7 > ISSUE > == > Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are > still active > Repro. steps followed > == > Disabled Cluster from UI. > Deploy a new VM > Expected Behavior > === > After disabling the cluster , the hosts should be disabled. and no VM's can > be deployed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10147) Disabled Xenserver cluster can still deploy VMs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397205#comment-16397205
]
ASF GitHub Bot commented on CLOUDSTACK-10147:
-
rafaelweingartner closed pull request #2442: CLOUDSTACK-10147 Disabled
Xenserver Cluster can still deploy VM's
URL: https://github.com/apache/cloudstack/pull/2442
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/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java
b/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java
index cc244ce41ba..5d8ad0a7051 100644
--- a/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java
+++ b/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java
@@ -1040,6 +1040,11 @@ private DeployDestination
checkClustersforDestination(List clusterList, Vi
for (Long clusterId : clusterList) {
ClusterVO clusterVO = _clusterDao.findById(clusterId);
+if (clusterVO.getAllocationState() ==
Grouping.AllocationState.Disabled) {
+s_logger.debug("Cannot deploy in disabled cluster " +
clusterId + ", skipping this cluster");
+avoid.addCluster(clusterVO.getId());
+}
+
if (clusterVO.getHypervisorType() !=
vmProfile.getHypervisorType()) {
s_logger.debug("Cluster: " + clusterId + " has HyperVisorType
that does not match the VM, skipping this cluster");
avoid.addCluster(clusterVO.getId());
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
> Disabled Xenserver cluster can still deploy VMs
>
>
> Key: CLOUDSTACK-10147
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10147
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, UI
>Affects Versions: 4.10.0.0, 4.9.2.0
> Environment: Xenserver 6.2, 7
>Reporter: Glenn Wagner
>Assignee: Henko Holtzhausen
>Priority: Major
>
> ENVIRONMENT
> =
> XenServer Version : 6.2 , 7
> ISSUE
> ==
> Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are
> still active
> Repro. steps followed
> ==
> Disabled Cluster from UI.
> Deploy a new VM
> Expected Behavior
> ===
> After disabling the cluster , the hosts should be disabled. and no VM's can
> be deployed
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10147) Disabled Xenserver cluster can still deploy VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16397200#comment-16397200 ] ASF GitHub Bot commented on CLOUDSTACK-10147: - DaanHoogland commented on issue #2442: CLOUDSTACK-10147 Disabled Xenserver Cluster can still deploy VM's URL: https://github.com/apache/cloudstack/pull/2442#issuecomment-372727944 @houthuis @rafaelweingartner I am fine with this. 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 > Disabled Xenserver cluster can still deploy VMs > > > Key: CLOUDSTACK-10147 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10147 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI >Affects Versions: 4.10.0.0, 4.9.2.0 > Environment: Xenserver 6.2, 7 >Reporter: Glenn Wagner >Assignee: Henko Holtzhausen >Priority: Major > > ENVIRONMENT > = > XenServer Version : 6.2 , 7 > ISSUE > == > Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are > still active > Repro. steps followed > == > Disabled Cluster from UI. > Deploy a new VM > Expected Behavior > === > After disabling the cluster , the hosts should be disabled. and no VM's can > be deployed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CLOUDSTACK-10298) Recreation of an earlier deleted Nuage managed isolated or vpc tier network fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets closed CLOUDSTACK-10298. --- Merged! > Recreation of an earlier deleted Nuage managed isolated or vpc tier network > fails > - > > Key: CLOUDSTACK-10298 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10298 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.11.0.0 >Reporter: Raf Smeets >Assignee: Sigert Goeminne >Priority: Major > > Scenario to reproduce for isolated network: (same applies for vpc tier > network) > Create L3Domain/Zone/Subnet/DefaultACLs in VSD and create a non-persistent > NetworkOffering in ACS, then createNetwork by specifying externalID attribute > in the request, which refers to the Subnet ID in VSD. > Then verify VSD objects and verify networking by deploying 2 VM's in this > network, enable static nat to one VM and ping to the other VM. > After that delete tall the VM's in this network and delete the network itself. > Don't delete data in VSD. > Recreate same network by specifying same externalID attribute in the request, > which refers to the Subnet ID in VSD. > management-server.log shows following error > 2018-02-07 00:15:27,464 DEBUG [c.c.a.ApiServlet] > (qtp66233253-20:ctx-a9727f69) (logid:13bd8add) ===START=== 10.30.39.11 - GET > acltype=Account=StjgrAiYEguhhZwogkx4SggkPhImhdxgSrDbfUZhLjL4As6bm4Xec8GC7WKFWuZXJmTAIl9zx_Qeh767T_yfpQ=f17d2601-984f-4cc6-ba78-4b89bdc87115=11ce9c88-0a46-11e8-bff2-faac09080700=Test+Network=10.0.0.1=b0fbe47b-173e-415b-b0e6-80fd17f75f1d=255.255.255.0=43897d72-6781-4e29-9a13-5ad9addbec01=json=test-a-TestNuageManagedSubnets-VL53W7=TestNet-10.0.0.1-NET_OFF-True-0KWFQ8=createNetwork=688UxfzAZdtoj%2BEFxHpwf6rrAoQ%3D > 2018-02-07 00:15:27,468 DEBUG [c.c.a.ApiServer] (qtp66233253-20:ctx-a9727f69 > ctx-3d2464e6) (logid:13bd8add) CIDRs from which account > 'Acct[555cb263-0a46-11e8-bff2-faac09080700-admin]' is allowed to perform API > calls: 0.0.0.0/0,::/0 > 2018-02-07 00:15:27,479 DEBUG [c.c.u.AccountManagerImpl] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Access granted to Acct[5ff94a35-075a-4023-bb2a-2186a6a00853-admin] to > Domain:1/ by AffinityGroupAccessChecker > 2018-02-07 00:15:27,488 DEBUG [c.c.r.ResourceLimitManagerImpl] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Checking if amount of resources of Type = 'network' for Account Name = > test-a-TestNuageManagedSubnets-VL53W7 in Domain Id = 1 is exceeded: Account > Resource Limit = 20, Current Account Resource Amount = 0, Requested Resource > Amount = 1. > 2018-02-07 00:15:27,506 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Refusing to design this network, the physical isolation type is not > BCF_SEGMENT > 2018-02-07 00:15:27,506 DEBUG [o.a.c.n.c.m.ContrailGuru] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Refusing to design this network > 2018-02-07 00:15:27,507 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Refusing to design this network > 2018-02-07 00:15:27,508 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Refusing to design this network > 2018-02-07 00:15:27,509 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Refusing to design this network > 2018-02-07 00:15:27,512 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) SSP > not configured to be active > 2018-02-07 00:15:27,513 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Refusing to design this network > 2018-02-07 00:15:27,515 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Refusing to design network. VsdManaged network object already present in zone. > 2018-02-07 00:15:27,516 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Releasing lock for > Acct[fe4ef34f-7563-4c66-8aba-15c600cd794e-test-a-TestNuageManagedSubnets-VL53W7] > 2018-02-07 00:15:27,537 DEBUG [c.c.u.d.T.Transaction] > (qtp66233253-20:ctx-a9727f69 ctx-3d2464e6 ctx-4b65e7ca) (logid:13bd8add) > Rolling back the transaction: Time = 52 Name = qtp66233253-20; called by >
[jira] [Updated] (CLOUDSTACK-10324) Remove branches 4.1l10n, 4.2-*, 4.3.0-forward, and 4.4-*
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner updated CLOUDSTACK-10324: Description: Following the protocol defined in [1]. We will remove branches of 4.10.0.0-RC The branches that will be removed are the following: * 4.1l10n * 4.2-forward * 4.2-workplace * 4.3.0-forward * 4.4-automation * 4.4-forward * 4.4-forward-iam * 4.4-forward-iam-disabled [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol was: Following the protocol defined in [1]. We will remove branches of 4.10.0.0-RC The branches that will be removed are the following: * 4.1l10n * 4.2-forward * 4.2-workplace * 4.3.0-forward * 4.4-automation * 4.4-forward * 4.4-forward-iam * 4.4-forward-iam-disabled * [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol > Remove branches 4.1l10n, 4.2-*, 4.3.0-forward, and 4.4-* > > > Key: CLOUDSTACK-10324 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10324 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Following the protocol defined in [1]. We will remove branches of 4.10.0.0-RC > The branches that will be removed are the following: > * 4.1l10n > * 4.2-forward > * 4.2-workplace > * 4.3.0-forward > * 4.4-automation > * 4.4-forward > * 4.4-forward-iam > * 4.4-forward-iam-disabled > [1] > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10324) Remove branches 4.1l10n, 4.2-*, 4.3.0-forward, and 4.4-*
Rafael Weingärtner created CLOUDSTACK-10324: --- Summary: Remove branches 4.1l10n, 4.2-*, 4.3.0-forward, and 4.4-* Key: CLOUDSTACK-10324 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10324 Project: CloudStack Issue Type: Sub-task Security Level: Public (Anyone can view this level - this is the default.) Reporter: Rafael Weingärtner Assignee: Rafael Weingärtner Following the protocol defined in [1]. We will remove branches of 4.10.0.0-RC The branches that will be removed are the following: * 4.1l10n * 4.2-forward * 4.2-workplace * 4.3.0-forward * 4.4-automation * 4.4-forward * 4.4-forward-iam * 4.4-forward-iam-disabled * [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10147) Disabled Xenserver cluster can still deploy VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396997#comment-16396997 ] ASF GitHub Bot commented on CLOUDSTACK-10147: - rafaelweingartner commented on issue #2442: CLOUDSTACK-10147 Disabled Xenserver Cluster can still deploy VM's URL: https://github.com/apache/cloudstack/pull/2442#issuecomment-372679976 @DaanHoogland are you ok with this one? The tests passed, and everything seems to be fine. The contributor is not responding our inquiries. I am willing to merge it. 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 > Disabled Xenserver cluster can still deploy VMs > > > Key: CLOUDSTACK-10147 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10147 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI >Affects Versions: 4.10.0.0, 4.9.2.0 > Environment: Xenserver 6.2, 7 >Reporter: Glenn Wagner >Assignee: Henko Holtzhausen >Priority: Major > > ENVIRONMENT > = > XenServer Version : 6.2 , 7 > ISSUE > == > Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are > still active > Repro. steps followed > == > Disabled Cluster from UI. > Deploy a new VM > Expected Behavior > === > After disabling the cluster , the hosts should be disabled. and no VM's can > be deployed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10307) Remove unused things from HostDaoImpl
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396989#comment-16396989 ] ASF GitHub Bot commented on CLOUDSTACK-10307: - rafaelweingartner commented on issue #2438: [CLOUDSTACK-10307] Remove unused things from HostDaoImpl URL: https://github.com/apache/cloudstack/pull/2438#issuecomment-372678649 @borisstoyanov are these errors persistent ones, or should I take a look into them? 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 > Remove unused things from HostDaoImpl > - > > Key: CLOUDSTACK-10307 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10307 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > > Remove unnecessary annotation of HostDaoImpl. While removing this annotation > I noticed that one of the methods were not necessary. While removing it, I > found some code in CloudZonesStartupProcessor that was also not used, and > removed it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396986#comment-16396986
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
rafaelweingartner commented on issue #2465: CLOUDSTACK-10232: SystemVMs and VR
to run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#issuecomment-372677945
@khos2ow as soon as you have some final results with these tests, please
tell us, so we can evaluate the next step to be taken here.
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
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10321) CPU Cap for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396985#comment-16396985 ] ASF GitHub Bot commented on CLOUDSTACK-10321: - blueorangutan commented on issue #2482: CLOUDSTACK-10321: CPU Cap for KVM URL: https://github.com/apache/cloudstack/pull/2482#issuecomment-372677845 Trillian test result (tid-2350) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 27672 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2482-t2350-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_public_ip_range.py Intermitten failure detected: /marvin/tests/smoke/test_service_offerings.py Intermitten failure detected: /marvin/tests/smoke/test_templates.py Intermitten failure detected: /marvin/tests/smoke/test_usage.py Intermitten failure detected: /marvin/tests/smoke/test_volumes.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_vpn.py Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py Smoke tests completed. 62 look OK, 5 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_01_service_offering_cpu_limit_use | `Error` | 120.73 | test_service_offerings.py test_04_extract_template | `Failure` | 128.38 | test_templates.py ContextSuite context=TestISOUsage>:setup | `Error` | 0.00 | test_usage.py test_06_download_detached_volume | `Failure` | 136.77 | test_volumes.py test_hostha_enable_ha_when_host_in_maintenance | `Error` | 3.92 | 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 > CPU Cap for KVM > --- > > Key: CLOUDSTACK-10321 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10321 > 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 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10314) Add Text-Field to each ACL Rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-10314. - Resolution: Fixed Fix Version/s: 4.12 > Add Text-Field to each ACL Rule > > > Key: CLOUDSTACK-10314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10314 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > Fix For: 4.12 > > > It might be interesting to have a text field (e.g. CHAR-256) added to each > ACL rule, which allows to enter a "reason" for each FW Rule created. This is > valuable for customer documentation, as well as best practice for an evidence > towards auditing the system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10314) Add Text-Field to each ACL Rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396981#comment-16396981 ] ASF subversion and git services commented on CLOUDSTACK-10314: -- Commit 7efdaa65f7cef4cc27441fff36165d0042422b94 in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=7efdaa6 ] [CLOUDSTACK-10314] Add Text-Field to each ACL Rule (#2475) * [CLOUDSTACK-10314] Add Text-Field to each ACL Rule It is interesting to have a text field (e.g. CHAR-256) added to each ACL rule, which allows to enter a "reason" for each FW Rule created. This is valuable for customer documentation, as well as best practice for an evidence towards auditing the system * Formatting to make check style happy and code clean ups > Add Text-Field to each ACL Rule > > > Key: CLOUDSTACK-10314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10314 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > > It might be interesting to have a text field (e.g. CHAR-256) added to each > ACL rule, which allows to enter a "reason" for each FW Rule created. This is > valuable for customer documentation, as well as best practice for an evidence > towards auditing the system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10314) Add Text-Field to each ACL Rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396982#comment-16396982 ] ASF subversion and git services commented on CLOUDSTACK-10314: -- Commit 7efdaa65f7cef4cc27441fff36165d0042422b94 in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=7efdaa6 ] [CLOUDSTACK-10314] Add Text-Field to each ACL Rule (#2475) * [CLOUDSTACK-10314] Add Text-Field to each ACL Rule It is interesting to have a text field (e.g. CHAR-256) added to each ACL rule, which allows to enter a "reason" for each FW Rule created. This is valuable for customer documentation, as well as best practice for an evidence towards auditing the system * Formatting to make check style happy and code clean ups > Add Text-Field to each ACL Rule > > > Key: CLOUDSTACK-10314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10314 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > > It might be interesting to have a text field (e.g. CHAR-256) added to each > ACL rule, which allows to enter a "reason" for each FW Rule created. This is > valuable for customer documentation, as well as best practice for an evidence > towards auditing the system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10314) Add Text-Field to each ACL Rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396977#comment-16396977 ] ASF GitHub Bot commented on CLOUDSTACK-10314: - rafaelweingartner commented on issue #2475: [CLOUDSTACK-10314] Add Text-Field to each ACL Rule URL: https://github.com/apache/cloudstack/pull/2475#issuecomment-372677147 I am going to leave it as is. If we change the "reason" field name, I would need to change all references (JS, CSS, and labels) to make a more concise change. Maybe, if we feel that description is better, I can change that in the near future with another PR. 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 > Add Text-Field to each ACL Rule > > > Key: CLOUDSTACK-10314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10314 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > > It might be interesting to have a text field (e.g. CHAR-256) added to each > ACL rule, which allows to enter a "reason" for each FW Rule created. This is > valuable for customer documentation, as well as best practice for an evidence > towards auditing the system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396896#comment-16396896 ] ASF GitHub Bot commented on CLOUDSTACK-10241: - rafaelweingartner commented on issue #2414: [CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools URL: https://github.com/apache/cloudstack/pull/2414#issuecomment-372653103 @DaanHoogland I managed to separate the formatting from the code change itself. Now it should be easier to review. @khos2ow, @marcaurele and others, this might be of your interest as well (if you run XenServer). 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 > Duplicated file SRs being created in XenServer pools > > > Key: CLOUDSTACK-10241 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241 > 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 > > Due to a race condition between multiple management servers, in some rare > cases, CloudStack is creating multiple file SRs to the same secondary folder. > This causes a problem when introducing the SR to the XenServer pools, as > “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they > are seen in different SRs, and therefore cause an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10314) Add Text-Field to each ACL Rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396877#comment-16396877 ] ASF GitHub Bot commented on CLOUDSTACK-10314: - rafaelweingartner commented on issue #2475: [CLOUDSTACK-10314] Add Text-Field to each ACL Rule URL: https://github.com/apache/cloudstack/pull/2475#issuecomment-372647841 I am still thinking about the change you mentioned. As soon as I have some feedback I tell you guys. 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 > Add Text-Field to each ACL Rule > > > Key: CLOUDSTACK-10314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10314 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > > It might be interesting to have a text field (e.g. CHAR-256) added to each > ACL rule, which allows to enter a "reason" for each FW Rule created. This is > valuable for customer documentation, as well as best practice for an evidence > towards auditing the system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10314) Add Text-Field to each ACL Rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396875#comment-16396875 ] ASF GitHub Bot commented on CLOUDSTACK-10314: - marcaurele commented on issue #2475: [CLOUDSTACK-10314] Add Text-Field to each ACL Rule URL: https://github.com/apache/cloudstack/pull/2475#issuecomment-372647342 Yeah, it wasn't aimed to this PR, more as a general idea. I'm ok with this change. If you think `description` is better than `reason` and you're willing to modify your PR, let us know otherwise we'll merge it. 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 > Add Text-Field to each ACL Rule > > > Key: CLOUDSTACK-10314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10314 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > > It might be interesting to have a text field (e.g. CHAR-256) added to each > ACL rule, which allows to enter a "reason" for each FW Rule created. This is > valuable for customer documentation, as well as best practice for an evidence > towards auditing the system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10314) Add Text-Field to each ACL Rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396871#comment-16396871 ] ASF GitHub Bot commented on CLOUDSTACK-10314: - rafaelweingartner commented on issue #2475: [CLOUDSTACK-10314] Add Text-Field to each ACL Rule URL: https://github.com/apache/cloudstack/pull/2475#issuecomment-372645391 What do you mean? Add the same thing to those rules/configurations? Well, that is interesting but it is not a requirement in our side for now. Maybe in the future. 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 > Add Text-Field to each ACL Rule > > > Key: CLOUDSTACK-10314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10314 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > > It might be interesting to have a text field (e.g. CHAR-256) added to each > ACL rule, which allows to enter a "reason" for each FW Rule created. This is > valuable for customer documentation, as well as best practice for an evidence > towards auditing the system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10314) Add Text-Field to each ACL Rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396869#comment-16396869 ] ASF GitHub Bot commented on CLOUDSTACK-10314: - marcaurele commented on issue #2475: [CLOUDSTACK-10314] Add Text-Field to each ACL Rule URL: https://github.com/apache/cloudstack/pull/2475#issuecomment-372644992 It would be helpful for SG rules too for example, for IP aliases, snapshots... 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 > Add Text-Field to each ACL Rule > > > Key: CLOUDSTACK-10314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10314 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > > It might be interesting to have a text field (e.g. CHAR-256) added to each > ACL rule, which allows to enter a "reason" for each FW Rule created. This is > valuable for customer documentation, as well as best practice for an evidence > towards auditing the system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10296) Fix timestamp difference in heartbeat script for rVRs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396811#comment-16396811 ] ASF GitHub Bot commented on CLOUDSTACK-10296: - blueorangutan commented on issue #2458: CLOUDSTACK-10296: Find time different from last timestamp URL: https://github.com/apache/cloudstack/pull/2458#issuecomment-372622468 @rhtyd 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 > Fix timestamp difference in heartbeat script for rVRs > - > > Key: CLOUDSTACK-10296 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10296 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0, 4.9.3.0 >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.11.1.1 > > > Raised recently on dev@ ML by Jayakartheek, the difference code in heartbeat > checker script for rVRs wrongly take difference, that will always be less > than or equal to 0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10296) Fix timestamp difference in heartbeat script for rVRs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396810#comment-16396810 ] ASF GitHub Bot commented on CLOUDSTACK-10296: - rhtyd commented on issue #2458: CLOUDSTACK-10296: Find time different from last timestamp URL: https://github.com/apache/cloudstack/pull/2458#issuecomment-372622417 @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 > Fix timestamp difference in heartbeat script for rVRs > - > > Key: CLOUDSTACK-10296 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10296 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0, 4.9.3.0 >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.11.1.1 > > > Raised recently on dev@ ML by Jayakartheek, the difference code in heartbeat > checker script for rVRs wrongly take difference, that will always be less > than or equal to 0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10169) Clean up old and obsolete branches
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner updated CLOUDSTACK-10169:
Description:
The following is full list of branches available on
https://github.com/apache/cloudstack and the old ones can be deleted.
||Branch name||Ticket number||POM version||Last updated||Last commit||HEAD on
master||PR number||Should be deleted||
|4.0|-|4.0.2|Jul 19
2013|[8f4b9bc|https://github.com/apache/cloudstack/commit/8f4b9bccfed63a37762907bdd058506f4e7b6e6d)]|No|-|{color:#d04437}*No*{color}|
|4.1|-|4.1.2-SNAPSHOT|Dec 10
2013|[1b7c886|https://github.com/apache/cloudstack/commit/1b7c886bb1a4cd28840a13e199fedc8c2e865011)]|No|-|{color:#d04437}*No*{color}|
|4.10|-|4.10.1.0-SNAPSHOT|Nov 16
2017|[330f241|https://github.com/apache/cloudstack/commit/330f24117cc5c90b85db291981652a2191417d5a)]|Yes|-|{color:#d04437}*No*{color}|
|4.1l10n|-|4.1.0-SNAPSHOT|Feb 27
2013|[80b9b25|https://github.com/apache/cloudstack/commit/80b9b255ae641a238b6d626e5a8bda9e958d99a8)]|No|-|Yes|
|4.2|-|4.2.1-SNAPSHOT|May 13
2015|[709e0c0|https://github.com/apache/cloudstack/commit/709e0c093fc280cee79b30c7ee0a11331ebbae57)]|No|-|{color:#d04437}*No*{color}|
|4.2-forward|-|4.2.0-SNAPSHOT|May 31
2014|[6196958|https://github.com/apache/cloudstack/commit/6196958a76bfda706da52ad42fd479db4bc047b9)]|No|-|Yes|
|4.2-workplace|-|4.2.1-SNAPSHOT|Dec 11
2013|[f9dd2c9|https://github.com/apache/cloudstack/commit/f9dd2c9d483ba35768d3b80deefb74f54282ae5a)]|No|-|Yes|
|4.3|-|4.3.2|Aug 12
2015|[c116ca9|https://github.com/apache/cloudstack/commit/c116ca968e552f079e1ebfe855b4bfa02d368f74)]|No|-|{color:#d04437}*No*{color}|
|4.3.0-forward|-|4.3.0|Apr 3
2014|[825929d|https://github.com/apache/cloudstack/commit/825929d7e98cbd680c57ff424f987bbb0b0aff62)]|No|-|Yes|
|4.4|-|4.4.5-SNAPSHOT|Sep 1
2015|[b0a4593|https://github.com/apache/cloudstack/commit/b0a45931527cb57e4d23edab36adf4fac1ffa494)]|No|-|{color:#d04437}*No*{color}|
|4.4-automation|-|4.4.0-SNAPSHOT|May 5
2014|[87205f9|https://github.com/apache/cloudstack/commit/87205f955523556a1aad5da72360c67f0b8ba697)]|No|-|Yes|
|4.4-forward|-|4.4.0-SNAPSHOT|Aug 6
2014|[30ca56a|https://github.com/apache/cloudstack/commit/30ca56aff85e3d61708ec35dd49fdd34beea69f1)]|No|-|Yes|
|4.4-forward-iam|-|4.4.0-SNAPSHOT|May 23
2014|[9d676d0|https://github.com/apache/cloudstack/commit/9d676d0d366484eebd425da3cde66c922a03edfb)]|No|-|Yes|
|4.4-forward-iam-disabled|-|4.4.0-SNAPSHOT|May 16
2014|[d1f6120|https://github.com/apache/cloudstack/commit/d1f6120c43cc66c85f5d84f7b48014bfc641589d)]|No|-|Yes|
|4.5|-|4.5.3-SNAPSHOT|Oct 18
2016|[e731c70|https://github.com/apache/cloudstack/commit/e731c70cf7ab72b593cde10af8e49673a21b9f9c)]|No|-|{color:#d04437}*No*{color}|
|4.5.2.1-security-RC20160525T1207|-|4.5.2.1|May 25
2016|[7059c29|https://github.com/apache/cloudstack/commit/7059c29e940f9e1321eee2b35ff045c2eb655df3)]|No|-|Yes|
|4.6|-|4.6.3-SNAPSHOT|Oct 18
2016|[08b4052|https://github.com/apache/cloudstack/commit/08b40525955881869340a8ae3b268dea6edd926b)]|No|-|{color:#d04437}*No*{color}|
|4.7|-|4.7.2-SNAPSHOT|Nov 8
2016|[0279ac2|https://github.com/apache/cloudstack/commit/0279ac20e46cbbc7f699dc41eafbe31fe0c4797b)]|Yes|-|{color:#d04437}*No*{color}|
|4.7.0-RC20151213T2109|-|4.7.0|Dec 13
2015|[2f26a85|https://github.com/apache/cloudstack/commit/2f26a859a971a9852ed9f6f34fe35e52fe6028a9)]|Yes|-|Yes|
|4.7.1-RC20160120T2318|-|4.7.1|Jan 20
2016|[5ea07dc|https://github.com/apache/cloudstack/commit/5ea07dc93799f28dd6c268b17514867d92dc53f7)]|No|-|Yes|
|4.7.1.1-RC20160525T1230|-|4.7.1.1|May 25
2016|[781775a|https://github.com/apache/cloudstack/commit/781775a31f6c0f08043cb6f73494628e71fb)]|No|-|Yes|
|4.8|-|4.8.2.0-SNAPSHOT|Feb 28
2017|[113ce13|https://github.com/apache/cloudstack/commit/113ce13bda9d4a095ff3a22d6fedf925117f4f6f)]|Yes|-|{color:#d04437}*No*{color}|
|4.8.0-RC20160120T2343|-|4.8.0|Jan 20
2016|[62f218b|https://github.com/apache/cloudstack/commit/62f218b7bd005d201d1c8516180d8e6d6797)]|Yes|-|Yes|
|4.8.0.1-RC20160525T1247|-|4.8.0.1|May 25
2016|[6d575df|https://github.com/apache/cloudstack/commit/6d575df3b83dd3e2f5eb94c1ba63bb7a083f44d0)]|No|-|Yes|
|4.8.1-RC20160808T1006|-|4.8.1|Aug 8
2016|[a63db21|https://github.com/apache/cloudstack/commit/a63db21d16072821a1e27473813fddf36accfdd4)]|Yes|-|Yes|
|4.8.2.0-RC20161210T0832|-|4.8.2.0|Dec 10
2016|[4a1f7ed|https://github.com/apache/cloudstack/commit/4a1f7ed8bc51d859c5e0e5b9c3ad513752ff8c40)]|No|-|Yes|
|4.9|-|4.9.4.0-SNAPSHOT|Nov 15
2017|[f250b3a|https://github.com/apache/cloudstack/commit/f250b3ae0cf7efeef486f15474b606299d17318e)]|Yes|-|{color:#d04437}*No*{color}|
|4.9-bountycastle-daan|-|4.10.0.0-SNAPSHOT|May 18
2016|[b9ee34f|https://github.com/apache/cloudstack/commit/b9ee34fa9510f10b0bddeff869c821a5361932b2)]|No|Closed
([1511|https://github.com/apache/cloudstack/pull/1511])|Yes|
|4.9-systemdubuntupkging|-|4.9.1.0-SNAPSHOT|Aug 24
[jira] [Updated] (CLOUDSTACK-10313) Remove branches 4.6.*-RC*
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner updated CLOUDSTACK-10313:
Status: Reviewable (was: In Progress)
> Remove branches 4.6.*-RC*
> -
>
> Key: CLOUDSTACK-10313
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10313
> Project: CloudStack
> Issue Type: Sub-task
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> Remove branches matching the REGEX:
> {code:java}
> 4.6.*-RC*
> {code}
> from Apache CloudStack official repository.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10313) Remove branches 4.6.*-RC*
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner resolved CLOUDSTACK-10313.
-
Resolution: Fixed
> Remove branches 4.6.*-RC*
> -
>
> Key: CLOUDSTACK-10313
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10313
> Project: CloudStack
> Issue Type: Sub-task
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> Remove branches matching the REGEX:
> {code:java}
> 4.6.*-RC*
> {code}
> from Apache CloudStack official repository.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (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:all-tabpanel ] Rafael Weingärtner updated CLOUDSTACK-10323: Description: 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 was: Change disk offering when volume is migrated to different type of storage pool. 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 > 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
[jira] [Created] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
Rafael Weingärtner created CLOUDSTACK-10323: --- Summary: 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 Change disk offering when volume is migrated to different type of storage pool. 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-10314) Add Text-Field to each ACL Rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396774#comment-16396774 ] ASF GitHub Bot commented on CLOUDSTACK-10314: - rafaelweingartner commented on issue #2475: [CLOUDSTACK-10314] Add Text-Field to each ACL Rule URL: https://github.com/apache/cloudstack/pull/2475#issuecomment-372613094 That is an interesting suggestion. I have not thought about "description" to name that field. 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 > Add Text-Field to each ACL Rule > > > Key: CLOUDSTACK-10314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10314 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > > It might be interesting to have a text field (e.g. CHAR-256) added to each > ACL rule, which allows to enter a "reason" for each FW Rule created. This is > valuable for customer documentation, as well as best practice for an evidence > towards auditing the system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10296) Fix timestamp difference in heartbeat script for rVRs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396765#comment-16396765 ] ASF GitHub Bot commented on CLOUDSTACK-10296: - blueorangutan commented on issue #2458: CLOUDSTACK-10296: Find time different from last timestamp URL: https://github.com/apache/cloudstack/pull/2458#issuecomment-372610958 Packaging result: ✔centos6 ✔centos7 ✖debian. JID-1769 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 > Fix timestamp difference in heartbeat script for rVRs > - > > Key: CLOUDSTACK-10296 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10296 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0, 4.9.3.0 >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.11.1.1 > > > Raised recently on dev@ ML by Jayakartheek, the difference code in heartbeat > checker script for rVRs wrongly take difference, that will always be less > than or equal to 0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10296) Fix timestamp difference in heartbeat script for rVRs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396726#comment-16396726 ] ASF GitHub Bot commented on CLOUDSTACK-10296: - blueorangutan commented on issue #2458: CLOUDSTACK-10296: Find time different from last timestamp URL: https://github.com/apache/cloudstack/pull/2458#issuecomment-372599074 @rhtyd 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 > Fix timestamp difference in heartbeat script for rVRs > - > > Key: CLOUDSTACK-10296 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10296 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0, 4.9.3.0 >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.11.1.1 > > > Raised recently on dev@ ML by Jayakartheek, the difference code in heartbeat > checker script for rVRs wrongly take difference, that will always be less > than or equal to 0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10296) Fix timestamp difference in heartbeat script for rVRs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396724#comment-16396724 ] ASF GitHub Bot commented on CLOUDSTACK-10296: - rhtyd commented on issue #2458: CLOUDSTACK-10296: Find time different from last timestamp URL: https://github.com/apache/cloudstack/pull/2458#issuecomment-372598940 @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 > Fix timestamp difference in heartbeat script for rVRs > - > > Key: CLOUDSTACK-10296 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10296 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0, 4.9.3.0 >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.11.1.1 > > > Raised recently on dev@ ML by Jayakartheek, the difference code in heartbeat > checker script for rVRs wrongly take difference, that will always be less > than or equal to 0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396595#comment-16396595 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - blueorangutan commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-372556770 @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 > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396594#comment-16396594 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - borisstoyanov commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-372556713 @rafaelweingartner the environment has failed, let me re-run it. @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 > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10321) CPU Cap for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396590#comment-16396590 ] ASF GitHub Bot commented on CLOUDSTACK-10321: - blueorangutan commented on issue #2482: CLOUDSTACK-10321: CPU Cap for KVM URL: https://github.com/apache/cloudstack/pull/2482#issuecomment-372555880 @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 > CPU Cap for KVM > --- > > Key: CLOUDSTACK-10321 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10321 > 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 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
