DEPRECATED - This group version of CSINode is deprecated by storage/v1/CSINode.
See the release notes for more information.
CSINode holds information about all CSI drivers installed on a node.
CSI drivers do not need to create the CSINode object directly.
As long as they use the node-driver-registrar sidecar container, the kubelet will automatically populate the CSINode object for the CSI driver as part of kubelet plugin registration.
CSINode has the same name as a node.
If the object is missing, it means either there are no CSI Drivers available on the node, or the Kubelet version is low enough that it doesn't create this object.
CSINode has an OwnerReference that points to the corresponding node object.
Returns the relative, descendent directory path between this module and other.
Throws if no such path exists.
For example, if module mod1 has path /dir1/mod1.pkl, and module mod2 has path /dir1/dir2/dir3/mod2.pkl,
then mod1.relativePathTo(mod2) will return List("dir2", "dir3").
A common use case is to compute the directory path between a template located at the root of a hierarchy
(say rootModule.pkl) and the currently evaluated module (accessible via the module keyword):
FieldsV1 stores a set of fields in a data structure like a Trie, in JSON format.
Each key is either a '.' representing the field itself, and will always map to an empty set, or a string representing a sub-field or item.
The string will follow one of these four formats:
'f:', where is the name of a field in a struct, or key in a map
'v:', where is the exact json formatted value of a list item
'i:', where is position of a item in a list
'k:', where is a map of a list item's key fields to their unique values
If a key maps to an empty Fields value, the field that key represents is part of the set.
The exact format is defined in sigs.k8s.io/structured-merge-diff.