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

Alena Prokharchyk resolved CLOUDSTACK-4605.
-------------------------------------------

    Resolution: Won't Fix

Its by design. CS does lots of things (besides configuring ips)on router reboot 
when called from CS - for example, configuring userdata/metadata. If reboot is 
called outside of the CS, all this information will be missed as the only one 
way to determine of what needs to be configured - by extracting this info from 
the CS DB and applying as a part of reboot process.


If router Vm gets shutdown from the inside by some reason, you should leave it 
for CloudStack HA to handle. The HA process will stop the router and restart it 
with applying all the configs needed.
                
> 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