Handle non-OvsFetchInterfaceAnswer in OVS tunnel manager#12860
Handle non-OvsFetchInterfaceAnswer in OVS tunnel manager#12860dheeraj12347 wants to merge 1 commit intoapache:4.22from
Conversation
|
@dheeraj12347 |
|
@dheeraj12347 |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 4.22 #12860 +/- ##
============================================
- Coverage 17.61% 17.61% -0.01%
+ Complexity 15662 15661 -1
============================================
Files 5917 5917
Lines 531415 531438 +23
Branches 64973 64974 +1
============================================
+ Hits 93588 93589 +1
- Misses 427271 427293 +22
Partials 10556 10556
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Pull request overview
This PR hardens the OVS tunnel manager’s handling of agent responses for OvsFetchInterfaceCommand to prevent management server failures (e.g., ClassCastException) when the agent returns a non-OvsFetchInterfaceAnswer (such as UnsupportedAnswer) during GRE isolated network setup on XCP-ng.
Changes:
- Add null/empty checks for the
Answer[]returned by the agent. - Guard the cast to
OvsFetchInterfaceAnswerwith aninstanceofcheck and log a clear warning when the returned answer type is unexpected. - Minor cleanup of the IP string empty-check (
isEmpty()).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| OvsTunnelInterfaceVO ti = createInterfaceRecord(ans.getIp(), | ||
| ans.getNetmask(), ans.getMac(), hostId, ans.getLabel()); | ||
| ans.getNetmask(), ans.getMac(), hostId, ans.getLabel()); | ||
| return ti.getIp(); |
I don’t currently have a full CloudStack 4.22 + XCP‑ng 8.3 + OVS/GRE environment to reproduce this end‑to‑end. If you think it’s important that I verify it myself, I can try to set up such a lab, but it may take some time given my hardware/resources. |
|
Normally, PR authors test their changes before requesting peer review. However, I understand that in some cases it may not be possible to reproduce the issue due to differences in hardware or environment, or because the issue itself is difficult to reproduce. That said, I don’t think it’s necessary to acquire new hardware to reproduce and verify the fix in this case. It would be helpful if @UAnton could test the changes. However, as mentioned in my previous comment, I don’t think this PR will fix the issue #12815. We need to understand why the expected |
|
@dheeraj12347 @DaanHoogland @weizhouapache |
When starting a GRE isolated network on XCP-ng, the management server can fail with a ClassCastException like UnsupportedAnswer cannot be cast to OvsFetchInterfaceAnswer in OvsTunnelManagerImpl.handleFetchInterfaceAnswer. This happens when the agent returns an UnsupportedAnswer (or another Answer type) for OvsFetchInterfaceCommand, but the code unconditionally casts the first Answer to OvsFetchInterfaceAnswer.
Root cause
handleFetchInterfaceAnswer assumed answers[0] is always an OvsFetchInterfaceAnswer and directly cast it without checking for null, array length, or actual runtime type. When the hypervisor agent responds with a different Answer implementation (e.g. UnsupportedAnswer), this results in a ClassCastException and the GRE tunnel setup fails.
Solution
Add null and length checks for the Answer[] to handle missing or empty responses.
Check answers[0] with instanceof OvsFetchInterfaceAnswer before casting.
If the answer is not an OvsFetchInterfaceAnswer, log a clear warning with the actual type and details, and return null instead of throwing a ClassCastException.
Preserve the existing success path when a successful OvsFetchInterfaceAnswer with a non-empty IP address is returned.
Testing
Local build on 4.22:
bash
mvn -pl api,server -am -DskipTests clean install
Addresses #12815