charts/karmada: ignore the static-resource Pod in the post-install check

[iawia002]

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

I encountered the following situation: the static-resource Job failed during execution, so it retried once. The retry was successful, and although the Job eventually completed successfully, the initial failure resulted in a failed Pod. Because of this failed Pod, the post-install check script kept running, even though all Karmada components were already running. This patch makes the post-install script ignore Pods related to static-resource.

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

none

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 29.40%. Comparing base (bcefb22) to head (8f3e32c).

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5369      +/-   ##
==========================================
- Coverage   29.41%   29.40%   -0.01%     
==========================================
  Files         632      632              
  Lines       43835    43835              
==========================================
- Hits        12892    12889       -3     
- Misses      30003    30004       +1     
- Partials      940      942       +2     

Flag	Coverage Δ
unittests	29.40% <ø> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[iawia002]

/assign @chaosi-zju

[chaosi-zju]

Hi, this problem realted to issue #5233

if you continue to try helm installation, you may also encounter this problem.

I have a batter resolution in PR #5305, but lack of people who good at helm reviews.

I think you are very proficient in helm. Can you help me review it?

when that pr merged, this problem will gone.

[iawia002]

Hi, this problem realted to issue #5233

I didn't see how this relates to #5233, even if we merge #5305, the static-resource Job will still exist, right? It may still fail and leave behind a Pod in a Failed state, causing the post-install check to fail. The last time I encountered this issue (I forgot to take a screenshot), I remember it had nothing to do with the secret; it failed once because it couldn't connect to the apiserver.

Can you help me review it?

I can help review #5305, but I'm new to the Karmada chart, I don't know the big picture about it, so I can barely give some review comments.

[chaosi-zju]

even if we merge #5305, the static-resource Job will still exist, right?

yes

causing the post-install check to fail.

no, after my #5305, it will no longer check static-resource Job pod.

I didn't see how this relates to #5233
I remember it had nothing to do with the secret

the relation is, you can see that wait condition in static-resource job and some init-container are newly introduced, which aims to install each component in order. However, these wait conditions are unreasonably implemented.

unreasonable wait condition caused #5233 and yours failure, so we hope to completely rectify these wait conditions, eventually we want to change it to #5305

Of cource, if your issue is more urgent, we can also merge yours in first and then I'll think about moving forward #5305.

but I'm new to the Karmada chart, I don't know the big picture about it

actually, I mainly want to ask for your opinion on the issue of sequentially installing deployments. I wonder if you know some best practices.

[iawia002]

We may not on the same page. The post-install Job is still checking if all the Pods under the karmada-system namespace are Ready, isn't it? I didn't see any updates to the post-install check script in #5305. It still checks all the Pods under the entire namespace, including the static-resource, of course.

My issue is that if the static-resource Job has ever failed, the post-install Job will not exit. It will keep waiting because there is a failed static-resource Pod in the karmada-system namespace.

actually, I mainly want to ask for your opinion on the issue of sequentially installing deployments. I wonder if you know some best practices.

Hardly at all, Helm's ability to handle dependency installation is very weak.

[chaosi-zju]

The post-install Job is still checking if all the Pods under the karmada-system namespace are Ready, isn't it?

Oh, sorry ! My fault, this pr has been around for nearly 10 days, and my memory is a little confused (((;꒪ꈊ꒪;)))

I originally intended to remove this waiting check in post-install Job directly (let job auto cleanup after finished), and then for some reason did not do so, I mistakenly thought I did.

So, your this PR is not conflict with that PR, I will continue to review it~

[chaosi-zju]

/retest

[chaosi-zju]

/lgtm

cc @RainbowMango

[iawia002]

/assign @RainbowMango
/unassign @chaosi-zju

[RainbowMango]

/approve
Thanks.

[karmada-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: RainbowMango

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• charts/OWNERS [RainbowMango]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment