Test by enabling consistent list from cache in storage version migrator stress test that uses
conversion webhook that bottlenects events comming to watch cache.
Set concurrency to 10, based on maximum/average transform latency when
running stress test. In my testing max was about 60-100ms, while average
was 6-10ms.
I was workinng on updating a dependency, and noticed that running
hack/update-vendor.sh resulted in a diff. Comitting the result
as a PR.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* automatically escape reserved keywords for direct usage
* Add reserved keyword support in a ratcheting way, add tests.
---------
Co-authored-by: Wenxue Zhao <ballista01@outlook.com>
Dynamic resource allocation is similar to storage in the sense that users
create ResourceClaim objects to request resources, same as with persistent
volume claims. The actual resource usage is only known when allocating claims,
but some limits can already be enforced at admission time:
- "count/resourceclaims.resource.k8s.io" limits the number of ResourceClaim objects in
a namespace; this is a generic feature that is already supported also without
this commit.
- "resourceclaims" is *not* an alias - use "count/resourceclaims.resource.k8s.io"
instead.
- <device-class-name>.deviceclass.resource.k8s.io/devices limits the number of
ResourceClaim objects in a namespace such that the number of devices
requested through those objects with that class does not exceed the limit.
A single request may cause the allocation of multiple devices. For exact
counts, the quota limit is based on the sum of those exact counts. For requests
asking for "all" matching devices, the maximum number of allocated devices per
claim is used as a worst-case upper bound.
Requests asking for "admin access" contribute to the quota.
DRA quota: remove admin mode exception
make sure to cleanup after setting RelaxPolicyForUserNamespacePods
setup test variables to be a little more terse and similar between tests
cleanup Allowed checking
Signed-off-by: Peter Hunt <pehunt@redhat.com>
a masked proc mount has traditionally been used to prevent untrusted containers from accessing leaky kernel APIs.
However, within a user namespace, typical ID checks protect better than masked proc. Further, allowing unmasked proc
with a user namespace gives access to a container mounting sub procs, which opens avenues for container-in-container use cases.
Update PSS for baseline to allow a container to access an unmasked /proc, if it's in a user namespace and if the UserNamespacesPodSecurityStandards feature is enabled.
Signed-off-by: Peter Hunt <pehunt@redhat.com>
