Like most internal Google services, Borgmaster had an imperative, unversioned, monolithic RPC API built using the precursor to http://grpc.io , Stubby. It exposed an ad hoc collection of operations, like CreateJob, LookupPackage, StartAllocUpdate, and SetMachineAttributes
-
Show this thread
-
Hundreds to thousands of clients interfaced with this API. Many of them were asynchronous controllers or monitoring agents, as discussed in previous threads, and there was a simple command-line tool, and two widely used configuration CLIs
1 reply 0 retweets 1 likeShow this thread -
The APIs were manually mapped into the two Turing-complete configuration languages, and there was also a hand-crafted diff library for comparing the previous and new desired states. The sets of concepts, RPC operations, and configurable resource types were not easily extended
1 reply 1 retweet 5 likesShow this thread -
Some extensions of the core functionality, such as for batch scheduling and vertical autoscaling, used the Borgmaster as a configuration store by manually adding substructures stored with Job objects, which were then retrieved by polling Jobs.
1 reply 0 retweets 1 likeShow this thread -
Others, such as for load balancing, built independent services with their own service APIs and configuration mechanisms. This enabled teams to evolve their services independently, but created a heterogeneous, inconsistent management surface.
1 reply 0 retweets 2 likesShow this thread -
Omega supported an extensible object model, and
@davidopp had proposed putting an API in front of the persistent store, as we later did in Kubernetes, but it wasn't declarative. Separate work on a common configuration store was discontinued as Google Cloud became the focus1 reply 0 retweets 0 likesShow this thread -
GCP was comprised of independent services, with some common standards, such as the org hierarchy and authz. They used REST APIs, as the rest of the industry, and gRPC didn't exist yet. But, GCP’s APIs were not natively declarative, and Terraform didn’t exist, either
2 replies 0 retweets 1 likeShow this thread -
Replying to @bgrant0607
GCE was RESTful and, to some degree, was declarative. We didn't model all transitions as declarative though. We also didn't have a clear separation of the parameters that are set by the users and those that are status or set by the system.
2 replies 0 retweets 2 likes -
Replying to @jbeda
Unpredictable generated names, imperative set addition and removal, custom verbs, inconsistent metadata. As we can see from K8s v1beta1, consistency doesn't happen unless it's a priority
2 replies 1 retweet 2 likes -
Replying to @bgrant0607 @jbeda
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.
2 replies 0 retweets 0 likes
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.
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.