Kubernetes Borg/Omega history topic 7: The Kubernetes Resource Model: why we (eventually) made it uniform and declarative. A topic even deeper than watch. More details can be found here: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/resource-management.md …
-
-
IIRC, part of the reason for the irregularity of the GCE update APIs was a desire for all-or-nothing transactionality. This meant that a general update API was replaced by separate methods for disk, network, etc. This yes/no answer was done for convenience of consumers.
-
The separation of desired and observed state was another take on the solution. You could ask for a disk to be attached and a new IP at the same time and figure out that the disk didn't exist but the IP was assigned by looking at the actual state.
- Show replies
New conversation -
-
-
IIRC, the GCE update API irregularities are due to a desire to support transactional all-or-nothing updates to VMs. So the API doesn't let you (for example) attach a disk and add a public IP address at the same time, because those resources came from different systems.
-
That may be one reason. Others include authz of fine-grain actions (which one can argue whether is useful or not), imperative maintenance operations like reboot and snapshot, and lack of a mechanism to update associative lists, but mostly just due to a difference in mindset.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.