Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from
Jan 13, 2025

Conversation

codingben
Copy link
Member

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.

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.

Signed-off-by: Ben Oukhanov <boukhanov@redhat.com>
@kubevirt-bot kubevirt-bot added release-note Denotes a PR that will be considered when it comes time to generate release notes. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. labels Dec 16, 2024
@codingben
Copy link
Member Author

/cc @jcanocan @lyarwood

Copy link
Member

@0xFelix 0xFelix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

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. 

@codingben
Copy link
Member Author

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
Copy link
Member

0xFelix commented Dec 18, 2024

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
Copy link
Contributor

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
Copy link
Contributor

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.

@codingben
Copy link
Member Author

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 .

The image's storage config is set by MAXIMUM_LAYER_SIZE as mentioned in the Quay's docs [1]. The default config is 20gb and the user can set another value in the deployment of Quay.

[1] https://docs.projectquay.io/config_quay.html

@ksimon1
Copy link
Member

ksimon1 commented Jan 13, 2025

/retest

@ksimon1
Copy link
Member

ksimon1 commented Jan 13, 2025

/approve

@kubevirt-bot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ksimon1

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

The pull request process is described here

Needs approval from an approver in each of these files:

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

@kubevirt-bot kubevirt-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 13, 2025
Copy link

openshift-ci bot commented Jan 13, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: codingben, ksimon1

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

The pull request process is described here

Needs approval from an approver in each of these files:

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

1 similar comment
Copy link

openshift-ci bot commented Jan 13, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: codingben, ksimon1

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

The pull request process is described here

Needs approval from an approver in each of these files:

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

@jcanocan
Copy link
Contributor

/lgtm

@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Jan 13, 2025
@kubevirt-bot kubevirt-bot merged commit fd46251 into kubevirt:main Jan 13, 2025
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/S
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants