This implementation allows Pod to request multiple hugepage resources
of different size and mount hugepage volumes using storage medium
HugePage-<size>, e.g.
spec:
containers:
resources:
requests:
hugepages-2Mi: 2Mi
hugepages-1Gi: 2Gi
volumeMounts:
- mountPath: /hugepages-2Mi
name: hugepage-2mi
- mountPath: /hugepages-1Gi
name: hugepage-1gi
...
volumes:
- name: hugepage-2mi
emptyDir:
medium: HugePages-2Mi
- name: hugepage-1gi
emptyDir:
medium: HugePages-1Gi
NOTE: This is an alpha feature.
Feature gate HugePageStorageMediumSize must be enabled for it to work.
This combines container names into a single list because separating them
into a long, variable length string isn't particularly useful in the
context of an streaming error message.
Remove the validation for pre-allocated hugepages on node level.
Validation is currently the only thing making it impossible to use
pre-allocated huge pages in more than one size.
We have now quite a few reports from real users that this feature is
welcome.
Such declarations will make using the package exported identifiers impossible after the declaration or create confusion when reading the code.
Signed-off-by: clarklee92 <clarklee1992@hotmail.com>
All objects with graceful deletion allow multiple DELETE calls in the pending
state. Namespace is the one outlier, and the error here predates graceful
deletion and finalizers. We should make this behavior consistent with other
calls and merely indicate success and return the state of the object, the
same as if there were pending metadata finalizers.
Clients that previously checked for a conflict error during delete to know
that the server is already deleting will now no longer receive an error
(as if the object were rapidly deleted). There is a small chance that some
clients have error checking for this state, but a much larger chance that
clients that want to trigger a delete of the namespace do not handle this
error case.
Discovered in an e2e test that used the framework namespace and triggered
deletion of that ns itself, and then the AfterEach step in e2e failed
because the namespace was already pending deletion.
