golang-k8s-sigs-structured-merge-diff 4.4.1+ds1-1 source package in Ubuntu
Changelog
golang-k8s-sigs-structured-merge-diff (4.4.1+ds1-1) unstable; urgency=medium * Team upload. * New upstream version. * section: golang * Standards-Version: 4.6.2 -- Jérémy Lal <email address hidden> Tue, 26 Dec 2023 14:41:13 +0100
Upload details
- Uploaded by:
- Debian Go Packaging Team
- Uploaded to:
- Sid
- Original maintainer:
- Debian Go Packaging Team
- Architectures:
- all
- Section:
- golang
- Urgency:
- Medium Urgency
See full publishing history Publishing
| Series | Published | Component | Section | |
|---|---|---|---|---|
| Noble | release | universe | misc |
Downloads
| File | Size | SHA-256 Checksum |
|---|---|---|
| golang-k8s-sigs-structured-merge-diff_4.4.1+ds1-1.dsc | 2.5 KiB | 59356c9dff9ae3fcda08f5d736b64d1cc5468bf94c53cb001c31f752ab4546e4 |
| golang-k8s-sigs-structured-merge-diff_4.4.1+ds1.orig.tar.xz | 147.9 KiB | 5af03992758497df8d9acb1811ff8110babf3dab552ab4688308b2bddc4177a6 |
| golang-k8s-sigs-structured-merge-diff_4.4.1+ds1-1.debian.tar.xz | 3.1 KiB | d5d792d61402563ab4115c040813a734aeb210f3404823bac471b6c31c673f6a |
Available diffs
- diff from 4.1.2+ds1-2 to 4.4.1+ds1-1 (107.9 KiB)
No changes file available.
Binary packages built by this source
- golang-k8s-sigs-structured-merge-diff-dev: implementation for "server-side apply" (library)
What is the apply operation?
.
It models resources in a control plane as having multiple
"managers". Each manager is typically trying to manage only one
aspect of a resource. The goal is to make it easy for disparate
managers to make the changes they need without messing up the things
that other managers are doing. In this system, both humans and
machines (aka "controllers") act as managers.
.
To do this, it explicitly tracks (using the fieldset data structure)
which fields each manager is currently managing.
.
Now, there are two basic mechanisms by which one modifies an object.
.
PUT/PATCH: This is a write command that says: "Make the object look
EXACTLY like X".
.
APPLY: This is a write command that says: "The fields I manage should
now look exactly like this (but I don't care about other fields)".
.
For PUT/PATCH, it deduces which fields will be managed based on what
is changing. For APPLY, the user is explicitly stating which fields
they wish to manage (and therefore requesting deletion of any fields
that they used to manage but stop mentioning).
.
Any time a manager begins managing some new field, that field is removed
from all other managers. If the manager is using the APPLY command, it
calls these conflicts, and will not proceed unless the user passes the
"force" option. This prevents accidentally setting fields which some
other entity is managing.
.
PUT/PATCH always "force". They are mostly used by automated systems,
which won't do anything productive with a new error type.
