Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 17.50%. Comparing base (d60f455) to head (0c962bf).
⚠️ Report is 31 commits behind head on main.

@@             Coverage Diff              @@
##               main   #11766      +/-   ##
============================================
- Coverage     17.50%   17.50%   -0.01%     
  Complexity    15427    15427              
============================================
  Files          5894     5894              
  Lines        526847   526851       +4     
  Branches      64335    64337       +2     
============================================
- Hits          92234    92233       -1     
- Misses       424236   424241       +5     
  Partials      10377    10377              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@blueorangutan ui

@CodeBleu a Jenkins job has been kicked to build UI QA env. I'll keep you posted as I make progress.

UI build: ✔️
Live QA URL: https://qa.cloudstack.cloud/simulator/pr/11766 (QA-JID-770)

@CodeBleu , I tested this in QA, but it silently fails, i.e. it reports success but does not change the cidr. Have a look at https://qa.cloudstack.cloud/client/pr/11766/#/publicip/e7314c68-c570-42c5-939e-e61f5b30cb4b

@CodeBleu , I tested this in QA, but it silently fails, i.e. it reports success but does not change the cidr. Have a look at https://qa.cloudstack.cloud/client/pr/11766/#/publicip/e7314c68-c570-42c5-939e-e61f5b30cb4b

@DaanHoogland I believe this is because the QA build is not running the version needed to actually make the changes via the API.

#11766 (comment)

@CodeBleu , I tested this in QA, but it silently fails, i.e. it reports success but does not change the cidr. Have a look at https://qa.cloudstack.cloud/client/pr/11766/#/publicip/e7314c68-c570-42c5-939e-e61f5b30cb4b

@DaanHoogland I believe this is because the QA build is not running the version needed to actually make the changes via the API.

#11766 (comment)

ah, you might have a point, I’ll create a lab env.

@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.

Didn't test this, but UI changes LGTM. I'm assuming this editing CIDR is available via API

Yes, this is the API code that was already merged #11568

@rosi-shapeblue can you help testing this, we'd like to include it in 4.22

Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 15325

@blueorangutan package

@harikrishna-patnala 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 15333

@CodeBleu , I tested this in QA, but it silently fails, i.e. it reports success but does not change the cidr. Have a look at https://qa.cloudstack.cloud/client/pr/11766/#/publicip/e7314c68-c570-42c5-939e-e61f5b30cb4b

@DaanHoogland I believe this is because the QA build is not running the version needed to actually make the changes via the API.
#11766 (comment)

ah, you might have a point, I’ll create a lab env.

@CodeBleu , I see the same behaviour in a lab env build with the code in this PR.

@CodeBleu , I tested this in QA, but it silently fails, i.e. it reports success but does not change the cidr. Have a look at https://qa.cloudstack.cloud/client/pr/11766/#/publicip/e7314c68-c570-42c5-939e-e61f5b30cb4b

@DaanHoogland I believe this is because the QA build is not running the version needed to actually make the changes via the API.
#11766 (comment)

ah, you might have a point, I’ll create a lab env.

@CodeBleu , I see the same behaviour in a lab env build with the code in this PR.

@DaanHoogland are you sure you are using a lab that has this code in it? - #11568 ? It works for me.

Here is it working for me:

I created packages #11766 (comment), which is based on this PR merged in main. It should contain all the code.

I created packages #11766 (comment), which is based on this PR merged in main. It should contain all the code.

Could it not be including the code because it's in the code to use 4.22, and the packaging is not including it? I'm not sure exactly how that works. I just manually built it from the main branch locally and used that to test with.

I'm just not able to reproduce your issue, so it's hard for me to do anything differently if it's working for me.

If you let me know the steps you are taking, I can try to reproduce. How does one get the package from the package build ? #11766 (comment)

I created packages #11766 (comment), which is based on this PR merged in main. It should contain all the code.

Could it not be including the code because it's in the code to use 4.22, and the packaging is not including it? I'm not sure exactly how that works. I just manually built it from the main branch locally and used that to test with.

I'm just not able to reproduce your issue, so it's hard for me to do anything differently if it's working for me.

I understand, but the packeging job creates a merge commit and builds from that.

If you let me know the steps you are taking, I can try to reproduce. How does one get the package from the package build ? #11766 (comment)

So I build a clean set of packages from this PR merged into main (the standard at blueorangutan package) and then I build a virtualised environment from that. I tried several formats. As the last one exactly the one you show in your clip; I first made it empty (that was successful) and then I added two cidrs back in. I tried with “1.1.1.1/32,2.2.2.0/24” and with “1.2.3.4/32,5.6.7.8/32”. Both failed to add. When finally I add a single cidr it succeeds (e.g. “1.2.3.0/24”)

Are you sure you don’t have an extra fix (in comparison to main) in your environment?

I’ll double-check @DaanHoogland 's findings on my test environment and update

@blueorangutan package

@vladimirpetrov 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 15354

@blueorangutan package

@vladimirpetrov 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 15355

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 15356

@DaanHoogland , @CodeBleu - I’ve completed testing this on my test environment.

1. Creating a Load Balancer rule with single/multiple CIDRs (e.g. 1.1.1.1/32,2.2.2.0/24,3.3.3.3/32) works as expected.

2. Editing an existing rule and appending additional CIDRs fails with:

Failed to edit rule
Invalid CIDR list: 1.1.1.1/32 2.2.2.0/24,3.3.3.3/32

The input was entered correctly (no spaces), but during the edit flow the UI alters the CIDR string - a space replaces the first comma between the CIDRs, resulting in a malformed value being sent to the backend.

Browser console shows:

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'push')
at LoadBalancing.vue:1188

➝ This confirms the issue is UI-related, not API-related.

Backend log showing malformed CIDR string (space between 1st and 2nd CIDR) received during UpdateLoadBalancerRuleCmd.

Summary:

• Multiple CIDRs work on rule creation.
• Single CIDRs work on rule creation.
• Multiple CIDRs break when editing due to the UI transforming the CIDR list incorrectly.
• API itself accepts the correct format.

Happy to retest after a fix.

ok @CodeBleu so basically @rosi-shapeblue confirms my testing. Are you sure you have added all your code to the PR?