[jira] [Commented] (CLOUDSTACK-9955) Featured Templates/Iso's created by Root/admin user are not visible to Domain Admin users
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114833#comment-16114833 ] ASF subversion and git services commented on CLOUDSTACK-9955: - Commit 6203013ec6b9bf09bf94f48150a4f72aba598424 in cloudstack's branch refs/heads/master from niteshsarda [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=6203013 ] CLOUDSTACK-9955 : Featured Templates/Iso's created by Root/admin user are not visible to Domain Admin users (#2144) ISSUE: Featured Templates/Iso's created by Root/admin user are not visible to Domain Admin users. STEPS TO REPRODUCE Mark a template as featured and try to view it from a domain admin user The issue occurs for both templates and iso's registered before and after upgrade Templates,ISO's whose owner is ROOT admin, public: Yes, featured: Yes Log in to UI (as a domain admin, such as an admin of “TEST/TEST1” domain) Choose “Templates”. Error message will be shown on UI > Featured Templates/Iso's created by Root/admin user are not visible to Domain > Admin users > - > > Key: CLOUDSTACK-9955 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9955 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitesh Sarda >Priority: Minor > > ISSUE > > Featured Templates/Iso's created by Root/admin user are not visible to Domain > Admin users. > STEPS TO REPRODUCE > == > * Mark a template as featured and try to view it from a domain admin user > * The issue occurs for both templates and iso's registered before and after > upgrade > Templates,ISO's whose owner is ROOT admin, public: Yes, featured: Yes > Log in to UI (as a domain admin, such as an admin of “TEST/TEST1” domain) > Choose “Templates”. > * Error message will be shown on UI -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9801) IPSec VPN does not work after vRouter reboot or recreate
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114811#comment-16114811
]
ASF subversion and git services commented on CLOUDSTACK-9801:
-
Commit a5778139c2205971a0210f30ce537217ef0a2473 in cloudstack's branch
refs/heads/master from [~slair1]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=a577813 ]
CLOUDSTACK-9801: IPSec VPN does not work after vRouter reboot or recreate
(#1966)
This makes sure IP address is active.
After a vRouter is recreated (e.g. reboot via CloudStack UI) and Remote Access
VPN enabled, VPN won't work anymore. Here is the abbreviated output of "ipsec
auto -status" while we were having the issue:
root@r-10-VM:~# ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 169.254.1.45
000 interface eth0/eth0 169.254.1.45
000 %myid = (none)
After this commit, the following occurs and VPNs work:
root@r-10-VM:~# ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 169.254.1.45
000 interface eth0/eth0 169.254.1.45
000 interface eth1/eth1 xxx.xxx.xxx.172
000 interface eth1/eth1 xxx.xxx.xxx.172
000 interface eth2/eth2 192.168.1.1
000 interface eth2/eth2 192.168.1.1
000 %myid = (none)
eth1 interface IP is masked, but now ipsec sees all the interfaces and VPN
works.
Looks like this bug was introduced by Pull Request #1423
It added code to start ipsec
(cloudstack/systemvm/patches/debian/config/opt/cloud/bin/configure.py)
if vpnconfig['create']:
logging.debug("Enabling remote access vpn on "+ public_ip)
CsHelper.start_if_stopped("ipsec")
> IPSec VPN does not work after vRouter reboot or recreate
>
>
> Key: CLOUDSTACK-9801
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9801
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.9.0, 4.9.2.0, 4.9.0.1
> Environment: Tested in XenServer as hypervisor. With RemoteAccess
> VPN enabled. Both Remote Access VPN and Site to Site VPN functionality won't
> work.
>Reporter: Sean Lair
>Priority: Critical
> Labels: ipsec, virtual-router, vpc, vpn
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> After a vRouter is recreated (which happens when a reboot via CloudStack UI
> for example) and Remote Access VPN enabled, VPN won't work anymore. Here is
> the abbreviated output of "ipsec auto -status" while we were having the issue:
> root@r-10-VM:~# ipsec auto --status
> 000 using kernel interface: netkey
> 000 interface lo/lo 127.0.0.1
> 000 interface lo/lo 127.0.0.1
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth0/eth0 169.254.1.45
> 000 %myid = (none)
> Notice that only eth0 is shown, not the public interface eth1. Because of
> that ipsec is broken.
> However, if we manually stopped and started ipsec, then issued a "ipsec auto
> -status", the abbreviated output would be:
> root@r-10-VM:~# ipsec auto --status
> 000 using kernel interface: netkey
> 000 interface lo/lo 127.0.0.1
> 000 interface lo/lo 127.0.0.1
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth1/eth1 xxx.xxx.xxx.172
> 000 interface eth1/eth1 xxx.xxx.xxx.172
> 000 interface eth2/eth2 192.168.1.1
> 000 interface eth2/eth2 192.168.1.1
> 000 %myid = (none)
> eth1 interface IP is masked, but now ipsec sees all the interfaces and VPN
> works.
> Looks like this bug was introduced by Pull Request #1423
> https://github.com/apache/cloudstack/pull/1423
> It added code to start ipsec
> (cloudstack/systemvm/patches/debian/config/opt/cloud/bin/configure.py)
> if vpnconfig['create']:
> logging.debug("Enabling remote access vpn on "+ public_ip)
> CsHelper.start_if_stopped("ipsec")
> self.configure_l2tpIpsec(public_ip, self.dbag[public_ip])
> The issue is that if a reboot is issued from the CloudStack UI (as opposed to
> manually by logging into the vRouter), the NICS (except eth0) are not added
> to the VM until the cloud service is running.
> Since ipsec was started before the nics were added to the VM and before the
> public IP address is added to the nic, ipsec is not listening on the public
> IP address and all VPNs are broken.
> This is not a problem with the Site2Site VPN section of configure.py, because
> that section does not start ipsec if the public IP is not on the system
> yet...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9801) IPSec VPN does not work after vRouter reboot or recreate
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114805#comment-16114805
]
ASF subversion and git services commented on CLOUDSTACK-9801:
-
Commit a5778139c2205971a0210f30ce537217ef0a2473 in cloudstack's branch
refs/heads/4.10 from [~slair1]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=a577813 ]
CLOUDSTACK-9801: IPSec VPN does not work after vRouter reboot or recreate
(#1966)
This makes sure IP address is active.
After a vRouter is recreated (e.g. reboot via CloudStack UI) and Remote Access
VPN enabled, VPN won't work anymore. Here is the abbreviated output of "ipsec
auto -status" while we were having the issue:
root@r-10-VM:~# ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 169.254.1.45
000 interface eth0/eth0 169.254.1.45
000 %myid = (none)
After this commit, the following occurs and VPNs work:
root@r-10-VM:~# ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 169.254.1.45
000 interface eth0/eth0 169.254.1.45
000 interface eth1/eth1 xxx.xxx.xxx.172
000 interface eth1/eth1 xxx.xxx.xxx.172
000 interface eth2/eth2 192.168.1.1
000 interface eth2/eth2 192.168.1.1
000 %myid = (none)
eth1 interface IP is masked, but now ipsec sees all the interfaces and VPN
works.
Looks like this bug was introduced by Pull Request #1423
It added code to start ipsec
(cloudstack/systemvm/patches/debian/config/opt/cloud/bin/configure.py)
if vpnconfig['create']:
logging.debug("Enabling remote access vpn on "+ public_ip)
CsHelper.start_if_stopped("ipsec")
> IPSec VPN does not work after vRouter reboot or recreate
>
>
> Key: CLOUDSTACK-9801
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9801
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.9.0, 4.9.2.0, 4.9.0.1
> Environment: Tested in XenServer as hypervisor. With RemoteAccess
> VPN enabled. Both Remote Access VPN and Site to Site VPN functionality won't
> work.
>Reporter: Sean Lair
>Priority: Critical
> Labels: ipsec, virtual-router, vpc, vpn
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> After a vRouter is recreated (which happens when a reboot via CloudStack UI
> for example) and Remote Access VPN enabled, VPN won't work anymore. Here is
> the abbreviated output of "ipsec auto -status" while we were having the issue:
> root@r-10-VM:~# ipsec auto --status
> 000 using kernel interface: netkey
> 000 interface lo/lo 127.0.0.1
> 000 interface lo/lo 127.0.0.1
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth0/eth0 169.254.1.45
> 000 %myid = (none)
> Notice that only eth0 is shown, not the public interface eth1. Because of
> that ipsec is broken.
> However, if we manually stopped and started ipsec, then issued a "ipsec auto
> -status", the abbreviated output would be:
> root@r-10-VM:~# ipsec auto --status
> 000 using kernel interface: netkey
> 000 interface lo/lo 127.0.0.1
> 000 interface lo/lo 127.0.0.1
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth1/eth1 xxx.xxx.xxx.172
> 000 interface eth1/eth1 xxx.xxx.xxx.172
> 000 interface eth2/eth2 192.168.1.1
> 000 interface eth2/eth2 192.168.1.1
> 000 %myid = (none)
> eth1 interface IP is masked, but now ipsec sees all the interfaces and VPN
> works.
> Looks like this bug was introduced by Pull Request #1423
> https://github.com/apache/cloudstack/pull/1423
> It added code to start ipsec
> (cloudstack/systemvm/patches/debian/config/opt/cloud/bin/configure.py)
> if vpnconfig['create']:
> logging.debug("Enabling remote access vpn on "+ public_ip)
> CsHelper.start_if_stopped("ipsec")
> self.configure_l2tpIpsec(public_ip, self.dbag[public_ip])
> The issue is that if a reboot is issued from the CloudStack UI (as opposed to
> manually by logging into the vRouter), the NICS (except eth0) are not added
> to the VM until the cloud service is running.
> Since ipsec was started before the nics were added to the VM and before the
> public IP address is added to the nic, ipsec is not listening on the public
> IP address and all VPNs are broken.
> This is not a problem with the Site2Site VPN section of configure.py, because
> that section does not start ipsec if the public IP is not on the system
> yet...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9801) IPSec VPN does not work after vRouter reboot or recreate
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114799#comment-16114799
]
ASF subversion and git services commented on CLOUDSTACK-9801:
-
Commit a5778139c2205971a0210f30ce537217ef0a2473 in cloudstack's branch
refs/heads/4.9 from [~slair1]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=a577813 ]
CLOUDSTACK-9801: IPSec VPN does not work after vRouter reboot or recreate
(#1966)
This makes sure IP address is active.
After a vRouter is recreated (e.g. reboot via CloudStack UI) and Remote Access
VPN enabled, VPN won't work anymore. Here is the abbreviated output of "ipsec
auto -status" while we were having the issue:
root@r-10-VM:~# ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 169.254.1.45
000 interface eth0/eth0 169.254.1.45
000 %myid = (none)
After this commit, the following occurs and VPNs work:
root@r-10-VM:~# ipsec auto --status
000 using kernel interface: netkey
000 interface lo/lo 127.0.0.1
000 interface lo/lo 127.0.0.1
000 interface eth0/eth0 169.254.1.45
000 interface eth0/eth0 169.254.1.45
000 interface eth1/eth1 xxx.xxx.xxx.172
000 interface eth1/eth1 xxx.xxx.xxx.172
000 interface eth2/eth2 192.168.1.1
000 interface eth2/eth2 192.168.1.1
000 %myid = (none)
eth1 interface IP is masked, but now ipsec sees all the interfaces and VPN
works.
Looks like this bug was introduced by Pull Request #1423
It added code to start ipsec
(cloudstack/systemvm/patches/debian/config/opt/cloud/bin/configure.py)
if vpnconfig['create']:
logging.debug("Enabling remote access vpn on "+ public_ip)
CsHelper.start_if_stopped("ipsec")
> IPSec VPN does not work after vRouter reboot or recreate
>
>
> Key: CLOUDSTACK-9801
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9801
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.9.0, 4.9.2.0, 4.9.0.1
> Environment: Tested in XenServer as hypervisor. With RemoteAccess
> VPN enabled. Both Remote Access VPN and Site to Site VPN functionality won't
> work.
>Reporter: Sean Lair
>Priority: Critical
> Labels: ipsec, virtual-router, vpc, vpn
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> After a vRouter is recreated (which happens when a reboot via CloudStack UI
> for example) and Remote Access VPN enabled, VPN won't work anymore. Here is
> the abbreviated output of "ipsec auto -status" while we were having the issue:
> root@r-10-VM:~# ipsec auto --status
> 000 using kernel interface: netkey
> 000 interface lo/lo 127.0.0.1
> 000 interface lo/lo 127.0.0.1
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth0/eth0 169.254.1.45
> 000 %myid = (none)
> Notice that only eth0 is shown, not the public interface eth1. Because of
> that ipsec is broken.
> However, if we manually stopped and started ipsec, then issued a "ipsec auto
> -status", the abbreviated output would be:
> root@r-10-VM:~# ipsec auto --status
> 000 using kernel interface: netkey
> 000 interface lo/lo 127.0.0.1
> 000 interface lo/lo 127.0.0.1
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth0/eth0 169.254.1.45
> 000 interface eth1/eth1 xxx.xxx.xxx.172
> 000 interface eth1/eth1 xxx.xxx.xxx.172
> 000 interface eth2/eth2 192.168.1.1
> 000 interface eth2/eth2 192.168.1.1
> 000 %myid = (none)
> eth1 interface IP is masked, but now ipsec sees all the interfaces and VPN
> works.
> Looks like this bug was introduced by Pull Request #1423
> https://github.com/apache/cloudstack/pull/1423
> It added code to start ipsec
> (cloudstack/systemvm/patches/debian/config/opt/cloud/bin/configure.py)
> if vpnconfig['create']:
> logging.debug("Enabling remote access vpn on "+ public_ip)
> CsHelper.start_if_stopped("ipsec")
> self.configure_l2tpIpsec(public_ip, self.dbag[public_ip])
> The issue is that if a reboot is issued from the CloudStack UI (as opposed to
> manually by logging into the vRouter), the NICS (except eth0) are not added
> to the VM until the cloud service is running.
> Since ipsec was started before the nics were added to the VM and before the
> public IP address is added to the nic, ipsec is not listening on the public
> IP address and all VPNs are broken.
> This is not a problem with the Site2Site VPN section of configure.py, because
> that section does not start ipsec if the public IP is not on the system
> yet...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10032) Database entries for templates created from snapshots disappear after management-server service restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114355#comment-16114355 ] Nitesh Sarda commented on CLOUDSTACK-10032: --- PR is raised for this issue. Following are the details : https://github.com/apache/cloudstack/pull/2224 > Database entries for templates created from snapshots disappear after > management-server service restart > --- > > Key: CLOUDSTACK-10032 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10032 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitesh Sarda > > ISSUE > > *This issue occurs only with KVM hypervisor*. Database entries for templates > created from snapshots disappear after management-server service restart > STEPS TO REPRODUCE > == > # Create a ACP setup and add KVM hypervisor as host. > # Create snapshot of any disk (root or data disk) of an instance. > # Create template using disk snapshot. > # Verify that template got downloaded completely and is in Ready state. > # Also, verify that entry for this template is present in template_store_ref > table in database. > # Now restart management server. > # Once management server is restarted completely and web UI is available, > check the template status. It will be in Active state instead of downloaded. > # Also, entry for this template vanishes from template_store_ref table in > database. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CLOUDSTACK-10022) Allow domain admin to create and delete subdomains
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Beims Bräscher updated CLOUDSTACK-10022: Status: Reviewable (was: In Progress) > Allow domain admin to create and delete subdomains > -- > > Key: CLOUDSTACK-10022 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10022 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Gabriel Beims Bräscher >Assignee: Gabriel Beims Bräscher >Priority: Minor > Fix For: 4.10.1.0 > > > This ticket proposes that domain admins should be able to create and delete > subdomains. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CLOUDSTACK-9977) Enhance SSL protocol used by Console Proxy
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Beims Bräscher resolved CLOUDSTACK-9977. Resolution: Fixed > Enhance SSL protocol used by Console Proxy > -- > > Key: CLOUDSTACK-9977 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9977 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Gabriel Beims Bräscher >Assignee: Gabriel Beims Bräscher >Priority: Minor > Attachments: SSLReportA.png, SSLReportC.png > > > Current SSL protocol and ciphers used in SystemVMs are not the recommended. > To analyze it is possible to use tests such as from SSL Labs > (https://www.ssllabs.com/ssltest/). > The attached image 'SSLReportC' shows the SSL report of console proxy with > grade capped to C. With a few changes, it is possible to change it to the > report from the attached image 'SSLReportA' (A-). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CLOUDSTACK-9925) Quota: fix tariff description for memory. Tariff value is for 1MB of RAM used per month (not hour).
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Beims Bräscher resolved CLOUDSTACK-9925. Resolution: Fixed > Quota: fix tariff description for memory. Tariff value is for 1MB of RAM used > per month (not hour). > --- > > Key: CLOUDSTACK-9925 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9925 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Gabriel Beims Bräscher >Assignee: Gabriel Beims Bräscher >Priority: Minor > > The quota memory tariff description in the CloudStack UI is wrong when > defines that the value is for "using 1MB or RAM for 1 hour". The quota > currency values reflect the value of a resource used per month, not an hour. > Quota divides the tariff value by the number of hours a month has (30 days - > 720 hours); then it calculates the credits used by a client based on the > amount of resources used per hour. The memory tariff description in the > interface is wrong and can guide users to configure values for an hour. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CLOUDSTACK-10032) Database entries for templates created from snapshots disappear after management-server service restart
Nitesh Sarda created CLOUDSTACK-10032: - Summary: Database entries for templates created from snapshots disappear after management-server service restart Key: CLOUDSTACK-10032 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10032 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Nitesh Sarda ISSUE *This issue occurs only with KVM hypervisor*. Database entries for templates created from snapshots disappear after management-server service restart STEPS TO REPRODUCE == # Create a ACP setup and add KVM hypervisor as host. # Create snapshot of any disk (root or data disk) of an instance. # Create template using disk snapshot. # Verify that template got downloaded completely and is in Ready state. # Also, verify that entry for this template is present in template_store_ref table in database. # Now restart management server. # Once management server is restarted completely and web UI is available, check the template status. It will be in Active state instead of downloaded. # Also, entry for this template vanishes from template_store_ref table in database. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10031) change default configuration for router.aggregation.command.each.timeout from 3 to 600 seconds.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114177#comment-16114177 ] Sigert Goeminne commented on CLOUDSTACK-10031: -- Solved with https://github.com/apache/cloudstack/pull/2223 > change default configuration for router.aggregation.command.each.timeout from > 3 to 600 seconds. > --- > > Key: CLOUDSTACK-10031 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10031 > 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.11.0.0 > Environment: KVM >Reporter: Raf Smeets >Assignee: Sigert Goeminne > > As CLOUDSTACK-9569: add router.aggregation.command.each.timeout to > agent.properties > was introduced, now VR is no longer spawned in time and is stopped. > Looking into the code the value of 10 minutes (600 seconds) is most used. > The default value of router.aggregation.command.each.timeout should be > changed from 3 seconds to 600seconds. > Refer to CLOUDSTACK-9569: add router.aggregation.command.each.timeout to > agent.properties (#1933) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9708) Router deployment failed due to two threads start VR simultaneosuly
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114145#comment-16114145
]
ASF subversion and git services commented on CLOUDSTACK-9708:
-
Commit f4a138d251e4d0bccb79ee7bdd626aaa35563118 in cloudstack's branch
refs/heads/master from [~bhaisaab]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=f4a138d ]
Revert "CLOUDSTACK-9708: Router deployment failed due to two threads start VR
simultaneously." (#2220)
This reverts commit 42e60ebac6f067e003598447ef75d914b7916734 /
9e20525e08d8dae7bcf3d568c5a1ccdb793eeb9d.
> Router deployment failed due to two threads start VR simultaneosuly
> ---
>
> Key: CLOUDSTACK-9708
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9708
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nitin Kumar Maharana
>
> This is some race condition observed with HyperV host.
> The issue is produced when two or more threads try to start Router VMs
> simultaneously.
> This is a race condition between two threads trying to start Router VMs
> simultaneosuly, see the two threads below:
> 2015-01-08 17:10:03,750 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-11:ctx-5eb09ffd) (logid:b22fde6c) Sending cmd to
> https://10.81.56.130:8250/api/HypervResource/com.cloud.agent.api.GetStorageStatsCommand
> cmd
> data:{"id":"6e95644b-967e-3b15-a9f5-029e814252b1","localPath":"/storage/primary","pooltype":"SMB","contextMap":{"logid":"b22fde6c"},"wait":0}
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 static nat(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 static nat(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 firewall Ingress rule(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 firewall Ingress rule(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 port forwarding rule(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 port forwarding rule(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 static nat rule(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 static nat rule(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 vpn(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 vpn(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,784 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 load balancing rule(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,784 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 load balancing rule(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,787 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Creating monitoring services on VM[DomainRouter|r-7-VM]
>
[jira] [Commented] (CLOUDSTACK-9708) Router deployment failed due to two threads start VR simultaneosuly
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114139#comment-16114139
]
ASF subversion and git services commented on CLOUDSTACK-9708:
-
Commit f4a138d251e4d0bccb79ee7bdd626aaa35563118 in cloudstack's branch
refs/heads/4.10 from [~bhaisaab]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=f4a138d ]
Revert "CLOUDSTACK-9708: Router deployment failed due to two threads start VR
simultaneously." (#2220)
This reverts commit 42e60ebac6f067e003598447ef75d914b7916734 /
9e20525e08d8dae7bcf3d568c5a1ccdb793eeb9d.
> Router deployment failed due to two threads start VR simultaneosuly
> ---
>
> Key: CLOUDSTACK-9708
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9708
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nitin Kumar Maharana
>
> This is some race condition observed with HyperV host.
> The issue is produced when two or more threads try to start Router VMs
> simultaneously.
> This is a race condition between two threads trying to start Router VMs
> simultaneosuly, see the two threads below:
> 2015-01-08 17:10:03,750 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-11:ctx-5eb09ffd) (logid:b22fde6c) Sending cmd to
> https://10.81.56.130:8250/api/HypervResource/com.cloud.agent.api.GetStorageStatsCommand
> cmd
> data:{"id":"6e95644b-967e-3b15-a9f5-029e814252b1","localPath":"/storage/primary","pooltype":"SMB","contextMap":{"logid":"b22fde6c"},"wait":0}
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 static nat(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 static nat(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 firewall Ingress rule(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 firewall Ingress rule(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 port forwarding rule(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 port forwarding rule(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 static nat rule(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 static nat rule(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 vpn(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 vpn(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,784 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 load balancing rule(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,784 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 load balancing rule(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,787 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Creating monitoring services on VM[DomainRouter|r-7-VM]
> start...
[jira] [Commented] (CLOUDSTACK-9708) Router deployment failed due to two threads start VR simultaneosuly
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114136#comment-16114136
]
ASF subversion and git services commented on CLOUDSTACK-9708:
-
Commit f4a138d251e4d0bccb79ee7bdd626aaa35563118 in cloudstack's branch
refs/heads/4.9 from [~bhaisaab]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=f4a138d ]
Revert "CLOUDSTACK-9708: Router deployment failed due to two threads start VR
simultaneously." (#2220)
This reverts commit 42e60ebac6f067e003598447ef75d914b7916734 /
9e20525e08d8dae7bcf3d568c5a1ccdb793eeb9d.
> Router deployment failed due to two threads start VR simultaneosuly
> ---
>
> Key: CLOUDSTACK-9708
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9708
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nitin Kumar Maharana
>
> This is some race condition observed with HyperV host.
> The issue is produced when two or more threads try to start Router VMs
> simultaneously.
> This is a race condition between two threads trying to start Router VMs
> simultaneosuly, see the two threads below:
> 2015-01-08 17:10:03,750 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-11:ctx-5eb09ffd) (logid:b22fde6c) Sending cmd to
> https://10.81.56.130:8250/api/HypervResource/com.cloud.agent.api.GetStorageStatsCommand
> cmd
> data:{"id":"6e95644b-967e-3b15-a9f5-029e814252b1","localPath":"/storage/primary","pooltype":"SMB","contextMap":{"logid":"b22fde6c"},"wait":0}
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 static nat(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 static nat(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 firewall Ingress rule(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 firewall Ingress rule(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 port forwarding rule(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 port forwarding rule(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 static nat rule(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 static nat rule(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 vpn(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,782 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 vpn(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,784 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Found 0 load balancing rule(s) to apply as a part of domR
> VM[DomainRouter|r-7-VM] start.
> 2015-01-08 17:10:03,784 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-4:ctx-7d37a603 job-21/job-25 ctx-d4e904bb)
> (logid:d5036c46) Found 0 load balancing rule(s) to apply as a part of domR
> VM[DomainRouter|r-8-VM] start.
> 2015-01-08 17:10:03,787 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-5:ctx-16557d57 job-22/job-26 ctx-f19c2085)
> (logid:1d478d14) Creating monitoring services on VM[DomainRouter|r-7-VM]
> start...
[jira] [Assigned] (CLOUDSTACK-10031) change default configuration for router.aggregation.command.each.timeout from 3 to 600 seconds.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sigert Goeminne reassigned CLOUDSTACK-10031: Assignee: Sigert Goeminne > change default configuration for router.aggregation.command.each.timeout from > 3 to 600 seconds. > --- > > Key: CLOUDSTACK-10031 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10031 > 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.11.0.0 > Environment: KVM >Reporter: Raf Smeets >Assignee: Sigert Goeminne > > As CLOUDSTACK-9569: add router.aggregation.command.each.timeout to > agent.properties > was introduced, now VR is no longer spawned in time and is stopped. > Looking into the code the value of 10 minutes (600 seconds) is most used. > The default value of router.aggregation.command.each.timeout should be > changed from 3 seconds to 600seconds. > Refer to CLOUDSTACK-9569: add router.aggregation.command.each.timeout to > agent.properties (#1933) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CLOUDSTACK-10031) change default configuration for router.aggregation.command.each.timeout from 3 to 600 seconds.
Raf Smeets created CLOUDSTACK-10031: --- Summary: change default configuration for router.aggregation.command.each.timeout from 3 to 600 seconds. Key: CLOUDSTACK-10031 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10031 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.11.0.0 Environment: KVM Reporter: Raf Smeets As CLOUDSTACK-9569: add router.aggregation.command.each.timeout to agent.properties was introduced, now VR is no longer spawned in time and is stopped. Looking into the code the value of 10 minutes (600 seconds) is most used. The default value of router.aggregation.command.each.timeout should be changed from 3 seconds to 600seconds. Refer to CLOUDSTACK-9569: add router.aggregation.command.each.timeout to agent.properties (#1933) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
