[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103646#comment-15103646 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user nislim commented on the pull request: https://github.com/apache/cloudstack/pull/985#issuecomment-172307572 Any progress on getting the patches into upstream libvirt-java? @wido > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103648#comment-15103648 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user wido commented on the pull request: https://github.com/apache/cloudstack/pull/985#issuecomment-172309253 @nislim No, not really. The people at libvirt-java aren't the fastest. Thinking about forking it into CloudStack itself. > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9210) KVM security re-programming fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103668#comment-15103668 ] ASF subversion and git services commented on CLOUDSTACK-9210: - Commit 239148c31bd2cb0dce19aaef63391073564d3530 in cloudstack's branch refs/heads/master from [~widodh] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=239148c ] CLOUDSTACK-9210: Pass secondary IPs to default_network_rules() function This is a mandatory argument but it was NOT passed which caused the re-programming of security groups to fail. Simple fix to just add the argument since the variable is available there. > KVM security re-programming fails > - > > Key: CLOUDSTACK-9210 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9210 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Wido den Hollander >Assignee: Wido den Hollander >Priority: Critical > Labels: kvm, python, security_groups > > If security groups need to be re-programmed for an instance for some reason > we currently do not provide the mandatory argument with secondary IPs to the > Python function. > This causes the programming of security groups to fail completely. > Effectively the Instance looses it's connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9210) KVM security re-programming fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103669#comment-15103669 ] ASF subversion and git services commented on CLOUDSTACK-9210: - Commit 2afb739f0656d14e5c298bf469f797fff6da221b in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2afb739 ] Merge pull request #1309 from wido/CLOUDSTACK-9210 CLOUDSTACK-9210: Pass secondary IPs to default_network_rules() functionThis is a mandatory argument but it was NOT passed which caused the re-programming of security groups to fail. Simple fix to just add the argument since the variable is available there. * pr/1309: CLOUDSTACK-9210: Pass secondary IPs to default_network_rules() function Signed-off-by: Remi Bergsma > KVM security re-programming fails > - > > Key: CLOUDSTACK-9210 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9210 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Wido den Hollander >Assignee: Wido den Hollander >Priority: Critical > Labels: kvm, python, security_groups > > If security groups need to be re-programmed for an instance for some reason > we currently do not provide the mandatory argument with secondary IPs to the > Python function. > This causes the programming of security groups to fail completely. > Effectively the Instance looses it's connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9210) KVM security re-programming fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103670#comment-15103670 ] ASF subversion and git services commented on CLOUDSTACK-9210: - Commit 2afb739f0656d14e5c298bf469f797fff6da221b in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2afb739 ] Merge pull request #1309 from wido/CLOUDSTACK-9210 CLOUDSTACK-9210: Pass secondary IPs to default_network_rules() functionThis is a mandatory argument but it was NOT passed which caused the re-programming of security groups to fail. Simple fix to just add the argument since the variable is available there. * pr/1309: CLOUDSTACK-9210: Pass secondary IPs to default_network_rules() function Signed-off-by: Remi Bergsma > KVM security re-programming fails > - > > Key: CLOUDSTACK-9210 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9210 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Wido den Hollander >Assignee: Wido den Hollander >Priority: Critical > Labels: kvm, python, security_groups > > If security groups need to be re-programmed for an instance for some reason > we currently do not provide the mandatory argument with secondary IPs to the > Python function. > This causes the programming of security groups to fail completely. > Effectively the Instance looses it's connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9210) KVM security re-programming fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103672#comment-15103672 ] ASF GitHub Bot commented on CLOUDSTACK-9210: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1309 > KVM security re-programming fails > - > > Key: CLOUDSTACK-9210 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9210 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Wido den Hollander >Assignee: Wido den Hollander >Priority: Critical > Labels: kvm, python, security_groups > > If security groups need to be re-programmed for an instance for some reason > we currently do not provide the mandatory argument with secondary IPs to the > Python function. > This causes the programming of security groups to fail completely. > Effectively the Instance looses it's connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9210) KVM security re-programming fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103671#comment-15103671 ] ASF subversion and git services commented on CLOUDSTACK-9210: - Commit 2afb739f0656d14e5c298bf469f797fff6da221b in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2afb739 ] Merge pull request #1309 from wido/CLOUDSTACK-9210 CLOUDSTACK-9210: Pass secondary IPs to default_network_rules() functionThis is a mandatory argument but it was NOT passed which caused the re-programming of security groups to fail. Simple fix to just add the argument since the variable is available there. * pr/1309: CLOUDSTACK-9210: Pass secondary IPs to default_network_rules() function Signed-off-by: Remi Bergsma > KVM security re-programming fails > - > > Key: CLOUDSTACK-9210 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9210 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Wido den Hollander >Assignee: Wido den Hollander >Priority: Critical > Labels: kvm, python, security_groups > > If security groups need to be re-programmed for an instance for some reason > we currently do not provide the mandatory argument with secondary IPs to the > Python function. > This causes the programming of security groups to fail completely. > Effectively the Instance looses it's connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9149) Remove unused folder(s)/file(s); cloud-cli
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103675#comment-15103675 ] ASF subversion and git services commented on CLOUDSTACK-9149: - Commit c459dfe62c57c72ced99ddb0c7d8a9547a380305 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c459dfe ] Merge pull request #1228 from borisroman/CLOUDSTACK-9149 Removed cloud-cli folder and contents, as it is not maintained or used anymore.Remove legacy code. Compiles ok: ``` [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 7:16.245s [INFO] Finished at: Sat Dec 12 15:06:24 CET 2015 [INFO] Final Memory: 101M/821M [INFO] ``` Running integration tests now! Ping @wido @wilderrodrigues @remibergsma * pr/1228: Removed cloud-cli folder and contents, as it is not maintained or used anymore. Signed-off-by: Remi Bergsma > Remove unused folder(s)/file(s); cloud-cli > -- > > Key: CLOUDSTACK-9149 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9149 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Boris Schrijver >Assignee: Boris Schrijver > > In the folder an old cloudstack cli tool resides. We currently have > cloudmonkey. As this is not maintained, it should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9148) Remove unused folder(s)/file(s); .pydevproject
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103676#comment-15103676 ] ASF subversion and git services commented on CLOUDSTACK-9148: - Commit fb658f575d66d692688012c711028730bdf8f4f3 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fb658f5 ] Merge pull request #1226 from borisroman/CLOUDSTACK-9148 Removed .pydevproject from plugin kvm hypervisor.Ping @wido @wilderrodrigues @remibergsma @miguelaferreira It's there for no apparent reason... Running integration tests now. ``` [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 6:12.189s [INFO] Finished at: Sat Dec 12 02:13:01 CET 2015 [INFO] Final Memory: 102M/808M [INFO] ``` * pr/1226: Removed .pydevproject from plugin kvm hypervisor. Signed-off-by: Remi Bergsma > Remove unused folder(s)/file(s); .pydevproject > -- > > Key: CLOUDSTACK-9148 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9148 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Boris Schrijver >Assignee: Boris Schrijver > > It's there for no apparent reason. It has also been added to .gitignore -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9195) Cancelled/failed async jobs not getting cleaned up from DB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103678#comment-15103678 ] ASF GitHub Bot commented on CLOUDSTACK-9195: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1272#issuecomment-172318575 Ping @DaanHoogland @borisroman @wilderrodrigues Can you guys have a look at this one-line change please? Thanks! > Cancelled/failed async jobs not getting cleaned up from DB > -- > > Key: CLOUDSTACK-9195 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9195 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0, 4.7.0 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.8.0 > > > Some cancelled/failed async jobs are not getting cleaned up from DB even > after "job.expire.minutes". These jobs are marked as cancelled/failed when MS > is restarted, check for 'job_status' as 2 (FAILED) and 'job_result' as "job > cancelled because of management server restart or shutdown" in async_job > table in DB. These are not getting cleaned as 'job_complete_msid' field is > not set in DB. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9240) Templatesize >40GB doesn't work properly
Remi Bergsma created CLOUDSTACK-9240: Summary: Templatesize >40GB doesn't work properly Key: CLOUDSTACK-9240 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9240 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.7.0 Reporter: Remi Bergsma Assignee: Remi Bergsma Priority: Critical Fix For: 4.7.1 Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the size of the template that gets created. I could not find any justification of that. I am just removing them as they caused us a huge headache when we tried to create bigger templates and they failed without any good error. Source: https://github.com/apache/cloudstack/pull/1223 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9240) Templatesize >40GB doesn't work properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103680#comment-15103680 ] ASF GitHub Bot commented on CLOUDSTACK-9240: GitHub user remibergsma opened a pull request: https://github.com/apache/cloudstack/pull/1343 CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scripts Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the size of the template that gets created. I could not find any justification of that. I am just removing them as they caused us a huge headache when we tried to create bigger templates and they failed without any good error. This closes #1223 (This PR was against master, made a new one against 4.7) Thanks Syed You can merge this pull request into a Git repository by running: $ git pull https://github.com/remibergsma/cloudstack CLOUDSTACK-9240 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1343.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1343 commit 69022f97c5283eb12abe41aabbee73a6a945c332 Author: Remi Bergsma Date: 2016-01-17T12:26:43Z CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scripts Thanks Syed > Templatesize >40GB doesn't work properly > > > Key: CLOUDSTACK-9240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9240 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Remi Bergsma >Assignee: Remi Bergsma >Priority: Critical > Fix For: 4.7.1 > > > Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the > size of the template that gets created. I could not find any justification of > that. I am just removing them as they caused us a huge headache when we tried > to create bigger templates and they failed without any good error. > Source: https://github.com/apache/cloudstack/pull/1223 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9240) Templatesize >40GB doesn't work properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103683#comment-15103683 ] ASF GitHub Bot commented on CLOUDSTACK-9240: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1343#issuecomment-172320121 Will merge this based on the LGTMs in #1223 as the only difference is the branch. > Templatesize >40GB doesn't work properly > > > Key: CLOUDSTACK-9240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9240 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Remi Bergsma >Assignee: Remi Bergsma >Priority: Critical > Fix For: 4.7.1 > > > Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the > size of the template that gets created. I could not find any justification of > that. I am just removing them as they caused us a huge headache when we tried > to create bigger templates and they failed without any good error. > Source: https://github.com/apache/cloudstack/pull/1223 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9240) Templatesize >40GB doesn't work properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103684#comment-15103684 ] ASF subversion and git services commented on CLOUDSTACK-9240: - Commit 69022f97c5283eb12abe41aabbee73a6a945c332 in cloudstack's branch refs/heads/4.7 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=69022f9 ] CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scripts Thanks Syed > Templatesize >40GB doesn't work properly > > > Key: CLOUDSTACK-9240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9240 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Remi Bergsma >Assignee: Remi Bergsma >Priority: Critical > Fix For: 4.7.1 > > > Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the > size of the template that gets created. I could not find any justification of > that. I am just removing them as they caused us a huge headache when we tried > to create bigger templates and they failed without any good error. > Source: https://github.com/apache/cloudstack/pull/1223 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9240) Templatesize >40GB doesn't work properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103686#comment-15103686 ] ASF subversion and git services commented on CLOUDSTACK-9240: - Commit 7d4b3d4d806d5a55c4710656b0391e9a781ce88c in cloudstack's branch refs/heads/4.7 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7d4b3d4 ] Merge pull request #1343 from remibergsma/CLOUDSTACK-9240 CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scriptsBoth createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the size of the template that gets created. I could not find any justification of that. I am just removing them as they caused us a huge headache when we tried to create bigger templates and they failed without any good error. This closes #1223 (This PR was against master, made a new one against 4.7) Thanks Syed * pr/1343: CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scripts Signed-off-by: Remi Bergsma > Templatesize >40GB doesn't work properly > > > Key: CLOUDSTACK-9240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9240 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Remi Bergsma >Assignee: Remi Bergsma >Priority: Critical > Fix For: 4.7.1 > > > Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the > size of the template that gets created. I could not find any justification of > that. I am just removing them as they caused us a huge headache when we tried > to create bigger templates and they failed without any good error. > Source: https://github.com/apache/cloudstack/pull/1223 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9240) Templatesize >40GB doesn't work properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103689#comment-15103689 ] ASF GitHub Bot commented on CLOUDSTACK-9240: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1343 > Templatesize >40GB doesn't work properly > > > Key: CLOUDSTACK-9240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9240 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Remi Bergsma >Assignee: Remi Bergsma >Priority: Critical > Fix For: 4.7.1 > > > Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the > size of the template that gets created. I could not find any justification of > that. I am just removing them as they caused us a huge headache when we tried > to create bigger templates and they failed without any good error. > Source: https://github.com/apache/cloudstack/pull/1223 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9240) Templatesize >40GB doesn't work properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103685#comment-15103685 ] ASF subversion and git services commented on CLOUDSTACK-9240: - Commit 7d4b3d4d806d5a55c4710656b0391e9a781ce88c in cloudstack's branch refs/heads/4.7 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7d4b3d4 ] Merge pull request #1343 from remibergsma/CLOUDSTACK-9240 CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scriptsBoth createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the size of the template that gets created. I could not find any justification of that. I am just removing them as they caused us a huge headache when we tried to create bigger templates and they failed without any good error. This closes #1223 (This PR was against master, made a new one against 4.7) Thanks Syed * pr/1343: CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scripts Signed-off-by: Remi Bergsma > Templatesize >40GB doesn't work properly > > > Key: CLOUDSTACK-9240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9240 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Remi Bergsma >Assignee: Remi Bergsma >Priority: Critical > Fix For: 4.7.1 > > > Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the > size of the template that gets created. I could not find any justification of > that. I am just removing them as they caused us a huge headache when we tried > to create bigger templates and they failed without any good error. > Source: https://github.com/apache/cloudstack/pull/1223 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9240) Templatesize >40GB doesn't work properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103687#comment-15103687 ] ASF subversion and git services commented on CLOUDSTACK-9240: - Commit 7d4b3d4d806d5a55c4710656b0391e9a781ce88c in cloudstack's branch refs/heads/4.7 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7d4b3d4 ] Merge pull request #1343 from remibergsma/CLOUDSTACK-9240 CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scriptsBoth createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the size of the template that gets created. I could not find any justification of that. I am just removing them as they caused us a huge headache when we tried to create bigger templates and they failed without any good error. This closes #1223 (This PR was against master, made a new one against 4.7) Thanks Syed * pr/1343: CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scripts Signed-off-by: Remi Bergsma > Templatesize >40GB doesn't work properly > > > Key: CLOUDSTACK-9240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9240 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Remi Bergsma >Assignee: Remi Bergsma >Priority: Critical > Fix For: 4.7.1 > > > Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the > size of the template that gets created. I could not find any justification of > that. I am just removing them as they caused us a huge headache when we tried > to create bigger templates and they failed without any good error. > Source: https://github.com/apache/cloudstack/pull/1223 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9041) Modifying template creation from snapshot function in base.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103691#comment-15103691 ] ASF subversion and git services commented on CLOUDSTACK-9041: - Commit ad420bb1dfb78fca6202ac46e18535d39d8d073f in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ad420bb ] Merge pull request #1041 from pritisarap12/CLOUDSTACK-9041-Modifying-template-creation-from-snapshot-function-in-base.py CLOUDSTACK-9041: Modifying template creation from snapshot function In create_from_snapshot function of Template class there is no parameter to accept if the template is public hence default it is creating private templates Hence adding this parameter. * pr/1041: CLOUDSTACK-9041: Modifying template creation from snapshot function in base.py Signed-off-by: Remi Bergsma > Modifying template creation from snapshot function in base.py > - > > Key: CLOUDSTACK-9041 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9041 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > In create_from_snapshot function of Template class there is no parameter to > accept if the template is public hence default it is creating private > templates > Hence adding this parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9041) Modifying template creation from snapshot function in base.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103694#comment-15103694 ] ASF GitHub Bot commented on CLOUDSTACK-9041: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1041 > Modifying template creation from snapshot function in base.py > - > > Key: CLOUDSTACK-9041 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9041 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > In create_from_snapshot function of Template class there is no parameter to > accept if the template is public hence default it is creating private > templates > Hence adding this parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9041) Modifying template creation from snapshot function in base.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103692#comment-15103692 ] ASF subversion and git services commented on CLOUDSTACK-9041: - Commit ad420bb1dfb78fca6202ac46e18535d39d8d073f in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ad420bb ] Merge pull request #1041 from pritisarap12/CLOUDSTACK-9041-Modifying-template-creation-from-snapshot-function-in-base.py CLOUDSTACK-9041: Modifying template creation from snapshot function In create_from_snapshot function of Template class there is no parameter to accept if the template is public hence default it is creating private templates Hence adding this parameter. * pr/1041: CLOUDSTACK-9041: Modifying template creation from snapshot function in base.py Signed-off-by: Remi Bergsma > Modifying template creation from snapshot function in base.py > - > > Key: CLOUDSTACK-9041 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9041 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > In create_from_snapshot function of Template class there is no parameter to > accept if the template is public hence default it is creating private > templates > Hence adding this parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9041) Modifying template creation from snapshot function in base.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103693#comment-15103693 ] ASF subversion and git services commented on CLOUDSTACK-9041: - Commit ad420bb1dfb78fca6202ac46e18535d39d8d073f in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ad420bb ] Merge pull request #1041 from pritisarap12/CLOUDSTACK-9041-Modifying-template-creation-from-snapshot-function-in-base.py CLOUDSTACK-9041: Modifying template creation from snapshot function In create_from_snapshot function of Template class there is no parameter to accept if the template is public hence default it is creating private templates Hence adding this parameter. * pr/1041: CLOUDSTACK-9041: Modifying template creation from snapshot function in base.py Signed-off-by: Remi Bergsma > Modifying template creation from snapshot function in base.py > - > > Key: CLOUDSTACK-9041 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9041 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > In create_from_snapshot function of Template class there is no parameter to > accept if the template is public hence default it is creating private > templates > Hence adding this parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9041) Modifying template creation from snapshot function in base.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103690#comment-15103690 ] ASF subversion and git services commented on CLOUDSTACK-9041: - Commit bbe0fc4be9527d51820b067a602886003991db4d in cloudstack's branch refs/heads/master from [~pritisarap12] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bbe0fc4 ] CLOUDSTACK-9041: Modifying template creation from snapshot function in base.py > Modifying template creation from snapshot function in base.py > - > > Key: CLOUDSTACK-9041 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9041 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > In create_from_snapshot function of Template class there is no parameter to > accept if the template is public hence default it is creating private > templates > Hence adding this parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9005) Modifying tearDown function
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103698#comment-15103698 ] ASF subversion and git services commented on CLOUDSTACK-9005: - Commit a4d0af21331a395f02b7e0d459d5452c2212e408 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a4d0af2 ] Merge pull request #1000 from pritisarap12/CLOUDSTACK-9005-Modifying-tearDown-function CLOUDSTACK-9005: Modifying tearDown functionModifying tearDown function to check if data volume is in detached state before deleting the volume * pr/1000: CLOUDSTACK-9005: Modifying tearDown function Signed-off-by: Remi Bergsma > Modifying tearDown function > > > Key: CLOUDSTACK-9005 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9005 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > Modifying tearDown function to check if data volume is in detached state > before deleting the volume -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9005) Modifying tearDown function
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103696#comment-15103696 ] ASF subversion and git services commented on CLOUDSTACK-9005: - Commit a4d0af21331a395f02b7e0d459d5452c2212e408 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a4d0af2 ] Merge pull request #1000 from pritisarap12/CLOUDSTACK-9005-Modifying-tearDown-function CLOUDSTACK-9005: Modifying tearDown functionModifying tearDown function to check if data volume is in detached state before deleting the volume * pr/1000: CLOUDSTACK-9005: Modifying tearDown function Signed-off-by: Remi Bergsma > Modifying tearDown function > > > Key: CLOUDSTACK-9005 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9005 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > Modifying tearDown function to check if data volume is in detached state > before deleting the volume -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9005) Modifying tearDown function
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103697#comment-15103697 ] ASF subversion and git services commented on CLOUDSTACK-9005: - Commit a4d0af21331a395f02b7e0d459d5452c2212e408 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a4d0af2 ] Merge pull request #1000 from pritisarap12/CLOUDSTACK-9005-Modifying-tearDown-function CLOUDSTACK-9005: Modifying tearDown functionModifying tearDown function to check if data volume is in detached state before deleting the volume * pr/1000: CLOUDSTACK-9005: Modifying tearDown function Signed-off-by: Remi Bergsma > Modifying tearDown function > > > Key: CLOUDSTACK-9005 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9005 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > Modifying tearDown function to check if data volume is in detached state > before deleting the volume -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9005) Modifying tearDown function
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103695#comment-15103695 ] ASF subversion and git services commented on CLOUDSTACK-9005: - Commit d793c7f50ff56a3ecdd6c8862df1ee67ebcc9ac4 in cloudstack's branch refs/heads/master from [~pritisarap12] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d793c7f ] CLOUDSTACK-9005: Modifying tearDown function > Modifying tearDown function > > > Key: CLOUDSTACK-9005 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9005 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > Modifying tearDown function to check if data volume is in detached state > before deleting the volume -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9005) Modifying tearDown function
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103699#comment-15103699 ] ASF GitHub Bot commented on CLOUDSTACK-9005: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1000 > Modifying tearDown function > > > Key: CLOUDSTACK-9005 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9005 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > Modifying tearDown function to check if data volume is in detached state > before deleting the volume -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9001) Modifying snapshot results validation in testpath_uuid_event testpath
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103701#comment-15103701 ] ASF subversion and git services commented on CLOUDSTACK-9001: - Commit 0e01c7f357cd6596570fd966e0f2ac65c4bbedb1 in cloudstack's branch refs/heads/master from [~pritisarap12] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0e01c7f ] CLOUDSTACK-9001: Modifying snapshot results validation in testpath_uuid_event testpath > Modifying snapshot results validation in testpath_uuid_event testpath > -- > > Key: CLOUDSTACK-9001 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9001 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > Currently snapshots results validation is based on length of snapshot result > but if snapshot creation fails then None type object will not have "len" > attribute hence modifying the validation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9001) Modifying snapshot results validation in testpath_uuid_event testpath
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103703#comment-15103703 ] ASF subversion and git services commented on CLOUDSTACK-9001: - Commit 329c012b7947bfbdeedcb608b2352c749203e458 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=329c012 ] Merge pull request #994 from pritisarap12/snapshot-has-no-attribute-len CLOUDSTACK-9001: Modifying snapshot results validation Currently snapshots results validation is based on length of snapshot result but if snapshot creation fails then None type object will not have "len" attribute hence modifying the validation. * pr/994: CLOUDSTACK-9001: Modifying snapshot results validation in testpath_uuid_event testpath Signed-off-by: Remi Bergsma > Modifying snapshot results validation in testpath_uuid_event testpath > -- > > Key: CLOUDSTACK-9001 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9001 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > Currently snapshots results validation is based on length of snapshot result > but if snapshot creation fails then None type object will not have "len" > attribute hence modifying the validation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9001) Modifying snapshot results validation in testpath_uuid_event testpath
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103702#comment-15103702 ] ASF subversion and git services commented on CLOUDSTACK-9001: - Commit 329c012b7947bfbdeedcb608b2352c749203e458 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=329c012 ] Merge pull request #994 from pritisarap12/snapshot-has-no-attribute-len CLOUDSTACK-9001: Modifying snapshot results validation Currently snapshots results validation is based on length of snapshot result but if snapshot creation fails then None type object will not have "len" attribute hence modifying the validation. * pr/994: CLOUDSTACK-9001: Modifying snapshot results validation in testpath_uuid_event testpath Signed-off-by: Remi Bergsma > Modifying snapshot results validation in testpath_uuid_event testpath > -- > > Key: CLOUDSTACK-9001 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9001 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > Currently snapshots results validation is based on length of snapshot result > but if snapshot creation fails then None type object will not have "len" > attribute hence modifying the validation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9001) Modifying snapshot results validation in testpath_uuid_event testpath
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103705#comment-15103705 ] ASF GitHub Bot commented on CLOUDSTACK-9001: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/994 > Modifying snapshot results validation in testpath_uuid_event testpath > -- > > Key: CLOUDSTACK-9001 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9001 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Priti Sarap > > Currently snapshots results validation is based on length of snapshot result > but if snapshot creation fails then None type object will not have "len" > attribute hence modifying the validation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9240) Templatesize >40GB doesn't work properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103712#comment-15103712 ] ASF subversion and git services commented on CLOUDSTACK-9240: - Commit 262be758bcc140f09cdf7b1df2057ecfacd7e1f2 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=262be75 ] Merge release branch 4.7 to master * 4.7: CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scripts > Templatesize >40GB doesn't work properly > > > Key: CLOUDSTACK-9240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9240 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Remi Bergsma >Assignee: Remi Bergsma >Priority: Critical > Fix For: 4.7.1 > > > Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the > size of the template that gets created. I could not find any justification of > that. I am just removing them as they caused us a huge headache when we tried > to create bigger templates and they failed without any good error. > Source: https://github.com/apache/cloudstack/pull/1223 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9240) Templatesize >40GB doesn't work properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103709#comment-15103709 ] ASF subversion and git services commented on CLOUDSTACK-9240: - Commit 7d4b3d4d806d5a55c4710656b0391e9a781ce88c in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7d4b3d4 ] Merge pull request #1343 from remibergsma/CLOUDSTACK-9240 CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scriptsBoth createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the size of the template that gets created. I could not find any justification of that. I am just removing them as they caused us a huge headache when we tried to create bigger templates and they failed without any good error. This closes #1223 (This PR was against master, made a new one against 4.7) Thanks Syed * pr/1343: CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scripts Signed-off-by: Remi Bergsma > Templatesize >40GB doesn't work properly > > > Key: CLOUDSTACK-9240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9240 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Remi Bergsma >Assignee: Remi Bergsma >Priority: Critical > Fix For: 4.7.1 > > > Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the > size of the template that gets created. I could not find any justification of > that. I am just removing them as they caused us a huge headache when we tried > to create bigger templates and they failed without any good error. > Source: https://github.com/apache/cloudstack/pull/1223 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9240) Templatesize >40GB doesn't work properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103708#comment-15103708 ] ASF subversion and git services commented on CLOUDSTACK-9240: - Commit 69022f97c5283eb12abe41aabbee73a6a945c332 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=69022f9 ] CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scripts Thanks Syed > Templatesize >40GB doesn't work properly > > > Key: CLOUDSTACK-9240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9240 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Remi Bergsma >Assignee: Remi Bergsma >Priority: Critical > Fix For: 4.7.1 > > > Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the > size of the template that gets created. I could not find any justification of > that. I am just removing them as they caused us a huge headache when we tried > to create bigger templates and they failed without any good error. > Source: https://github.com/apache/cloudstack/pull/1223 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9240) Templatesize >40GB doesn't work properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103710#comment-15103710 ] ASF subversion and git services commented on CLOUDSTACK-9240: - Commit 7d4b3d4d806d5a55c4710656b0391e9a781ce88c in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7d4b3d4 ] Merge pull request #1343 from remibergsma/CLOUDSTACK-9240 CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scriptsBoth createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the size of the template that gets created. I could not find any justification of that. I am just removing them as they caused us a huge headache when we tried to create bigger templates and they failed without any good error. This closes #1223 (This PR was against master, made a new one against 4.7) Thanks Syed * pr/1343: CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scripts Signed-off-by: Remi Bergsma > Templatesize >40GB doesn't work properly > > > Key: CLOUDSTACK-9240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9240 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Remi Bergsma >Assignee: Remi Bergsma >Priority: Critical > Fix For: 4.7.1 > > > Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the > size of the template that gets created. I could not find any justification of > that. I am just removing them as they caused us a huge headache when we tried > to create bigger templates and they failed without any good error. > Source: https://github.com/apache/cloudstack/pull/1223 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9240) Templatesize >40GB doesn't work properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103711#comment-15103711 ] ASF subversion and git services commented on CLOUDSTACK-9240: - Commit 7d4b3d4d806d5a55c4710656b0391e9a781ce88c in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7d4b3d4 ] Merge pull request #1343 from remibergsma/CLOUDSTACK-9240 CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scriptsBoth createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the size of the template that gets created. I could not find any justification of that. I am just removing them as they caused us a huge headache when we tried to create bigger templates and they failed without any good error. This closes #1223 (This PR was against master, made a new one against 4.7) Thanks Syed * pr/1343: CLOUDSTACK-9240 remove 40GB filesize limit from SSVM scripts Signed-off-by: Remi Bergsma > Templatesize >40GB doesn't work properly > > > Key: CLOUDSTACK-9240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9240 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 >Reporter: Remi Bergsma >Assignee: Remi Bergsma >Priority: Critical > Fix For: 4.7.1 > > > Both createvolume.sh and createtmplt.sh have a 40GB hardcoded limit for the > size of the template that gets created. I could not find any justification of > that. I am just removing them as they caused us a huge headache when we tried > to create bigger templates and they failed without any good error. > Source: https://github.com/apache/cloudstack/pull/1223 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9195) Cancelled/failed async jobs not getting cleaned up from DB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103719#comment-15103719 ] ASF GitHub Bot commented on CLOUDSTACK-9195: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1272#issuecomment-172323097 @koushik-das your change makes perfect sense to me from a db housekeeping point of view. I have one (little) doubt; what are the semantic ramifications. An asynchronous job might have continued after MS shutdown and its result might be actually success or failure. I am not sure if diving into this field is appropriate for this PR. Just checking with you as you might have already considered it. code LGTM > Cancelled/failed async jobs not getting cleaned up from DB > -- > > Key: CLOUDSTACK-9195 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9195 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0, 4.7.0 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.8.0 > > > Some cancelled/failed async jobs are not getting cleaned up from DB even > after "job.expire.minutes". These jobs are marked as cancelled/failed when MS > is restarted, check for 'job_status' as 2 (FAILED) and 'job_result' as "job > cancelled because of management server restart or shutdown" in async_job > table in DB. These are not getting cleaned as 'job_complete_msid' field is > not set in DB. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9054) countIp6InRange(final String ip6Range) does not handle open range
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103734#comment-15103734 ] ASF GitHub Bot commented on CLOUDSTACK-9054: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1060#issuecomment-172326528 discussions to dev@ as indicated by @jburwell . this PR losts its purpose. > countIp6InRange(final String ip6Range) does not handle open range > - > > Key: CLOUDSTACK-9054 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9054 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > in case of '-1::0' or "0::0-" errors are thrown while the meaning of the > range is clear > In the testcase for this method an exception is thrown because of this: > 2015-11-11 10:20:57,997 ERROR [utils.net.NetUtils] (main:) Failed to convert > a string to an IPv6 address > java.lang.IllegalArgumentException: can not parse [] > at > com.googlecode.ipv6.IPv6Address.tryParseStringArrayIntoLongArray(IPv6Address.java:94) > at com.googlecode.ipv6.IPv6Address.fromString(IPv6Address.java:80) > at com.cloud.utils.net.NetUtils.countIp6InRange(NetUtils.java:1332) > at > com.cloud.utils.net.NetUtilsTest.testCountIp6InRangeWithNullStart(NetUtilsTest.java:153) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9054) countIp6InRange(final String ip6Range) does not handle open range
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103735#comment-15103735 ] ASF GitHub Bot commented on CLOUDSTACK-9054: Github user DaanHoogland closed the pull request at: https://github.com/apache/cloudstack/pull/1060 > countIp6InRange(final String ip6Range) does not handle open range > - > > Key: CLOUDSTACK-9054 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9054 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > in case of '-1::0' or "0::0-" errors are thrown while the meaning of the > range is clear > In the testcase for this method an exception is thrown because of this: > 2015-11-11 10:20:57,997 ERROR [utils.net.NetUtils] (main:) Failed to convert > a string to an IPv6 address > java.lang.IllegalArgumentException: can not parse [] > at > com.googlecode.ipv6.IPv6Address.tryParseStringArrayIntoLongArray(IPv6Address.java:94) > at com.googlecode.ipv6.IPv6Address.fromString(IPv6Address.java:80) > at com.cloud.utils.net.NetUtils.countIp6InRange(NetUtils.java:1332) > at > com.cloud.utils.net.NetUtilsTest.testCountIp6InRangeWithNullStart(NetUtilsTest.java:153) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9120) As a Developer I want the new component tests to be moved into the smoke directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103743#comment-15103743 ] ASF GitHub Bot commented on CLOUDSTACK-9120: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1202#issuecomment-172328911 @remibergsma good point, will do > As a Developer I want the new component tests to be moved into the smoke > directory > -- > > Key: CLOUDSTACK-9120 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9120 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues >Priority: Minor > > The following tests... > component/test_routers_network_ops.py > component/test_vpc_redundant.py > component/test_router_dhcphosts.py > component/test_routers_iptables_default_policy > component/test_vpc_router_nics > ... should be moved into the smoke directory due to their nature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9231) Root volume migration from one primary to another primary storage within the same cluster is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103747#comment-15103747 ] ASF GitHub Bot commented on CLOUDSTACK-9231: Github user cristofolini commented on the pull request: https://github.com/apache/cloudstack/pull/1336#issuecomment-172333464 Fix looks simple enough. Code LGTM. Although I would usually suggest adding a javadoc the new `MigrateWithStorageCommand` method you've created, this just changes the existing method (which looks clear enough to me already) to use Lists instead of maps, so I'll leave that decision up to you @nitin-maharana. > Root volume migration from one primary to another primary storage within the > same cluster is failing > > > Key: CLOUDSTACK-9231 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9231 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > EXPECTED BEHAVIOR > === > Root Volume migration within cluster should work. > ACTUAL BEHAVIOR > > Root volume migration within cluster failed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103821#comment-15103821
]
ASF GitHub Bot commented on CLOUDSTACK-9154:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1277#issuecomment-172359841
Run the tests again, all fine.
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,required_hardware=true \
component/test_vpc_redundant.py \
component/test_routers_iptables_default_policy.py \
component/test_routers_network_ops.py \
component/test_vpc_router_nics.py \
smoke/test_loadbalance.py \
smoke/test_internal_lb.py \
smoke/test_ssvm.py \
smoke/test_network.py
```
Result:
```
Check the password file in the Router VM ... === TestName:
test_isolate_network_password_server | Status : SUCCESS ===
ok
Create a redundant VPC with two networks with two VMs in each network ...
=== TestName: test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Status :
SUCCESS ===
ok
Create a redundant VPC with two networks with two VMs in each network and
check default routes ... === TestName: test_02_redundant_VPC_default_routes |
Status : SUCCESS ===
ok
Create a redundant VPC with two networks with two VMs in each network ...
=== TestName:
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Status :
SUCCESS ===
ok
Create a redundant VPC with 1 Tier, 1 VM, 1 ACL, 1 PF and test Network GC
Nics ... === TestName: test_04_rvpc_network_garbage_collector_nics | Status :
SUCCESS ===
ok
Create a redundant VPC with 1 Tier, 1 VM, 1 ACL, 1 PF and test Network GC
Nics ... === TestName: test_05_rvpc_multi_tiers | Status : SUCCESS ===
ok
Test iptables default INPUT/FORWARD policy on RouterVM ... === TestName:
test_02_routervm_iptables_policies | Status : SUCCESS ===
ok
Test iptables default INPUT/FORWARD policies on VPC router ... ===
TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName:
test_03_RVR_Network_check_router_state | Status : SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test nics
after destroy ... === TestName: test_01_VPC_nics_after_destroy | Status :
SUCCESS ===
ok
Create a VPC with two networks with one VM in each network and test default
routes ... === TestName: test_02_VPC_default_routes | Status : SUCCESS ===
ok
Check that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... ===
TestName: test_router_dhcphosts | Status : SUCCESS ===
ok
Test to create Load balancing rule with source NAT ... === TestName:
test_01_create_lb_rule_src_nat | Status : SUCCESS ===
ok
Test to create Load balancing rule with non source NAT ... === TestName:
test_02_create_lb_rule_non_nat | Status : SUCCESS ===
ok
Test for assign & removing load balancing rule ... === TestName:
test_assign_and_removal_lb | Status : SUCCESS ===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic
to 3 vm's in a Single VPC ... === TestName:
test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 | Status : SUCCESS ===
ok
Test create, assign, remove of an Internal LB with roundrobin http traffic
to 3 vm's in a Redundant VPC ... === TestName:
test_02_internallb_roundrobin_1RVPC_3VM_HTTP_port80 | Status : SUCCESS ===
ok
Test to verify access to loadbalancer haproxy admin stats page ... ===
TestName: test_03_vpc_internallb_haproxy_stats_on_all_interfaces | Status :
SUCCESS ===
ok
Test to verify access to loadbalancer haproxy admin stats page ... ===
TestName: test_04_rvpc_internallb_haproxy_stats_on_all_interfaces | Status :
SUCCESS ===
ok
Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status :
SUCCESS ===
ok
Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status :
SUCCESS ===
ok
Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS ===
ok
Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS ===
ok
Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS
===
ok
Test reb
[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103828#comment-15103828
]
ASF subversion and git services commented on CLOUDSTACK-9154:
-
Commit 5ef3144fdf65922a3da99357c6f90f3811b231d8 in cloudstack's branch
refs/heads/4.7 from [~wilder.rodrigues]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5ef3144 ]
CLOUDSTACK-9154 - Sets the pub interface down when all guest nets are gone
- Refactors the set_backup, set_master and set_fault methods to have better
names for the variable
- Increase the sleep on the test in order to wait for the routers to be
ready. It's now 3 times the GC settings
> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo: mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> {
>
> [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.2.146",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth1": [
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.24/24",
> "device": "eth1",
> "first_i_p": true,
> "gateway": "x.y.238.1",
> "netmask": "255.255.255.0",
> "network": "x.y.238.0/24",
> "new_nic": false,
> "nic_dev_id": 1,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "x.y.238.24",
> "size": "24",
> "source_nat": true,
> "vif_mac_address": "06:fc:da:00:00:1c"
> },
> {
> "add": true,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.51/24",
> "device": "eth1",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "1",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.51",
> "size": "24",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": false,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.173/24",
>
[jira] [Commented] (CLOUDSTACK-9187) rVPC routers in Master/Master due to concurrency problem when writing the keepalivd.conf
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103840#comment-15103840
]
ASF subversion and git services commented on CLOUDSTACK-9187:
-
Commit ff89587fd119b1cad543d8e96f0c428e41c35840 in cloudstack's branch
refs/heads/4.7 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff89587 ]
Merge pull request #1277 from ekholabs/fix/4.7-rvpc-net-gc-CLOUDSTACK-9154
[4.7] Critical VPCVR issues fixed: CLOUDSTACK-9154; CLOUDSTACK-9187; and
CLOUDSTACK-9188This PR applies the same fixes as in the PR #1259, but against
branch 4.7.
Please refer to PR #1259 for the tests results and all the comments already
made there.
Issues fixed are:
* CLOUDSTACK-9154: rVPC doesn't recover from cleaning up of network garbage
collector
* CLOUDSTACK-9187: rVPC routers in Master/Master due to concurrency problem
when writing the keepalivd.conf
* CLOUDSTACK-9188: NetworkGarbageCollector is not using gc.interval and gc.wait
from settings
Those changes have been covered by 2 new tests added to
```smoke/test_vpc_redundant.py```:
* test_04_rvpc_network_garbage_collector_nics
* test_05_rvpc_multi_tiers
The test ```test_04_rvpc_network_garbage_collector_nics``` depends on the
global settings for the network.gc.interval and gc.wait. If one wants the test
to run quicker, please change the settings (default is 600 seconds for each)
and restart the Management Server before running the tests. I would suggest to
set it to 60 seconds.
In addition, the NetworkGarbageCollector was redefining the settings above
mentioned and not reading their values through ConfigDao. Due to that, the
settings were not being applied properly and the test was waiting to long to
check the VPC routers.
* pr/1277:
CLOUDSTACK-9154 - Sets the pub interface down when all guest nets are gone
CLOUDSTACK-9187 - Makes code ready for more something like eth, if we
ever get that far
CLOUDSTACK-9188 - Reads network GC interval and wait from configDao
CLOUDSTACK-9187 - Fixes interface allocation to VRRP instances
CLOUDSTACK-9187 - Adds test to cover multiple nics and nic removal
CLOUDSTACK-9154 - Adds test to cover nics state after GC
CLOUDSTACK-9154 - Returns the guest iterface that is marked as added
Signed-off-by: Remi Bergsma
> rVPC routers in Master/Master due to concurrency problem when writing the
> keepalivd.conf
>
>
> Key: CLOUDSTACK-9187
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9187
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth3
> virtual_router_id 51
> ```
> and this is r-518-VM:
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth4
> virtual_router_id 51
> nopreempt
> ```
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9187) rVPC routers in Master/Master due to concurrency problem when writing the keepalivd.conf
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103831#comment-15103831
]
ASF subversion and git services commented on CLOUDSTACK-9187:
-
Commit ff89587fd119b1cad543d8e96f0c428e41c35840 in cloudstack's branch
refs/heads/4.7 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff89587 ]
Merge pull request #1277 from ekholabs/fix/4.7-rvpc-net-gc-CLOUDSTACK-9154
[4.7] Critical VPCVR issues fixed: CLOUDSTACK-9154; CLOUDSTACK-9187; and
CLOUDSTACK-9188This PR applies the same fixes as in the PR #1259, but against
branch 4.7.
Please refer to PR #1259 for the tests results and all the comments already
made there.
Issues fixed are:
* CLOUDSTACK-9154: rVPC doesn't recover from cleaning up of network garbage
collector
* CLOUDSTACK-9187: rVPC routers in Master/Master due to concurrency problem
when writing the keepalivd.conf
* CLOUDSTACK-9188: NetworkGarbageCollector is not using gc.interval and gc.wait
from settings
Those changes have been covered by 2 new tests added to
```smoke/test_vpc_redundant.py```:
* test_04_rvpc_network_garbage_collector_nics
* test_05_rvpc_multi_tiers
The test ```test_04_rvpc_network_garbage_collector_nics``` depends on the
global settings for the network.gc.interval and gc.wait. If one wants the test
to run quicker, please change the settings (default is 600 seconds for each)
and restart the Management Server before running the tests. I would suggest to
set it to 60 seconds.
In addition, the NetworkGarbageCollector was redefining the settings above
mentioned and not reading their values through ConfigDao. Due to that, the
settings were not being applied properly and the test was waiting to long to
check the VPC routers.
* pr/1277:
CLOUDSTACK-9154 - Sets the pub interface down when all guest nets are gone
CLOUDSTACK-9187 - Makes code ready for more something like eth, if we
ever get that far
CLOUDSTACK-9188 - Reads network GC interval and wait from configDao
CLOUDSTACK-9187 - Fixes interface allocation to VRRP instances
CLOUDSTACK-9187 - Adds test to cover multiple nics and nic removal
CLOUDSTACK-9154 - Adds test to cover nics state after GC
CLOUDSTACK-9154 - Returns the guest iterface that is marked as added
Signed-off-by: Remi Bergsma
> rVPC routers in Master/Master due to concurrency problem when writing the
> keepalivd.conf
>
>
> Key: CLOUDSTACK-9187
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9187
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth3
> virtual_router_id 51
> ```
> and this is r-518-VM:
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth4
> virtual_router_id 51
> nopreempt
> ```
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9188) NetworkGarbageCollector is not using gc.interval and gc.wait from settings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103835#comment-15103835 ] ASF subversion and git services commented on CLOUDSTACK-9188: - Commit ff89587fd119b1cad543d8e96f0c428e41c35840 in cloudstack's branch refs/heads/4.7 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff89587 ] Merge pull request #1277 from ekholabs/fix/4.7-rvpc-net-gc-CLOUDSTACK-9154 [4.7] Critical VPCVR issues fixed: CLOUDSTACK-9154; CLOUDSTACK-9187; and CLOUDSTACK-9188This PR applies the same fixes as in the PR #1259, but against branch 4.7. Please refer to PR #1259 for the tests results and all the comments already made there. Issues fixed are: * CLOUDSTACK-9154: rVPC doesn't recover from cleaning up of network garbage collector * CLOUDSTACK-9187: rVPC routers in Master/Master due to concurrency problem when writing the keepalivd.conf * CLOUDSTACK-9188: NetworkGarbageCollector is not using gc.interval and gc.wait from settings Those changes have been covered by 2 new tests added to ```smoke/test_vpc_redundant.py```: * test_04_rvpc_network_garbage_collector_nics * test_05_rvpc_multi_tiers The test ```test_04_rvpc_network_garbage_collector_nics``` depends on the global settings for the network.gc.interval and gc.wait. If one wants the test to run quicker, please change the settings (default is 600 seconds for each) and restart the Management Server before running the tests. I would suggest to set it to 60 seconds. In addition, the NetworkGarbageCollector was redefining the settings above mentioned and not reading their values through ConfigDao. Due to that, the settings were not being applied properly and the test was waiting to long to check the VPC routers. * pr/1277: CLOUDSTACK-9154 - Sets the pub interface down when all guest nets are gone CLOUDSTACK-9187 - Makes code ready for more something like eth, if we ever get that far CLOUDSTACK-9188 - Reads network GC interval and wait from configDao CLOUDSTACK-9187 - Fixes interface allocation to VRRP instances CLOUDSTACK-9187 - Adds test to cover multiple nics and nic removal CLOUDSTACK-9154 - Adds test to cover nics state after GC CLOUDSTACK-9154 - Returns the guest iterface that is marked as added Signed-off-by: Remi Bergsma > NetworkGarbageCollector is not using gc.interval and gc.wait from settings > -- > > Key: CLOUDSTACK-9188 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9188 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.7.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues > Fix For: 4.7.1 > > > The settings are bing used from local object and not retrieving what has been > saved in the DB. > From lines to 3336: > public static final ConfigKey NetworkGcWait = new > ConfigKey(Integer.class, "network.gc.wait", "Advanced", "600", > "Time (in seconds) to wait before shutting down a network that's > not in used", false, Scope.Global, null); > public static final ConfigKey NetworkGcInterval = new > ConfigKey(Integer.class, "network.gc.interval", "Advanced", "600", > "Seconds to wait before checking for networks to shutdown", true, > Scope.Global, null); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103823#comment-15103823
]
ASF subversion and git services commented on CLOUDSTACK-9154:
-
Commit 749ac2e2242d8af9f05977951dd1b4855c1f6f08 in cloudstack's branch
refs/heads/4.7 from [~wilder.rodrigues]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=749ac2e ]
CLOUDSTACK-9154 - Adds test to cover nics state after GC
> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo: mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> {
>
> [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.2.146",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth1": [
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.24/24",
> "device": "eth1",
> "first_i_p": true,
> "gateway": "x.y.238.1",
> "netmask": "255.255.255.0",
> "network": "x.y.238.0/24",
> "new_nic": false,
> "nic_dev_id": 1,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "x.y.238.24",
> "size": "24",
> "source_nat": true,
> "vif_mac_address": "06:fc:da:00:00:1c"
> },
> {
> "add": true,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.51/24",
> "device": "eth1",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "1",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.51",
> "size": "24",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": false,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.173/24",
> "device": "eth2",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_
[jira] [Commented] (CLOUDSTACK-9187) rVPC routers in Master/Master due to concurrency problem when writing the keepalivd.conf
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103834#comment-15103834
]
ASF subversion and git services commented on CLOUDSTACK-9187:
-
Commit ff89587fd119b1cad543d8e96f0c428e41c35840 in cloudstack's branch
refs/heads/4.7 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff89587 ]
Merge pull request #1277 from ekholabs/fix/4.7-rvpc-net-gc-CLOUDSTACK-9154
[4.7] Critical VPCVR issues fixed: CLOUDSTACK-9154; CLOUDSTACK-9187; and
CLOUDSTACK-9188This PR applies the same fixes as in the PR #1259, but against
branch 4.7.
Please refer to PR #1259 for the tests results and all the comments already
made there.
Issues fixed are:
* CLOUDSTACK-9154: rVPC doesn't recover from cleaning up of network garbage
collector
* CLOUDSTACK-9187: rVPC routers in Master/Master due to concurrency problem
when writing the keepalivd.conf
* CLOUDSTACK-9188: NetworkGarbageCollector is not using gc.interval and gc.wait
from settings
Those changes have been covered by 2 new tests added to
```smoke/test_vpc_redundant.py```:
* test_04_rvpc_network_garbage_collector_nics
* test_05_rvpc_multi_tiers
The test ```test_04_rvpc_network_garbage_collector_nics``` depends on the
global settings for the network.gc.interval and gc.wait. If one wants the test
to run quicker, please change the settings (default is 600 seconds for each)
and restart the Management Server before running the tests. I would suggest to
set it to 60 seconds.
In addition, the NetworkGarbageCollector was redefining the settings above
mentioned and not reading their values through ConfigDao. Due to that, the
settings were not being applied properly and the test was waiting to long to
check the VPC routers.
* pr/1277:
CLOUDSTACK-9154 - Sets the pub interface down when all guest nets are gone
CLOUDSTACK-9187 - Makes code ready for more something like eth, if we
ever get that far
CLOUDSTACK-9188 - Reads network GC interval and wait from configDao
CLOUDSTACK-9187 - Fixes interface allocation to VRRP instances
CLOUDSTACK-9187 - Adds test to cover multiple nics and nic removal
CLOUDSTACK-9154 - Adds test to cover nics state after GC
CLOUDSTACK-9154 - Returns the guest iterface that is marked as added
Signed-off-by: Remi Bergsma
> rVPC routers in Master/Master due to concurrency problem when writing the
> keepalivd.conf
>
>
> Key: CLOUDSTACK-9187
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9187
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth3
> virtual_router_id 51
> ```
> and this is r-518-VM:
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth4
> virtual_router_id 51
> nopreempt
> ```
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103829#comment-15103829
]
ASF subversion and git services commented on CLOUDSTACK-9154:
-
Commit ff89587fd119b1cad543d8e96f0c428e41c35840 in cloudstack's branch
refs/heads/4.7 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff89587 ]
Merge pull request #1277 from ekholabs/fix/4.7-rvpc-net-gc-CLOUDSTACK-9154
[4.7] Critical VPCVR issues fixed: CLOUDSTACK-9154; CLOUDSTACK-9187; and
CLOUDSTACK-9188This PR applies the same fixes as in the PR #1259, but against
branch 4.7.
Please refer to PR #1259 for the tests results and all the comments already
made there.
Issues fixed are:
* CLOUDSTACK-9154: rVPC doesn't recover from cleaning up of network garbage
collector
* CLOUDSTACK-9187: rVPC routers in Master/Master due to concurrency problem
when writing the keepalivd.conf
* CLOUDSTACK-9188: NetworkGarbageCollector is not using gc.interval and gc.wait
from settings
Those changes have been covered by 2 new tests added to
```smoke/test_vpc_redundant.py```:
* test_04_rvpc_network_garbage_collector_nics
* test_05_rvpc_multi_tiers
The test ```test_04_rvpc_network_garbage_collector_nics``` depends on the
global settings for the network.gc.interval and gc.wait. If one wants the test
to run quicker, please change the settings (default is 600 seconds for each)
and restart the Management Server before running the tests. I would suggest to
set it to 60 seconds.
In addition, the NetworkGarbageCollector was redefining the settings above
mentioned and not reading their values through ConfigDao. Due to that, the
settings were not being applied properly and the test was waiting to long to
check the VPC routers.
* pr/1277:
CLOUDSTACK-9154 - Sets the pub interface down when all guest nets are gone
CLOUDSTACK-9187 - Makes code ready for more something like eth, if we
ever get that far
CLOUDSTACK-9188 - Reads network GC interval and wait from configDao
CLOUDSTACK-9187 - Fixes interface allocation to VRRP instances
CLOUDSTACK-9187 - Adds test to cover multiple nics and nic removal
CLOUDSTACK-9154 - Adds test to cover nics state after GC
CLOUDSTACK-9154 - Returns the guest iterface that is marked as added
Signed-off-by: Remi Bergsma
> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo: mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> {
>
> [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
>
[jira] [Commented] (CLOUDSTACK-9187) rVPC routers in Master/Master due to concurrency problem when writing the keepalivd.conf
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103825#comment-15103825
]
ASF subversion and git services commented on CLOUDSTACK-9187:
-
Commit c99d6f18c9fccdc44698a30af1b20701a2e85df4 in cloudstack's branch
refs/heads/4.7 from [~wilder.rodrigues]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c99d6f1 ]
CLOUDSTACK-9187 - Fixes interface allocation to VRRP instances
> rVPC routers in Master/Master due to concurrency problem when writing the
> keepalivd.conf
>
>
> Key: CLOUDSTACK-9187
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9187
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth3
> virtual_router_id 51
> ```
> and this is r-518-VM:
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth4
> virtual_router_id 51
> nopreempt
> ```
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9187) rVPC routers in Master/Master due to concurrency problem when writing the keepalivd.conf
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103839#comment-15103839
]
ASF subversion and git services commented on CLOUDSTACK-9187:
-
Commit ff89587fd119b1cad543d8e96f0c428e41c35840 in cloudstack's branch
refs/heads/4.7 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff89587 ]
Merge pull request #1277 from ekholabs/fix/4.7-rvpc-net-gc-CLOUDSTACK-9154
[4.7] Critical VPCVR issues fixed: CLOUDSTACK-9154; CLOUDSTACK-9187; and
CLOUDSTACK-9188This PR applies the same fixes as in the PR #1259, but against
branch 4.7.
Please refer to PR #1259 for the tests results and all the comments already
made there.
Issues fixed are:
* CLOUDSTACK-9154: rVPC doesn't recover from cleaning up of network garbage
collector
* CLOUDSTACK-9187: rVPC routers in Master/Master due to concurrency problem
when writing the keepalivd.conf
* CLOUDSTACK-9188: NetworkGarbageCollector is not using gc.interval and gc.wait
from settings
Those changes have been covered by 2 new tests added to
```smoke/test_vpc_redundant.py```:
* test_04_rvpc_network_garbage_collector_nics
* test_05_rvpc_multi_tiers
The test ```test_04_rvpc_network_garbage_collector_nics``` depends on the
global settings for the network.gc.interval and gc.wait. If one wants the test
to run quicker, please change the settings (default is 600 seconds for each)
and restart the Management Server before running the tests. I would suggest to
set it to 60 seconds.
In addition, the NetworkGarbageCollector was redefining the settings above
mentioned and not reading their values through ConfigDao. Due to that, the
settings were not being applied properly and the test was waiting to long to
check the VPC routers.
* pr/1277:
CLOUDSTACK-9154 - Sets the pub interface down when all guest nets are gone
CLOUDSTACK-9187 - Makes code ready for more something like eth, if we
ever get that far
CLOUDSTACK-9188 - Reads network GC interval and wait from configDao
CLOUDSTACK-9187 - Fixes interface allocation to VRRP instances
CLOUDSTACK-9187 - Adds test to cover multiple nics and nic removal
CLOUDSTACK-9154 - Adds test to cover nics state after GC
CLOUDSTACK-9154 - Returns the guest iterface that is marked as added
Signed-off-by: Remi Bergsma
> rVPC routers in Master/Master due to concurrency problem when writing the
> keepalivd.conf
>
>
> Key: CLOUDSTACK-9187
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9187
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth3
> virtual_router_id 51
> ```
> and this is r-518-VM:
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth4
> virtual_router_id 51
> nopreempt
> ```
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103822#comment-15103822
]
ASF subversion and git services commented on CLOUDSTACK-9154:
-
Commit 7988f51ac07782ad9b9873c32438fd7cdb24edba in cloudstack's branch
refs/heads/4.7 from [~wilder.rodrigues]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7988f51 ]
CLOUDSTACK-9154 - Returns the guest iterface that is marked as added
- Force a restart of keepalived if conntrackd is not running or
configuration has changed
> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo: mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> {
>
> [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.2.146",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth1": [
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.24/24",
> "device": "eth1",
> "first_i_p": true,
> "gateway": "x.y.238.1",
> "netmask": "255.255.255.0",
> "network": "x.y.238.0/24",
> "new_nic": false,
> "nic_dev_id": 1,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "x.y.238.24",
> "size": "24",
> "source_nat": true,
> "vif_mac_address": "06:fc:da:00:00:1c"
> },
> {
> "add": true,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.51/24",
> "device": "eth1",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "1",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.51",
> "size": "24",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": false,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.173/24",
> "device": "eth2",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "
[jira] [Commented] (CLOUDSTACK-9188) NetworkGarbageCollector is not using gc.interval and gc.wait from settings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103838#comment-15103838 ] ASF subversion and git services commented on CLOUDSTACK-9188: - Commit ff89587fd119b1cad543d8e96f0c428e41c35840 in cloudstack's branch refs/heads/4.7 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff89587 ] Merge pull request #1277 from ekholabs/fix/4.7-rvpc-net-gc-CLOUDSTACK-9154 [4.7] Critical VPCVR issues fixed: CLOUDSTACK-9154; CLOUDSTACK-9187; and CLOUDSTACK-9188This PR applies the same fixes as in the PR #1259, but against branch 4.7. Please refer to PR #1259 for the tests results and all the comments already made there. Issues fixed are: * CLOUDSTACK-9154: rVPC doesn't recover from cleaning up of network garbage collector * CLOUDSTACK-9187: rVPC routers in Master/Master due to concurrency problem when writing the keepalivd.conf * CLOUDSTACK-9188: NetworkGarbageCollector is not using gc.interval and gc.wait from settings Those changes have been covered by 2 new tests added to ```smoke/test_vpc_redundant.py```: * test_04_rvpc_network_garbage_collector_nics * test_05_rvpc_multi_tiers The test ```test_04_rvpc_network_garbage_collector_nics``` depends on the global settings for the network.gc.interval and gc.wait. If one wants the test to run quicker, please change the settings (default is 600 seconds for each) and restart the Management Server before running the tests. I would suggest to set it to 60 seconds. In addition, the NetworkGarbageCollector was redefining the settings above mentioned and not reading their values through ConfigDao. Due to that, the settings were not being applied properly and the test was waiting to long to check the VPC routers. * pr/1277: CLOUDSTACK-9154 - Sets the pub interface down when all guest nets are gone CLOUDSTACK-9187 - Makes code ready for more something like eth, if we ever get that far CLOUDSTACK-9188 - Reads network GC interval and wait from configDao CLOUDSTACK-9187 - Fixes interface allocation to VRRP instances CLOUDSTACK-9187 - Adds test to cover multiple nics and nic removal CLOUDSTACK-9154 - Adds test to cover nics state after GC CLOUDSTACK-9154 - Returns the guest iterface that is marked as added Signed-off-by: Remi Bergsma > NetworkGarbageCollector is not using gc.interval and gc.wait from settings > -- > > Key: CLOUDSTACK-9188 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9188 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.7.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues > Fix For: 4.7.1 > > > The settings are bing used from local object and not retrieving what has been > saved in the DB. > From lines to 3336: > public static final ConfigKey NetworkGcWait = new > ConfigKey(Integer.class, "network.gc.wait", "Advanced", "600", > "Time (in seconds) to wait before shutting down a network that's > not in used", false, Scope.Global, null); > public static final ConfigKey NetworkGcInterval = new > ConfigKey(Integer.class, "network.gc.interval", "Advanced", "600", > "Seconds to wait before checking for networks to shutdown", true, > Scope.Global, null); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9188) NetworkGarbageCollector is not using gc.interval and gc.wait from settings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103826#comment-15103826 ] ASF subversion and git services commented on CLOUDSTACK-9188: - Commit 2aab4c142d47b77e7bbc584927a80b8ba180934e in cloudstack's branch refs/heads/4.7 from [~wilder.rodrigues] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2aab4c1 ] CLOUDSTACK-9188 - Reads network GC interval and wait from configDao > NetworkGarbageCollector is not using gc.interval and gc.wait from settings > -- > > Key: CLOUDSTACK-9188 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9188 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.7.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues > Fix For: 4.7.1 > > > The settings are bing used from local object and not retrieving what has been > saved in the DB. > From lines to 3336: > public static final ConfigKey NetworkGcWait = new > ConfigKey(Integer.class, "network.gc.wait", "Advanced", "600", > "Time (in seconds) to wait before shutting down a network that's > not in used", false, Scope.Global, null); > public static final ConfigKey NetworkGcInterval = new > ConfigKey(Integer.class, "network.gc.interval", "Advanced", "600", > "Seconds to wait before checking for networks to shutdown", true, > Scope.Global, null); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103830#comment-15103830
]
ASF subversion and git services commented on CLOUDSTACK-9154:
-
Commit ff89587fd119b1cad543d8e96f0c428e41c35840 in cloudstack's branch
refs/heads/4.7 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff89587 ]
Merge pull request #1277 from ekholabs/fix/4.7-rvpc-net-gc-CLOUDSTACK-9154
[4.7] Critical VPCVR issues fixed: CLOUDSTACK-9154; CLOUDSTACK-9187; and
CLOUDSTACK-9188This PR applies the same fixes as in the PR #1259, but against
branch 4.7.
Please refer to PR #1259 for the tests results and all the comments already
made there.
Issues fixed are:
* CLOUDSTACK-9154: rVPC doesn't recover from cleaning up of network garbage
collector
* CLOUDSTACK-9187: rVPC routers in Master/Master due to concurrency problem
when writing the keepalivd.conf
* CLOUDSTACK-9188: NetworkGarbageCollector is not using gc.interval and gc.wait
from settings
Those changes have been covered by 2 new tests added to
```smoke/test_vpc_redundant.py```:
* test_04_rvpc_network_garbage_collector_nics
* test_05_rvpc_multi_tiers
The test ```test_04_rvpc_network_garbage_collector_nics``` depends on the
global settings for the network.gc.interval and gc.wait. If one wants the test
to run quicker, please change the settings (default is 600 seconds for each)
and restart the Management Server before running the tests. I would suggest to
set it to 60 seconds.
In addition, the NetworkGarbageCollector was redefining the settings above
mentioned and not reading their values through ConfigDao. Due to that, the
settings were not being applied properly and the test was waiting to long to
check the VPC routers.
* pr/1277:
CLOUDSTACK-9154 - Sets the pub interface down when all guest nets are gone
CLOUDSTACK-9187 - Makes code ready for more something like eth, if we
ever get that far
CLOUDSTACK-9188 - Reads network GC interval and wait from configDao
CLOUDSTACK-9187 - Fixes interface allocation to VRRP instances
CLOUDSTACK-9187 - Adds test to cover multiple nics and nic removal
CLOUDSTACK-9154 - Adds test to cover nics state after GC
CLOUDSTACK-9154 - Returns the guest iterface that is marked as added
Signed-off-by: Remi Bergsma
> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo: mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> {
>
> [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
>
[jira] [Commented] (CLOUDSTACK-9187) rVPC routers in Master/Master due to concurrency problem when writing the keepalivd.conf
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103824#comment-15103824
]
ASF subversion and git services commented on CLOUDSTACK-9187:
-
Commit b1e421068280fe0acc427baf3e9f07dd2d610803 in cloudstack's branch
refs/heads/4.7 from [~wilder.rodrigues]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b1e4210 ]
CLOUDSTACK-9187 - Adds test to cover multiple nics and nic removal
> rVPC routers in Master/Master due to concurrency problem when writing the
> keepalivd.conf
>
>
> Key: CLOUDSTACK-9187
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9187
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth3
> virtual_router_id 51
> ```
> and this is r-518-VM:
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth4
> virtual_router_id 51
> nopreempt
> ```
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103833#comment-15103833
]
ASF subversion and git services commented on CLOUDSTACK-9154:
-
Commit ff89587fd119b1cad543d8e96f0c428e41c35840 in cloudstack's branch
refs/heads/4.7 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff89587 ]
Merge pull request #1277 from ekholabs/fix/4.7-rvpc-net-gc-CLOUDSTACK-9154
[4.7] Critical VPCVR issues fixed: CLOUDSTACK-9154; CLOUDSTACK-9187; and
CLOUDSTACK-9188This PR applies the same fixes as in the PR #1259, but against
branch 4.7.
Please refer to PR #1259 for the tests results and all the comments already
made there.
Issues fixed are:
* CLOUDSTACK-9154: rVPC doesn't recover from cleaning up of network garbage
collector
* CLOUDSTACK-9187: rVPC routers in Master/Master due to concurrency problem
when writing the keepalivd.conf
* CLOUDSTACK-9188: NetworkGarbageCollector is not using gc.interval and gc.wait
from settings
Those changes have been covered by 2 new tests added to
```smoke/test_vpc_redundant.py```:
* test_04_rvpc_network_garbage_collector_nics
* test_05_rvpc_multi_tiers
The test ```test_04_rvpc_network_garbage_collector_nics``` depends on the
global settings for the network.gc.interval and gc.wait. If one wants the test
to run quicker, please change the settings (default is 600 seconds for each)
and restart the Management Server before running the tests. I would suggest to
set it to 60 seconds.
In addition, the NetworkGarbageCollector was redefining the settings above
mentioned and not reading their values through ConfigDao. Due to that, the
settings were not being applied properly and the test was waiting to long to
check the VPC routers.
* pr/1277:
CLOUDSTACK-9154 - Sets the pub interface down when all guest nets are gone
CLOUDSTACK-9187 - Makes code ready for more something like eth, if we
ever get that far
CLOUDSTACK-9188 - Reads network GC interval and wait from configDao
CLOUDSTACK-9187 - Fixes interface allocation to VRRP instances
CLOUDSTACK-9187 - Adds test to cover multiple nics and nic removal
CLOUDSTACK-9154 - Adds test to cover nics state after GC
CLOUDSTACK-9154 - Returns the guest iterface that is marked as added
Signed-off-by: Remi Bergsma
> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo: mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> {
>
> [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
>
[jira] [Commented] (CLOUDSTACK-9187) rVPC routers in Master/Master due to concurrency problem when writing the keepalivd.conf
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103827#comment-15103827
]
ASF subversion and git services commented on CLOUDSTACK-9187:
-
Commit f5a6dee8dd6b89ef954d39b4ade91f8f898cc026 in cloudstack's branch
refs/heads/4.7 from [~wilder.rodrigues]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f5a6dee ]
CLOUDSTACK-9187 - Makes code ready for more something like eth, if we ever
get that far
- Adds log info to NetworkOrchestrator in order to make the work of the
Net-Scavenger more visible.
> rVPC routers in Master/Master due to concurrency problem when writing the
> keepalivd.conf
>
>
> Key: CLOUDSTACK-9187
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9187
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth3
> virtual_router_id 51
> ```
> and this is r-518-VM:
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth4
> virtual_router_id 51
> nopreempt
> ```
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103836#comment-15103836
]
ASF subversion and git services commented on CLOUDSTACK-9154:
-
Commit ff89587fd119b1cad543d8e96f0c428e41c35840 in cloudstack's branch
refs/heads/4.7 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff89587 ]
Merge pull request #1277 from ekholabs/fix/4.7-rvpc-net-gc-CLOUDSTACK-9154
[4.7] Critical VPCVR issues fixed: CLOUDSTACK-9154; CLOUDSTACK-9187; and
CLOUDSTACK-9188This PR applies the same fixes as in the PR #1259, but against
branch 4.7.
Please refer to PR #1259 for the tests results and all the comments already
made there.
Issues fixed are:
* CLOUDSTACK-9154: rVPC doesn't recover from cleaning up of network garbage
collector
* CLOUDSTACK-9187: rVPC routers in Master/Master due to concurrency problem
when writing the keepalivd.conf
* CLOUDSTACK-9188: NetworkGarbageCollector is not using gc.interval and gc.wait
from settings
Those changes have been covered by 2 new tests added to
```smoke/test_vpc_redundant.py```:
* test_04_rvpc_network_garbage_collector_nics
* test_05_rvpc_multi_tiers
The test ```test_04_rvpc_network_garbage_collector_nics``` depends on the
global settings for the network.gc.interval and gc.wait. If one wants the test
to run quicker, please change the settings (default is 600 seconds for each)
and restart the Management Server before running the tests. I would suggest to
set it to 60 seconds.
In addition, the NetworkGarbageCollector was redefining the settings above
mentioned and not reading their values through ConfigDao. Due to that, the
settings were not being applied properly and the test was waiting to long to
check the VPC routers.
* pr/1277:
CLOUDSTACK-9154 - Sets the pub interface down when all guest nets are gone
CLOUDSTACK-9187 - Makes code ready for more something like eth, if we
ever get that far
CLOUDSTACK-9188 - Reads network GC interval and wait from configDao
CLOUDSTACK-9187 - Fixes interface allocation to VRRP instances
CLOUDSTACK-9187 - Adds test to cover multiple nics and nic removal
CLOUDSTACK-9154 - Adds test to cover nics state after GC
CLOUDSTACK-9154 - Returns the guest iterface that is marked as added
Signed-off-by: Remi Bergsma
> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo: mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> {
>
> [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
>
[jira] [Commented] (CLOUDSTACK-9187) rVPC routers in Master/Master due to concurrency problem when writing the keepalivd.conf
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103837#comment-15103837
]
ASF subversion and git services commented on CLOUDSTACK-9187:
-
Commit ff89587fd119b1cad543d8e96f0c428e41c35840 in cloudstack's branch
refs/heads/4.7 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff89587 ]
Merge pull request #1277 from ekholabs/fix/4.7-rvpc-net-gc-CLOUDSTACK-9154
[4.7] Critical VPCVR issues fixed: CLOUDSTACK-9154; CLOUDSTACK-9187; and
CLOUDSTACK-9188This PR applies the same fixes as in the PR #1259, but against
branch 4.7.
Please refer to PR #1259 for the tests results and all the comments already
made there.
Issues fixed are:
* CLOUDSTACK-9154: rVPC doesn't recover from cleaning up of network garbage
collector
* CLOUDSTACK-9187: rVPC routers in Master/Master due to concurrency problem
when writing the keepalivd.conf
* CLOUDSTACK-9188: NetworkGarbageCollector is not using gc.interval and gc.wait
from settings
Those changes have been covered by 2 new tests added to
```smoke/test_vpc_redundant.py```:
* test_04_rvpc_network_garbage_collector_nics
* test_05_rvpc_multi_tiers
The test ```test_04_rvpc_network_garbage_collector_nics``` depends on the
global settings for the network.gc.interval and gc.wait. If one wants the test
to run quicker, please change the settings (default is 600 seconds for each)
and restart the Management Server before running the tests. I would suggest to
set it to 60 seconds.
In addition, the NetworkGarbageCollector was redefining the settings above
mentioned and not reading their values through ConfigDao. Due to that, the
settings were not being applied properly and the test was waiting to long to
check the VPC routers.
* pr/1277:
CLOUDSTACK-9154 - Sets the pub interface down when all guest nets are gone
CLOUDSTACK-9187 - Makes code ready for more something like eth, if we
ever get that far
CLOUDSTACK-9188 - Reads network GC interval and wait from configDao
CLOUDSTACK-9187 - Fixes interface allocation to VRRP instances
CLOUDSTACK-9187 - Adds test to cover multiple nics and nic removal
CLOUDSTACK-9154 - Adds test to cover nics state after GC
CLOUDSTACK-9154 - Returns the guest iterface that is marked as added
Signed-off-by: Remi Bergsma
> rVPC routers in Master/Master due to concurrency problem when writing the
> keepalivd.conf
>
>
> Key: CLOUDSTACK-9187
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9187
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth3
> virtual_router_id 51
> ```
> and this is r-518-VM:
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth4
> virtual_router_id 51
> nopreempt
> ```
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9188) NetworkGarbageCollector is not using gc.interval and gc.wait from settings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103832#comment-15103832 ] ASF subversion and git services commented on CLOUDSTACK-9188: - Commit ff89587fd119b1cad543d8e96f0c428e41c35840 in cloudstack's branch refs/heads/4.7 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff89587 ] Merge pull request #1277 from ekholabs/fix/4.7-rvpc-net-gc-CLOUDSTACK-9154 [4.7] Critical VPCVR issues fixed: CLOUDSTACK-9154; CLOUDSTACK-9187; and CLOUDSTACK-9188This PR applies the same fixes as in the PR #1259, but against branch 4.7. Please refer to PR #1259 for the tests results and all the comments already made there. Issues fixed are: * CLOUDSTACK-9154: rVPC doesn't recover from cleaning up of network garbage collector * CLOUDSTACK-9187: rVPC routers in Master/Master due to concurrency problem when writing the keepalivd.conf * CLOUDSTACK-9188: NetworkGarbageCollector is not using gc.interval and gc.wait from settings Those changes have been covered by 2 new tests added to ```smoke/test_vpc_redundant.py```: * test_04_rvpc_network_garbage_collector_nics * test_05_rvpc_multi_tiers The test ```test_04_rvpc_network_garbage_collector_nics``` depends on the global settings for the network.gc.interval and gc.wait. If one wants the test to run quicker, please change the settings (default is 600 seconds for each) and restart the Management Server before running the tests. I would suggest to set it to 60 seconds. In addition, the NetworkGarbageCollector was redefining the settings above mentioned and not reading their values through ConfigDao. Due to that, the settings were not being applied properly and the test was waiting to long to check the VPC routers. * pr/1277: CLOUDSTACK-9154 - Sets the pub interface down when all guest nets are gone CLOUDSTACK-9187 - Makes code ready for more something like eth, if we ever get that far CLOUDSTACK-9188 - Reads network GC interval and wait from configDao CLOUDSTACK-9187 - Fixes interface allocation to VRRP instances CLOUDSTACK-9187 - Adds test to cover multiple nics and nic removal CLOUDSTACK-9154 - Adds test to cover nics state after GC CLOUDSTACK-9154 - Returns the guest iterface that is marked as added Signed-off-by: Remi Bergsma > NetworkGarbageCollector is not using gc.interval and gc.wait from settings > -- > > Key: CLOUDSTACK-9188 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9188 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.7.0 >Reporter: Wilder Rodrigues >Assignee: Wilder Rodrigues > Fix For: 4.7.1 > > > The settings are bing used from local object and not retrieving what has been > saved in the DB. > From lines to 3336: > public static final ConfigKey NetworkGcWait = new > ConfigKey(Integer.class, "network.gc.wait", "Advanced", "600", > "Time (in seconds) to wait before shutting down a network that's > not in used", false, Scope.Global, null); > public static final ConfigKey NetworkGcInterval = new > ConfigKey(Integer.class, "network.gc.interval", "Advanced", "600", > "Seconds to wait before checking for networks to shutdown", true, > Scope.Global, null); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103841#comment-15103841
]
ASF subversion and git services commented on CLOUDSTACK-9154:
-
Commit ff89587fd119b1cad543d8e96f0c428e41c35840 in cloudstack's branch
refs/heads/4.7 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff89587 ]
Merge pull request #1277 from ekholabs/fix/4.7-rvpc-net-gc-CLOUDSTACK-9154
[4.7] Critical VPCVR issues fixed: CLOUDSTACK-9154; CLOUDSTACK-9187; and
CLOUDSTACK-9188This PR applies the same fixes as in the PR #1259, but against
branch 4.7.
Please refer to PR #1259 for the tests results and all the comments already
made there.
Issues fixed are:
* CLOUDSTACK-9154: rVPC doesn't recover from cleaning up of network garbage
collector
* CLOUDSTACK-9187: rVPC routers in Master/Master due to concurrency problem
when writing the keepalivd.conf
* CLOUDSTACK-9188: NetworkGarbageCollector is not using gc.interval and gc.wait
from settings
Those changes have been covered by 2 new tests added to
```smoke/test_vpc_redundant.py```:
* test_04_rvpc_network_garbage_collector_nics
* test_05_rvpc_multi_tiers
The test ```test_04_rvpc_network_garbage_collector_nics``` depends on the
global settings for the network.gc.interval and gc.wait. If one wants the test
to run quicker, please change the settings (default is 600 seconds for each)
and restart the Management Server before running the tests. I would suggest to
set it to 60 seconds.
In addition, the NetworkGarbageCollector was redefining the settings above
mentioned and not reading their values through ConfigDao. Due to that, the
settings were not being applied properly and the test was waiting to long to
check the VPC routers.
* pr/1277:
CLOUDSTACK-9154 - Sets the pub interface down when all guest nets are gone
CLOUDSTACK-9187 - Makes code ready for more something like eth, if we
ever get that far
CLOUDSTACK-9188 - Reads network GC interval and wait from configDao
CLOUDSTACK-9187 - Fixes interface allocation to VRRP instances
CLOUDSTACK-9187 - Adds test to cover multiple nics and nic removal
CLOUDSTACK-9154 - Adds test to cover nics state after GC
CLOUDSTACK-9154 - Returns the guest iterface that is marked as added
Signed-off-by: Remi Bergsma
> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo: mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> {
>
> [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
>
[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103842#comment-15103842
]
ASF subversion and git services commented on CLOUDSTACK-9154:
-
Commit ff89587fd119b1cad543d8e96f0c428e41c35840 in cloudstack's branch
refs/heads/4.7 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff89587 ]
Merge pull request #1277 from ekholabs/fix/4.7-rvpc-net-gc-CLOUDSTACK-9154
[4.7] Critical VPCVR issues fixed: CLOUDSTACK-9154; CLOUDSTACK-9187; and
CLOUDSTACK-9188This PR applies the same fixes as in the PR #1259, but against
branch 4.7.
Please refer to PR #1259 for the tests results and all the comments already
made there.
Issues fixed are:
* CLOUDSTACK-9154: rVPC doesn't recover from cleaning up of network garbage
collector
* CLOUDSTACK-9187: rVPC routers in Master/Master due to concurrency problem
when writing the keepalivd.conf
* CLOUDSTACK-9188: NetworkGarbageCollector is not using gc.interval and gc.wait
from settings
Those changes have been covered by 2 new tests added to
```smoke/test_vpc_redundant.py```:
* test_04_rvpc_network_garbage_collector_nics
* test_05_rvpc_multi_tiers
The test ```test_04_rvpc_network_garbage_collector_nics``` depends on the
global settings for the network.gc.interval and gc.wait. If one wants the test
to run quicker, please change the settings (default is 600 seconds for each)
and restart the Management Server before running the tests. I would suggest to
set it to 60 seconds.
In addition, the NetworkGarbageCollector was redefining the settings above
mentioned and not reading their values through ConfigDao. Due to that, the
settings were not being applied properly and the test was waiting to long to
check the VPC routers.
* pr/1277:
CLOUDSTACK-9154 - Sets the pub interface down when all guest nets are gone
CLOUDSTACK-9187 - Makes code ready for more something like eth, if we
ever get that far
CLOUDSTACK-9188 - Reads network GC interval and wait from configDao
CLOUDSTACK-9187 - Fixes interface allocation to VRRP instances
CLOUDSTACK-9187 - Adds test to cover multiple nics and nic removal
CLOUDSTACK-9154 - Adds test to cover nics state after GC
CLOUDSTACK-9154 - Returns the guest iterface that is marked as added
Signed-off-by: Remi Bergsma
> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo: mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> {
>
> [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
>
[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103846#comment-15103846
]
ASF GitHub Bot commented on CLOUDSTACK-9154:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1277#issuecomment-172361223
PR is merged but not properly picked up by Github or so. Checked all
commits, they are in 4.7 just fine. @wilderrodrigues please close this PR,
thanks!
> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo: mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> {
>
> [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.2.146",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth1": [
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.24/24",
> "device": "eth1",
> "first_i_p": true,
> "gateway": "x.y.238.1",
> "netmask": "255.255.255.0",
> "network": "x.y.238.0/24",
> "new_nic": false,
> "nic_dev_id": 1,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "x.y.238.24",
> "size": "24",
> "source_nat": true,
> "vif_mac_address": "06:fc:da:00:00:1c"
> },
> {
> "add": true,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.51/24",
> "device": "eth1",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "1",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.51",
> "size": "24",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": false,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.173/24",
> "device": "eth2",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
>
[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103853#comment-15103853
]
ASF GitHub Bot commented on CLOUDSTACK-9154:
Github user wilderrodrigues closed the pull request at:
https://github.com/apache/cloudstack/pull/1277
> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo: mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> {
>
> [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.2.146",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth1": [
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.24/24",
> "device": "eth1",
> "first_i_p": true,
> "gateway": "x.y.238.1",
> "netmask": "255.255.255.0",
> "network": "x.y.238.0/24",
> "new_nic": false,
> "nic_dev_id": 1,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "x.y.238.24",
> "size": "24",
> "source_nat": true,
> "vif_mac_address": "06:fc:da:00:00:1c"
> },
> {
> "add": true,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.51/24",
> "device": "eth1",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "1",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.51",
> "size": "24",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": false,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.173/24",
> "device": "eth2",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.173",
> "size": "24",
> "source_nat": false
> },
> {
> "add": true,
[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103852#comment-15103852
]
ASF GitHub Bot commented on CLOUDSTACK-9154:
Github user wilderrodrigues commented on the pull request:
https://github.com/apache/cloudstack/pull/1277#issuecomment-172362547
This PR has already been merged by @remibergsma . For same weird reason it
remained open here and now says it has conflicts. Closing it.
Thanks, Remi!
> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo: mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> {
>
> [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.2.146",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth1": [
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.24/24",
> "device": "eth1",
> "first_i_p": true,
> "gateway": "x.y.238.1",
> "netmask": "255.255.255.0",
> "network": "x.y.238.0/24",
> "new_nic": false,
> "nic_dev_id": 1,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "x.y.238.24",
> "size": "24",
> "source_nat": true,
> "vif_mac_address": "06:fc:da:00:00:1c"
> },
> {
> "add": true,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.51/24",
> "device": "eth1",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "1",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.51",
> "size": "24",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": false,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.173/24",
> "device": "eth2",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
[jira] [Commented] (CLOUDSTACK-9230) Remove unnecessary return statement from cloudStack.js
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103887#comment-15103887 ] ASF GitHub Bot commented on CLOUDSTACK-9230: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1335#issuecomment-172369877 LGTM, makes sense. Checked syntax and that is also still OK. https://cloud.githubusercontent.com/assets/1630096/12379391/223bdafa-bd5a-11e5-9795-1252ed58adb8.png";> > Remove unnecessary return statement from cloudStack.js > -- > > Key: CLOUDSTACK-9230 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9230 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > The return statement is never reached. So removed the statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9230) Remove unnecessary return statement from cloudStack.js
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103895#comment-15103895 ] ASF GitHub Bot commented on CLOUDSTACK-9230: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1335 > Remove unnecessary return statement from cloudStack.js > -- > > Key: CLOUDSTACK-9230 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9230 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > The return statement is never reached. So removed the statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9230) Remove unnecessary return statement from cloudStack.js
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103893#comment-15103893 ] ASF subversion and git services commented on CLOUDSTACK-9230: - Commit 24277e1d8e6b0b4a7fc427d183b6fb136f0a1446 in cloudstack's branch refs/heads/4.7 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=24277e1 ] Merge pull request #1335 from nitin-maharana/CloudStack-Nitin18_4.7 CLOUDSTACK-9230: Remove unnecessary return statement from cloudStack.jsRemoved the unnecessary return statement. The statement is never reached. * pr/1335: CLOUDSTACK-9230: Remove unnecessary return statement from cloudStack.js Signed-off-by: Remi Bergsma > Remove unnecessary return statement from cloudStack.js > -- > > Key: CLOUDSTACK-9230 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9230 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > The return statement is never reached. So removed the statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9230) Remove unnecessary return statement from cloudStack.js
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103894#comment-15103894 ] ASF subversion and git services commented on CLOUDSTACK-9230: - Commit 24277e1d8e6b0b4a7fc427d183b6fb136f0a1446 in cloudstack's branch refs/heads/4.7 from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=24277e1 ] Merge pull request #1335 from nitin-maharana/CloudStack-Nitin18_4.7 CLOUDSTACK-9230: Remove unnecessary return statement from cloudStack.jsRemoved the unnecessary return statement. The statement is never reached. * pr/1335: CLOUDSTACK-9230: Remove unnecessary return statement from cloudStack.js Signed-off-by: Remi Bergsma > Remove unnecessary return statement from cloudStack.js > -- > > Key: CLOUDSTACK-9230 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9230 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > The return statement is never reached. So removed the statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9230) Remove unnecessary return statement from cloudStack.js
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103892#comment-15103892 ] ASF subversion and git services commented on CLOUDSTACK-9230: - Commit 1c01b4ed8c9584ad35d07ccff0bfaf64f77b9da0 in cloudstack's branch refs/heads/4.7 from [~nitin.maharana] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1c01b4e ] CLOUDSTACK-9230: Remove unnecessary return statement from cloudStack.js Removed the unnecessary return statement. The statement is never reached. > Remove unnecessary return statement from cloudStack.js > -- > > Key: CLOUDSTACK-9230 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9230 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > The return statement is never reached. So removed the statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9132) API createVolume takes empty string for name parameter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103904#comment-15103904 ] ASF GitHub Bot commented on CLOUDSTACK-9132: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1319#issuecomment-172376749 @nitin-maharana We can merge this once the integration tests have run. Will put it on my list. > API createVolume takes empty string for name parameter > -- > > Key: CLOUDSTACK-9132 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9132 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Nitin Kumar Maharana > > Steps to Reproduce: > > Create a volume using createVolume API where parameter name is empty. > It creates a volume with empty name. > But the name parameter is mandatory.(Issue) > Expected Behaviour: > > It shouldn't create a volume with an empty name. Error should be returned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9132) API createVolume takes empty string for name parameter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103905#comment-15103905 ] ASF GitHub Bot commented on CLOUDSTACK-9132: Github user nitin-maharana commented on the pull request: https://github.com/apache/cloudstack/pull/1319#issuecomment-172376856 Sure @remi > API createVolume takes empty string for name parameter > -- > > Key: CLOUDSTACK-9132 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9132 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Nitin Kumar Maharana > > Steps to Reproduce: > > Create a volume using createVolume API where parameter name is empty. > It creates a volume with empty name. > But the name parameter is mandatory.(Issue) > Expected Behaviour: > > It shouldn't create a volume with an empty name. Error should be returned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9149) Remove unused folder(s)/file(s); cloud-cli
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103924#comment-15103924 ] ASF subversion and git services commented on CLOUDSTACK-9149: - Commit fa41bc769c442287076d28a667a2f3967bae4ed1 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fa41bc7 ] Revert "Merge pull request #1228 from borisroman/CLOUDSTACK-9149" This reverts commit c459dfe62c57c72ced99ddb0c7d8a9547a380305, reversing changes made to 2afb739f0656d14e5c298bf469f797fff6da221b. > Remove unused folder(s)/file(s); cloud-cli > -- > > Key: CLOUDSTACK-9149 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9149 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Boris Schrijver >Assignee: Boris Schrijver > > In the folder an old cloudstack cli tool resides. We currently have > cloudmonkey. As this is not maintained, it should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9160) Remove unused folder(s)/file(s); engine/api/src/org/apache/engine/subsystem/api/storage/disktype
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103927#comment-15103927 ] ASF GitHub Bot commented on CLOUDSTACK-9160: Github user rodrigo93 commented on the pull request: https://github.com/apache/cloudstack/pull/1238#issuecomment-172384379 LGTM based on the files, no tests were made. What is happening with Jenkins? I noticed that many PRs are flagged with error because Jenkins did not work. I saw in an email before that communication seems poor. > Remove unused folder(s)/file(s); > engine/api/src/org/apache/engine/subsystem/api/storage/disktype > > > Key: CLOUDSTACK-9160 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9160 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Boris Schrijver >Assignee: Boris Schrijver > > Empty files. Move DiskFormat.java to > engine/api/src/org/apache/engine/subsystem/api/storage/type -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8939) VM Snapshot size with memory is not correctly calculated in cloud.usage_event (XenServer)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103953#comment-15103953 ] ASF GitHub Bot commented on CLOUDSTACK-8939: Github user rodrigo93 commented on the pull request: https://github.com/apache/cloudstack/pull/914#issuecomment-172391340 @remibergsma The author seems to be inactive in github. His last public activity was on Oct 20, 2015... > VM Snapshot size with memory is not correctly calculated in cloud.usage_event > (XenServer) > - > > Key: CLOUDSTACK-8939 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8939 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > 1. created a VM snapshot with memory on a VM with 512 MB RAM > list all the VBDs for the VM > xe vbd-list vm-name-label=i-2-43-VM empty=false params=vdi-uuid > vdi-uuid ( RO): fbe638dd-02c5-42f5-96b2-7b3d73e68658 > Verify the size of the snapshot disk and its parent (I understand from the > code we only check one parent in the chain) > # xe vdi-list params=physical-utilisation,sm-config,is-a-snapshot > uuid=fbe638dd-02c5-42f5-96b2-7b3d73e68658 > is-a-snapshot ( RO) : false > physical-utilisation ( RO): 38124032 <- >sm-config (MRO): > host_OpaqueRef:52c1ec01-cef6-d4fd-7d81-68795a853ee0: RW; vhd-parent: > 993e3859-8be9-414c-819b-61095ab2eff1 > parent: > # xe vdi-list params=physical-utilisation,sm-config,is-a-snapshot > uuid=993e3859-8be9-414c-819b-61095ab2eff1 > is-a-snapshot ( RO) : false > physical-utilisation ( RO): 119816704 <- >sm-config (MRO): vhd-blocks: > eJxrYAAB0QcMWAELduFBDwSgNAsaHxcQARGMNHMOQfsJARFGRgkGRkWgOxmxGiWCwz5c9qLLU+o+YoGooIBUp6CgIJ2sIxnQKxzoZQ8M0Dof09s/1AMALcYD3A==; > vhd-parent: 4b7ee66c-de53-47bb-b3d5-306d40a0ea08 > At this stage, not counting the "suspend VDI", the size looks as follows: > 38124032 + 119816704 = 157940736 = 150.6 MB > Now, let's calulate the "suspend VDI" size and add it to the above value: > Note my test VM has 512 MB of RAM > # xe vdi-list name-label=Suspend\ image params=all > uuid ( RO): e2ae7a47-c410-479b-9e2b-5f05c01f1b4f > name-label ( RW): Suspend image > name-description ( RW): Suspend image >is-a-snapshot ( RO): true > physical-utilisation ( RO): 6144 > <--- >sm-config (MRO): vhd-parent: > c286583b-dd47-4a21-a5fe-ba2f671f1163 > Looking at the parent > # xe vdi-list uuid=c286583b-dd47-4a21-a5fe-ba2f671f1163 params=all > uuid ( RO): c286583b-dd47-4a21-a5fe-ba2f671f1163 > name-label ( RW): base copy >is-a-snapshot ( RO): false > virtual-size ( RO): 782237696 > physical-utilisation ( RO): 252154368 > <--- >sm-config (MRO): vhd-blocks: eJz7/x8ZNDA0MEDAASiNyucAAHMeEPs= > > So the "suspend VDI" + its parent has "physical utilisation" of 6144 + > 252154368 = 252160512 = 17.55 MB > Now, if we add it to the previously calculated disk sizes, we'll get: > xapi (phys util): 157940736 (non-memory snap disks)+ 252160512 (memory snap > disks) = 410101248 = 391.1 MB > Let's verify the size in cloud.usage_event now: > select * from cloud.usage_event where resource_name like "i-2-43-VM%" \G > > >id: 528 > > > type: VMSNAPSHOT.CREATE > > >account_id: 2 > > > created: 2015-04-14 11:48:56 > zone_id: 1 > resource_id: 43 > resource_name: i-2-43-VM_VS_20150414114830 > offering_id: NULL > template_id: 64 > size: 119863296 <- > resource_type: NULL > processed: 0 > virtual_size: NULL > 1 row in set (0.01 sec) > Overall, the snapshot size in cloud.usage_event != size calculated from xapi > objects based on the code > xapi (phys util): 157940736 (non-memory snap disks)+ 252160512 (memory snap > disks) = 410101248 = 391.1 MB > but: > usage_even
[jira] [Commented] (CLOUDSTACK-8849) Usage job should stop usage generation in case of any exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103967#comment-15103967 ] ASF GitHub Bot commented on CLOUDSTACK-8849: Github user rodrigo93 commented on the pull request: https://github.com/apache/cloudstack/pull/827#issuecomment-172394161 Hi @yvsubhash, could you make a Jira? Sorry to ask you, but, why did you remove the tries and catches? It should throw exceptions if that part of the code can be executed, should it not? How did you test it? > Usage job should stop usage generation in case of any exception > --- > > Key: CLOUDSTACK-8849 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8849 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > usage server should stop completely after getting an exception. When it > continues it can result in wrong usage data -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9195) Cancelled/failed async jobs not getting cleaned up from DB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15104156#comment-15104156 ] ASF GitHub Bot commented on CLOUDSTACK-9195: Github user koushik-das commented on the pull request: https://github.com/apache/cloudstack/pull/1272#issuecomment-172421544 @DaanHoogland Thanks for reviewing the code. On MS shutdown/restart the incomplete job entry will always get marked as cancelled in DB. You are right that an async job might continue to run even after MS shutdown. For e.g. MS is stopped in middle of deploy VM operation. If the command to deploy VM has reached HV before MS stop, then it will get started. The DB will be synced to correct state based on vm sync once the MS is started again. For volume and other operations (snapshot etc.), there is no recovery in these scenarios. Something like storage sync needs to be implemented which can update DB state based on the actual content/state of primary and secondary storages. > Cancelled/failed async jobs not getting cleaned up from DB > -- > > Key: CLOUDSTACK-9195 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9195 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0, 4.7.0 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.8.0 > > > Some cancelled/failed async jobs are not getting cleaned up from DB even > after "job.expire.minutes". These jobs are marked as cancelled/failed when MS > is restarted, check for 'job_status' as 2 (FAILED) and 'job_result' as "job > cancelled because of management server restart or shutdown" in async_job > table in DB. These are not getting cleaned as 'job_complete_msid' field is > not set in DB. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9231) Root volume migration from one primary to another primary storage within the same cluster is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15104884#comment-15104884 ] ASF GitHub Bot commented on CLOUDSTACK-9231: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1336#issuecomment-172449988 [1336.vpc.results.txt](https://github.com/apache/cloudstack/files/93940/1336.vpc.results.txt) [1336.network.results.txt](https://github.com/apache/cloudstack/files/93941/1336.network.results.txt) haven't tested the fix itself yet > Root volume migration from one primary to another primary storage within the > same cluster is failing > > > Key: CLOUDSTACK-9231 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9231 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > EXPECTED BEHAVIOR > === > Root Volume migration within cluster should work. > ACTUAL BEHAVIOR > > Root volume migration within cluster failed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
