@mark1russell7/machines 0.3.30 → 0.3.32

package/README.md

@@ -53,6 +53,8 @@ The algebra reads these documents. It gives the closed form of each timer, the f
 | `RABBITMQ_CONNECTION` | `rabbitmq-connection` | RabbitMQ 4.3.6: one connection of AMQP 0-9-1 on the broker | server | 14 implemented, 1 documented |
 | `ATEN_DETECTOR` | `aten` | aten 0.6.0: one node that the failure detector of another node of RabbitMQ watches | server | 7 implemented |
 | `RA_MEMBER` | `ra-member` | ra 3.1.10: one member of the Raft cluster of a quorum queue of RabbitMQ 4.3.6 | server | 25 implemented |
+| `KAFKA_PARTITION` | `kafka-partition` | Apache Kafka 4.3.2: one broker that leads one partition, its answers at each acks, its high watermark and the loss of its leadership | server | 24 implemented |
+| `KAFKA_CONSUMER_GROUP` | `kafka-consumer-group` | Apache Kafka 4.3.2: one member of a consumer group under a process stop, its fence, the takeover of its partition and its commit after the stop | server | 14 implemented |
 | `GRPC_JS` | `grpc-js` | grpc-js 1.14.6: one channel to a gRPC server, its HTTP/2 transport, its keepalive and a unary call | driver | 27 implemented, 1 observed |
 | `GRPC_GO_SERVER` | `grpc-go-server` | A server of grpc-go v1.84.0: one HTTP/2 connection, its keepalive, its policy for PINGs and its TCP socket | server | 13 implemented, 1 documented |
 | `ETCD_SERVER` | `etcd-server` | The server of etcd v3.6.15 on grpc-go v1.83.2: one gRPC connection of a client | server | 19 implemented, 1 documented |
@@ -66,9 +68,13 @@ The algebra reads these documents. It gives the closed form of each timer, the f
 | `ISTIO_SIDECAR_OUTBOUND` | `istio-sidecar-outbound` | The client sidecar of Istio 1.31.3: Envoy 1.39.4 between the app and the mesh, its retries, an update of LDS and the SIGKILL | proxy | 31 implemented |
 | `ISTIO_SIDECAR_INBOUND` | `istio-sidecar-inbound` | The server sidecar of Istio 1.31.3: Envoy 1.39.4 between the mesh and the app, the policy, an update of LDS and the SIGKILL | proxy | 31 implemented |
 | `PILOT_AGENT` | `pilot-agent` | pilot-agent of Istio 1.31.3: the drain and the SIGKILL of the Envoy of a sidecar at the stop of its pod | proxy | 12 implemented |
+| `DEADLINE_CALL` | `deadline-call` | One call of a program, with a deadline and retries after a capped exponential backoff | self | 1 derived |
+| `KUBELET_READINESS` | `kubelet-readiness` | The readiness probe of the kubelet of Kubernetes 1.37.0, for one container | canary | 9 implemented, 1 documented |
 | `ZTUNNEL_HBONE` | `ztunnel-hbone` | ztunnel 1.31.3 in in-pod mode: one HBONE connection from a client pod to a server pod, its PING, its drain and the close of each flow of the app | proxy | 15 implemented, 3 derived |
 
-Thirty-three documents operate on Linux TCP (`over`). Eight documents operate on no other document. They are Linux TCP, conntrack, the Sentinel, the replication of mongod, aten, the member of Ra, the `RetryAgent` of undici and pilot-agent.
+Thirty-four documents operate on Linux TCP (`over`). Nine documents operate on no other document. They are Linux TCP, conntrack, the Sentinel, the replication of mongod, aten, the member of Ra, the `RetryAgent` of undici, pilot-agent and the kubelet probe.
+
+The call with a deadline is a generic client that the program configures, thus its knobs have no defaults. The readiness probe of the kubelet probes in sequence, thus its probes come at intervals of the longer of the period and the timeout.
 
 The `RetryAgent` is one request above the sockets of a `Client`. Its timer is the delay of a retry. Each retry can go on a new socket. The `conditions` of each document give the range where it holds, for example a range of kernels.
 

package/build/index.d.ts

@@ -1,4 +1,21 @@
 import { Expr, Machine } from "@mark1russell7/algebra";
