fix(CNV-53190): use emptyDir to store downloaded disk

[codingben]

What this PR does / why we need it:

Currently the downloaded disk image from
the source will be stored inside container's
temporary file system, that consumes RAM,
and instead it should be stored in the node's
storage by using emptyDir.

Release note:

Use emptyDir to store downloaded disk in disk-uploader.

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign 0xfelix for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: codingben
Once this PR has been reviewed and has the lgtm label, please assign 0xfelix for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[codingben]

/cc @jcanocan @lyarwood

[0xFelix]

Did you check what is a typical size for local ephemeral storage on nodes? It might be an issue to expect this storage to hold several hundred gigabytes.

https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#configurations-for-local-ephemeral-storage

Also, I think it's worth mentioning that streaming IO is preferable if possible.

[dominikholler]

Currently the downloaded disk image from
the source will be stored inside container's
temporary file system, that consumes RAM,
and instead it should be stored in the node's
storage by using emptyDir.

According to my understanding, it is not that simple.

I would write

The disk-uploader might take a significant amount of scratch space.
emptyDir is the the appropriate way to let kubernetes know about that. 

[openshift-ci]

@codingben: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/win2k22-pipeline-example-test	a11d8f7	link	true	/test win2k22-pipeline-example-test
ci/prow/e2e-tests	a11d8f7	link	true	/test e2e-tests
ci/prow/win11-pipeline-example-test	a11d8f7	link	true	/test win11-pipeline-example-test
ci/prow/win10-pipeline-example-test	a11d8f7	link	true	/test win10-pipeline-example-test

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[codingben]

Did you check what is a typical size for local ephemeral storage on nodes? It might be an issue to expect this storage to hold several hundred gigabytes.

https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#configurations-for-local-ephemeral-storage

Good catch Felix. I didn't check the typical size. I think from customer's perspective, it's cheaper to use storage than memory (it's also mentioned in the docs you shared).

We can set something like this, to guarantee the usage of disk-uploader:

...
    resources:
      requests:
        ephemeral-storage: "2Gi"
      limits:
        ephemeral-storage: "10Gi"

Altough I need to investigate the maximum disk size we can download from the source, rebuild as a containerDisk and upload to the container registry - I'm not sure about the values yet.

Alos, I think it's worth mentioning that streaming IO is preferable if possible.

I agree, but streaming IO is not supported in Export API.

[0xFelix]

We can set something like this, to guarantee the usage of disk-uploader

Not sure what to recommend here. A disk might be larger than 10Gi before compressing it? How much scratch space is needed when working with a 10Gi disk? Will there be multiple copies of it?

[dominikholler]

I expect that the resources limits and requests has to be customizable. I would postpone this adjustment after we understood the limitations of the default config of quay.io .

[dominikholler]

My personal reference how to start is https://github.com/openshift-pipelines/tektoncd-catalog/blob/650a046c582e5a70719669fb7032a224ab42357e/tasks/task-buildah/0.5.0/task-buildah.yaml#L171 , because if it works for buildah, it would be a good starting point for the disk uploader task, too.