SSP will create multiple DataImportCron CRs for each multi-architecture DataImportCronTemplate (DICT) object in the SSP CR.

A multi-architecture DICT object, is a DICT object with a non-empty ssp.kubevirt.io/dict.architectures annotation. The ssp.kubevirt.io/dict.architectures value is a comma separated list of architectures; e.g.

ssp.kubevirt.io/dict.architectures: "amd64,arm64"

Implementation details

If the ssp.kubevirt.io/dict.architectures annotation is missing or empty, SSP will create a DataImportCron (DIC) CR as done today.
When the ssp.kubevirt.io/dict.architectures annotation is not empty, SSP will create DIC CR for each one of the architectures listed in the annotation.

Creating a architecture specific DIC

1. the name of the dic will be the name of the DICT, with the suffix of its architecture; e.g. for the "rhel10-image-cron" DICT with ssp.kubevirt.io/dict.architectures annotation of "amd64,arm64", SSP will create two DICs: "rhel10-image-cron-amd64", and "rhel10-image-cron-arm64"
2. SSP will populate the spec.template.spec.source.registry.platform.architecture DIC field, with the architecture of this DIC.
3. SSP will set the DIC's spec.managedDataSource field, to the DICT value of the same field, with the suffix of the DIC specific architecture; e.g. if the DICT's spec.managedDataSource is rhel10-guest, the name of this field in the rhel10-image-cron-amd64 DIC, will be rhel10-guest-amd64
4. SSP will add the template.kubevirt.io/architecture label to the DIC, with the DIC architecture
5. SSP will add the cdi.kubevirt.io/storage.import.datasource-name label to the DIC, with the value of the DICT's spec.managedDataSource field (the architectute agnostic name).
6. SSP will not copy the ssp.kubevirt.io/dict.architectures annotation from the DICT to the architecture specific DIC.

Example

Assume the following DICT object in the SSP CR:

- metadata: 
    annotations: 
      cdi.kubevirt.io/storage.bind.immediate.requested: "true" 
      ssp.kubevirt.io/dict.architectures: "amd64,arm64" 
    labels: 
      kubevirt.io/dynamic-credentials-support: "true" 
    name: rhel10-image-cron 
  spec: 
    garbageCollect: Outdated 
    managedDataSource: rhel10 
    schedule: 4 8/12 * * * 
    template: 
      metadata: {} 
      spec: 
        source: 
          registry: 
            imageStream: rhel10-guest 
            pullMethod: node 
        storage: 
          resources: 
            requests: 
              storage: 30Gi 
      status: {} 

SSP will create two DIC CRs: rhel10-image-cron-amd64 and rhel10-image-cron-arm64

The rhel10-image-cron-amd64 will be (changes ar marked with an arrow):

apiVersion: cdi.kubevirt.io/v1beta1 
kind: DataImportCron 
metadata: 
    annotations: # <<== the ssp.kubevirt.io/dict.architectures DICT annotation is not copied here
      cdi.kubevirt.io/storage.bind.immediate.requested: "true" 
      ...
  labels: 
    ... 
    template.kubevirt.io/architecture: amd64 # <<== (new label)
    cdi.kubevirt.io/storage.import.datasource-name: rhel10 # <<== (new label)
  name: rhel10-image-cron-amd64 # <<== (DIC arch specific name)
  namespace: ... 
spec: 
  garbageCollect: Outdated 
  managedDataSource: rhel10-amd64 # <<== (arch specific DataSource name)
  schedule: 4 8/12 * * * 
  template: 
    metadata: {} 
    spec: 
      source: 
        registry: 
          imageStream: rhel10-guest 
          platform: # <<== (new field)
            architecture: amd64 # <<== (new field)
          pullMethod: node 
      storage: 
        resources: 
          requests: 
            storage: 30Gi 
    status: {} 

The rhel10-image-cron-arm64 DIC will be the same, but with "arm64" instead of "amd64" in all the relevant fields.