Skip to content

Implement Regex/Glob based resolver #575

@fabianburth

Description

@fabianburth

Description

Background Information:
As specified in #513, we want to deprecate the current fallback resolvers. The current fallback resolvers are a list of ocm repository specifications (currently, either OCI or CTF), combined with a priority and a component name prefix.
Basically, the implementation for these fallback resolvers

  • sorts this list by priority
  • iterates through the sorted list, attempting to resolve a component version (if the prefix matches)
    • try the next entry, if this returns an error
    • stop if the component version is found
  • in case of list, it actually iterates through all resolvers, accumulating and deduplicating the versions

For more details, see the previous issue which implemented this for backwards compatibility #513 or see the corresponding PR.
This fail-fallback behaviour can be quite inefficient, as

  • each api request is rather slow
  • this list can become arbitrarily long

Therefore, we'd like to replace this fail-fallback implementation.

Glob/Regex Resolvers:
The new behaviour is based on a mapping of:

component name prefix (regex or glob) repository specification
component name: ocm.software/core/* version: >1.0.0 core ocm repository specification

There will be no fail-fallback behaviour. So an entry is matched, but getting the component version from the corresponding repository returns an error, the resolving process fails and there is no retrying with another repository.

So, in this example, the second entry would essentially be unreachable and it would always be attempted to resolve the component version with the general ocm repository specification:

component name prefix (regex or glob) repository specification
component name: ocm.software/* version: >1.0.0 general ocm repository specification
component name: ocm.software/core/* version: >1.0.0 core ocm repository specification

The goal of this issue is to:

  • decide on (together with the team) glob or regex
  • introduce a new configuration type for the glob/regex resolvers (e.g. resolvers.config.ocm.software)
  • provide a implementation based on the new configuration type

The corresponding configuration type could look something like this:

type: resolvers.config.ocm.software
resolvers:
  - repository:
      type: OCIRegistry
      baseUrl: ghcr.io
      subPath: open-component-model/components
    componentName: ocm.software/core/*
    semver: >1.0.0

The config type should be added here under bindings/go/configuration and the implementation should be added under bindings/go/repository/component.

Out of Scope:

  • We discussed the versioning constraints and decided that this is explicitly out of scope for the initial implementation.

Done Criteria

  • Code has been reviewed by other team members
  • Analysis of existing tests (Unit and Integration)
  • Unit Tests created for new code or existing Unit Tests updated
  • Integration Test Suite updated (includes deletion of existing unnecessary Integration Test and/or creation of new ones if required)
  • Enduser Documentation updated (if applicable)
  • Internal technical Documentation created/updated (if applicable)
    • Deprecation statements in bindings/go/repository/component/fallback/v1 adjusted to point to the new implementation
  • Successful demonstration in Review

Metadata

Metadata

Assignees

Labels

kind/tasksmall task, normally part of feature or epic

Type

No fields configured for Task.

Projects

Status
🍺 Done

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions