Conversation
WalkthroughThe PR adds a complete Helm chart for the Hydra node extension, including chart metadata, comprehensive documentation, default values configuration, template helpers, Kubernetes resource manifests (ConfigMaps, Secrets, Services, ServiceAccount, StatefulSet), test configuration files for different deployment scenarios, and CI workflow integration with local deployment automation. Changes
Sequence DiagramsequenceDiagram
participant User
participant SetupScript as setup.sh
participant Kind as Kind Cluster
participant Helm as Helm
participant K8s as Kubernetes API
User->>SetupScript: Execute setup.sh
SetupScript->>Kind: Create cluster "supernode"
Kind-->>SetupScript: Cluster ready
SetupScript->>K8s: Create hydra namespace
SetupScript->>K8s: Create hydra-signing secret
SetupScript->>K8s: Create hydra-verification ConfigMap
SetupScript->>Helm: Install control-plane Helm release
Helm->>K8s: Deploy control-plane components
K8s-->>Helm: Deployment complete
SetupScript->>Helm: Deploy hydra release<br/>(ref: signing secret, verification ConfigMap)
Helm->>K8s: Create ConfigMaps (ledger, verification)
Helm->>K8s: Create Secrets (signing keys)
Helm->>K8s: Create Services (API, P2P, monitoring)
Helm->>K8s: Create StatefulSet<br/>(offline/online mode)
K8s-->>Helm: StatefulSet initialized
Helm-->>SetupScript: Release deployed
SetupScript-->>User: Setup complete
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Key areas requiring extra attention:
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
extensions/setup.sh (1)
19-36: Helm install/upgrade pattern is correct but consider error handling.The script correctly creates namespace, secret, and configmap before Helm install, then upgrades with the same values. Both operations reference the same existing resources, which maintains idempotency.
For robustness in CI/CD environments, consider adding
set -eat the beginning to exit on first error.extensions/hydra-node/templates/statefulset.yaml (1)
258-258: Use{{-for consistent whitespace control.Line 258 uses
{{ ifwhich may introduce extra whitespace. For consistency with the rest of the template, use{{- ifto trim leading whitespace.Apply this diff:
- {{ if $cardanoSocketProxyEnabled }} + {{- if $cardanoSocketProxyEnabled }}
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (22)
.github/workflows/check_extensions.yml(1 hunks)extensions/README.md(1 hunks)extensions/hydra-node/Chart.yaml(1 hunks)extensions/hydra-node/README.md(1 hunks)extensions/hydra-node/ci/values-offline-existing.yaml(1 hunks)extensions/hydra-node/ci/values-offline-inline.yaml(1 hunks)extensions/hydra-node/ci/values-online-inline.yaml(1 hunks)extensions/hydra-node/templates/_helpers.tpl(1 hunks)extensions/hydra-node/templates/configmap-cardano-verification.yaml(1 hunks)extensions/hydra-node/templates/configmap-hydra-verification.yaml(1 hunks)extensions/hydra-node/templates/configmap-initial-utxo.yaml(1 hunks)extensions/hydra-node/templates/configmap-protocol-parameters.yaml(1 hunks)extensions/hydra-node/templates/secret-cardano-signing.yaml(1 hunks)extensions/hydra-node/templates/secret-hydra-signing.yaml(1 hunks)extensions/hydra-node/templates/service-headless.yaml(1 hunks)extensions/hydra-node/templates/service.yaml(1 hunks)extensions/hydra-node/templates/serviceaccount.yaml(1 hunks)extensions/hydra-node/templates/statefulset.yaml(1 hunks)extensions/hydra-node/values.yaml(1 hunks)extensions/hydra.sk(1 hunks)extensions/hydra.vk(1 hunks)extensions/setup.sh(1 hunks)
🧰 Additional context used
🪛 LanguageTool
extensions/hydra-node/README.md
[grammar] ~30-~30: Ensure spelling is correct
Context: ...content before going live. - For online heads set keys.cardano.enabled=true and sup...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🪛 Shellcheck (0.11.0)
extensions/setup.sh
[error] 1-1: Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.
(SC2148)
🪛 YAMLlint (1.37.1)
extensions/hydra-node/templates/secret-hydra-signing.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
extensions/hydra-node/templates/configmap-initial-utxo.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
extensions/hydra-node/templates/configmap-protocol-parameters.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
extensions/hydra-node/templates/configmap-cardano-verification.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
extensions/hydra-node/templates/secret-cardano-signing.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
extensions/hydra-node/templates/statefulset.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
extensions/hydra-node/templates/service.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
extensions/hydra-node/templates/configmap-hydra-verification.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
extensions/hydra-node/templates/service-headless.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
extensions/hydra-node/templates/serviceaccount.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
🔇 Additional comments (23)
extensions/README.md (1)
7-7: Documentation update is clear and consistent.The addition accurately describes the Hydra node extension and aligns with the offline-first defaults mentioned throughout the PR.
extensions/hydra-node/ci/values-offline-inline.yaml (1)
1-9: CI configuration structure is well-organized.The placeholder values and nested structure are appropriate for offline-inline testing. The
hydra.vkfilename reference aligns with the static key files, and the multi-line syntax (|-) correctly handles text content.extensions/hydra-node/Chart.yaml (1)
1-10: Helm chart metadata is complete and follows best practices.The RC version tag appropriately signals this is a new chart, and all required fields are properly configured.
extensions/hydra-node/templates/service-headless.yaml (1)
1-25: Headless Service configuration is correct for StatefulSet deployment.The template properly sets
clusterIP: NonewithpublishNotReadyAddresses: true, which is the appropriate pattern for distributed systems like Hydra nodes. Port names and references align with expected service configuration.Please verify that the helper functions referenced here (
hydra-node.fullname,hydra-node.labels,hydra-node.selectorLabels) are defined in the_helpers.tpltemplate, and that all referenced.Values.service.*Portfields are present in thevalues.yamlfile. I can run a verification script if needed.extensions/hydra-node/templates/serviceaccount.yaml (1)
1-12: ServiceAccount template follows Helm best practices.The conditional creation pattern and optional annotations are correctly implemented. The helper references and value paths follow standard conventions.
Ensure the helper
hydra-node.serviceAccountNameis defined in_helpers.tpland that.Values.serviceAccount.{create, annotations}are present invalues.yaml.extensions/hydra-node/templates/configmap-hydra-verification.yaml (1)
1-21: ConfigMap template correctly implements conditional creation with validation.The logic properly validates item entries (filename + value present) and respects the bring-your-own-ConfigMap pattern via
existingConfigMap.name. Multi-line value indentation usingnindentis correctly applied.Verify that:
- The
hydra-node.hydraVerificationConfigMapNamehelper is defined in_helpers.tpl.Values.keys.hydraVerification.itemsand.Values.keys.hydraVerification.existingConfigMap.nameare present invalues.yaml- The CI test values (e.g.,
values-offline-inline.yaml) match the expected structureThis template's integration with downstream resources (StatefulSet, etc.) consuming this ConfigMap should be validated in testing.
extensions/hydra-node/ci/values-online-inline.yaml (1)
1-32: ✓ Online mode configuration looks good.Configuration values are properly structured and complete for online mode deployment with inline key material. The values align with the expected schema for the Hydra node Helm chart.
extensions/hydra-node/ci/values-offline-existing.yaml (1)
1-19: ✓ Offline existing mode configuration is correct.Configuration properly sets up resource references for reusing existing Kubernetes Secrets and ConfigMaps, enabling clean separation between infrastructure setup and Helm deployment.
extensions/hydra-node/templates/secret-hydra-signing.yaml (2)
2-2: Conditional logic is sound.The three-part condition correctly ensures the Secret is created only when: the name is derivable, no existing secret is referenced, and an inline signing value is provided. This pattern properly supports both inline and external secret modes.
1-12: All helper functions are properly defined.Verification confirms that all three helper functions referenced in the template exist in
extensions/hydra-node/templates/_helpers.tpl:
hydra-node.hydraSigningSecretName(line 90)hydra-node.hydraSigningSecretKey(line 103)hydra-node.labels(line 34)The template is correct as-is.
.github/workflows/check_extensions.yml (1)
48-56: ✓ CI workflow matrix entries are properly structured.The three new matrix entries for hydra-node (offline-inline, offline-existing, online-inline) follow the established pattern and will exercise different deployment configurations in the CI pipeline. All required value files are present and correctly referenced.
extensions/hydra-node/templates/configmap-cardano-verification.yaml (1)
1-12: ✓ Template follows consistent patterns with sound conditional logic.The ConfigMap template correctly implements the same conditional pattern as the signing secret template—creating a resource only when inline values are provided and no existing resource is referenced. Default filename handling is appropriate and defensible.
extensions/hydra-node/templates/configmap-initial-utxo.yaml (1)
1-13: ✓ Initial UTXO ConfigMap template is well-structured.The use of an intermediate
$shouldCreatevariable improves readability of the complex condition. The template correctly supports both inline content and external ConfigMap reference modes. Indentation handling withnindentis correct.extensions/hydra-node/templates/configmap-protocol-parameters.yaml (1)
1-13: ✓ Protocol parameters ConfigMap template is consistent and correct.The template is structurally identical to the initial UTXO template, demonstrating good consistency across the template family. The conditional logic properly enforces inline-or-external mode selection.
extensions/hydra-node/templates/service.yaml (1)
1-53: LGTM! Well-structured Service template.The Service template follows Helm best practices with proper conditional rendering, dynamic port configuration, and integration with helper templates. The support for multiple service types (ClusterIP, NodePort, LoadBalancer) and extra ports provides good flexibility.
Note: The YAMLlint syntax error reported by static analysis is a false positive—the
{{-syntax is valid Helm template syntax.extensions/hydra-node/README.md (1)
1-206: LGTM! Comprehensive and well-organized documentation.The README provides excellent coverage of the Helm chart's capabilities, including:
- Clear feature descriptions
- Detailed prerequisites and key management guidance
- Practical examples for both offline and online modes
- Step-by-step local testing instructions with kind
- Comprehensive values reference
The documentation will help users successfully deploy and configure Hydra nodes.
Note: The LanguageTool hint about Line 30 is a false positive—"heads" is correct terminology in the Hydra protocol context.
extensions/hydra-node/templates/secret-cardano-signing.yaml (1)
1-12: LGTM! Proper conditional Secret creation.The Secret template correctly:
- Conditionally creates the Secret only when Cardano is enabled, no existing Secret is specified, and an inline value is provided
- Uses helper templates for consistent naming and key resolution
- Properly base64-encodes the secret value
Note: The YAMLlint syntax error is a false positive—Helm template syntax is expected here.
extensions/hydra-node/values.yaml (1)
1-168: LGTM! Well-structured and comprehensive values configuration.The values file provides sensible defaults for Hydra node deployment:
- Offline mode enabled by default for easy experimentation
- Reasonable resource limits (2 CPU, 1Gi memory)
- Standard port configuration (API: 4001, P2P: 5001, Monitoring: 6001)
- Flexible key management supporting both inline values and existing Kubernetes resources
- Demo protocol parameters and initial UTXO for quick starts
The configuration is comprehensive and aligns well with the documented features in the README.
extensions/hydra-node/templates/statefulset.yaml (3)
1-78: LGTM! Excellent validation and configuration setup.The variable setup and validation logic is robust:
- Enforces at least one Hydra verification key
- Validates online mode requirements (Cardano keys, socket path)
- Properly computes checksums for ConfigMaps to trigger pod restarts on config changes
- Comprehensive socket proxy configuration with proper path validation
The extensive validation prevents invalid configurations at deployment time, improving the user experience.
79-136: LGTM! Dynamic argument construction handles both offline and online modes well.The args building logic correctly:
- Constructs different argument sets for offline vs. online modes
- Uses proper path concatenation for mounted volumes
- Includes all required flags (API host/port, P2P host/port, monitoring port, etc.)
- Supports extra arguments for customization
The conditional logic ensures the right arguments are passed based on the deployment mode.
137-384: LGTM! Comprehensive StatefulSet definition.The StatefulSet template is well-structured with:
- Proper checksum annotations to trigger restarts on config changes
- Support for both offline and online modes with appropriate volumes and mounts
- Optional Cardano socket proxy sidecar with proper volume sharing
- Flexible persistence options (emptyDir, existing PVC, or dynamic PVC)
- Comprehensive probe, resource, and scheduling configuration
- Good use of projected volumes for key material
The template provides excellent flexibility while maintaining security through external key management.
Note: The YAMLlint syntax error is a false positive—Helm template syntax is expected here.
extensions/hydra-node/templates/_helpers.tpl (2)
1-63: LGTM! Standard Helm helper templates.The core helper templates follow Helm best practices:
- Name and fullname helpers with proper truncation and override support
- Chart version helper with safe character replacement
- Comprehensive labels including standard Kubernetes labels and custom extraLabels
- Selector labels with component specificity
- Service account name resolution with proper fallback to "default"
65-159: LGTM! Well-structured resource name resolution helpers.The resource name resolution helpers are well-designed:
- ConfigMap and Secret name helpers properly handle both inline creation and existing resource references
- Consistent naming patterns with chart fullname prefix
- Proper truncation and suffix trimming for Kubernetes name length limits
- Key resolution helpers handle both existing resource keys and default filenames
- Conditional logic prevents resource conflicts
These helpers enable flexible key and config management while maintaining consistency across the chart.
| { | ||
| "type": "HydraSigningKey_ed25519", | ||
| "description": "", | ||
| "cborHex": "5820e4c36e5403e6a02ef4821a34bb71d504916df0ddea476f797a5639110bc1bd52" | ||
| } |
There was a problem hiding this comment.
Document the signing key purpose and security implications.
The empty description field lacks context for this sensitive key material. The signing key should be clearly marked as test/demo-only in documentation or comments.
Consider improving the description:
- "description": "",
+ "description": "Hydra signing key for offline node testing (demo only)",Additionally, ensure the PR description or extension documentation (extensions/hydra-node/README.md) explicitly warns users about test key exposure.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| { | |
| "type": "HydraSigningKey_ed25519", | |
| "description": "", | |
| "cborHex": "5820e4c36e5403e6a02ef4821a34bb71d504916df0ddea476f797a5639110bc1bd52" | |
| } | |
| { | |
| "type": "HydraSigningKey_ed25519", | |
| "description": "Hydra signing key for offline node testing (demo only)", | |
| "cborHex": "5820e4c36e5403e6a02ef4821a34bb71d504916df0ddea476f797a5639110bc1bd52" | |
| } |
🤖 Prompt for AI Agents
In extensions/hydra.sk around lines 1 to 5, the signing key JSON has an empty
description which fails to document its purpose and security implications;
update the "description" field to explicitly state this is a test/demo-only
signing key, not for production, and include brief guidance about not using or
distributing it, then add a corresponding warning in the PR description and in
extensions/hydra-node/README.md (or the extension docs) that clearly warns users
about test key exposure and instructs how to replace with a secure production
key.
| { | ||
| "type": "HydraVerificationKey_ed25519", | ||
| "description": "", | ||
| "cborHex": "5820b37aabd81024c043f53a069c91e51a5b52e4ea399ae17ee1fe3cb9c44db707eb" | ||
| } |
There was a problem hiding this comment.
Clarify the purpose and source of the verification key.
The empty description field should ideally document what this verification key is used for or how it was generated. Additionally, storing cryptographic key material in the repository (even for offline/test deployments) should be clearly documented for security awareness.
Consider adding a description like:
- "description": "",
+ "description": "Hydra verification key for offline node testing",📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| { | |
| "type": "HydraVerificationKey_ed25519", | |
| "description": "", | |
| "cborHex": "5820b37aabd81024c043f53a069c91e51a5b52e4ea399ae17ee1fe3cb9c44db707eb" | |
| } | |
| { | |
| "type": "HydraVerificationKey_ed25519", | |
| "description": "Hydra verification key for offline node testing", | |
| "cborHex": "5820b37aabd81024c043f53a069c91e51a5b52e4ea399ae17ee1fe3cb9c44db707eb" | |
| } |
🤖 Prompt for AI Agents
In extensions/hydra.vk around lines 1 to 5, the JSON has an empty description
and no context for the verification key; update the description to state the
key's purpose, origin, generation method, and intended environment (e.g., "Hydra
testnet verification key generated via ed25519 for local/integration testing; do
NOT use in production"), and add a short comment in the repo README or a
SECURITY.md referencing why this key is checked in, its risk, and instructions
for replacing it with secure keys for production deployments.
| # Create K8s cluster | ||
| kind create cluster --name supernode | ||
| kubectl config use-context kind-supernode |
There was a problem hiding this comment.
Add shebang directive for shell script execution.
Shell scripts should start with a shebang to enable direct execution and ensure the correct interpreter is used.
Apply this diff to add the shebang:
+#!/bin/bash
+
# Create K8s cluster
kind create cluster --name supernode
kubectl config use-context kind-supernode📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Create K8s cluster | |
| kind create cluster --name supernode | |
| kubectl config use-context kind-supernode | |
| #!/bin/bash | |
| # Create K8s cluster | |
| kind create cluster --name supernode | |
| kubectl config use-context kind-supernode |
🧰 Tools
🪛 Shellcheck (0.11.0)
[error] 1-1: Tips depend on target shell and yours is unknown. Add a shebang or a 'shell' directive.
(SC2148)
🤖 Prompt for AI Agents
In extensions/setup.sh lines 1-3, the script is missing a shebang; add a bash
shebang as the very first line (use an env-based shebang to locate bash) so the
script can be executed directly and uses the correct shell interpreter, then
keep the existing cluster creation and kubectl lines unchanged.
1 participant
Summary by CodeRabbit
New Features
Documentation
Tests