diff --git a/.github/workflows/unit-tests.yml b/.github/workflows/unit-tests.yml index c09c143e..921bd9cf 100644 --- a/.github/workflows/unit-tests.yml +++ b/.github/workflows/unit-tests.yml @@ -34,7 +34,7 @@ jobs: - name: Setup Go uses: actions/setup-go@v2 with: - go-version: '1.18' + go-version: '1.19' - name: Generate the coverage output run: make test-coverage - name: Send the coverage output diff --git a/cmd/custom/multiarch/multiarch_template.go.tmpl b/cmd/custom/multiarch/multiarch_template.go.tmpl index 786b8682..e871afc6 100644 --- a/cmd/custom/multiarch/multiarch_template.go.tmpl +++ b/cmd/custom/multiarch/multiarch_template.go.tmpl @@ -90,43 +90,66 @@

Multiple Architectures Dashboard

-

The audit tool output for the following packages were obtained by checking the image and the bundle manifests - distributed. This report aims to try to identify the package distributions that validates the bundle against - criteria to support Multiple Architectures. For further information check: +

The audit tool output for the following packages was obtained by checking the image and the bundle manifests + distributed. This report aims to identify the package distributions and validates the bundle against criteria to + support Multiple Architectures. For further information check: here.

Data from the image used
FAQ
-
1. How it works?
-

The images are inspect ($docker manifest inspect) and then:

-
  • raise a error(s) when is possible to confirm that images does not provide the support defined via to the labels on the CSV
    • -
  • raise a warning when it is possible to check that the Operator manager image(s) supports architecture(s) not defined via labels. Therefore, it shows like the labels are missing.
    • -
  • raise warnings when is possible to verify that the images defined in the CSV does not provide the same architecture(s) supported by the Operator manager image(s) or defined via the labels
    • +
    1. How does it work?
    +
    + The audit tool inspects ($ docker manifest inspect) the images in the CSV and then: +
      +
    • raises an error(s) when the images available do not match the platforms defined in the CSV labels.
      • +
    • raises a warning when the Operator manager image(s) supports one or more platforms not defined in the CSV labels. This suggests the labels may be missing.
      • +
    • raises a warning when an image defined in the CSV does not support the same platform(s) supported by the Operator manager image(s) or defined via the CSV labels.
      • +
    • raises a warning when an image defined in the CSV does not specify node affinity requirements for the platforms supported by the image.
      • +
    +
    -
    2. What is checked?
    -

    Note: On this check, we aggregate the archetype(s) and OS(s) provided via the labels and those which are found by checking the images so that, we can check:

    -
  • If your CSV is missing labels
    • -
  • If your Operator bundle specifies images which does not supports all archetypes found for your Operator image(s) (probably supported by your project)
    • -

    Note: To better guess the case scenarios where authors might missed the labels the following check will - verify all architectures support for the Operator image(s). However, by looking at the CSV we are not able to ensure what is - the Operator image because this info is not provided. Therefore, we know by SDK the Operator image container will be called manager.

    -
    How the Operator image(s) are identified?
    -
  • The container named as manager under the CSV Deployment InstallStrategy (`Spec.InstallStrategy.StrategySpec.DeploymentSpecs`)
    • -
  • And if the above not found, all images under the InstallStrategy excluding the a container named as ` kube-rbac-proxy` since it is also scaffolded by default
    • +
    +
    2. What is checked?
    + Note: In this check, the audit tool aggregates the platforms (`OS/architecture` pairs) provided via the labels and those which are found by inspecting the images so that we can check: +
      +
    • if your CSV is missing labels.
      • +
    • if your Operator bundle declares images that do not support all platforms found for your Operator image(s) (which indicates the intended platforms supported by your project).
      • +
    +

    Note: To detect when authors may have missed one or more labels, the following check will verify that all platforms declared are supported by the Operator + image(s). However, by looking at the CSV we are not able to automatically detect the Operator image because this information is not explicitly provided.

    +
    + +
    +
    How is the Operator image(s) identified?
    +
      +
    1. The audit tool scans for a container named manager, the OperatorSDK default, under the CSV Deployment InstallStrategy (`Spec.InstallStrategy.StrategySpec.DeploymentSpecs`).
      2. +
    2. If the above image is not found then all images under the InstallStrategy are used, excluding a container named `kube-rbac-proxy` since it is also scaffolded by default.
      3. +
    +
    + +
    +
    What is node affinity?
    +
      +
    • Node affinity is a PodSpec-defined scheduling requirement that can be used to ensure that pods never try to schedule images to a node of an incompatible platform type.
      • +
    • It is a best practice for authors to set node affinity requirements to match the platforms supported by the underlying images when possible.
      • +
    • You can learn more about node affinity in the Kubernetes documentation.
      • +
    +
    Multiple Architectures Unsupported
    -

    Following the packages which the only supports the SO linux and the architecture amd64. This solutions are not available for heterogeneous support.

    +

    The following packages only support the platform `linux/amd64` (`OS/architecture`). These solutions will not be available in multi-arch compute clusters + if one or more nodes of a matching platform type are not available.

    @@ -168,7 +191,7 @@
    @@ -256,7 +280,7 @@
    @@ -366,7 +390,7 @@
    @@ -493,7 +517,7 @@