[jira] [Commented] (CLOUDSTACK-9738) Optimize vm expunge process for instances with vm snapshots
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829137#comment-15829137 ] rashmidixit commented on CLOUDSTACK-9738: - Github user nvazquez commented on the issue: https://github.com/apache/cloudstack/pull/1905 @ozhanrk nice, then this PR shouldn't affect your workflow --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > Optimize vm expunge process for instances with vm snapshots > --- > > Key: CLOUDSTACK-9738 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9738 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > Fix For: 4.10.0.0 > > > h2. Description > It was noticed that expunging instances with many vm snapshots took a look of > time, as hypervisor received as many tasks as vm snapshots instance had, > apart from the delete vm task. We propose a way to optimize this process for > instances with vm snapshots by sending only one delete task to hypervisor, > which will delete vm and its snapshots > h2. Use cases > # deleteVMsnapohsot-> no changes to current behavior > # destroyVM with expunge=false -> no actions to VMsnaphsot is performed at > the moment. When VM cleanup thread is executed it will perform the same > sequence as #3. If instance is recovered before expunged by the cleanup > thread it will remain intact with VMSnapshot chain present > # destroyVM with expunge=true: > #* Vmsnaphsot is marked with removed timestamp and state = Expunging > in DB > #* VM is deleted in HW -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9738) Optimize vm expunge process for instances with vm snapshots
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829135#comment-15829135 ] ASF GitHub Bot commented on CLOUDSTACK-9738: Github user nvazquez commented on the issue: https://github.com/apache/cloudstack/pull/1905 @ozhanrk nice, then this PR shouldn't affect your workflow > Optimize vm expunge process for instances with vm snapshots > --- > > Key: CLOUDSTACK-9738 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9738 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > Fix For: 4.10.0.0 > > > h2. Description > It was noticed that expunging instances with many vm snapshots took a look of > time, as hypervisor received as many tasks as vm snapshots instance had, > apart from the delete vm task. We propose a way to optimize this process for > instances with vm snapshots by sending only one delete task to hypervisor, > which will delete vm and its snapshots > h2. Use cases > # deleteVMsnapohsot-> no changes to current behavior > # destroyVM with expunge=false -> no actions to VMsnaphsot is performed at > the moment. When VM cleanup thread is executed it will perform the same > sequence as #3. If instance is recovered before expunged by the cleanup > thread it will remain intact with VMSnapshot chain present > # destroyVM with expunge=true: > #* Vmsnaphsot is marked with removed timestamp and state = Expunging > in DB > #* VM is deleted in HW -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9738) Optimize vm expunge process for instances with vm snapshots
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828817#comment-15828817 ] rashmidixit commented on CLOUDSTACK-9738: - Github user ozhanrk commented on the issue: https://github.com/apache/cloudstack/pull/1905 Hi @nvazquez; You are right i am referring to volume based snapshots. Thanks --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > Optimize vm expunge process for instances with vm snapshots > --- > > Key: CLOUDSTACK-9738 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9738 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > Fix For: 4.10.0.0 > > > h2. Description > It was noticed that expunging instances with many vm snapshots took a look of > time, as hypervisor received as many tasks as vm snapshots instance had, > apart from the delete vm task. We propose a way to optimize this process for > instances with vm snapshots by sending only one delete task to hypervisor, > which will delete vm and its snapshots > h2. Use cases > # deleteVMsnapohsot-> no changes to current behavior > # destroyVM with expunge=false -> no actions to VMsnaphsot is performed at > the moment. When VM cleanup thread is executed it will perform the same > sequence as #3. If instance is recovered before expunged by the cleanup > thread it will remain intact with VMSnapshot chain present > # destroyVM with expunge=true: > #* Vmsnaphsot is marked with removed timestamp and state = Expunging > in DB > #* VM is deleted in HW -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9738) Optimize vm expunge process for instances with vm snapshots
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828816#comment-15828816 ] ASF GitHub Bot commented on CLOUDSTACK-9738: Github user ozhanrk commented on the issue: https://github.com/apache/cloudstack/pull/1905 Hi @nvazquez; You are right i am referring to volume based snapshots. Thanks > Optimize vm expunge process for instances with vm snapshots > --- > > Key: CLOUDSTACK-9738 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9738 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > Fix For: 4.10.0.0 > > > h2. Description > It was noticed that expunging instances with many vm snapshots took a look of > time, as hypervisor received as many tasks as vm snapshots instance had, > apart from the delete vm task. We propose a way to optimize this process for > instances with vm snapshots by sending only one delete task to hypervisor, > which will delete vm and its snapshots > h2. Use cases > # deleteVMsnapohsot-> no changes to current behavior > # destroyVM with expunge=false -> no actions to VMsnaphsot is performed at > the moment. When VM cleanup thread is executed it will perform the same > sequence as #3. If instance is recovered before expunged by the cleanup > thread it will remain intact with VMSnapshot chain present > # destroyVM with expunge=true: > #* Vmsnaphsot is marked with removed timestamp and state = Expunging > in DB > #* VM is deleted in HW -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828795#comment-15828795
]
rashmidixit commented on CLOUDSTACK-9500:
-
Github user vilisseranen closed the pull request at:
https://github.com/apache/cloudstack/pull/1706
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove
> configuration of the public IP on the VR configs
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on
> the old VR is not pignable but the switches arp table get updated every time
> the previous VR have configuration changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828794#comment-15828794
]
rashmidixit commented on CLOUDSTACK-9500:
-
Github user vilisseranen commented on the issue:
https://github.com/apache/cloudstack/pull/1706
This PR was not working as expected. See PR from @remibergsma for a proper
fix.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove
> configuration of the public IP on the VR configs
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on
> the old VR is not pignable but the switches arp table get updated every time
> the previous VR have configuration changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828790#comment-15828790
]
ASF GitHub Bot commented on CLOUDSTACK-9500:
Github user vilisseranen commented on the issue:
https://github.com/apache/cloudstack/pull/1706
This PR was not working as expected. See PR from @remibergsma for a proper
fix.
> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove
> configuration of the public IP on the VR configs
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on
> the old VR is not pignable but the switches arp table get updated every time
> the previous VR have configuration changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828792#comment-15828792
]
ASF GitHub Bot commented on CLOUDSTACK-9500:
Github user vilisseranen closed the pull request at:
https://github.com/apache/cloudstack/pull/1706
> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove
> configuration of the public IP on the VR configs
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on
> the old VR is not pignable but the switches arp table get updated every time
> the previous VR have configuration changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9710) Switch to JDK 1.8
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828712#comment-15828712 ] ASF GitHub Bot commented on CLOUDSTACK-9710: Github user swill commented on the issue: https://github.com/apache/cloudstack/pull/1888 Wow, these builds are getting complicated now. I will see if I can get Java8 installed on my CentOS6 Jenkins slaves so I can get my existing build pipelines working again. Thanks... > Switch to JDK 1.8 > - > > Key: CLOUDSTACK-9710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future, 4.10.0.0 > > > Switch to using JDK1.8 by default for building and running CloudStack. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9710) Switch to JDK 1.8
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828713#comment-15828713 ] rashmidixit commented on CLOUDSTACK-9710: - Github user swill commented on the issue: https://github.com/apache/cloudstack/pull/1888 Wow, these builds are getting complicated now. I will see if I can get Java8 installed on my CentOS6 Jenkins slaves so I can get my existing build pipelines working again. Thanks... --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > Switch to JDK 1.8 > - > > Key: CLOUDSTACK-9710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future, 4.10.0.0 > > > Switch to using JDK1.8 by default for building and running CloudStack. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9710) Switch to JDK 1.8
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828705#comment-15828705 ] ASF GitHub Bot commented on CLOUDSTACK-9710: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1888 @swill build el7 (centos7) packages on centos7, and el6 (centos6) packages on centos6. You may use my docker images, this is what Trillian/blueorangutan uses for building (PR) packages: https://hub.docker.com/u/bhaisaab/ > Switch to JDK 1.8 > - > > Key: CLOUDSTACK-9710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future, 4.10.0.0 > > > Switch to using JDK1.8 by default for building and running CloudStack. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9710) Switch to JDK 1.8
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828706#comment-15828706 ] rashmidixit commented on CLOUDSTACK-9710: - Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1888 @swill build el7 (centos7) packages on centos7, and el6 (centos6) packages on centos6. You may use my docker images, this is what Trillian/blueorangutan uses for building (PR) packages: https://hub.docker.com/u/bhaisaab/ --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > Switch to JDK 1.8 > - > > Key: CLOUDSTACK-9710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future, 4.10.0.0 > > > Switch to using JDK1.8 by default for building and running CloudStack. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9710) Switch to JDK 1.8
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828699#comment-15828699 ] rashmidixit commented on CLOUDSTACK-9710: - Github user swill commented on the issue: https://github.com/apache/cloudstack/pull/1888 Any suggestions to resolve this? I have built from master using JDK8 and have setup my `cloudstack.repo` to point to my build. I have been doing this successfully for the past month. My management server is on CentOS6.8. When I run: `sudo yum -y install cloudstack-management cloudstack-usage` It fails with: ``` Error: Package: cloudstack-management-4.10.0.0-SNAPSHOT.el7.centos.x86_64 (cloudstack) Requires: iptables-services Error: Package: cloudstack-common-4.10.0.0-SNAPSHOT.el7.centos.x86_64 (cloudstack) Requires: python(abi) = 2.7 Installed: python-2.6.6-66.el6_8.x86_64 (@updates) python(abi) = 2.6 Available: python-2.6.6-64.el6.x86_64 (base) python(abi) = 2.6 Available: python34-3.4.5-1.el6.i686 (epel) python(abi) = 3.4 ``` --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > Switch to JDK 1.8 > - > > Key: CLOUDSTACK-9710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future, 4.10.0.0 > > > Switch to using JDK1.8 by default for building and running CloudStack. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9710) Switch to JDK 1.8
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828698#comment-15828698 ] ASF GitHub Bot commented on CLOUDSTACK-9710: Github user swill commented on the issue: https://github.com/apache/cloudstack/pull/1888 Any suggestions to resolve this? I have built from master using JDK8 and have setup my `cloudstack.repo` to point to my build. I have been doing this successfully for the past month. My management server is on CentOS6.8. When I run: `sudo yum -y install cloudstack-management cloudstack-usage` It fails with: ``` Error: Package: cloudstack-management-4.10.0.0-SNAPSHOT.el7.centos.x86_64 (cloudstack) Requires: iptables-services Error: Package: cloudstack-common-4.10.0.0-SNAPSHOT.el7.centos.x86_64 (cloudstack) Requires: python(abi) = 2.7 Installed: python-2.6.6-66.el6_8.x86_64 (@updates) python(abi) = 2.6 Available: python-2.6.6-64.el6.x86_64 (base) python(abi) = 2.6 Available: python34-3.4.5-1.el6.i686 (epel) python(abi) = 3.4 ``` > Switch to JDK 1.8 > - > > Key: CLOUDSTACK-9710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future, 4.10.0.0 > > > Switch to using JDK1.8 by default for building and running CloudStack. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9738) Optimize vm expunge process for instances with vm snapshots
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828455#comment-15828455 ] rashmidixit commented on CLOUDSTACK-9738: - Github user nvazquez commented on the issue: https://github.com/apache/cloudstack/pull/1905 Hi @ozhanrk, In this PR, vm snapshots get deleted when the instance gets deleted from hypervisor, on task sent by the vm cleanup thread. Can it be possible that you were referring to volume snapshots instead of vm snapshots for restoring vms? Thanks --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > Optimize vm expunge process for instances with vm snapshots > --- > > Key: CLOUDSTACK-9738 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9738 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > Fix For: 4.10.0.0 > > > h2. Description > It was noticed that expunging instances with many vm snapshots took a look of > time, as hypervisor received as many tasks as vm snapshots instance had, > apart from the delete vm task. We propose a way to optimize this process for > instances with vm snapshots by sending only one delete task to hypervisor, > which will delete vm and its snapshots > h2. Use cases > # deleteVMsnapohsot-> no changes to current behavior > # destroyVM with expunge=false -> no actions to VMsnaphsot is performed at > the moment. When VM cleanup thread is executed it will perform the same > sequence as #3. If instance is recovered before expunged by the cleanup > thread it will remain intact with VMSnapshot chain present > # destroyVM with expunge=true: > #* Vmsnaphsot is marked with removed timestamp and state = Expunging > in DB > #* VM is deleted in HW -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9738) Optimize vm expunge process for instances with vm snapshots
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828453#comment-15828453 ] ASF GitHub Bot commented on CLOUDSTACK-9738: Github user nvazquez commented on the issue: https://github.com/apache/cloudstack/pull/1905 Hi @ozhanrk, In this PR, vm snapshots get deleted when the instance gets deleted from hypervisor, on task sent by the vm cleanup thread. Can it be possible that you were referring to volume snapshots instead of vm snapshots for restoring vms? Thanks > Optimize vm expunge process for instances with vm snapshots > --- > > Key: CLOUDSTACK-9738 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9738 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > Fix For: 4.10.0.0 > > > h2. Description > It was noticed that expunging instances with many vm snapshots took a look of > time, as hypervisor received as many tasks as vm snapshots instance had, > apart from the delete vm task. We propose a way to optimize this process for > instances with vm snapshots by sending only one delete task to hypervisor, > which will delete vm and its snapshots > h2. Use cases > # deleteVMsnapohsot-> no changes to current behavior > # destroyVM with expunge=false -> no actions to VMsnaphsot is performed at > the moment. When VM cleanup thread is executed it will perform the same > sequence as #3. If instance is recovered before expunged by the cleanup > thread it will remain intact with VMSnapshot chain present > # destroyVM with expunge=true: > #* Vmsnaphsot is marked with removed timestamp and state = Expunging > in DB > #* VM is deleted in HW -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9710) Switch to JDK 1.8
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828391#comment-15828391 ] rashmidixit commented on CLOUDSTACK-9710: - Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1888 @syed yes, if the systemvmtemplates were built from master after this PR was merged. There is no secret sauce in the systemvmtemplate that I've uploaded on packages.shapeblue.com S3 bucket. Checkout the readme file at tools/appliance, that's more updated than any wiki page. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > Switch to JDK 1.8 > - > > Key: CLOUDSTACK-9710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future, 4.10.0.0 > > > Switch to using JDK1.8 by default for building and running CloudStack. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9710) Switch to JDK 1.8
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828390#comment-15828390 ] ASF GitHub Bot commented on CLOUDSTACK-9710: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1888 @syed yes, if the systemvmtemplates were built from master after this PR was merged. There is no secret sauce in the systemvmtemplate that I've uploaded on packages.shapeblue.com S3 bucket. Checkout the readme file at tools/appliance, that's more updated than any wiki page. > Switch to JDK 1.8 > - > > Key: CLOUDSTACK-9710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future, 4.10.0.0 > > > Switch to using JDK1.8 by default for building and running CloudStack. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828355#comment-15828355
]
rashmidixit commented on CLOUDSTACK-9539:
-
Github user nvazquez commented on the issue:
https://github.com/apache/cloudstack/pull/1727
@serg38 done, I reverted DB changes to `schema-490to4910.sql`, thanks!
@koushik-das thanks for reviewing! I refactored PR according to your review
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
> Support changing Service offering for instance with VM Snapshots
>
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which
> have vm snapshots. In that case, previously taken snapshots (if reverted)
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way
> snapshot can be reverted to original state even though service offering can
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}}
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828354#comment-15828354
]
ASF GitHub Bot commented on CLOUDSTACK-9539:
Github user nvazquez commented on the issue:
https://github.com/apache/cloudstack/pull/1727
@serg38 done, I reverted DB changes to `schema-490to4910.sql`, thanks!
@koushik-das thanks for reviewing! I refactored PR according to your review
> Support changing Service offering for instance with VM Snapshots
>
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which
> have vm snapshots. In that case, previously taken snapshots (if reverted)
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way
> snapshot can be reverted to original state even though service offering can
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}}
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828341#comment-15828341
]
rashmidixit commented on CLOUDSTACK-9539:
-
Github user nvazquez commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1727#discussion_r96670694
--- Diff: server/src/com/cloud/vm/snapshot/VMSnapshotManagerImpl.java ---
@@ -707,16 +802,41 @@ private UserVm orchestrateRevertToVMSnapshot(Long
vmSnapshotId) throws Insuffici
throw new InvalidParameterValueException("There is other
active vm snapshot tasks on the instance, please try again later");
}
+revertUserVmDetailsFromVmSnapshot(userVm, vmSnapshotVo);
+
try {
VMSnapshotStrategy strategy =
findVMSnapshotStrategy(vmSnapshotVo);
strategy.revertVMSnapshot(vmSnapshotVo);
+updateUserVmServiceOffering(userVm, vmSnapshotVo);
--- End diff --
@koushik-das Done, thanks for your review!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
> Support changing Service offering for instance with VM Snapshots
>
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which
> have vm snapshots. In that case, previously taken snapshots (if reverted)
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way
> snapshot can be reverted to original state even though service offering can
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}}
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828338#comment-15828338
]
ASF GitHub Bot commented on CLOUDSTACK-9539:
Github user nvazquez commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1727#discussion_r96670694
--- Diff: server/src/com/cloud/vm/snapshot/VMSnapshotManagerImpl.java ---
@@ -707,16 +802,41 @@ private UserVm orchestrateRevertToVMSnapshot(Long
vmSnapshotId) throws Insuffici
throw new InvalidParameterValueException("There is other
active vm snapshot tasks on the instance, please try again later");
}
+revertUserVmDetailsFromVmSnapshot(userVm, vmSnapshotVo);
+
try {
VMSnapshotStrategy strategy =
findVMSnapshotStrategy(vmSnapshotVo);
strategy.revertVMSnapshot(vmSnapshotVo);
+updateUserVmServiceOffering(userVm, vmSnapshotVo);
--- End diff --
@koushik-das Done, thanks for your review!
> Support changing Service offering for instance with VM Snapshots
>
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which
> have vm snapshots. In that case, previously taken snapshots (if reverted)
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way
> snapshot can be reverted to original state even though service offering can
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}}
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9710) Switch to JDK 1.8
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828211#comment-15828211 ] ASF GitHub Bot commented on CLOUDSTACK-9710: Github user syed commented on the issue: https://github.com/apache/cloudstack/pull/1888 I got the master working now with the systemvm template http://packages.shapeblue.com.s3-eu-west-1.amazonaws.com/systemvmtemplate/4.10/systemvm64template-4.10-xen.vhd.bz2 @rhtyd would the systemvm template from http://jenkins.buildacloud.org/ also work? Also, we need to update the wiki https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+CloudStack with the newer URLs. I would prefer it be jenkins.buildacloud.org. > Switch to JDK 1.8 > - > > Key: CLOUDSTACK-9710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future, 4.10.0.0 > > > Switch to using JDK1.8 by default for building and running CloudStack. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9710) Switch to JDK 1.8
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828213#comment-15828213 ] rashmidixit commented on CLOUDSTACK-9710: - Github user syed commented on the issue: https://github.com/apache/cloudstack/pull/1888 I got the master working now with the systemvm template http://packages.shapeblue.com.s3-eu-west-1.amazonaws.com/systemvmtemplate/4.10/systemvm64template-4.10-xen.vhd.bz2 @rhtyd would the systemvm template from http://jenkins.buildacloud.org/ also work? Also, we need to update the wiki https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+CloudStack with the newer URLs. I would prefer it be jenkins.buildacloud.org. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > Switch to JDK 1.8 > - > > Key: CLOUDSTACK-9710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future, 4.10.0.0 > > > Switch to using JDK1.8 by default for building and running CloudStack. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9749) cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by password server on lb VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Maximus updated CLOUDSTACK-9749: -- Affects Version/s: 4.8.2.0 4.9.2.0 > cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by > password server on lb VM > -- > > Key: CLOUDSTACK-9749 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9749 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0, 4.9.2.0, 4.8.2.0 >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Critical > Fix For: 4.10.0.0 > > Attachments: runinfo.txt > > > cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by > password server on lb VM > Executed test/integration/plugins/nuagevsp/test_nuage_vpc_internal_lb.py > which failed in test_05_nuage_internallb_traffic at the point where it is > checking the lb via wget of file using port 8080. > As port 8080 already is occupied by the password_server, it fails. > I have added the runinfo.txt of the failing test to this bugticket. > Similar issue was reported internally via CLOUD-972. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-9749) cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by password server on lb VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828000#comment-15828000 ] Frank Maximus edited comment on CLOUDSTACK-9749 at 1/18/17 1:06 PM: Caused by commit [57d3ffaef893e00bf751fa0a516fb210bf4b478c|https://github.com/apache/cloudstack/commit/57d3ffaef893e00bf751fa0a516fb210bf4b478c] which maked password service enabled all the time. Proposed solution: * remove ENABLED=1 again * add `enable_svc cloud-passwd-srvr 1` to setup_vpcrouter() in cloud-early-config was (Author: fmaximus): Caused by commit 57d3ffaef893e00bf751fa0a516fb210bf4b478c which maked password service enabled all the time. Proposed solution: * remove ENABLED=1 again * add `enable_svc cloud-passwd-srvr 1` to setup_vpcrouter() in cloud-early-config > cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by > password server on lb VM > -- > > Key: CLOUDSTACK-9749 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9749 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Critical > Fix For: 4.10.0.0 > > Attachments: runinfo.txt > > > cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by > password server on lb VM > Executed test/integration/plugins/nuagevsp/test_nuage_vpc_internal_lb.py > which failed in test_05_nuage_internallb_traffic at the point where it is > checking the lb via wget of file using port 8080. > As port 8080 already is occupied by the password_server, it fails. > I have added the runinfo.txt of the failing test to this bugticket. > Similar issue was reported internally via CLOUD-972. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9749) cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by password server on lb VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828000#comment-15828000 ] Frank Maximus commented on CLOUDSTACK-9749: --- Caused by commit 57d3ffaef893e00bf751fa0a516fb210bf4b478c which maked password service enabled all the time. Proposed solution: * remove ENABLED=1 again * add `enable_svc cloud-passwd-srvr 1` to setup_vpcrouter() in cloud-early-config > cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by > password server on lb VM > -- > > Key: CLOUDSTACK-9749 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9749 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Critical > Fix For: 4.10.0.0 > > Attachments: runinfo.txt > > > cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by > password server on lb VM > Executed test/integration/plugins/nuagevsp/test_nuage_vpc_internal_lb.py > which failed in test_05_nuage_internallb_traffic at the point where it is > checking the lb via wget of file using port 8080. > As port 8080 already is occupied by the password_server, it fails. > I have added the runinfo.txt of the failing test to this bugticket. > Similar issue was reported internally via CLOUD-972. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-9749) cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by password server on lb VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Maximus reassigned CLOUDSTACK-9749: - Assignee: Frank Maximus > cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by > password server on lb VM > -- > > Key: CLOUDSTACK-9749 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9749 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Critical > Fix For: 4.10.0.0 > > Attachments: runinfo.txt > > > cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by > password server on lb VM > Executed test/integration/plugins/nuagevsp/test_nuage_vpc_internal_lb.py > which failed in test_05_nuage_internallb_traffic at the point where it is > checking the lb via wget of file using port 8080. > As port 8080 already is occupied by the password_server, it fails. > I have added the runinfo.txt of the failing test to this bugticket. > Similar issue was reported internally via CLOUD-972. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9749) cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by password server on lb VM
Raf Smeets created CLOUDSTACK-9749: -- Summary: cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by password server on lb VM Key: CLOUDSTACK-9749 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9749 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.10.0.0 Reporter: Raf Smeets Priority: Critical Fix For: 4.10.0.0 Attachments: runinfo.txt cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by password server on lb VM Executed test/integration/plugins/nuagevsp/test_nuage_vpc_internal_lb.py which failed in test_05_nuage_internallb_traffic at the point where it is checking the lb via wget of file using port 8080. As port 8080 already is occupied by the password_server, it fails. I have added the runinfo.txt of the failing test to this bugticket. Similar issue was reported internally via CLOUD-972. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15827758#comment-15827758
]
rashmidixit commented on CLOUDSTACK-9317:
-
Github user yvsubhash commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1908#discussion_r96598944
--- Diff: server/src/com/cloud/network/router/CommandSetupHelper.java ---
@@ -823,13 +826,39 @@ public int compare(final PublicIpAddress o1, final
PublicIpAddress o2) {
associatedWithNetworkId = ipAddrList.get(0).getNetworkId();
}
+// for network if the ips does not have any rules, then only
last ip
+List userIps =
_ipAddressDao.listByAssociatedNetwork(associatedWithNetworkId, null);
+
+int ipsWithrules = 0;
+int ipsStaticNat = 0;
+for (IPAddressVO ip : userIps) {
+if ( _firewallsDao.countRulesByIpIdAndState(ip.getId(),
FirewallRule.State.Active) > 0 ) {
+ipsWithrules++;
+}
+
+if (ip.isOneToOneNat()) {
+ipsStaticNat++;
+}
+}
+
final IpAssocCommand cmd = new IpAssocCommand(ipsToSend);
cmd.setAccessDetail(NetworkElementCommand.ROUTER_IP,
_routerControlHelper.getRouterControlIp(router.getId()));
cmd.setAccessDetail(NetworkElementCommand.ROUTER_GUEST_IP,
_routerControlHelper.getRouterIpInNetwork(associatedWithNetworkId,
router.getId()));
cmd.setAccessDetail(NetworkElementCommand.ROUTER_NAME,
router.getInstanceName());
final DataCenterVO dcVo =
_dcDao.findById(router.getDataCenterId());
cmd.setAccessDetail(NetworkElementCommand.ZONE_NETWORK_TYPE,
dcVo.getNetworkType().toString());
+boolean remove = false;
+// if there is only one static nat then it will be checked for
remove at the resource
+if (ipsWithrules == 0 && (ipsStaticNat == 0 || ipsStaticNat ==
1)) {
--- End diff --
Can you combine these two if blocks and eliminate remove variable if this
is not getting used at a later place
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply
> IP associations method in the management server. The method is not
> thread-safe. If it's called from multiple threads, each thread will load up
> the list of public IPs in different states (add or revoke)--correct for the
> thread, but not correct overall. Depending on execution order on the virtual
> router, the router can end up with public IPs assigned to it that are not
> supposed to be on it anymore. When another account acquires the same IP, this
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all
> recently released versions. Affected version is set to 4.7.x because that's
> what we verified against.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15827756#comment-15827756
]
ASF GitHub Bot commented on CLOUDSTACK-9317:
Github user yvsubhash commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1908#discussion_r96598944
--- Diff: server/src/com/cloud/network/router/CommandSetupHelper.java ---
@@ -823,13 +826,39 @@ public int compare(final PublicIpAddress o1, final
PublicIpAddress o2) {
associatedWithNetworkId = ipAddrList.get(0).getNetworkId();
}
+// for network if the ips does not have any rules, then only
last ip
+List userIps =
_ipAddressDao.listByAssociatedNetwork(associatedWithNetworkId, null);
+
+int ipsWithrules = 0;
+int ipsStaticNat = 0;
+for (IPAddressVO ip : userIps) {
+if ( _firewallsDao.countRulesByIpIdAndState(ip.getId(),
FirewallRule.State.Active) > 0 ) {
+ipsWithrules++;
+}
+
+if (ip.isOneToOneNat()) {
+ipsStaticNat++;
+}
+}
+
final IpAssocCommand cmd = new IpAssocCommand(ipsToSend);
cmd.setAccessDetail(NetworkElementCommand.ROUTER_IP,
_routerControlHelper.getRouterControlIp(router.getId()));
cmd.setAccessDetail(NetworkElementCommand.ROUTER_GUEST_IP,
_routerControlHelper.getRouterIpInNetwork(associatedWithNetworkId,
router.getId()));
cmd.setAccessDetail(NetworkElementCommand.ROUTER_NAME,
router.getInstanceName());
final DataCenterVO dcVo =
_dcDao.findById(router.getDataCenterId());
cmd.setAccessDetail(NetworkElementCommand.ZONE_NETWORK_TYPE,
dcVo.getNetworkType().toString());
+boolean remove = false;
+// if there is only one static nat then it will be checked for
remove at the resource
+if (ipsWithrules == 0 && (ipsStaticNat == 0 || ipsStaticNat ==
1)) {
--- End diff --
Can you combine these two if blocks and eliminate remove variable if this
is not getting used at a later place
> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply
> IP associations method in the management server. The method is not
> thread-safe. If it's called from multiple threads, each thread will load up
> the list of public IPs in different states (add or revoke)--correct for the
> thread, but not correct overall. Depending on execution order on the virtual
> router, the router can end up with public IPs assigned to it that are not
> supposed to be on it anymore. When another account acquires the same IP, this
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all
> recently released versions. Affected version is set to 4.7.x because that's
> what we verified against.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9748) VPN Users search functionality broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15827739#comment-15827739 ] rashmidixit commented on CLOUDSTACK-9748: - GitHub user Ashadeepa opened a pull request: https://github.com/apache/cloudstack/pull/1910 CLOUDSTACK-9748:VPN Users search functionality broken VPN Users search functionality broken If you try to search VPN users with itâs user name, you will not be able to search. Fixed the same. You can merge this pull request into a Git repository by running: $ git pull https://github.com/Ashadeepa/cloudstack CLOUDSTACK-9748 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1910.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 #1910 commit 0752ff667db09eeb3276627baef009eb414abaf4 Author: root Date: 2017-01-17T18:09:17Z CLOUDSTACK-9748:VPN Users search functionality broken --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > VPN Users search functionality broken > - > > Key: CLOUDSTACK-9748 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9748 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Ashadeepa Debnath > > VPN Users search functionality broken > If you try to search VPN users with it’s user name, you will not be able to > search. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9748) VPN Users search functionality broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15827737#comment-15827737 ] ASF GitHub Bot commented on CLOUDSTACK-9748: GitHub user Ashadeepa opened a pull request: https://github.com/apache/cloudstack/pull/1910 CLOUDSTACK-9748:VPN Users search functionality broken VPN Users search functionality broken If you try to search VPN users with it’s user name, you will not be able to search. Fixed the same. You can merge this pull request into a Git repository by running: $ git pull https://github.com/Ashadeepa/cloudstack CLOUDSTACK-9748 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1910.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 #1910 commit 0752ff667db09eeb3276627baef009eb414abaf4 Author: root Date: 2017-01-17T18:09:17Z CLOUDSTACK-9748:VPN Users search functionality broken > VPN Users search functionality broken > - > > Key: CLOUDSTACK-9748 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9748 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Ashadeepa Debnath > > VPN Users search functionality broken > If you try to search VPN users with it’s user name, you will not be able to > search. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9589) vmName entries from host_details table for the VM's whose state is Expunging should be deleted during upgrade from older versions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15827722#comment-15827722 ] ASF GitHub Bot commented on CLOUDSTACK-9589: Github user yvsubhash commented on the issue: https://github.com/apache/cloudstack/pull/1759 @rhtyd can you suggest me the branch for rebasing this commit against? > vmName entries from host_details table for the VM's whose state is Expunging > should be deleted during upgrade from older versions > - > > Key: CLOUDSTACK-9589 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9589 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Baremetal >Affects Versions: 4.4.4 > Environment: Baremetal zone >Reporter: subhash yedugundla > Fix For: 4.8.1 > > > Having vmName entries for VMs in 'expunging' states would cause with > deploying VMs with matching host tags fail. So removing them during upgrade -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9589) vmName entries from host_details table for the VM's whose state is Expunging should be deleted during upgrade from older versions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15827724#comment-15827724 ] rashmidixit commented on CLOUDSTACK-9589: - Github user yvsubhash commented on the issue: https://github.com/apache/cloudstack/pull/1759 @rhtyd can you suggest me the branch for rebasing this commit against? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- > vmName entries from host_details table for the VM's whose state is Expunging > should be deleted during upgrade from older versions > - > > Key: CLOUDSTACK-9589 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9589 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Baremetal >Affects Versions: 4.4.4 > Environment: Baremetal zone >Reporter: subhash yedugundla > Fix For: 4.8.1 > > > Having vmName entries for VMs in 'expunging' states would cause with > deploying VMs with matching host tags fail. So removing them during upgrade -- This message was sent by Atlassian JIRA (v6.3.4#6332)
