managedfields

package
Version: v0.22.4 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Nov 11, 2021 License: Apache-2.0 Imports: 8 Imported by: 177

Documentation

Index

Constants

This section is empty.

Variables

This section is empty.

Functions

func ExtractInto

func ExtractInto(object runtime.Object, objectType typed.ParseableType, fieldManager string, applyConfiguration interface{}, subresource string) error

ExtractInto extracts the applied configuration state from object for fieldManager into applyConfiguration. If no managed fields are found for the given fieldManager, no error is returned, but applyConfiguration is left unpopulated. It is possible that no managed fields were found for the fieldManager because other field managers have taken ownership of all the fields previously owned by the fieldManager. It is also possible the fieldManager never owned fields.

The provided object MUST bo a root resource object since subresource objects do not contain their own managed fields. For example, an autoscaling.Scale object read from a "scale" subresource does not have any managed fields and so cannot be used as the object.

If the fields of a subresource are a subset of the fields of the root object, and their field paths and types are exactly the same, then ExtractInto can be called with the root resource as the object and the subresource as the applyConfiguration. This works for "status", obviously, because status is represented by the exact same object as the root resource. This this does NOT work, for example, with the "scale" subresources of Deployment, ReplicaSet and StatefulSet. While the spec.replicas, status.replicas fields are in the same exact field path locations as they are in autoscaling.Scale, the selector fields are in different locations, and are a different type.

Types

This section is empty.

Source Files

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL