Uh oh!
There was an error while loading. Please reload this page.
CLOUDSTACK-9811: fixed an issue if the dev is not in the databag - #2003
Conversation
borisstoyanov
commented
Mar 13, 2017
Thanks for this fix @swill |
blueorangutan
commented
Mar 13, 2017
@borisstoyanov a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
blueorangutan
commented
Mar 13, 2017
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-591 |
borisstoyanov
commented
Mar 13, 2017
@blueorangutan test |
blueorangutan
commented
Mar 13, 2017
@borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
karuturi
commented
Mar 14, 2017
Thanks Will. Can you please add bug id(CLOUDSTACK-9811) to the PR and commit message? |
blueorangutan
commented
Mar 14, 2017
Trillian test result (tid-954)
|
ustcweizhou
commented
Mar 14, 2017
not tested it. but it seems the 'else' part also need to be changed. |
borisstoyanov
left a comment
There was a problem hiding this comment.
I've tested the changes and the VR does come up now, but I'm really concerned from the test failures we're getting
swill
commented
Mar 14, 2017
@ustcweizhou the @karuturi I have updated the PR title and I updated the commit message to include the jira ticket. @borisstoyanov do we have a run of these tests just against master recently to review the difference in output? |
ustcweizhou
commented
Mar 14, 2017
@swill what I mean is , if you do not want to change the logic, do you need to change 'else:' to 'elif index == -1:' ? |
swill
commented
Mar 14, 2017
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 Yes, I think you are right that the 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? |
swill
commented
Mar 14, 2017
On the Jira ticket, Wei Zhou mentioned that this could potentially happen if you have two different public IP ranges. So if you associate a public IP which is in a different range than the source nat, a new nic will be created. If you disassociate it, that nic will be removed. I guess my question is. Why is it not on the @borisstoyanov can you confirm that you have two different public IP ranges in your setup? |
borisstoyanov
commented
Mar 14, 2017
@swill we're using one IP range for the physical guest public network. I think we could set this up if required? |
ustcweizhou
commented
Mar 14, 2017
@borisstoyanov are you using vpc ? |
swill
commented
Mar 14, 2017
@borisstoyanov we are still trying to understand how the IP was found when looping through the @ustcweizhou has some good ideas on this front, but I don't think we have gotten to a point where we understand how this problem is happening. @borisstoyanov is there a chance you can post the |
borisstoyanov
commented
Mar 14, 2017
borisstoyanov
commented
Mar 14, 2017
@ustcweizhou no VPC |
swill
commented
Mar 14, 2017
@borisstoyanov I have a suspicion that the ip_association.json is a transient file which may be short lived. I am not sure because I have not seen it either, but it was the file being processed when you had your original error. I will review your ips.json and see what I can find. |
swill
commented
Mar 14, 2017
This How was this IP configured? I will see if I can get to the bottom of this, but this is pretty confusing. Do you have a sequence of events which produced this configuration? |
swill
commented
Mar 14, 2017
So... Looking at this with a different perspective. If there is a bug elsewhere which would cause an IP to be duplicated in the |
ustcweizhou
commented
Mar 14, 2017
the ips.json is very very weird |
borisstoyanov
commented
Mar 14, 2017
yes, agree with you @swill, it seems eth3 is duplicated eth2. The VR we're trying to bring up isn't supposed to have eth3 at all... |
ustcweizhou
commented
Mar 14, 2017
it seems nicDevId is not set correctly in java code. |
ustcweizhou
commented
Mar 14, 2017
@borisstoyanov what's the last commit in your code ? |
swill
commented
Mar 14, 2017
Ya, I am not sure where the problem is stemming from. The fact that my code is not defensive around this problem is a problem. That is for sure. But given my understanding of the moving parts here, I feel like there is something else going on as well. I will see if I can get an environment up and running tomorrow so I can do some more testing on this. |
ustcweizhou
commented
Mar 15, 2017
@borisstoyanov moreover, can you please restart the network with cleanup, to see if the new VRs can start ? |
swill
commented
Mar 16, 2017
I am considering changing my implementation to be the same as the old implementation (which removed the IP from the dbag in the initial loop of the merge), but if If I do this and there is a bug elsewhere that will duplicate the IPs in the databag, then this will clean that up (as I assume it was doing before). Not sure this will fix @borisstoyanov's current problem, but I think it is probably a safer implementation to keep the source nat IP as the first IP. I will update this PR with that change later today... |
borisstoyanov
commented
Mar 17, 2017
Hi @swill, could you please let us know when do you expect to address the changes you have mentioned, so I could schedule the testing accordingly. Thanks. |
ustcweizhou
commented
Mar 17, 2017
@borisstoyanov could you please test with my suggestion? I think it should fix the duplicated nics in VR. |
remibergsma
commented
Mar 17, 2017
@swill FYI if you look for |
swill
commented
Mar 17, 2017
Thanks @remibergsma. I am going to use @borisstoyanov I will work on getting you the new implementation today. |
swill
commented
Mar 17, 2017
@borisstoyanov alright, this is ready for you to start testing. Can you kick off CI on this as well? I will be doing testing of this locally as well. This implementation is very similar to how it was implemented before my original change. See: https://github.com/apache/cloudstack/pull/1741/files#diff-a7d6f7150cca74029f23c19b72ad0622L19 The only change from the original was that if the IP is a |
borisstoyanov
commented
Mar 17, 2017
not sure about the CI tests @swill, I think the easiest way to kick Travis tests is the close/reopen the PR. |
blueorangutan
commented
Mar 17, 2017
@borisstoyanov a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
blueorangutan
commented
Mar 17, 2017
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-594 |
borisstoyanov
commented
Mar 17, 2017
@blueorangutan test |
blueorangutan
commented
Mar 17, 2017
@borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
swill
commented
Mar 17, 2017
thank you sir. :) |
borisstoyanov
commented
Mar 18, 2017
@blueorangutan test |
blueorangutan
commented
Mar 18, 2017
@borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
blueorangutan
commented
Mar 18, 2017
Trillian test result (tid-958)
|
borisstoyanov
left a comment
There was a problem hiding this comment.
Thanks for the fix @swill, tests are looking good, I've manually confirmed VR is coming up.
LGTM
borisstoyanov
commented
Mar 20, 2017
ping @rhtyd @DaanHoogland@abhinandanprateek@PaulAngus for review. |
DaanHoogland
commented
Mar 20, 2017
code LGTM but @ustcweizhou 's patch still makes sense to me. Maybe you can add that separately? travis still fails! |
borisstoyanov
commented
Mar 20, 2017
@DaanHoogland you could review it as well it addressed in https://github.com/apache/cloudstack/pull/2011/files |
karuturi
commented
Mar 22, 2017
@ustcweizhou can you also review this fix? Is pr #2011 still required? |
yadvr
commented
Mar 22, 2017
LGTM, does this affect 4.9 as well @swill ? /cc @borisstoyanov |
borisstoyanov
commented
Mar 22, 2017
@rhtyd I think this was introduced with the StrongSwan implementation which was 4.10 I think. |
ustcweizhou
commented
Mar 22, 2017
@karuturi to be honest, I think PR#2011 fixes the issue, not this one. |
I think #2011 fixes the observed issue, but this PR improves the IP ordering fix originally added to the strongswan pr. This implementation ensures (again) that duplicate public ips will not be saved to the data bag while ensuring the source nat ip is primary on its nic. In short, I think both PRs are worth merging. |
borisstoyanov
commented
Mar 22, 2017
@karuturi we have 3 LGTMs, I think we're good to merge this. |
karuturi
commented
Mar 23, 2017
ok. Thanks everyone. I am merging this. |
CLOUDSTACK-9811: fixed an issue if the dev is not in the databagDefend against the specified dev not being in the databag. * pr/2003: changed the order fix to be closer to the original code CLOUDSTACK-9811: fixed an issue if the dev is not in the databag Signed-off-by: Rajani Karuturi <rajani.karuturi@accelerite.com>
Defend against the specified dev not being in the databag.