-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Only load needed part of configuration #2109
Conversation
Currently all configuration was loaded and validated regardless of what the CLI was doing, if you did a `nodes ls` or `serve` the whole thing would be loaded and validated which caused a machine that were doing only CLI stuff to need the full config, or at least a bunch that would throw errors. This commit cleans up and splits this so that only the subset needed for running the CLI (unix socket or remote gRPC) is required when running all commands except for `serve`. When `serve` is ran, the normal chain with validations and loading of the whole config is ran. This means that deprecation warnings for the server config will only be shown in the server log. Signed-off-by: Kristoffer Dalby <[email protected]>
This change makes headscale only check for updates when a user runs the CLI, not when the server is started. Signed-off-by: Kristoffer Dalby <[email protected]>
WalkthroughThe changes involve significant modifications to the Headscale application's CLI client instantiation, configuration management, and testing framework. Key updates include the introduction of new functions for client creation, the removal of deprecated functions, and enhancements to how configurations are loaded. Additionally, the test suite has been refined to improve clarity and validation of TLS configurations, reflecting a comprehensive restructuring of both the application logic and its testing processes. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CLI
participant ConfigManager
participant Service
User->>CLI: Execute Command
CLI->>ConfigManager: Load Configuration
ConfigManager-->>CLI: Return Config
CLI->>Service: Create Client with Config
Service-->>CLI: Return Client
CLI->>User: Command Result
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
|
Signed-off-by: Kristoffer Dalby <[email protected]>
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, codebase verification and nitpick comments (3)
cmd/headscale/cli/utils.go (1)
Line range hint
26-33
: Refactor approved but consider enhancing error handling.The renaming and refactoring of
newHeadscaleServerWithConfig
improve clarity and functionality. However, consider adding more detailed error logging for each step of the configuration and server initialisation process to aid in debugging and maintenance.cmd/headscale/cli/users.go (1)
Line range hint
47-62
: Integration of new CLI configuration function approved.The use of
newHeadscaleCLIWithConfig
increateUserCmd
is correctly implemented. Consider enhancing the error message to include more context about the failure, which could aid users in troubleshooting.cmd/headscale/cli/api_key.go (1)
Line range hint
57-88
: Integration of new CLI configuration function approved.The use of
newHeadscaleCLIWithConfig
inlistAPIKeys
is correctly implemented. Consider enhancing the error message to include more context about the failure, which could aid users in troubleshooting.
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (16)
- .gitignore (1 hunks)
- CHANGELOG.md (1 hunks)
- cmd/headscale/cli/api_key.go (4 hunks)
- cmd/headscale/cli/configtest.go (1 hunks)
- cmd/headscale/cli/debug.go (1 hunks)
- cmd/headscale/cli/nodes.go (8 hunks)
- cmd/headscale/cli/policy.go (2 hunks)
- cmd/headscale/cli/preauthkeys.go (3 hunks)
- cmd/headscale/cli/root.go (3 hunks)
- cmd/headscale/cli/routes.go (4 hunks)
- cmd/headscale/cli/serve.go (1 hunks)
- cmd/headscale/cli/users.go (4 hunks)
- cmd/headscale/cli/utils.go (2 hunks)
- cmd/headscale/headscale_test.go (2 hunks)
- hscontrol/types/config.go (21 hunks)
- hscontrol/types/config_test.go (10 hunks)
Files skipped from review due to trivial changes (2)
- .gitignore
- CHANGELOG.md
Additional comments not posted (33)
cmd/headscale/cli/configtest.go (1)
17-17
: Refactor to usenewHeadscaleServerWithConfig()
is appropriate.The change to use
newHeadscaleServerWithConfig()
aligns with the PR's objective to load only the necessary parts of the configuration. This should make the configuration testing more efficient and relevant to the actual server setup.Verification successful
Refactor to use
newHeadscaleServerWithConfig()
is appropriate. The functionnewHeadscaleServerWithConfig()
is correctly implemented in the codebase, confirming the validity of the refactoring mentioned in the review comment.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of `newHeadscaleServerWithConfig()`. # Test: Search for the implementation of `newHeadscaleServerWithConfig()`. Expect: Proper implementation details. ast-grep --lang go --pattern $'func newHeadscaleServerWithConfig($_, $_) { $$$ }'Length of output: 84
Script:
#!/bin/bash # Description: Verify the implementation of `newHeadscaleServerWithConfig()` without assuming parameter count. # Test: Search for the implementation of `newHeadscaleServerWithConfig()`. Expect: Proper implementation details. ast-grep --lang go --pattern $'func newHeadscaleServerWithConfig($$$) { $$$ }'Length of output: 81
Script:
#!/bin/bash # Description: Search for any function names containing "Headscale" to identify potential candidates. # Test: Use ripgrep to find any function names containing "Headscale". rg 'func .*Headscale.*\(' --glob '*.go' -A 2Length of output: 60161
cmd/headscale/cli/serve.go (1)
19-19
: Refactor to usenewHeadscaleServerWithConfig()
is appropriate forserve
command.Using
newHeadscaleServerWithConfig()
for theserve
command ensures that the full configuration is loaded, which is necessary for server operations. This change is consistent with the PR's goal to optimize configuration loading.Verification successful
Robust Error Handling in
serve
Command VerifiedThe
serve
command incmd/headscale/cli/serve.go
includes robust error handling usinglog.Fatal().Caller().Err(err).Msg(...)
for both initialization and server start errors. This confirms that the refactoring to usenewHeadscaleServerWithConfig()
is appropriate and consistent with the PR's goal to optimise configuration loading. The error handling ensures that any critical issues during server operations are logged and handled appropriately.
- File:
cmd/headscale/cli/serve.go
- Lines: Error handling is present for both initialization and server start.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the error handling and server behaviour after initialization. # Test: Search for error handling patterns in `serve` command. Expect: Robust error handling. rg --type go -A 5 $'log.Fatal().Caller().Err($_).Msg("Error initializing")'Length of output: 76
Script:
#!/bin/bash # Description: Search for common error handling patterns in the `serve` command implementation. # Test: Search for error handling using `log.Fatal` or `log.Error` in the `serve` command. rg --type go -A 5 'log\.Fatal\(' # Test: Search for error handling using `log.Error` in the `serve` command. rg --type go -A 5 'log\.Error\('Length of output: 40295
cmd/headscale/cli/policy.go (1)
33-33
: Refactor to usenewHeadscaleCLIWithConfig()
enhances client configuration flexibility.The change to use
newHeadscaleCLIWithConfig()
in bothgetPolicy
andsetPolicy
commands is a positive step towards more configurable client initialization. This aligns well with the PR's objectives to improve configuration handling.Also applies to: 78-78
Verification successful
Verified:
newHeadscaleCLIWithConfig()
enhances client configuration flexibility.The function
newHeadscaleCLIWithConfig()
is implemented incmd/headscale/cli/utils.go
and is used in bothgetPolicy
andsetPolicy
commands incmd/headscale/cli/policy.go
. This confirms the review comment's assertion that it enhances client configuration flexibility, aligning with the PR's objectives to improve configuration handling.
- Implementation found in
cmd/headscale/cli/utils.go
.- Usage confirmed in
cmd/headscale/cli/policy.go
.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation and usage of `newHeadscaleCLIWithConfig()`. # Test: Search for the implementation and usage of `newHeadscaleCLIWithConfig()`. Expect: Proper implementation and usage patterns. ast-grep --lang go --pattern $'func newHeadscaleCLIWithConfig($_, $_) { $$$ }'Length of output: 81
Script:
#!/bin/bash # Search for the implementation of `newHeadscaleCLIWithConfig` in the codebase. rg 'func newHeadscaleCLIWithConfig' -A 10 # Search for the usage of `newHeadscaleCLIWithConfig` in the `cmd/headscale/cli/policy.go` file. rg 'newHeadscaleCLIWithConfig' cmd/headscale/cli/policy.go -A 5Length of output: 1099
cmd/headscale/cli/root.go (1)
61-68
: Refactor to use viper for configuration retrieval is approved.The shift to using
viper
for configuration management simplifies the code and potentially enhances flexibility. However, ensure that the integration ofviper
with the existing system is thoroughly tested, especially in edge cases where configurations might be missing or malformed.Run the following script to verify the integration of
viper
:Verification successful
Integration of
viper
for configuration retrieval appears successful and well-tested.The extensive use of
viper.Get
across the codebase, along with its presence in test files, indicates a robust integration. Ensure that edge cases, such as missing or malformed configurations, are thoroughly tested to maintain system reliability.
- Ensure edge cases are covered in tests to maintain robustness.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the integration of `viper` with the existing system. # Test: Search for potential issues in the configuration retrieval. Expect: No errors or warnings. rg --type go -A 5 $'viper.Get'Length of output: 22458
cmd/headscale/cli/debug.go (1)
71-71
: Replacement of client instantiation function is approved.The change to use
newHeadscaleCLIWithConfig()
potentially offers more robust configuration options. However, verify that this new method integrates smoothly with the rest of the system and does not introduce regressions.Run the following script to verify the new function's implementation and its impact:
cmd/headscale/headscale_test.go (1)
Line range hint
1-1
: Concerns about the removal of TLS configuration validation tests.The removal of the
writeConfig
function and theTestTLSConfigValidation
test case could lead to gaps in testing TLS configurations. It is crucial to verify that the new testing strategy adequately covers these aspects.Run the following script to verify the new testing strategy:
cmd/headscale/cli/utils.go (1)
Line range hint
43-111
: Refactor approved with commendation for robust error handling.The changes to
newHeadscaleCLIWithConfig
not only align with the new configuration management strategy but also demonstrate good practices in error handling and logging. The detailed feedback provided to the user in case of configuration errors is particularly commendable.cmd/headscale/cli/users.go (3)
Line range hint
94-129
: Integration of new CLI configuration function approved.The use of
newHeadscaleCLIWithConfig
indestroyUserCmd
is correctly implemented and enhances the command's functionality with detailed prompts and robust error handling.
Line range hint
154-187
: Integration of new CLI configuration function approved.The use of
newHeadscaleCLIWithConfig
inlistUsersCmd
is correctly implemented. The output formatting is appropriately handled, enhancing the user experience by providing clear and structured information.
Line range hint
216-241
: Integration of new CLI configuration function approved.The use of
newHeadscaleCLIWithConfig
inrenameUserCmd
is correctly implemented. The error handling and output formatting are well-executed, providing clear feedback to the user.cmd/headscale/cli/api_key.go (3)
Line range hint
148-173
: Integration of new CLI configuration function approved.The use of
newHeadscaleCLIWithConfig
increateAPIKeyCmd
is correctly implemented and enhances the command's functionality with detailed prompts and robust error handling.
Line range hint
185-210
: Integration of new CLI configuration function approved.The use of
newHeadscaleCLIWithConfig
inexpireAPIKeyCmd
is correctly implemented. The output formatting is appropriately handled, enhancing the user experience by providing clear and structured information.
Line range hint
226-251
: Integration of new CLI configuration function approved.The use of
newHeadscaleCLIWithConfig
indeleteAPIKeyCmd
is correctly implemented. The error handling and output formatting are well-executed, providing clear feedback to the user.cmd/headscale/cli/preauthkeys.go (3)
67-67
: Verify the new client instantiation method.The replacement of
getHeadscaleCLIClient()
withnewHeadscaleCLIWithConfig()
in thelistPreAuthKeys
command handler is aligned with the PR's objectives. Please ensure that the new method correctly handles the configuration specifics and that it integrates seamlessly with the existing command functionality.
195-195
: Verify the new client instantiation method.The replacement of
getHeadscaleCLIClient()
withnewHeadscaleCLIWithConfig()
in thecreatePreAuthKeyCmd
command handler is aligned with the PR's objectives. Please ensure that the new method correctly handles the configuration specifics and that it integrates seamlessly with the existing command functionality.
234-234
: Verify the new client instantiation method.The replacement of
getHeadscaleCLIClient()
withnewHeadscaleCLIWithConfig()
in theexpirePreAuthKeyCmd
command handler is aligned with the PR's objectives. Please ensure that the new method correctly handles the configuration specifics and that it integrates seamlessly with the existing command functionality.cmd/headscale/cli/nodes.go (7)
123-123
: Verify the new client connection setup.The change to use
newHeadscaleCLIWithConfig()
inregisterNodeCmd
is significant. Please ensure that this function is thoroughly tested, particularly in how it handles configuration loading, error management, and resource cleanup.
182-182
: Verify the new client connection setup.The integration of
newHeadscaleCLIWithConfig()
inlistNodesCmd
should be carefully reviewed to ensure it handles client configurations and connections correctly, especially under different user scenarios and error conditions.
246-246
: Verify the new client connection setup.Ensure that
newHeadscaleCLIWithConfig()
is correctly implemented inexpireNodeCmd
. It's crucial that the function handles all necessary configurations and gracefully manages any errors that may occur during the connection setup.
289-289
: Verify the new client connection setup.The use of
newHeadscaleCLIWithConfig()
inrenameNodeCmd
needs thorough testing to confirm that it handles all aspects of client configuration and connection management effectively.
338-338
: Verify the new client connection setup.It is important to validate that
newHeadscaleCLIWithConfig()
indeleteNodeCmd
correctly manages client configurations and connections, particularly focusing on error scenarios and resource management.
438-438
: Verify the new client connection setup.Confirm that
newHeadscaleCLIWithConfig()
inmoveNodeCmd
is properly implemented, ensuring it handles all necessary configurations and gracefully manages any errors that may occur during the connection setup.
511-511
: Verify the new client connection setup.The integration of
newHeadscaleCLIWithConfig()
inbackfillNodeIPsCmd
should be carefully reviewed to ensure it handles client configurations and connections correctly, especially under different network scenarios and error conditions.cmd/headscale/cli/routes.go (4)
71-71
: Verify new client initialization function usage.Ensure that
newHeadscaleCLIWithConfig()
is correctly implemented and integrates well with the existing command logic. The placement ofdefer
statements for resource cleanup is appropriate.
157-157
: Verify new client initialization function usage.Ensure that
newHeadscaleCLIWithConfig()
is correctly implemented and integrates well with the existing command logic. The placement ofdefer
statements for resource cleanup is appropriate.
200-200
: Verify new client initialization function usage.Ensure that
newHeadscaleCLIWithConfig()
is correctly implemented and integrates well with the existing command logic. The placement ofdefer
statements for resource cleanup is appropriate.
243-243
: Verify new client initialization function usage.Ensure that
newHeadscaleCLIWithConfig()
is correctly implemented and integrates well with the existing command logic. The placement ofdefer
statements for resource cleanup is appropriate.hscontrol/types/config_test.go (2)
295-339
: Approve new test function for TLS configuration validation.The addition of
TestTLSConfigValidation
is a positive enhancement to the test suite, focusing on the robustness of TLS configuration settings. The implementation using temporary directories and file operations is appropriate for the intended testing scenarios.
27-27
: Verify function usage and consistency.The changes from
DNS()
todns()
and fromGetHeadscaleConfig()
toLoadServerConfig()
suggest a shift towards more encapsulated and descriptive function naming. Please ensure that these changes are consistent throughout the codebase and that the new functions maintain the intended functionality.Also applies to: 53-53, 84-84, 110-110, 141-141, 150-150, 170-170
Verification successful
Verification successful: Function usage is consistent.
The changes from
DNS()
todns()
and fromGetHeadscaleConfig()
toLoadServerConfig()
are consistent throughout the codebase. The functions are used appropriately, maintaining the intended encapsulation and functionality. No issues were found with these changes.
- The
dns()
function is used internally within the package as expected.- The
LoadServerConfig()
function is used to load server configurations consistently.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage of `dns()` and `LoadServerConfig()` across the codebase. # Test: Search for the function usage. Expect: Only occurrences of the new function names. rg --type go -A 5 $'dns()' rg --type go -A 5 $'LoadServerConfig()'Length of output: 38651
hscontrol/types/config.go (4)
Line range hint
215-298
: Approve enhancements toLoadConfig
function.The updates to the
LoadConfig
function, including detailed comments and the explicit statement about not validating the configuration, significantly enhance the clarity and documentation of the function. These changes help clarify the responsibilities and expected behaviour of the function.
Line range hint
300-371
: ApprovevalidateServerConfig
function implementation.The
validateServerConfig
function is well-implemented, effectively using thedeprecator
struct to manage deprecated configuration options. This approach ensures that the configuration is correct before the server starts and helps maintain backward compatibility.
Line range hint
374-462
: Approve renaming and encapsulation of configuration functions.The renaming of functions like
tlsConfig
,derpConfig
,logtailConfig
,policyConfig
,logConfig
,databaseConfig
, anddns
from public to private scope is a positive change, reflecting a shift towards better encapsulation. This change helps prevent misuse of these functions outside their intended scope and enhances the maintainability of the code.Also applies to: 472-500, 552-584
732-745
: Approve introduction ofLoadCLIConfig
andLoadServerConfig
functions.The introduction of
LoadCLIConfig
andLoadServerConfig
functions is a commendable change, enhancing clarity and maintainability by clearly separating the responsibilities for CLI and server configurations. This modular approach is beneficial for managing complex configurations in a large application.Also applies to: 747-889
Signed-off-by: Kristoffer Dalby <[email protected]>
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, codebase verification and nitpick comments (2)
cmd/headscale/cli/utils.go (2)
Line range hint
43-112
: Critical review of error handling and configuration loading innewHeadscaleCLIWithConfig
.The function
newHeadscaleCLIWithConfig
has several critical issues that need addressing:
- The use of
log.Fatal()
andos.Exit(-1)
within the function can be problematic. It's generally better to return errors and let the caller handle them, which improves the testability and reusability of the function.- The function handles different configurations based on the CLI environment, which is good. However, the error handling could be improved by not terminating the program directly within utility functions.
Consider refactoring to improve error handling:
- log.Fatal().Err(err).Caller().Msgf("Failed to load configuration") - os.Exit(-1) + return nil, nil, nil, nil, fmt.Errorf("failed to load configuration: %w", err)
Line range hint
133-158
: Refactor suggestion foroutput
function to enhance error handling.The
output
function now returns a string instead of printing directly, which is a good practice. However, the error handling within the switch-case can be improved. Instead of usinglog.Fatal()
, consider returning an error to the caller, which allows for more flexible error handling and better integration with other systems that might need to handle errors differently.Proposed refactor:
- log.Fatal().Err(err).Msg("failed to unmarshal output") + return "", fmt.Errorf("failed to unmarshal output: %w", err)
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (10)
- cmd/headscale/cli/api_key.go (10 hunks)
- cmd/headscale/cli/debug.go (6 hunks)
- cmd/headscale/cli/nodes.go (12 hunks)
- cmd/headscale/cli/policy.go (3 hunks)
- cmd/headscale/cli/preauthkeys.go (9 hunks)
- cmd/headscale/cli/root.go (3 hunks)
- cmd/headscale/cli/routes.go (11 hunks)
- cmd/headscale/cli/users.go (10 hunks)
- cmd/headscale/cli/utils.go (4 hunks)
- hscontrol/grpcv1.go (2 hunks)
Files skipped from review as they are similar to previous changes (6)
- cmd/headscale/cli/api_key.go
- cmd/headscale/cli/debug.go
- cmd/headscale/cli/policy.go
- cmd/headscale/cli/preauthkeys.go
- cmd/headscale/cli/root.go
- cmd/headscale/cli/routes.go
Additional comments not posted (11)
cmd/headscale/cli/users.go (4)
148-148
: Verify integration with configuration loading.The replacement of
getHeadscaleCLIClient()
withnewHeadscaleCLIWithConfig()
inlistUsersCmd
aligns with the PR's objective to optimise configuration loading. Please ensure that this integration is thoroughly tested, especially in scenarios where different configurations might affect the CLI's behaviour.Run the following script to verify the integration:
Verification successful
Integration of
newHeadscaleCLIWithConfig
verified across the codebase.The function
newHeadscaleCLIWithConfig
is consistently used across multiple files, indicating a successful integration with the configuration loading strategy. This confirms the correctness of the refactoring changes made in the PR.
- Files with usage:
debug.go
,users.go
,routes.go
,preauthkeys.go
,api_key.go
,policy.go
,nodes.go
.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the integration of `newHeadscaleCLIWithConfig` with the configuration loading. # Test: Search for the function usage. Expect: Only occurrences of the new signature. rg --type python -A 5 $'newHeadscaleCLIWithConfig'Length of output: 80
Script:
#!/bin/bash # Description: Verify the integration of `newHeadscaleCLIWithConfig` with the configuration loading. # Test: Search for the function usage in Go files. Expect: Only occurrences of the new signature. rg --type go -A 5 'newHeadscaleCLIWithConfig'Length of output: 9149
47-47
: Verify integration with configuration loading.The replacement of
getHeadscaleCLIClient()
withnewHeadscaleCLIWithConfig()
increateUserCmd
aligns with the PR's objective to optimise configuration loading. Please ensure that this integration is thoroughly tested, especially in scenarios where different configurations might affect the CLI's behaviour.Run the following script to verify the integration:
Verification successful
Integration of
newHeadscaleCLIWithConfig
is consistent and correct.The function
newHeadscaleCLIWithConfig
is consistently used across multiple CLI command files, indicating a successful integration with the configuration loading process. This aligns with the intended design to streamline configuration handling in the CLI.
- Files using
newHeadscaleCLIWithConfig
:
cmd/headscale/cli/users.go
cmd/headscale/cli/preauthkeys.go
cmd/headscale/cli/policy.go
cmd/headscale/cli/routes.go
cmd/headscale/cli/api_key.go
cmd/headscale/cli/debug.go
cmd/headscale/cli/nodes.go
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the integration of `newHeadscaleCLIWithConfig` with the configuration loading. # Test: Search for the function usage. Expect: Only occurrences of the new signature. rg --type python -A 5 $'newHeadscaleCLIWithConfig'Length of output: 80
Script:
#!/bin/bash # Description: Verify the integration of `newHeadscaleCLIWithConfig` with the configuration loading. # Test: Search for the function usage in Go files. Expect: Occurrences of the new signature. rg --type go -A 5 'newHeadscaleCLIWithConfig'Length of output: 9149
204-204
: Verify integration with configuration loading.The replacement of
getHeadscaleCLIClient()
withnewHeadscaleCLIWithConfig()
inrenameUserCmd
aligns with the PR's objective to optimise configuration loading. Please ensure that this integration is thoroughly tested, especially in scenarios where different configurations might affect the CLI's behaviour.Run the following script to verify the integration:
Verification successful
Integration of
newHeadscaleCLIWithConfig
is consistent and correct.The function
newHeadscaleCLIWithConfig
is consistently used across multiple CLI command files, indicating that the integration with configuration loading is correctly implemented. The pattern of usage aligns with the intended design, ensuring proper initialisation and resource management.
- Files using
newHeadscaleCLIWithConfig
:users.go
,routes.go
,preauthkeys.go
,policy.go
,debug.go
,nodes.go
,api_key.go
.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the integration of `newHeadscaleCLIWithConfig` with the configuration loading. # Test: Search for the function usage. Expect: Only occurrences of the new signature. rg --type python -A 5 $'newHeadscaleCLIWithConfig'Length of output: 80
Script:
#!/bin/bash # Description: Verify the integration of `newHeadscaleCLIWithConfig` with the configuration loading. # Test: Search for the function usage in Go files. Expect: Occurrences of the new signature. rg --type go -A 5 'newHeadscaleCLIWithConfig'Length of output: 9149
92-92
: Verify integration with configuration loading.The replacement of
getHeadscaleCLIClient()
withnewHeadscaleCLIWithConfig()
indestroyUserCmd
aligns with the PR's objective to optimise configuration loading. Please ensure that this integration is thoroughly tested, especially in scenarios where different configurations might affect the CLI's behaviour.Run the following script to verify the integration:
Verification successful
Integration of
newHeadscaleCLIWithConfig
is consistent and verified.The function
newHeadscaleCLIWithConfig
is consistently used across multiple files, includingusers.go
, with appropriate resource management. This confirms the successful integration of the new configuration loading strategy. No issues were found with the integration.
cmd/headscale/cli/utils.go
: Function definition.cmd/headscale/cli/users.go
: Multiple usages with proper resource management.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the integration of `newHeadscaleCLIWithConfig` with the configuration loading. # Test: Search for the function usage. Expect: Only occurrences of the new signature. rg --type python -A 5 $'newHeadscaleCLIWithConfig'Length of output: 80
Script:
#!/bin/bash # Description: Verify the integration of `newHeadscaleCLIWithConfig` with the configuration loading in Go files. # Test: Search for the function usage in Go files. Expect: Occurrences of the new signature. rg --type go -A 5 $'newHeadscaleCLIWithConfig'Length of output: 9149
hscontrol/grpcv1.go (4)
687-687
: Improved error handling in database access.The change to include a more descriptive error message when loading ACL from the database enhances clarity and debuggability. This is a good practice as it helps in identifying the exact failure point in the system.
699-699
: Enhanced error reporting for file access issues.Specifying the file path in the error message when an issue occurs while opening the policy file is a beneficial change. It aids in troubleshooting by pinpointing the location of the problem.
706-706
: Detailed error message for file reading failures.The addition of a detailed error message for failures during the reading of the policy file is a valuable improvement. It ensures that any issues encountered during this operation are clearly communicated, aiding in faster resolution.
712-712
: Explicit error handling for unsupported policy modes.The final error message for unsupported policy modes provides clear feedback about configuration issues, which is crucial for correct system setup and troubleshooting.
cmd/headscale/cli/utils.go (2)
Line range hint
26-34
: Refactor of configuration loading innewHeadscaleServerWithConfig
is well-implemented.The function
newHeadscaleServerWithConfig
correctly loads the server configuration usingtypes.LoadServerConfig()
. This change aligns with the PR's objective to load only the necessary parts of the configuration, enhancing performance and maintainability.
160-163
: Review ofSuccessOutput
function: Maintains functionality with improved structure.The
SuccessOutput
function correctly utilises the newoutput
function to handle its output formatting, maintaining its original purpose while improving its structure by separating concerns. This change is well-aligned with modern coding practices.cmd/headscale/cli/nodes.go (1)
121-121
: Consistent use ofnewHeadscaleCLIWithConfig
across CLI commands.The replacement of
getHeadscaleCLIClient
withnewHeadscaleCLIWithConfig
in various command implementations (registerNodeCmd
,listNodesCmd
,expireNodeCmd
,renameNodeCmd
,deleteNodeCmd
,moveNodeCmd
,backfillNodeIPsCmd
, andtagCmd
) is consistent and correctly implemented. This change supports the PR's objective to enhance configuration management and only load necessary configurations, which is crucial for performance and maintainability.Also applies to: 172-172, 228-228, 271-271, 320-320, 420-420, 493-493, 666-666
Signed-off-by: Kristoffer Dalby <[email protected]>
Signed-off-by: Kristoffer Dalby <[email protected]>
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
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (2)
- CHANGELOG.md (1 hunks)
- integration/cli_test.go (6 hunks)
Files skipped from review as they are similar to previous changes (1)
- CHANGELOG.md
Additional comments not posted (3)
integration/cli_test.go (3)
Line range hint
739-749
: Improved error handling inTestNodeTagCommand
.The changes simplify error handling by directly checking for errors and using
assert.ErrorContains
to validate the error message. This approach enhances the clarity and directness of the test.
1394-1404
: Improved error handling inTestNodeRenameCommand
.The changes simplify error handling by directly checking for errors and using
assert.ErrorContains
to validate the error message. This approach enhances the clarity and directness of the test.
Line range hint
1531-1546
: Improved error handling inTestNodeMoveCommand
.The changes simplify error handling by directly checking for errors and using
assert.ErrorContains
to validate the error message. This approach enhances the clarity and directness of the test.
Currently all configuration was loaded and validated regardless of what
the CLI was doing, if you did a
nodes ls
orserve
the whole thing wouldbe loaded and validated which caused a machine that were doing only CLI
stuff to need the full config, or at least a bunch that would throw errors.
This commit cleans up and splits this so that only the subset needed for
running the CLI (unix socket or remote gRPC) is required when running
all commands except for
serve
.When
serve
is ran, the normal chain with validations and loading of thewhole config is ran.
This means that deprecation warnings for the server config will only be shown
in the server log.
This should be a nice quality of life improvements for users running headscale
as a remote CLI, split config or Nix users with the module updates for 0.23.0 (NixOS/nixpkgs#340054).
Signed-off-by: Kristoffer Dalby [email protected]
Summary by CodeRabbit
New Features
serve
.viper
package.Bug Fixes
Documentation
Tests