Optimization WaitForStatefulSetRollout and WaitForDeploymentRollout

[helen-frank]

What type of PR is this?
/kind feature

What this PR does / why we need it:

1. use watch
2. use kubernetes-sigs/application judge status

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

NONE

[karmada-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign lonelycz after the PR has been reviewed.
You can assign the PR to them by writing /assign @lonelycz in a comment when ready.

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

Needs approval from an approver in each of these files:

• pkg/karmadactl/OWNERS

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

[helen-frank]

/retest

[helen-frank]

/ok-to-test
/retest

[codecov-commenter]

Codecov Report

Merging #3418 (565eeed) into master (dff7a5b) will decrease coverage by 0.11%.
The diff coverage is 1.03%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@            Coverage Diff             @@
##           master    #3418      +/-   ##
==========================================
- Coverage   55.22%   55.12%   -0.11%     
==========================================
  Files         221      221              
  Lines       20831    20870      +39     
==========================================
  Hits        11504    11504              
- Misses       8717     8756      +39     
  Partials      610      610              

Flag	Coverage Δ
unittests	55.12% <1.03%> (-0.11%)	⬇️

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

Impacted Files	Coverage Δ
pkg/karmadactl/util/check.go	0.00% <0.00%> (ø)
pkg/karmadactl/cmdinit/kubernetes/deploy.go	41.01% <100.00%> (ø)

[helen-frank]

/cc @RainbowMango @lonelyCZ

[RainbowMango]

Can you explain why we need to do this a little bit?

[helen-frank]

Can you explain why we need to do this a little bit?

More accurate status determination and event-dependent waiting instead of violent polling

[RainbowMango]

More accurate status determination and event-dependent waiting instead of violent polling

Yes, agree, that's the benefit we can get from this. I'd like to invite @yanfeng1992 to take a look as he just optimized this piece of code at #3221.

[helen-frank]

/cc @yanfeng1992

[karmada-bot]

New changes are detected. LGTM label has been removed.

[helen-frank]

/retest

[RainbowMango]

I'm looking at the CLI/init tests. Don't worry about that.

[helen-frank]

I'm looking at the CLI/init tests. Don't worry about that.

I previously looked at the updated code is relatively simple, did not do the test in their own environment
I self-tested and found that it would report an error "error: prepare karmada failed. failed download file. url: https://github.com/karmada-io/karmada/releases/download/v1.7.0/crds. tar.gz code: 404"
The reason is

karmada/pkg/version/release.go

Lines 14 to 27 in cd9ca28

	// ParseGitVersion parses a git version string, such as:
	// - v1.1.0-73-g7e6d4f69
	// - v1.1.0
	func ParseGitVersion(gitVersion string) (*ReleaseVersion, error) {
	v, err := utilversion.ParseGeneric(gitVersion)
	if err != nil {
	return nil, err
	}
	return &ReleaseVersion{
	Version: v,
	}, nil
	}

But I see that cicd is using the local crds.tar.gz

[RainbowMango]

I self-tested and found that it would report an error "error: prepare karmada failed. failed download file.

Yes, because I tagged a pre-release [v1.7.0-alpha.1](https://github.com/karmada-io/karmada/releases/tag/v1.7.0-alpha.1) this morning, init will use the v1.7.0 as the default version. I'm thinking about how to deal with this.
cc @jwcesign who also looking at this issue.

By the way. I just disabled the CLI/init workflow temporarily, so that it won't block the following PRs.

[helen-frank]

I self-tested and found that it would report an error "error: prepare karmada failed. failed download file.

Yes, because I tagged a pre-release [v1.7.0-alpha.1](https://github.com/karmada-io/karmada/releases/tag/v1.7.0-alpha.1) this morning, init will use the v1.7.0 as the default version. I'm thinking about how to deal with this. cc @jwcesign who also looking at this issue.

By the way. I just disabled the CLI/init workflow temporarily, so that it won't block the following PRs.

I found out that the reason for waiting for APIService is that karmada-aggregated-apiserver uses v1.7.0, so it can't pull the image and apiservice v1alpha1.cluster.karmada.io is not ready.

By the way request to merge #3415 to reduce the log volume

[jwcesign]

I found out that the reason for waiting for APIService is that karmada-aggregated-apiserver uses v1.7.0, so it can't pull the image and apiservice v1alpha1.cluster.karmada.io is not ready.

The main reason is that when building karmadactl, the latest tag is used as the image version. However, when parsing the v1.7.0-alpha.1 tag, it results in a parsed version of v1.7.0, which is not what was expected.

[helen-frank]

An idea: use the committed code to build images and crds.tar.gz for testing? @RainbowMango

[jwcesign]

An idea: use the committed code to build images and crds.tar.gz for testing?

It makes sense, now the crd is from the committed code, but images are not.

[helen-frank]

/cc @jwcesign @lonelyCZ

[helen-frank]

ping @RainbowMango

[RainbowMango]

I guess this will conflict with #3665, I'll look at it after #3665 get merged.

[RainbowMango]

I'm hesitant to move this forward because it lacks enough benefits.

[helen-frank]

I'm hesitant to move this forward because it lacks enough benefits.

My idea is to use as many kubernetes mechanisms as possible to make code more cloud-native and faster. And using watch is cooler than wait.