Fix deployment of CKS clusters in Basic zone#11457
Conversation
|
@blueorangutan package |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## 4.20 #11457 +/- ##
============================================
- Coverage 16.17% 16.17% -0.01%
- Complexity 13285 13286 +1
============================================
Files 5656 5656
Lines 498000 498001 +1
Branches 60401 60401
============================================
- Hits 80539 80534 -5
- Misses 408496 408505 +9
+ Partials 8965 8962 -3
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:
|
|
@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]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 14643 |
|
@blueorangutan test |
|
@Pearl1594 a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
@blueorangutan test keepEnv basicZone |
|
@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-14069)
|
|
[SF] Trillian test result (tid-14068)
|
rajujith
left a comment
There was a problem hiding this comment.
LGTM
Tested. I was able to create a CKS cluster in a basic zone.
|
@blueorangutan test |
|
@weizhouapache a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-14079)
|
DaanHoogland
left a comment
There was a problem hiding this comment.
makes sense, thanks for the explanation @Pearl1594 clgtm
|
[SF] Trillian test result (tid-14080)
|
Description
Fixes: #11252
This PR fixes issue with deploying CKS clusters in basic zones. This happens because when deploying the control node, an IP from the shared network IP pool is allocated to it i.e., marked as allocated, but allocatedTime isn't set. When attempt is then made to reserve an IP for the virtual router, it runs the following query:
SELECT u.* FROM user_ip_address u INNER JOIN vlan v ON v.id = u.vlan_db_id INNER JOIN pod_vlan_map pvm ON pvm.vlan_db_id = u.vlan_db_id WHERE u.data_center_id = ? AND v.vlan_type = "DirectAttached" AND v.network_id = ? AND u.allocated IS NULL and u.vlan_db_id = ? AND u.forsystemvms = 0 ORDER BY u.forsystemvms ASC, u.vlan_db_id ASC LIMIT = 1where it gets the 1st IP that has allocated (allocatedtime) as null, so it returns an IP that has already been assigned to the control node.
To address the issue, if the allocated time is set along with updating the state, this issue will not be encountered.
Types of changes
Feature/Enhancement Scale or Bug Severity
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Deployed CKS cluster in a basic zone
How did you try to break this feature and the system with this change?