Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-60424

OLMv1 chooses incorrect registry+v1 bundle when version contains build metadata

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • 4.18.z, 4.19.z, 4.20.0
    • OLM
    • Quality / Stability / Reliability
    • False
    • Hide

      None

      Show
      None
    • None
    • Important
    • No
    • None
    • Rejected
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Description of problem:

      OLMv1 uses the semver spec to sort bundles by their version in order to select the highest version that matches a user's filter criteria.
      
      The semver spec states in https://semver.org/#spec-item-10 that build metadata MUST be ignored when determining version precedence.
      
      Unfortunately, the registry+v1 bundle spec specifically decided to ignore that aspect of the spec when implementing `olm.substitutesFor`. For registry+v1 bundles, build metadata is considered for precedence with the following rules:
      1. It is considered after major, minor, patch, and prerelease
      2. When major, minor, patch, and prerelease are the same, build metadata is compared using the prerelease comparison algorithm (see https://semver.org/#spec-item-11)
      
      OLMv1 does not implement this modification to the semver spec for registry+v1 bundles.
      
      Also, if a ClusterExtension specifies a specific version that includes bundle metadata, OLMv1 does not always select that specific version.

      Version-Release number of selected component (if applicable):

      4.18

      How reproducible:

      Nearly always (the sort order is non-deterministic, so sometimes the "right" version is chosen)    

      Steps to Reproduce:

      When not specifying build metadata in version filter:
          1. Create a cluster extension for package `ansible-automation-platform-operator` with the version set to `2.5.0`
          2. Inspect the ClusterExtension status and find the installed version.
      
      
      When specifying build metadata in version filter:
          1. Create a cluster extension for package `ansible-automation-platform-operator` with the version set to `2.5.0+0.1727241223`
          2. Inspect the ClusterExtension status and find the installed version.

      Actual results:

      When not specifying build metadata in version filter:
          The installed version has build metadata that is less than other bundles 2.5.0 bundles
      
      
      When specifying build metadata in version filter:
          The installed version does not match 2.5.0+0.1727241223

      Expected results:

      When not specifying build metadata in version filter:
          The installed version has build metadata that is the highest among all other 2.5.0 bundle build metadatas.
      
      When specifying build metadata in version filter:
          The installed version is 2.5.0+0.1727241223

      Additional info:

      NOTE TO DEVELOPER: We should not propagate this behavior to other bundle formats because it is a violation of the semver spec. The implementation should only apply this logic when comparing between registry+v1 bundles. 
      
      Future bundle formats MUST NOT consider build metadata for precedence purposes.

              jlanford@redhat.com Joe Lanford
              jlanford@redhat.com Joe Lanford
              None
              None
              Jian Zhang Jian Zhang
              None
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated: