Repository navigation
Conversation
DaanHoogland
left a comment
There was a problem hiding this comment.
@nagaboinaramgopal can you see if this is applicable to older LTS branches?
82d4eb1 to
d0fc3c2
Compare
|
Thanks @DaanHoogland . I removed the inline comment, the null-guard reads clearly on its own. And on the LTS question: the same deref of a possibly-null requested profile in checkForRaceAndAllocateNic is present on 4.19, 4.20 and 4.22, so this applies to all of them. Happy to open backport PRs once this merges, or to retarget to the oldest branch and let it merge forward, whichever you prefer. |
We have the custom to put fixes on the oldest open LTS branch (until january that will be 4.20) and than merge it forwards to newer LTS branches and main. So rebasing this (and some of your other contribution) on 4.20 would be great, thanks. |
Sounds good, thanks for explaining the workflow. I'll rebase this onto 4.20 and update the base, and do the same for my other bug-fix PRs so they merge forward. The two feature PRs (HA capacity reserve, event-driven DRS) I'll leave targeting main. |
thanks, and welcome to the community ;) |
…ce is lost checkForRaceAndAllocateNic dereferenced the requested NicProfile when a concurrent deploy had already taken the IP (persistNicAfterRaceCheck returned null). On the common path the user requests no explicit IP, so requested is null and the loser threw a NullPointerException instead of nulling the IP and retrying. This defeats the ipv4AllocationRaceCheck retry for exactly the case it exists for (bulk/autoscale/CKS deploys onto one network). Null-guard the requested profile so the allocation is retried.
d0fc3c2 to
0035c61
Compare
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
|
@blueorangutan package |
|
@DaanHoogland 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]: ✔️ el8 ✔️ el9 ✔️ el10 ✖️ debian ✔️ suse15. SL-JID 19094 |
|
Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 19122 |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✖️ debian ✔️ suse15. SL-JID 19127 |
Fold the requested-IPv4 throw and the address reset under a single requested != null guard instead of repeating the check on both branches.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 4.20 #14038 +/- ##
=========================================
Coverage 16.34% 16.35%
- Complexity 13574 13579 +5
=========================================
Files 5669 5669
Lines 501368 501406 +38
Branches 60903 60908 +5
=========================================
+ Hits 81964 81996 +32
+ Misses 410219 410214 -5
- Partials 9185 9196 +11
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✖️ debian ✔️ suse15. SL-JID 19145 |
|
@blueorangutan test |
|
generic hardening, I think smoke tests should be enough for this one, cc @sureshanaparti , can you do a quick review? |
|
@blueorangutan package |
|
@nvazquez 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]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19152 |
|
@blueorangutan test |
|
@nvazquez a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-16931)
|
|
Thank you @DaanHoogland, @nvazquez and @sudo87 for the reviews, and for running the smoke tests. Please let me know if anything else is needed from my side for 4.20.4. |
@sudo87 , am i correct to understand, you did test this? (can you expand a little?) |
|
@DaanHoogland my bad, should have used "clgtm". I didn't test it. |
| throw new InsufficientVirtualNetworkCapacityException("Unable to acquire requested Guest IP address " + requested.getRequestedIPv4() + " for network " + network, DataCenter.class, dcVo.getId()); | ||
| } else { | ||
| requested.setIPv4Address(null); | ||
| if (requested != null) { |
There was a problem hiding this comment.
which deploy path sends no nic profile here? user vm deploys always build one even when no ip is asked, so i think its routers or system vms and not bulk or cks deploys
There was a problem hiding this comment.
Good question, thanks @Damans227. The null requested comes from allocate(): when a network is handed in with an empty profile list, the loop adds a single null entry and calls allocateNic(null, ...). You're right that normal user-vm deploys build a NicProfile and don't reach it; the path that does is reallocate() in Basic zones and the other internal add-network flows that pass no profile. Before the fix, losing the allocation race there dereferenced the null requested and threw NPE; the guard makes it retry the same as the non-null case.
There was a problem hiding this comment.
makes sense, so its the basic zone reallocate plus the control and management nics on routers and system vms. can we update the description too? it still says bulk deploys, autoscale and cks hit this
There was a problem hiding this comment.
Good point, thanks. Updated the description to drop the bulk/autoscale/cks examples, since those are user VMs that build a profile. It now says the null-requested path is the internal deploys that pass no profile: basic-zone reallocate and the control and management NICs on routers and system VMs.
Description
checkForRaceAndAllocateNic dereferenced the requested NicProfile when a
concurrent deploy had already taken the IP (persistNicAfterRaceCheck returned
null). When the deploy passes no requested profile, requested is null, so the
losing thread threw a NullPointerException instead of nulling the IP and
retrying.
The null-requested path is the internal deploys that allocate a NIC without a
profile: Basic zone reallocate, and the control and management NICs on routers
and system VMs. User VM deploys build a NicProfile even when no IP is asked, so
they already retried correctly.
Null-guard the requested profile so a lost race retries the allocation.
Types of changes
Feature/Enhancement Scale or Bug Severity
Bug Severity
How Has This Been Tested?
Added a unit test that simulates losing the allocation race with no explicit IP
requested and asserts the allocation is retried rather than throwing a
NullPointerException. Also built the standard packages and deployed on a KVM
advanced zone.