-
Notifications
You must be signed in to change notification settings - Fork 97
Update the docker-compose deployment .env.sample default configuration #6667
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
📝 Walkthrough📝 Walkthrough📝 WalkthroughWalkthroughThe pull request modifies the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (1)
deploy/compose/README.md (1)
Line range hint
1-100
: Document the HOPRD_API_PORT for metricspusherThe
docker-compose.yml
introduces a new environment variableHOPRD_API_PORT
for the metricspusher service, but this change isn't reflected in the README. Consider adding this information to the metrics-push profile section.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
deploy/compose/README.md
(1 hunks)deploy/compose/docker-compose.yml
(1 hunks)
🔇 Additional comments (3)
deploy/compose/README.md (1)
33-33
:
Verify compatibility with OpenTelemetry settings
The README introduces Jaeger tracing support, but the .env.sample
file disables OpenTelemetry (HOPRD_USE_OPENTELEMETRY=false
). Please clarify:
- Is OpenTelemetry required for Jaeger tracing to work?
- If yes, should we document that users need to enable it?
- If no, how does Jaeger tracing work without OpenTelemetry?
deploy/compose/docker-compose.yml (2)
145-146
: Ensure documentation is updated
Since this change is part of a configuration update, ensure the documentation reflects the new environment variable requirements.
✅ Verification successful
Documentation is up-to-date with the environment variable
The environment variable HOPRD_API_PORT
is already well-documented:
- In the root
README.md
: Documents the API port configuration - In
deploy/compose/README.md
: Specifies the default value (3001) and usage
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if documentation mentions HOPRD_API_PORT
# Look for documentation files
fd -e md -e rst . | xargs rg "HOPRD_API_PORT|metricspusher"
# Check if there's a README in the deploy directory
cat deploy/README.md 2>/dev/null || echo "No README found in deploy directory"
Length of output: 430
145-146
: Consider impact of telemetry configuration changes
The addition of HOPRD_API_PORT
aligns with metrics pushing, but since HOPRD_USE_OPENTELEMETRY
is being set to false (per .env.sample changes), verify that metrics collection still works as expected.
✅ Verification successful
Metrics collection is independent of OpenTelemetry configuration
The metrics collection system is separate from OpenTelemetry and will continue to work. The evidence shows:
- Metrics collection is handled by dedicated containers (cadvisor, nodeexporter, metricspusher) under separate profiles ('metrics', 'metrics-vis', 'metrics-push')
- The HOPRD_API_PORT is used by metricspusher container independently of HOPRD_USE_OPENTELEMETRY
- OpenTelemetry configuration (HOPRD_USE_OPENTELEMETRY) is only used for tracing/logging and doesn't affect the metrics infrastructure
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for dependencies between OpenTelemetry and metrics collection
# Look for any conditional logic based on HOPRD_USE_OPENTELEMETRY
rg "HOPRD_USE_OPENTELEMETRY" --type yaml --type sh
# Check if metrics endpoints are dependent on OpenTelemetry
rg "metrics.*endpoint" --type yaml --type sh
Length of output: 192
Script:
#!/bin/bash
# Let's check for any metrics-related configuration and usage
# Check for metrics-related environment variables in docker-compose
rg "HOPRD.*METRICS|METRICS.*PORT" --type yaml
# Look for metrics configuration in environment files
fd ".env" --exec cat {}
# Search for any metrics setup or collection logic
rg "metrics" -i --type yaml --type sh -A 3 -B 3
Length of output: 150925
Script:
#!/bin/bash
# Let's check for metrics and telemetry configuration in environment files and docker compose
# Check for metrics and telemetry related variables in environment files
fd -e env -e env.sample -e env.example --exec cat {}
# Look for metrics and telemetry configuration in docker-compose
rg "HOPRD_API_PORT|HOPRD_USE_OPENTELEMETRY|metrics" -i --type yaml -A 2 -B 2 deploy/compose/docker-compose.yml
Length of output: 1824
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
deploy/compose/prometheus/metricspusher.sh (1)
9-10
: Consider adding health checksThe script might benefit from initial health checks before entering the main loop.
Consider adding a health check function:
#!/bin/sh +check_hoprd_health() { + for i in $(seq 1 30); do + if curl -s -f -H "X-Auth-Token: ${HOPRD_API_TOKEN}" "http://hoprd:${HOPRD_API_PORT}/api/v3/node/status" > /dev/null; then + return 0 + fi + echo "Waiting for Hoprd API to be ready... (attempt ${i}/30)" + sleep 2 + done + echo "Error: Hoprd API failed to become ready" + return 1 +} + +# Wait for Hoprd to be ready +if ! check_hoprd_health; then + exit 1 +fi + METRICS_PUSH_URL=${1}
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
deploy/compose/prometheus/metricspusher.sh
(1 hunks)
🔇 Additional comments (1)
deploy/compose/prometheus/metricspusher.sh (1)
9-10
: Verify the Hoprd API endpoint configuration
The script now uses a dynamic port for the Hoprd API. Let's verify this aligns with the Docker Compose configuration.
✅ Verification successful
The Hoprd API endpoint configuration is properly aligned
The verification confirms that:
- The
HOPRD_API_PORT
is correctly configured with a default value of 3001 in.env.sample
- The docker-compose.yml properly maps the container's internal port 3001 to the configurable
HOPRD_API_PORT
- The metricspusher script correctly uses this dynamic port configuration
- All related configurations (prometheus, grafana) are consistent with this setup
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if HOPRD_API_PORT is properly configured in docker-compose and .env files
# Check docker-compose files for HOPRD_API_PORT configuration
echo "Checking docker-compose files for HOPRD_API_PORT:"
rg -l "HOPRD_API_PORT" deploy/compose/
# Check .env files for HOPRD_API_PORT default value
echo -e "\nChecking .env files for HOPRD_API_PORT:"
rg "HOPRD_API_PORT" deploy/compose/.env*
Length of output: 473
Script:
#!/bin/bash
# Check docker-compose configuration for hoprd service and port mapping
echo "Checking docker-compose.yml for hoprd service configuration:"
cat deploy/compose/docker-compose.yml | grep -A 10 "hoprd:"
# Check if the port is properly exposed in the compose file
echo -e "\nChecking port exposures in docker-compose.yml:"
rg "3001:" deploy/compose/docker-compose.yml
# Check if there are any other references to the API port
echo -e "\nChecking other references to port 3001:"
rg "3001" deploy/compose/
Length of output: 1385
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
deploy/compose/prometheus/metricspusher.sh (2)
Line range hint
1-8
: Remove duplicate content at the beginning and end of the fileThe file appears to have duplicate content from a merge or diff application issue. The first few lines and the last line should be removed as they're duplicated by the new content.
Apply this diff to fix the duplication:
-#!/bin/sh - - -METRICS_PUSH_URL=${1} - -# Run the loop -while true; do - echo Publishing metrics ... sleep 15 doneAlso applies to: 43-43
31-41
: Consider enhancing error logging with timestampsWhile the error handling is well implemented, adding timestamps to the log messages would help with debugging and monitoring.
Apply this diff to enhance the logging:
- echo "Error: Failed to fetch metrics from Hoprd API" + echo "$(date -u '+%Y-%m-%d %H:%M:%S UTC') Error: Failed to fetch metrics from Hoprd API" - echo "Error: Failed to push metrics to ${METRICS_PUSH_URL}" + echo "$(date -u '+%Y-%m-%d %H:%M:%S UTC') Error: Failed to push metrics to ${METRICS_PUSH_URL}"
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
deploy/compose/prometheus/metricspusher.sh
(1 hunks)
🔇 Additional comments (2)
deploy/compose/prometheus/metricspusher.sh (2)
11-26
: LGTM! Environment variable validation is well implemented
The validation of required environment variables is properly implemented with clear error messages and appropriate exit codes.
32-32
: Verify the timeout values are sufficient
The script uses 10-second timeouts for both API calls. Let's verify these timeouts align with typical response times.
Also applies to: 39-39
✅ Verification successful
10-second timeout for metrics API calls is appropriate
The current timeout values are well-aligned with typical metrics collection practices:
- The 10-second timeout for fetching metrics from the Hoprd API is reasonable as metrics endpoints typically respond quickly
- The script has a built-in retry mechanism with 5-second backoff for failed fetches
- The 15-second interval between collections provides adequate buffer for the operations
- The timeout matches common practices seen in the OpenTelemetry metrics configurations in the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any configuration or documentation about timeout values
# Look for timeout-related configuration in compose files
echo "Checking compose files for timeout configuration:"
fd -e yml -e yaml . deploy/compose/ --exec grep -l "timeout"
# Look for timeout documentation
echo "Checking documentation for timeout information:"
fd -e md . --exec grep -l "timeout"
Length of output: 2832
Script:
#!/bin/bash
# Let's check the actual usage of metrics API in the codebase and any related timeout configurations
# Check the metrics pusher script for context
echo "Checking metrics pusher script:"
cat deploy/compose/prometheus/metricspusher.sh
# Search for any metrics-related API calls or configurations
echo -e "\nSearching for metrics API usage:"
rg -l "metrics" --type sh
# Look for any HTTP client timeout configurations in the codebase
echo -e "\nSearching for timeout configurations:"
rg -i "timeout.*metrics|metrics.*timeout"
Length of output: 67030
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (2)
deploy/compose/prometheus/metricspusher.sh (2)
15-18
: Consider enhancing the error message with usage information.While the validation is correct, the error message could be more helpful by including usage information.
if [ -z "${METRICS_PUSH_URL}" ]; then - echo "Error: METRICS_PUSH_URL argument is required" + echo "Error: METRICS_PUSH_URL argument is required" + echo "Usage: $0 <metrics_push_url>" exit 1 fi
23-33
: Consider enhancing the error handling and configuration.While the current implementation is good, here are some suggested improvements:
- Make timeouts configurable via environment variables
- Add retry mechanism for failed pushes
- Make sleep intervals configurable
#!/bin/sh +# Default configuration +CURL_TIMEOUT=${CURL_TIMEOUT:-10} +RETRY_INTERVAL=${RETRY_INTERVAL:-5} +PUSH_INTERVAL=${PUSH_INTERVAL:-15} +MAX_RETRIES=${MAX_RETRIES:-3} # Validate required environment variables if [ -z "${HOPRD_API_TOKEN}" ]; then echo "Error: HOPRD_API_TOKEN is not set" exit 1 fi # Run the loop while true; do echo Publishing metrics ... # Add timeout and retry with backoff - if ! metrics=$(curl -s --max-time 10 -H "X-Auth-Token: ${HOPRD_API_TOKEN}" "http://hoprd:${HOPRD_API_PORT}/api/v3/node/metrics"); then - echo "Error: Failed to fetch metrics from Hoprd API" - sleep 5 - continue + retries=0 + while [ $retries -lt $MAX_RETRIES ]; do + if metrics=$(curl -s --max-time "$CURL_TIMEOUT" -H "X-Auth-Token: ${HOPRD_API_TOKEN}" "http://hoprd:${HOPRD_API_PORT}/api/v3/node/metrics"); then + break + fi + retries=$((retries + 1)) + echo "Error: Failed to fetch metrics from Hoprd API (attempt $retries/$MAX_RETRIES)" + [ $retries -lt $MAX_RETRIES ] && sleep "$RETRY_INTERVAL" + done + + if [ $retries -eq $MAX_RETRIES ]; then + echo "Error: Failed to fetch metrics after $MAX_RETRIES attempts" + sleep "$PUSH_INTERVAL" + continue fi # Push metrics with timeout - if ! echo "${metrics}" | curl -s --max-time 10 --data-binary @- "${METRICS_PUSH_URL}"; then - echo "Error: Failed to push metrics to ${METRICS_PUSH_URL}" + retries=0 + while [ $retries -lt $MAX_RETRIES ]; do + if echo "${metrics}" | curl -s --max-time "$CURL_TIMEOUT" --data-binary @- "${METRICS_PUSH_URL}"; then + break + fi + retries=$((retries + 1)) + echo "Error: Failed to push metrics to ${METRICS_PUSH_URL} (attempt $retries/$MAX_RETRIES)" + [ $retries -lt $MAX_RETRIES ] && sleep "$RETRY_INTERVAL" + done + + if [ $retries -eq $MAX_RETRIES ]; then + echo "Error: Failed to push metrics after $MAX_RETRIES attempts" fi - sleep 15 + sleep "$PUSH_INTERVAL" done
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
deploy/compose/prometheus/metricspusher.sh
(1 hunks)
🔇 Additional comments (1)
deploy/compose/prometheus/metricspusher.sh (1)
3-12
: LGTM! Environment variable validation is well implemented.
The validation checks for required environment variables are properly implemented with clear error messages and appropriate exit codes.
No description provided.