A provider is a (node, module) pair (design 23), and the pin — the one way a
consumer names its provider — named only the node. Two modules on one node
can both answer a provision (public-acme and step-ca both offer acme-ca on
novox), and then the resolver, given a pin naming that node, took the last
provider listed: a coin flip. The same ambiguity beside the consumer was
settled by a map walk — random per plan — which is how novox's own
route-proxy got its issuer (novox/hq #258).
pin <node> <provision> <from-node> <module>: both halves, always. The
console gains pin and unpin. The provider may be on the consumer's own
node, since two modules beside it can both answer.
The resolver refuses ambiguity instead of picking, across machines and
beside the consumer alike, naming every candidate as node/module and the
form of the pin that settles it. A plain capability that grants nothing
and serves nothing (three shells beside an editor) is not a choice to put
to anybody and stays as it was.
provision_pin gains a nullable module (0050); records made before are
completed where the node they name answers once, and left for a person
where it answers twice (0051).
The provider of something already satisfied is looked for among what was
assigned, not only what the walk has reached — a consumer reached before
the provider beside it no longer loses its binding.
The start-time check that every declared verb is runnable samples each
verb's required arguments from its schema instead of three guessed keys.
Live consequence: a node that has two providers of one bound provision
assigned (novox: acme-ca) resolves only once pinned — pin novox acme-ca novox public-acme.
Tests: go test -p 1 ./... with MESH_TEST_POSTGRES — every package passes except internal/broker's installer-template comparison, which fails on main too: it reads ../mesh-host/examples/foundation-first-node-nats.lock, behind the controller's current permissions (the live symptom of hq #251).
Not merged by ace: the rollout changes what novox's own plan needs (the pin above) — novox decides when.
A provider is a (node, module) pair (design 23), and the pin — the one way a
consumer names its provider — named only the node. Two modules on one node
can both answer a provision (public-acme and step-ca both offer acme-ca on
novox), and then the resolver, given a pin naming that node, took the last
provider listed: a coin flip. The same ambiguity beside the consumer was
settled by a map walk — random per plan — which is how novox's own
route-proxy got its issuer (novox/hq #258).
- `pin <node> <provision> <from-node> <module>`: both halves, always. The
console gains `pin` and `unpin`. The provider may be on the consumer's own
node, since two modules beside it can both answer.
- The resolver refuses ambiguity instead of picking, across machines and
beside the consumer alike, naming every candidate as node/module and the
form of the pin that settles it. A plain capability that grants nothing
and serves nothing (three shells beside an editor) is not a choice to put
to anybody and stays as it was.
- provision_pin gains a nullable module (0050); records made before are
completed where the node they name answers once, and left for a person
where it answers twice (0051).
- The provider of something already satisfied is looked for among what was
assigned, not only what the walk has reached — a consumer reached before
the provider beside it no longer loses its binding.
- The start-time check that every declared verb is runnable samples each
verb's required arguments from its schema instead of three guessed keys.
Live consequence: a node that has two providers of one bound provision
assigned (novox: acme-ca) resolves only once pinned —
`pin novox acme-ca novox public-acme`.
Tests: `go test -p 1 ./...` with MESH_TEST_POSTGRES — every package passes except internal/broker's installer-template comparison, which fails on main too: it reads `../mesh-host/examples/foundation-first-node-nats.lock`, behind the controller's current permissions (the live symptom of hq #251).
**Not merged by ace**: the rollout changes what novox's own plan needs (the pin above) — novox decides when.
A provider is a (node, module) pair (design 23), and the pin — the one way a
consumer names its provider — named only the node. Two modules on one node
can both answer a provision (public-acme and step-ca both offer acme-ca on
novox), and then the resolver, given a pin naming that node, took the last
provider listed: a coin flip. The same ambiguity beside the consumer was
settled by a map walk — random per plan — which is how novox's own
route-proxy got its issuer (novox/hq #258).
- `pin <node> <provision> <from-node> <module>`: both halves, always. The
console gains `pin` and `unpin`. The provider may be on the consumer's own
node, since two modules beside it can both answer.
- The resolver refuses ambiguity instead of picking, across machines and
beside the consumer alike, naming every candidate as node/module and the
form of the pin that settles it. A plain capability that grants nothing
and serves nothing (three shells beside an editor) is not a choice to put
to anybody and stays as it was.
- provision_pin gains a nullable module (0050); records made before are
completed where the node they name answers once, and left for a person
where it answers twice (0051).
- The provider of something already satisfied is looked for among what was
assigned, not only what the walk has reached — a consumer reached before
the provider beside it no longer loses its binding.
- The start-time check that every declared verb is runnable samples each
verb's required arguments from its schema instead of three guessed keys.
Live consequence: a node that has two providers of one bound provision
assigned (novox: acme-ca) resolves only once pinned —
`pin novox acme-ca novox public-acme`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
A provider is a (node, module) pair (design 23), and the pin — the one way a
consumer names its provider — named only the node. Two modules on one node
can both answer a provision (public-acme and step-ca both offer acme-ca on
novox), and then the resolver, given a pin naming that node, took the last
provider listed: a coin flip. The same ambiguity beside the consumer was
settled by a map walk — random per plan — which is how novox's own
route-proxy got its issuer (novox/hq #258).
pin <node> <provision> <from-node> <module>: both halves, always. Theconsole gains
pinandunpin. The provider may be on the consumer's ownnode, since two modules beside it can both answer.
beside the consumer alike, naming every candidate as node/module and the
form of the pin that settles it. A plain capability that grants nothing
and serves nothing (three shells beside an editor) is not a choice to put
to anybody and stays as it was.
completed where the node they name answers once, and left for a person
where it answers twice (0051).
assigned, not only what the walk has reached — a consumer reached before
the provider beside it no longer loses its binding.
verb's required arguments from its schema instead of three guessed keys.
Live consequence: a node that has two providers of one bound provision
assigned (novox: acme-ca) resolves only once pinned —
pin novox acme-ca novox public-acme.Tests:
go test -p 1 ./...with MESH_TEST_POSTGRES — every package passes except internal/broker's installer-template comparison, which fails on main too: it reads../mesh-host/examples/foundation-first-node-nats.lock, behind the controller's current permissions (the live symptom of hq #251).Not merged by ace: the rollout changes what novox's own plan needs (the pin above) — novox decides when.