> 3. What is the nature and description of the request? Currently, it's not possible to set memory limits on EmptyDir volumes. > 4. Why does the customer need this? (List the business requirements here) This BZ is a spin-off of a bug where emptydir using medium set to memory could lead to memory being exhausted on a node. > 5. How would the customer like to achieve this? (List the functional requirements here) Giving the user the chance to set individual limits to EmptyDir in-memory volumes, so that he can somehow manage his RAM quota among the different tmpfs file systems in a controlled fashion. > 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. Example scenario: User creates an in-memory volume for volatile data. User should be able to set a memory limit when creating the volume. > 10. List any affected packages or components.
A memory backed emptyDir volume is limited based on the total pod memory limit defined by the sum of each container memory limit in that pod. The container that writes to the emptyDir memory-backed volume is charged for the write. If a container restarts, the charges are transferred to the pod cgroup. The ability to size the tmpfs that backs the emptyDir volume is not yet supported. Red Hat has engaged in review of an upstream PR that proposed to add the feature: https://github.com/kubernetes/kubernetes/pull/63641 The change is still under discussion in the broader community.
>This BZ is a spin-off of a bug where emptydir using medium set to memory could lead to memory being exhausted on a node. This should no longer be a primary concern as the node is able to enforce node allocatable such that pod memory usage cannot bring down the whole node via system-reservations. I would like to understand if the primary concern was protecting against node exhaustion or something else. Can the user provide more detail on the usage scenario to know if its different than https://github.com/kubernetes/kubernetes/pull/63641#issuecomment-460416786 ?
With the introduction of OpenShift 4, Red Hat has delivered or roadmapped a substantial number of features based on feedback by our customers. Many of the enhancements encompass specific RFEs which have been requested, or deliver a comparable solution to a customer problem, rendering an RFE redundant. This bz (RFE) has been identified as a feature request not yet planned or scheduled for an OpenShift release and is being closed. If this feature is still an active request that needs to be tracked, Red Hat Support can assist in filing a request in the new JIRA RFE system, as well as provide you with updates as the RFE progress within our planning processes. Please open a new support case: https://access.redhat.com/support/cases/#/case/new Opening a New Support Case: https://access.redhat.com/support/cases/#/case/new As the new Jira RFE system is not yet public, Red Hat Support can help answer your questions about your RFEs via the same support case system.