cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xin He (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CLOUDSTACK-8839) concurrent ip disassociate commands for virtual router maybe out of order, and this cause some public ips remnant in VR
Date Sun, 13 Sep 2015 09:25:45 GMT
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)

Mime
View raw message