Skip to content

objectstorage: make storage error descriptions extensible per backend #2661

Open

Description

Background
#2614 added objectstorage.DescribeServiceError, which the in-tree object-store plugin uses to log a scrubbed description of an error it maps to Internal: the HTTP status, plus the service's code and message where the backend judges them safe (for GCS, the XML error's Code and Message, never Details). To keep that PR small, DescribeServiceError calls the GCS describer directly, then falls back to any error with an HTTPStatusCode() int method (e.g. S3 SDK errors) for the status alone.

Problem

  • The generic DescribeServiceError names a specific backend (GCS), so each new backend means editing it.
  • Every backend's describer runs regardless of which backend the plugin was configured with.
  • Go code outside this repo that imports pkg/objectstorage and adds its own backend can't plug in a describer.

Out-of-process third-party plugins log their own errors, so this is only about Go backends built on pkg/objectstorage.

Options

  1. Describer on the configured backend: an exported interface, e.g. ErrorDescriber { DescribeError(error) (ServiceError, bool) }, implemented by the ObjectStorage client. The plugin asks only the backend it was built with, and external backends can implement it. A rough prototype passed tests but needs a typed field per plugin instead of any, and the Control plugin's objectstore.Store path would need the same.
  2. Errors describe themselves: each backend wraps the errors it returns in a type implementing a describer interface. It's fully generic, but every error-return site has to wrap, and a missed site silently loses detail.
  3. Per-backend registration via init(): we tried this in fix(atelet): fall back to anonymous GCS read with objectstore-plugin Internal #2614 and reverted it. It's simpler, but it isn't extensible outside the package and still runs every describer.

Related: #2614, #2630

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/storagekind/designDesign discussion, investigation, or research required before implementation

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions