🐛 wrap service account not found error

[rashmi43]

Description

Reviewer Checklist

• API Go Documentation
• Tests: Unit Tests (and E2E Tests, if appropriate)
• Comprehensive Commit Messages
• Links to related GitHub Issue(s)

[netlify]

✅ Deploy Preview for olmv1 ready!

Name	Link
🔨 Latest commit	5196201
🔍 Latest deploy log	https://app.netlify.com/sites/olmv1/deploys/673ca53027a4210008e8815c
😎 Deploy Preview	https://deploy-preview-1477--olmv1.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 4 lines in your changes missing coverage. Please review.

Project coverage is 74.63%. Comparing base (e5820ae) to head (6062677).

Files with missing lines	Patch %	Lines
internal/authentication/tokengetter.go	0.00%	3 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1477      +/-   ##
==========================================
- Coverage   74.73%   74.63%   -0.10%     
==========================================
  Files          42       42              
  Lines        3241     3244       +3     
==========================================
- Hits         2422     2421       -1     
- Misses        646      649       +3     
- Partials      173      174       +1     

Flag	Coverage Δ
e2e	52.28% <0.00%> (-0.15%)	⬇️
unit	57.12% <0.00%> (-0.09%)	⬇️

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.

[rashmi43]

fixes #1297

[thetechnick]

While PR creates a predictable error string, the message is still pretty much the same and does not yet fix the issue:

  - lastTransitionTime: "2024-11-18T14:41:05Z"
    message: 'Kubernetes cluster unreachable: Get "https://10.96.0.1:443/version":
      service account not found'
    observedGeneration: 1
    reason: Failed
    status: Unknown
    type: Installed

@rashmi43 Would you please create your own error type[1] and catch this error before it is written to the Condition message to provide your own custom error message?
[1]: https://go.dev/tour/methods/19

[everettraven]

@rashmi43 @thetechnick I have a feeling that prefix to the error message of Kubernetes cluster unreachable: Get .... : has to do with us injecting a custom http.RoundTripper for fetching service account tokens:

operator-controller/internal/action/restconfig.go

Lines 15 to 32 in e5820ae

	func ServiceAccountRestConfigMapper(tokenGetter *authentication.TokenGetter) func(ctx context.Context, o client.Object, c *rest.Config) (*rest.Config, error) {
	return func(ctx context.Context, o client.Object, c *rest.Config) (*rest.Config, error) {
	cExt := o.(*ocv1.ClusterExtension)
	saKey := types.NamespacedName{
	Name: cExt.Spec.ServiceAccount.Name,
	Namespace: cExt.Spec.Namespace,
	}
	saConfig := rest.AnonymousClientConfig(c)
	saConfig.Wrap(func(rt http.RoundTripper) http.RoundTripper {
	return &authentication.TokenInjectingRoundTripper{
	Tripper: rt,
	TokenGetter: tokenGetter,
	Key: saKey,
	}
	})
	return saConfig, nil
	}
	}

I imagine somewhere, either in the client-go or Helm code, there is an assumption that if these round trips fail it is likely due to the cluster being "unreachable" for some reason.

I'm not sure that implementing a custom error type will remove that information from the error message. Would improving the message to be more reflective of the context in which it is being returned be more helpful?

Maybe we can have something like:

  - lastTransitionTime: "2024-11-18T14:41:05Z"
    message: 'Unable to apply bundle content to cluster: Kubernetes cluster unreachable: Get "https://10.96.0.1:443/version": Unable to authenticate with Kubernetes cluster using ServiceAccount "foo": ServiceAccount "foo" not found'
    observedGeneration: 1
    reason: Failed
    status: Unknown
    type: Installed

Would that make it a bit more clear that in this case the Kubernetes cluster is unreachable when using a client relying on authenticating as the provided ServiceAccount since that ServiceAccount does not exist?

[everettraven]

Alternatively, with the custom error type we could attempt to parse the error string/type wherever it is returned and attempt to strip out what we think is the unnecessary prefix.

[camilamacedo86]

HI @rashmi43

Could you please rebase the commits?
Otherwise, when it gets merged, and we run git log, it will result in a very lousy commit message.

[thetechnick]

@everettraven By creating a custom error into the TokenGetter we can keep the error message short and precise.
I don't see a reason to expose the whole error wrap-chain to the user, when we know exactly that the Service Account is missing in this case and the additional information is not useful or actually missleading.

To pick up your example, I would be very happy if the condition message just reads:
Unable to authenticate with Kubernetes cluster using ServiceAccount "foo": ServiceAccount "foo" not found.

[everettraven]

@everettraven By creating a custom error into the TokenGetter we can keep the error message short and precise. I don't see a reason to expose the whole error wrap-chain to the user, when we know exactly that the Service Account is missing in this case and the additional information is not useful or actually missleading.

To pick up your example, I would be very happy if the condition message just reads: Unable to authenticate with Kubernetes cluster using ServiceAccount "foo": ServiceAccount "foo" not found.

I think this is reasonable. I mostly wanted to call out that I think it will take more of an effort to restrict the error string that we place into the status than simply adding a custom error type that is returned in the TokenGetter. The custom error may help us to identify when we've hit that error type, but there is most certainly additional error wrapping happening beyond the error message that we are returning from the TokenGetter.