Github user swill commented on the issue:

    https://github.com/apache/cloudstack/pull/2003
  
    I have to admit, I am not sure how the IP was found when looping through 
the list initially, but then when trying to update the index for the IP that 
was found, it is not there.  The only way I can think of that would cause this 
is if the IP <-> dev mapping is broken somehow.  It found the matching IP, but 
apparently that IP is not on the dev defined by the `nic_dev_id` (which comes 
from either: `nic_dev_id = address['nic_dev_id']` (from the databag), which can 
then be overridden by `nic_dev_id = ip['nic_dev_id']` (from the passed in IP) ).
    
    Yes, I think you are right that the `else` case does not work right now.  
This is because we are appending the IP to this dev, but we never removed it 
from the other dev it was apparently found in.  This logic is SUPPOSED to find 
the existing IP's index and then if found, update that index with the updated 
info.  
    
    The old logic which just removed all "found" IPs and then re-added them, 
did not preserve the order, so the source nat IP could get reconfigured as a 
secondary IP on a nic instead of it being primary.  This reordering of the IPs 
on VR reboot caused the VPN to fail because the source nat IP was no longer the 
primary IP.  
    
    So we know that removing all found IPs and then adding them does not work 
because it changes the order of the IPs causing the source nat IP to become a 
secondary IP on the nic.
    
    The error described in CLOUDSTACK-9811 seems to be a situation where the IP 
is found on one nic, but then for some reason the dev which the IP is 
associated with is changed (I don't know why this would be happening), causing 
the index where the IP was found to not be valid because the IP is actually on 
a different dev.  
    
    To know how to fix this correctly, we need to understand why/how an IP can 
be associated with one dev (index found) and then get changed to be associated 
with a different dev.
    
    We need to find a way to preserve IP order while being able to update the 
IP configurations.
    
    @remibergsma do you have any ideas on this?  Anyone else have ideas here?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to