Closed abh1sar closed 5 days ago
Attention: Patch coverage is 0%
with 48 lines
in your changes missing coverage. Please review.
Project coverage is 14.98%. Comparing base (
b2ef53b
) to head (1fb61ae
). Report is 70 commits behind head on 4.19.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Check will be done only for cases where Ipv4 allocation might race.
right now, this means when allocating for the GuestNetworkGuru. Can you look at @hsato03 's implementation (together with him) to see if it can be unified?
@abh1sar can you review and address outstanding comments? And, can you care to run packaging and smoketests for your own PRs that are ready for review. @blueorangutan package
@rohityadavcloud a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.
Packaging result [SF]: ✖️ el7 ✔️ el8 ✔️ el9 ✖️ debian ✔️ suse15. SL-JID 10097
@blueorangutan package
@sureshanaparti a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.
Packaging result [SF]: ✔️ el7 ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 10101
@blueorangutan package
@abh1sar a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.
Packaging result [SF]: ✔️ el7 ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 10135
@blueorangutan test
@abh1sar a [SL] Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests
[SF] Trillian test result (tid-10631) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 41624 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr9240-t10631-kvm-centos7.zip Smoke tests completed. 131 look OK, 0 have errors, 0 did not run Only failed and skipped tests results shown below:
Test | Result | Time (s) | Test File |
---|
I tried to reproduce the issue on a env without this PR
create a shared network with 5 IPs (1 for VR, 3 for test vms). deployed 6 vms in parallel, 3 works and 3 failed
create isolated network with netmask 255.255.255.248 (6 IPs in total, 1 for VR, 2 for existing VM, 2 for test vms). deploy 6 vms in parallel
2 vms failed, 4 vms succeeded (3 vms have the same IP)
With this PR (on another env)
Description
Fixes: #7907
This PR fixes the issue where two VMs can be assigned the same IP if they are created at the same time.
NetworkOrchestrator.allocateNic()
callsguru.alocate()
which returns a free IP address.NetworkOrchestrator.allocateNic()
then calls_nicDao.persists()
But
guru.allocate()
can return same IPs to two VMs if the first VM hasn't persisted the nic to the DB yet. Doing the whole thing in a transaction might be costly.So the fix is to check if the IP returned by guru.allocate is already assigned just before persisting the NicVO in a transaction. Check will be done only for cases where Ipv4 allocation might race.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Wasn't possible to reproduce the actual race, but I tested by manually setting values with debugger and verifying that the code does what it is supposed to.
How did you try to break this feature and the system with this change?