chore(testnet): split tx-generator into its own feature testnet#111
Draft
chore(testnet): split tx-generator into its own feature testnet#111
Conversation
Mirrors 43bf739 (chore(testnet): remove adversary service from cardano_node_master) — same shape, different component. The master testnet is the canonical reference cluster: cron-fired Antithesis runs against it produce the baseline-finding signal that everyone reads. With tx-generator in active iteration (reconnect supervisor #105, freshness gate #110, composer-assertion shape work in #98), keeping it on master pollutes that signal with experiments in flight. This commit: * Creates testnets/cardano_node_tx_generator/ — same topology as master (3 producers + 2 relays + tracer + sidecars + log-tailer) plus the tx-generator service. Asteria-stub is deliberately absent (different feature, lives on master). * Removes tx-generator from testnets/cardano_node_master/ along with its 'utxo-keys' volume mount on configurator and the volume declaration. Nothing else on master uses utxo-keys. * README in the new testnet documents why and how to dispatch. Workflow dispatch from this point: gh workflow run cardano-node.yaml \ --ref <feature-branch> \ -f test=cardano_node_tx_generator \ -f duration=1 publish-images currently only scrapes cardano_node_master's compose; the new testnet's tx-generator image is pushed manually until the publish-images script is generalised to all testnets (follow-up).
|
🚀 Documentation preview Preview: https://cf-cna-pr-111.surge.sh Built from |
After PR #111 dropped tx-generator from cardano_node_master/, the 'Compose smoke test' job that runs scripts/smoke-test.sh against master fails because the script unconditionally probes the tx-generator control socket — which is only present on the new cardano_node_tx_generator/ testnet now. Skip the tx-generator-specific block when the compose under test doesn't declare a 'tx-generator:' service. Same script keeps working for both master (no tx-generator) and the new feature testnet (still drives the daemon end-to-end).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Same shape as 43bf739 (adversary removal from master): the master testnet is the canonical reference cluster, and components in active iteration belong on a feature-testnet so master's signal stays clean.
Why
tx-generatoris being iterated on across:Each of those changes wants its own pre-merge Antithesis dispatch via
--ref <branch>to compare findings before re-merging — a workflow that's much smoother on a dedicated testnet than on master.What
testnets/cardano_node_tx_generator/— clone of master's topology (3 producers, 2 relays, tracer + sidecars + log-tailer) plus thetx-generatorservice. Asteria-stub deliberately excluded (different feature, stays on master).tx-generatorservice entirely, theutxo-keysvolume mount on configurator (onlytx-generatorconsumed it), and theutxo-keysvolume declaration.Workflow
Dispatch the new testnet via
cardano-node.yaml's existingtestinput:```sh
gh workflow run cardano-node.yaml \
--ref \
-f test=cardano_node_tx_generator \
-f duration=1
```
The cron's default stays
cardano_node_master; nothing on the schedule changes.Out of scope (follow-ups)
scripts/push-cardano_node_master_images.shis hard-coded to one testnet directory. Until it's generalised, thetx-generatorimage referenced by the new testnet's compose continues to be pushed manually (nix build .#docker-image→docker tag→docker push). Same friction as today on the bump branch.testnets/cardano_node_tx_generator/docker-compose.yamlinstead.Verification
tx-generatorblock +utxo-keysmounts/declaration come out.Related