"Real" clients use objectWithMeta to enforce support for meta.Object;
strictly speaking, fakes don't need this, but it's best to align them
with the real clients to ensure that fakes don't end up allowing types
that can't be used with the real clients.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
This adds a generic implementation of a fake clientset, and uses it to
replace the template code in generated fake clientsets for the default
methods. The templates are preserved as-is (or as close as they can
be) for use in extensions, whether for resources or subresources.
Fake clientsets with no extensions are reduced to their main getter,
their specific struct, and their constructor. All method
implementations are provided by the generic implementation. The
dedicated struct is preserved to allow extensions and expansions to be
defined where necessary.
Instead of handling the variants (with/without list, apply) with a
complex sequence of if statements, build up an index into an array
containing the various declarations.
Similarly, instead of calling different action constructors for
namespaced and non-namespaced clientsets, assume the current behaviour
of non-namespaced action creation (equivalent to creating a namespaced
action with an empty namespace) and document that assumption in the
action implementation.
Signed-off-by: Stephen Kitt <skitt@redhat.com>
1. Pod cgrooup configured to use resources from pod spec if feature is enabled and resources are set at pod-level
2. Container cgroup limits defaulted to pod-level limits is container limits are not set
1. Use pod-level resource when feature is enabled and resources are set at pod-level
2. Edge case handling: When a pod defines only CPU or memory limits at pod-level (but not both), and container-level requests/limits are unset, the pod-level requests stay empty for the resource without a pod-limit. The container's request for that resource is then set to the default request value from schedutil.
1. The effective container requests cannot be greater than pod-level requests
2. Inidividual container limits cannot be greater than pod-level limits
3. Only CPU & Memory are supported at pod-level
4. Inplace container resources updates are not supported if pod-level resources are set
Note: effective container requests cannot be greater than pod-level limits is supported by transitivity. Effective container requests <= pod-level requests && pod-level requests <= pod-level limits; Therefore effective container requests <= pod-level limits
Signed-off-by: ndixita <ndixita@google.com>
1. If pod-level limit is set, pod-level request is unset and container-level request is set: derive pod-level request from container-level requests
2. If pod-level limit is set, pod-level request is unset and container-level request is unset: set pod-level request equal to pod-level limit
1. Add support for pod level resources in kubectl
2. Reuse the existing method to describe container resources and generalize it to describe both pod and container level resources
1. Add Resources struct to PodSpec struct in both external and internal API packages
2. Adding feature gate and logic for dropping disabled fields for Pod Level Resources
KEP: enhancements/keps/sig-node/2837-pod-level-resource-spec
- add an integration test that exercises the unsafe delete flow
- extend newTransformTest to enable RBAC
- add integration test to verify that LIST returns corrupt object keys
