Xin He created CLOUDSTACK-8839:
----------------------------------
Summary: concurrent ip disassociate commands for virtual router
maybe out of order, and this cause some public ips remnant in VR
Key: CLOUDSTACK-8839
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8839
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.5.2
Environment: three management server and handreds of vmware compute
nodes
Reporter: Xin He
Priority: Critical
Fix For: 4.5.2
*[appearance]*
when many cocurrent disable static nat command happend in one network, some
public ips may remnant in VR, and this will cause a big problem for the hole
cloud netowrk
*[reason]*
when executing the disable static nat command, CS will execute disassociate ip
command at the same time, and this command will put all the public ip, include
the associate and disassociate ips, to VR, however, if cocurrent disable static
nat commands is out of order, some ip which should be disassociated may be
associated again by the command should be executed first (because this command
reach VR last, maybe for reason of some network latency).
*[bug fix suggestion]*
use some kind of lock mechanism like "optimistic lock", this "optimistic lock"
will give a version id for network and vpc, anytime the network or vpc is doing
some about public ip or network rules (network rules also have this problem),
the version id will have an increment, when the resouce part (like
VmwareResource) find the command which it got is before the last version they
got before, this command will be discarded. This method guarantee that every
command sent by resource part and rechieved by VR will be the last version of
network or vpc at that time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
