feat: add new workload pod and fixed orphan tcp connections #263
Conversation
WalkthroughThe updates involve enhancing functionalities related to JSON configurations, port forwarding tasks, and Kubernetes context handling. Key changes include introducing a mechanism to remove blank or default fields from JSON, utilizing Changes
Sequence Diagram(s)Port Forwarding CancellationsequenceDiagram
participant User
participant UI as User Interface
participant App as KFTray App
participant PF as Port Forwarding Task
participant CancelNotifier as CANCEL_NOTIFIER
User->>UI: Initiates port forwarding
UI->>App: Start port forwarding with workload type
App->>PF: Starts task
PF-->>App: Task running
User->>UI: Requests cancellation
UI->>App: Cancels port forwarding
App->>CancelNotifier: Notify cancellation
CancelNotifier->>PF: Signals task to cancel
PF->>App: Task cancelled
App-->>User: Cancellation confirmed
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 as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (2)
crates/kftray-tauri/tauri.conf.jsonis excluded by!**/*.jsonfrontend/dist/index.htmlis excluded by!**/dist/**
Files selected for processing (12)
- crates/kftray-tauri/src/config.rs (7 hunks)
- crates/kftray-tauri/src/kubeforward/commands.rs (13 hunks)
- crates/kftray-tauri/src/kubeforward/kubecontext.rs (6 hunks)
- crates/kftray-tauri/src/kubeforward/pod_finder.rs (3 hunks)
- crates/kftray-tauri/src/kubeforward/port_forward.rs (10 hunks)
- crates/kftray-tauri/src/main.rs (1 hunks)
- crates/kftray-tauri/src/models/config.rs (3 hunks)
- crates/kftray-tauri/src/models/kube.rs (2 hunks)
- frontend/src/components/AddConfigModal/index.tsx (19 hunks)
- frontend/src/components/Main/index.tsx (8 hunks)
- frontend/src/components/PortForwardTable/ContextsAccordion/PortForwardRow/index.tsx (5 hunks)
- frontend/src/types/index.ts (3 hunks)
Additional comments not posted (45)
crates/kftray-tauri/src/models/config.rs (2)
29-30: Added a new optional fieldtargetto theConfigstruct.This addition aligns with the PR objectives to support new workload types and is correctly implemented using optional serialization to maintain backward compatibility.
39-40: Updated default values forlocal_port,remote_port,protocol, andtarget.These changes are consistent with the PR's intention to enhance configuration management. Ensure that these new defaults are documented and communicated to users if they represent a significant change from previous configurations.
Also applies to: 43-43, 49-49
crates/kftray-tauri/src/models/kube.rs (1)
39-42: Introduced a new structPodInfowith a single fieldlabels_str.This struct is well-defined and supports the PR's goals of better handling different workload types. The use of
labels_strsuggests flexibility in selecting pods based on multiple labels.crates/kftray-tauri/src/kubeforward/pod_finder.rs (2)
21-33: Refactored thefindmethod to support both service names and pod labels.The refactoring is logical and supports the PR's objectives by enhancing the flexibility of pod selection based on different criteria. Ensure that this method is covered by unit tests, especially for the new branching logic.
Line range hint
35-89: Added methodsfind_pod_by_service_nameandfind_pod_by_labelto facilitate pod discovery based on service names or labels.These methods are well-implemented and improve the modularity of the code. They also align with the PR's goals of handling different workload types more effectively. Again, ensure comprehensive testing for these new methods.
crates/kftray-tauri/src/main.rs (1)
115-115: Updated the list of Tauri command handlers to include new Kubernetes-related functionalities.The addition of these handlers is essential for integrating the new backend functionalities with the Tauri frontend. This ensures that the new features are accessible and manageable through the application's GUI.
frontend/src/types/index.ts (3)
14-14: The addition of the 'target' field in theStatusinterface is consistent with the PR objectives of handling different workload types.
34-34: The addition of the 'target' field in theConfiginterface supports new functionality and is consistent with other parts of the application.
49-49: The addition of the 'target' field in theResponseinterface aligns with the new features introduced in the PR.crates/kftray-tauri/src/kubeforward/kubecontext.rs (5)
1-1: The added imports and the newPodInfostruct are essential for supporting the new functionalities related to Kubernetes pod management.Also applies to: 15-15, 39-39
113-116: The modified function signature oflist_podsenhances clarity and aligns with the newPodInfostruct usage.
117-155: The implementation of thelist_podsfunction correctly utilizes the newPodInfostruct and standard Rust practices for error handling and asynchronous programming.
277-277: The modified function signature oflist_service_portsaligns with the new error handling strategy and improves the function's usability.
279-379: The implementation oflist_service_portseffectively handles different scenarios based ontarget_portand improves error handling, aligning with the PR's objectives.crates/kftray-tauri/src/config.rs (3)
22-36: The new functionis_value_defaultand the modifications toremove_blank_or_default_fieldsenhance configuration management by effectively handling default values.Also applies to: 45-50
296-298: The modifications to theexport_configsfunction improve the integrity of exported configurations by ensuring that they do not contain redundant default values.
Line range hint
425-466: The test forremove_blank_or_default_fieldseffectively verifies that the function correctly removes blank and default fields, ensuring its reliability.frontend/src/components/PortForwardTable/ContextsAccordion/PortForwardRow/index.tsx (2)
106-110: The modifications to thestartPortForwardingandstopPortForwardingfunctions to handle 'service' and 'pod' workload types for TCP protocols align with the PR's objectives and are correctly implemented.Also applies to: 139-143
255-270: The modifications to the tooltip display logic to show 'Pod' instead of 'Service' when the workload type is 'pod' enhance the user interface consistency and clarity.frontend/src/components/Main/index.tsx (7)
40-40: Introduced a new state variabletargetin the initial state setup fornewConfig. Ensure that this is consistently used throughout the component and properly integrated with backend changes.
85-85: Similarly,targetis reset when opening the modal. This is consistent with the initial state setup. Good practice in maintaining state consistency.
251-251: The newtargetfield is being set from the fetched config during edit operations. This ensures that thetargetfield is editable and maintained across component states.
280-280: Thetargetfield is included in the submission of edited configurations. This is crucial for ensuring that edits to thetargetfield are persisted.
329-329: Thetargetfield is included when saving a configuration, whether it’s a new addition or an edit. This inclusion is necessary for the correct operation of the feature.
[APROVED]
Line range hint
349-401: The logic for stopping and starting port forwarding now takes into account theworkload_typeof 'pod'. This is a significant change that aligns with the backend modifications to support different types of workloads.
474-474: Handling of theworkload_type'pod' in thehandlePortForwardingfunction. This change is necessary for the new functionality and is consistent with the backend changes.crates/kftray-tauri/src/kubeforward/port_forward.rs (6)
14-14: Added import fortokio::sync::Notify. This is used for handling cancellation signals, which is a critical feature for managing long-running network operations safely.
32-32: Usage of a global staticCANCEL_NOTIFIERwhich is crucial for managing cancellation signals across asynchronous tasks in port forwarding operations.
Line range hint
103-129: Enhanced theport_forward_tcpfunction to use theCANCEL_NOTIFIERfor handling cancellations effectively. This is a robust enhancement for improving the reliability and responsiveness of the port forwarding feature.
Line range hint
156-213: Refactoredforward_connectionto include thecancel_notifier. This change is part of enhancing the cancellation handling in the port forwarding logic, allowing for cleaner termination of connections.
Line range hint
243-367: Implemented detailed cancellation handling in bothcreate_client_to_upstream_taskandcreate_upstream_to_client_task. These changes ensure that tasks can be cancelled promptly, which is crucial for resource management and error handling.
Line range hint
380-421: Thedetect_connection_closefunction now also listens for cancellation notifications, allowing the system to react quickly to cancellation requests and close connections appropriately.crates/kftray-tauri/src/kubeforward/commands.rs (8)
31-31: Introducingtokio::sync::Notifyfor task cancellation is a good practice in asynchronous environments.
54-54: The static referenceCANCEL_NOTIFIERis well implemented usingArcto manage shared state across async tasks.
129-136: The log message construction within the match block is well implemented. It dynamically adjusts the message based on the workload type, enhancing the maintainability of the code.
220-226: The error handling in this section is robust, providing detailed error messages that are specific to the configuration and protocol. This will be helpful for debugging issues with port forwarding setups.
237-242: The error message here is clear and informative, which is crucial for understanding the failure points when creatingPortForwardinstances.
281-283: Usingnotify_waitersto signal cancellation across potentially multiple waiting tasks is an efficient way to handle cleanup in asynchronous operations.
427-429: Proper use of the cancellation notifier in thestop_port_forwardfunction ensures that all related tasks are notified to terminate, adhering to good concurrency practices.
79-85: The handling of different workload types using a match statement is clear and well-structured. However, ensure proper handling and testing when thetargetorservicefields areNone, asunwrap_or_default()might introduce unexpected behaviors.frontend/src/components/AddConfigModal/index.tsx (5)
53-53: The introduction ofselectedServiceOrTargetas a state variable facilitates handling both services and targets, aligning with the backend changes to support multiple workload types.
155-169: Query setup for listing pods is well implemented, with appropriate checks to ensure the query is only enabled when necessary. This prevents unnecessary API calls.
251-256: The logic to handle the selection of either a service or target based on the workload type is well implemented, providing flexibility in the UI to adapt to different configurations.
660-686: The conditional rendering based on the workload type (podvsservice) is a good approach to dynamically adjust the UI. This makes the component more adaptable to different use cases.
528-528: Adding the 'pod' option to the workload type selector is a necessary update to support the new functionality introduced in the backend. Ensure that this option is well tested across different scenarios.
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- .github/workflows/main.yml (1 hunks)
Files skipped from review as they are similar to previous changes (1)
- .github/workflows/main.yml
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- .github/workflows/main.yml (1 hunks)
Files skipped from review as they are similar to previous changes (1)
- .github/workflows/main.yml
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- .github/workflows/main.yml (1 hunks)
Files skipped from review as they are similar to previous changes (1)
- .github/workflows/main.yml
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- .github/workflows/main.yml (1 hunks)
Files skipped from review as they are similar to previous changes (1)
- .github/workflows/main.yml
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- .github/workflows/main.yml (1 hunks)
Files skipped from review as they are similar to previous changes (1)
- .github/workflows/main.yml
There was a problem hiding this comment.
Actionable comments posted: 2
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (8)
- crates/kftray-tauri/src/kubeforward/commands.rs (13 hunks)
- crates/kftray-tauri/src/kubeforward/kubecontext.rs (6 hunks)
- crates/kftray-tauri/src/kubeforward/pod_finder.rs (2 hunks)
- crates/kftray-tauri/src/kubeforward/pod_selection.rs (2 hunks)
- crates/kftray-tauri/src/kubeforward/port_forward.rs (10 hunks)
- crates/kftray-tauri/src/main.rs (1 hunks)
- frontend/src/components/AddConfigModal/index.tsx (18 hunks)
- frontend/src/components/PortForwardTable/ContextsAccordion/PortForwardRow/index.tsx (5 hunks)
Files skipped from review as they are similar to previous changes (6)
- crates/kftray-tauri/src/kubeforward/commands.rs
- crates/kftray-tauri/src/kubeforward/kubecontext.rs
- crates/kftray-tauri/src/kubeforward/pod_finder.rs
- crates/kftray-tauri/src/kubeforward/port_forward.rs
- crates/kftray-tauri/src/main.rs
- frontend/src/components/PortForwardTable/ContextsAccordion/PortForwardRow/index.tsx
Additional comments not posted (2)
frontend/src/components/AddConfigModal/index.tsx (2)
537-537: Update UI elements and logic to handle new workload types effectively.The changes to the UI elements and the logic for handling different workload types, such as the addition of the 'pod' option and the conditional rendering based on
workload_type, are well-implemented. These changes enhance the flexibility of the configuration modal and improve the user experience by accommodating different Kubernetes resource types.Also applies to: 669-721
155-170: Review the conditions for enabling queries to ensure they align with the intended functionality.This verification will help ensure that the conditions for enabling queries are consistent and correctly implemented across the component.
Also applies to: 172-172, 195-223
Verification successful
The conditions for enabling the queries in the
frontend/src/components/AddConfigModal/index.tsxfile appear to be consistent and well-aligned with the intended functionality. EachuseQuerycall has specific conditions based on the state variables, such asnewConfig.context,newConfig.namespace, andnewConfig.workload_type.
namespaceQueryis enabled ifnewConfig.contextis defined.podsQueryis enabled ifnewConfig.context,newConfig.namespaceare defined, andnewConfig.workload_typeis 'pod'.serviceOrTargetQueryis enabled ifnewConfig.context,newConfig.namespaceare defined, andnewConfig.workload_typeis not 'proxy'.portQueryconditions are based onnewConfig.context,newConfig.namespace, andnewConfig.workload_type.These conditions are consistent and ensure that queries are only enabled when the necessary state variables are available.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the conditions under which queries are enabled and ensure they align with the expected states. # Test: Check for consistency in the conditions across different queries. rg --type tsx --files-with-matches $'useQuery\\(.*enabled:'Length of output: 87
Script:
#!/bin/bash # Description: Verify the conditions under which queries are enabled and ensure they align with the expected states. # Test: Check for consistency in the conditions across different queries. rg --type-add 'tsx:*.{ts,tsx}' --files-with-matches $'useQuery\\(.*enabled:'Length of output: 76
Script:
#!/bin/bash # Description: Search for all `useQuery` calls in the codebase for manual inspection. # Test: Find all instances of `useQuery` in TypeScript files. rg --type-add 'tsx:*.{ts,tsx}' 'useQuery('Length of output: 113
Script:
#!/bin/bash # Description: Search for all `useQuery` calls in the codebase for manual inspection. # Test: Find all instances of `useQuery` in TypeScript files. rg --type-add 'tsx:*.{ts,tsx}' 'useQuery\('Length of output: 377
Script:
#!/bin/bash # Description: Extract the code around `useQuery` calls to inspect the conditions for enabling the queries. # Extract relevant code snippets for each `useQuery` call. rg --type-add 'tsx:*.{ts,tsx}' -A 10 -B 10 'useQuery\(' frontend/src/components/AddConfigModal/index.tsxLength of output: 1970
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (1)
crates/kftray-tauri/tauri.conf.jsonis excluded by!**/*.json
Files selected for processing (6)
- .github/workflows/ci.yaml (1 hunks)
- .github/workflows/main.yml (2 hunks)
- crates/kftray-tauri/src/config.rs (7 hunks)
- crates/kftray-tauri/src/kubeforward/commands.rs (13 hunks)
- crates/kftray-tauri/src/kubeforward/port_forward.rs (10 hunks)
- frontend/src/components/AddConfigModal/index.tsx (18 hunks)
Files skipped from review due to trivial changes (1)
- .github/workflows/ci.yaml
Files skipped from review as they are similar to previous changes (5)
- .github/workflows/main.yml
- crates/kftray-tauri/src/config.rs
- crates/kftray-tauri/src/kubeforward/commands.rs
- crates/kftray-tauri/src/kubeforward/port_forward.rs
- frontend/src/components/AddConfigModal/index.tsx
* test * feat: add new workload pod and fixed orphan tcp connections * feat: add new workload pod and fixed orphan tcp connections * feat: add new workload pod and fixed orphan tcp connections * feat: add new workload pod and fixed orphan tcp connections * feat: add new workload pod and fixed orphan tcp connections * feat: add new workload pod and fixed orphan tcp connections * Update main.yml * Update main.yml * feat: add new workload pod and fixed orphan tcp connections * feat: add new workload pod and fixed orphan tcp connections * feat: add new workload pod and fixed orphan tcp connections
changes:
ref: Port-forward to pods not available #260 )