+//#region src/call.d.ts
+/**
+ * This document is one call of a program on a socket of Linux TCP: a deadline for each try, and a
+ * retry after each deadline. It is a generic client that the program configures, as the
+ * `RetryAgent` of undici is configured with its options. No system sets its knobs, thus no knob has
+ * a default.
+ *
+ * - The deadline of a try is `timeout`. A timeout of 0 turns the deadline off, and the call waits
+ *   for a layer below.
+ * - After a deadline, the program waits `backoff`, and the wait doubles at each retry up to
+ *   `backoff_cap`. This backoff has no jitter.
+ * - The `retry` timer gives the time from the send of one try to the send of the next. Thus the sum of
+ *   its first n waits is the start of try n + 1.
+ * - The count of retries is the count of firings of `retry`. The caller gives it.
+ */
+export declare const DEADLINE_CALL: Machine;
+//#endregion
 //#region src/grpc/grpc-go-server.d.ts
 /**
  * This document is a server of grpc-go v1.84.0 on its own listener: grpc.NewServer on net.Listen, at the
@@ -144,6 +161,67 @@ export declare const IOREDIS_STATUS: Machine;
  */
 export declare const MANIFESTATIONS: Readonly<Record<string, readonly string[]>>;
 //#endregion
+//#region src/k8s/kubelet-readiness.d.ts
+/**
+ * This document is the readiness probe of the kubelet of Kubernetes 1.37.0 for one container. Each
+ * fact comes from the source at the tag v1.37.0, with the file and the line. The defaults are a
+ * period of 10 s, a timeout of 1 s and a failure threshold of 3.
+ *
+ * - The worker probes once at its start, then once at each tick of a Go ticker of one period. The
+ *   probe is synchronous. A Go ticker keeps one tick for a slow receiver, thus a probe that takes
+ *   longer than a period starts the next probe at once. The interval is max(period, timeout).
+ * - A probe of a pod that stops to answer fails at its timeout. An HTTP probe that times out is a
+ *   failure without an error, thus the kubelet does not try it again.
+ * - The result changes after `threshold` failures in a row. Thus the pod becomes unready at the
+ *   timeout of probe `threshold`, counted from the first probe after the fault.
+ * - The first probe after the fault comes within one period. Thus the band is one period wide.
+ * - A tcpSocket probe passes on a stalled process, because its kernel accepts the connection.
+ *
+ * This document does not hold two delays of the start of a container. The probe waits for
+ * `initialDelaySeconds` after the start. A kubelet that started less than one period ago sleeps a
+ * random part of a period before its first probe.
+ */
+export declare const KUBELET_READINESS: Machine;
+//#endregion
+//#region src/kafka/group.d.ts
+/**
+ * This document is Apache Kafka 4.3.2, for one member of a consumer group that a process stop holds.
+ * It gives when the coordinator removes the member, and when another member gets its partition. It
+ * also gives the answer to a commit of the old offsets after the stop.
+ *
+ * In the consumer protocol the session is a setting of the broker. Each heartbeat starts the session
+ * timer again. The last heartbeat came up to one interval before the stop, thus the fence comes one
+ * session after the stop, less up to one interval. The other member takes the partition at one of its
+ * own heartbeats after the fence.
+ *
+ * A commit of the member after the fence gets UNKNOWN_MEMBER_ID, and the client throws
+ * CommitFailedException. The rejoin changes this. A member that polls after the fence joins again at
+ * epoch 0 and gets a new epoch. The commit check at the same epoch asks no question about who owns the
+ * partition. Thus the broker accepts a commit of the old offsets at the new epoch. That commit moves
+ * the committed offset back while another member owns the partition.
+ */
+export declare const KAFKA_CONSUMER_GROUP: Machine;
+//#endregion
+//#region src/kafka/partition.d.ts
+/**
+ * This document is Apache Kafka 4.3.2, for one broker that leads one partition, in KRaft mode. It
+ * gives what the broker answers at each `acks`, and how the high watermark moves. It also gives how
+ * the broker loses the leadership when a fault cuts it from the other brokers and the controller.
+ *
+ * With `acks=1` a broker answers after its own append. With `acks=all` the write waits in a purgatory
+ * until the high watermark passes it. The high watermark is the smallest log end of the maximal
+ * in-sync replicas. A leader that cannot reach the controller cannot shrink that set, thus its high
+ * watermark stays.
+ *
+ * The controller fences a broker when no heartbeat came for `broker.session.timeout.ms`, and it
+ * elects another leader. The cut broker is not told, and it has no timer that stops it. It stays a
+ * leader in its own view until the metadata of the change reaches it, after the cut lifts. It then
+ * becomes a follower, and it ends each write in the purgatory with NOT_LEADER_OR_FOLLOWER. It fetches
+ * from the new leader, which answers with the end of its log at its election. The old leader
+ * truncates to that offset, not to the high watermark.
+ */
+export declare const KAFKA_PARTITION: Machine;
+//#endregion
 //#region src/mongo/mongod-replication.d.ts
 /**
  * This document is the replication of mongod 9.0.4. It gives one member of a replica set, its view