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
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
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
Therefore, we'd like to replace this fail-fallback implementation.
Glob/Regex Resolvers:
The new behaviour is based on a mapping of:
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:
The goal of this issue is to:
resolvers.config.ocm.software)The corresponding configuration type could look something like this:
The config type should be added here under
bindings/go/configurationand the implementation should be added underbindings/go/repository/component.Out of Scope:
Done Criteria
bindings/go/repository/component/fallback/v1adjusted to point to the new implementation