hard-coded importer-template about containerized-data-importer

[jeffvance]

Agree. It will likely be "filled in" somehow by an APB.

[jeffvance]

This should be a bit higher priority:
If we have a go template for the importer pod then we won't need the IMPORTER_IMAGE env variable.
We also could change hack/version/lib.sh's getVersionedFiles function to only grep .yml, .yaml, and .json files, and thus we would be able to delete CDI_VERSION from common.go.

[jeffvance]

Can someone add a use case for this issue? Thanks!
@nellyc @shiywang @davidvossel

[nellyc]

for me its just to avoid having some person's name in the code
docker.io/jcoperh

[davidvossel]

Can someone add a use case for this issue? Thanks! @nellyc @shiywang @davidvossel

if we're using the the hardcoded "docker.io/jcoperh/importer:" prefix, how can I test my own dev build of the importer?

In kubevirt, we pass the VM pod's image as a cli arg to our virt-controller component. https://github.com/kubevirt/kubevirt/blob/master/manifests/dev/virt-controller.yaml.in#L37

The same thing could be done here with CDI. the cdi controller would take an argument to represent the import container image

[awels]

Resolved by PR#269