BundleDeployment status error message improvement

[p-se]

When a resource of a BundleDeployment is removed after the Bundle has been created, the BundleDeployment says it is missing. This is also the case if the resource is not removed but changes its owner. In that case, the message of a resource that is missing might be misleading. These changes adapt the message to say " is not owned by us" instead of saying that the "<resource> is missing".

Part of #2134

[manno]

Suggested change

	Exist bool `json:"exist,omitempty"`
	// Exist is true if the modified resource exists in the cluster. This can happen, when ...
	Exist bool `json:"exist,omitempty"`

So this happens because we're missing annotations and the resource ends up in plan.Create instead of plan.Update?

This is probably the last usage of wrangler apply in the agent, we pass the helm resources.Objects into wrangler's DryRun and get a plan with several lists returned (Create, Update, Delete, Objects).

plan, err := m.applied.DryRun(ns, applied.GetSetID(bd.Name, m.labelPrefix, m.labelSuffix), resources.Objects...)

Our Diff only takes resources with updates to existing fields into account, it only looks at plan.Update.

https://github.com/rancher/fleet/blob/main/internal/cmd/agent/deployer/monitor/updatestatus.go#L161-L170

If we wrote our own applied.DryRun, could it return lists that fit our use case better? So that we don't have to do a an additional Get for every resource in plan.Create? I'm asking, because we do want to remove wrangler where possible.

[p-se]

So this happens because we're missing annotations and the resource ends up in plan.Create instead of plan.Update?

It might not be accurate to say, that we're missing annotations. So far I was only able to reproduce the issue when two bundles have fought for ownership. When one has it and the other takes it, the first says "missing" instead of "isn't owned by me". This message is adapted in this PR.

If we wrote our own applied.DryRun, could it return lists that fit our use case better? So that we don't have to do a an additional Get for every resource in plan.Create? I'm asking, because we do want to remove wrangler where possible.

Yes, I think we can do better when we write our own function to diff. However, I do not claim to have fully understood the diffing process.

And I only was able to reproduce the issue with two competing bundles, not with resources installed without a bundle and a bundle failing to properly adopt them. The newly create SURE might help to further investigate that.

[manno]

This adds 10 get requests per deployment if I'm right. Is that a performance problem?

[p-se]

This adds 10 get requests per deployment if I'm right. Is that a performance problem?

This adds up to 10 requests per bundledeployment. One request for every resource that the dry-run reported to be missing (that it would create). There is no default requeue period set in the reconciler, so that those requests are only done once on an attempted deployment of the downstream cluster (or if the bundledeployment is changed). It does not look like a performance problem to me.

[weyfonk]

LGTM