[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roeland Kuipers updated CLOUDSTACK-4605:
----------------------------------------

    Description: 
When rebooting a VPC router outside of cloudstack it will come up without 
proper configuration.

All interfaces are unconfigured except for eth0.

All other systemvm's are completely configured by kernel parameters and these 
parameters are also cached in /var/cache/cloud/cmdline. So configurations are 
persistent across reboots.

VPC routers are configured only when rebooting them by cloudstack.

We like to see the same method as for normal routers for the following reason:

We have experienced a serious outage on redundant routing vm pair due to the 
OOM killer. Somehow the master node ran OoM and the OOM killer decided to kill 
random processes causing HAproxy to go down. But since keepalived was still 
running and functioning, a failover never happened. 
In our experience we rather panic on OOM instead of praying that the OOM-killer 
will do the right thing while it in 99% percent of the cases it just renders a 
machine useless.
If this RvR would have panicked and rebooted we would have had a nice 
keepalived failure/failover without much impact on our customer.


See also CLOUDSTACK-4607 and CLOUDSTACK-4606

  was:
When rebooting a VPC router outside of cloudstack it will come up without 
proper configuration.

All interfaces are unconfigured except for eth0.

All other systemvm's are completely configured by kernel parameters and these 
parameters are also cached in /var/cache/cloud/cmdline. So configurations are 
persistent across reboots.

VPC routers are configured only when rebooting them by cloudstack.

We like to see the same method as for normal routers for the following reason:

We have experienced a serious outage on redundant routing vm pair due to the 
OOM killer. Somehow the master node ran OoM and the OOM killer decided to kill 
random processes causing HAproxy to go down. But since keepalived was still 
running and functioning, a failover never happened. 
In our experience we rather panic on OOM instead of praying that the OOM-killer 
will do the right thing while it in 99% percent of the cases it just renders a 
machine useless.
If this RvR would have panicked and rebooted we would have had a nice 
keepalived failure/failover without much impact on our customer.

    
> VPC router loses config after reboot
> ------------------------------------
>
>                 Key: CLOUDSTACK-4605
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4605
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the 
> default.) 
>          Components: Virtual Router
>    Affects Versions: 4.1.1
>            Reporter: Roeland Kuipers
>
> When rebooting a VPC router outside of cloudstack it will come up without 
> proper configuration.
> All interfaces are unconfigured except for eth0.
> All other systemvm's are completely configured by kernel parameters and these 
> parameters are also cached in /var/cache/cloud/cmdline. So configurations are 
> persistent across reboots.
> VPC routers are configured only when rebooting them by cloudstack.
> We like to see the same method as for normal routers for the following reason:
> We have experienced a serious outage on redundant routing vm pair due to the 
> OOM killer. Somehow the master node ran OoM and the OOM killer decided to 
> kill random processes causing HAproxy to go down. But since keepalived was 
> still running and functioning, a failover never happened. 
> In our experience we rather panic on OOM instead of praying that the 
> OOM-killer will do the right thing while it in 99% percent of the cases it 
> just renders a machine useless.
> If this RvR would have panicked and rebooted we would have had a nice 
> keepalived failure/failover without much impact on our customer.
> See also CLOUDSTACK-4607 and CLOUDSTACK-4606

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to