zeekay
8a65db078a
The canonical C-Chains are the RLP archives, 1,082,781 blocks on mainnet and 218 on testnet. Each runs as luxd-archive on the chains node and answers publicly through the rpc door, which passes only eth_/net_/web3_ methods and answers admin_, debug_, personal_ and txpool_ itself. Testnet is frozen: its database is an emptyDir rebuilt from the archive inside VM initialization on every boot, so its admin API is never on and no restart depends on state surviving one. Mainnet is too large for that and is imported once with admin_importChain; its admin API is behind the door, and the pod is OnDelete and must not be deleted until luxfi/evm#152 is fixed (after an import, a restart leaves the C-Chain unable to initialize). Genesis is declared. The luxd-genesis ConfigMaps now hold the documents the archives chain to: mainnet block 0 0x3f4fa2a0…, testnet 0x1c5fe377…, each verified by booting it. The testnet document here before was a different one (gasLimit 0x3b9aca00) that refuses every archived block, and the mainnet one carried a C-Chain genesis that hashes to 0x43befc4e…. api.lux.network and api.lux.cloud route /v1/chain and / to the door at priority 300, above the unified api-* router, and no longer point at validators on the LAN. The five-validator luxd sets are 0. They start from a genesis the archive does not chain to and import nothing, so any block they made would fork it. They come back on the canonical genesis once #152 is fixed.
k8s — reference, not deployment
deploy/ is authoritative. Nothing in this directory is applied by anything.
The lux-fleet ApplicationSet generates one Application per
deploy/<namespace>/<app>.yaml and reads no other path in this repository, so a
manifest here reaches a cluster only if a person types kubectl apply. For a
service that also has a values file, that apply is a second, competing
description of one workload — and the values files were generated from what is
RUNNING while these were hand-applied over a long period, so when the two
disagree it is this tree that is stale.
Twelve services were declared in both. Each carried something the values file did not — an IngressRoute, a ConfigMap, a claim, a Role — so deleting them outright would have dropped the half of a service users reach. Those objects moved into the values files first, verified by rendering the chart and diffing it against the manifest, and only then were the manifests removed.
Two objects stayed, because the chart cannot express either:
lux-mainnet/luxd-rpc.yaml— a Service selecting onlux.network/rpc: fresh, one key more than luxd's own labels. rpc-tip-gate patches that key on and off.lux-testnet/exchange-api-ingress.yaml— moving it renames it, and an Ingress name is a cert-manager Certificate name.
lux-testnet/explorer.yaml also stayed, deliberately: this directory's own
kustomization records it as "a mix of aspirational + stale" that "would clobber
the live explorer pod", so its ConfigMap is not content to promote into the tree
CD reconciles from.
What legitimately lives here: chain CRs (LuxChain, LuxNetwork, LuxIndexer,
LuxGateway, LuxMPC), which are not services and have their own controllers;
NetworkPolicies; DNS zone files; and the historical record. Some aggregate roots
do not build — lux-k8s/kustomization.yaml lists a kms directory that does not
exist — and are kept for that history rather than for use.
Clusters
| Cluster | Environment | Domain | Nodes |
|---|---|---|---|
lux-k8s |
mainnet + testnet + devnet + storm (namespaces) | *.lux.network |
lux-nodes, lux-runners-amd64 |
hanzo-k8s |
prod | cloud.hanzo.network |
worker-pool, runner-pool-32g |
lux-dev-k8s and lux-test-k8s no longer exist. Devnet and testnet are the
lux-devnet / lux-testnet namespaces on do-sfo3-lux-k8s. Node workloads
are not defined under k8s/: the only luxd source is the three CD values files
under deploy/, preventing stale manifests from downgrading a network.
Tracked Chains
The runtime automation in Makefile + scripts/ensure-tracked-chains.sh enforces:
lux(C-Chain)zoohanzospcpars
Testnet aliases are used automatically: zootest, hanzotest, spctest, parstest.
Apply
A supporting resource here — a NetworkPolicy, a chain CR — is still applied by hand, and diffed first:
kubectl --context do-sfo3-hanzo-k8s diff -k k8s/hanzo-k8s
kubectl --context do-sfo3-hanzo-k8s apply -k k8s/hanzo-k8s
Never apply a workload from here. If a service has a values file, the values
file is what runs it; if it does not, give it one. Never add a luxd StatefulSet
or Network resource back to these roots — the only luxd source is the three
values files under deploy/.