Skip to content
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

feat: check CoreDNS #120

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

c3y1huang
Copy link
Contributor

Which issue(s) this PR fixes:

Issue longhorn/longhorn#9752

What this PR does / why we need it:

Check if CoreDNS has more than 2 ready replicas.

Special notes for your reviewer:

None

Additional documentation or context

None

@c3y1huang c3y1huang self-assigned this Nov 14, 2024
Copy link

coderabbitai bot commented Nov 14, 2024

Walkthrough

The pull request introduces several changes, including an update to the go.mod file to replace a dependency on github.com/longhorn/go-common-libs with github.com/c3y1huang/go-common-libs. Additionally, a new constant AppNameCoreDNS is added in pkg/consts/preflight.go, and a new method checkCoreDNS is introduced in pkg/local/preflight/checker.go to verify CoreDNS deployment configurations. The newClusterRole method in pkg/remote/preflight/checker.go is modified to include permissions for both DaemonSets and Deployments. Lastly, a new function GetDeployment is added to retrieve Kubernetes deployments.

Changes

File Change Summary
go.mod Updated to replace dependency github.com/longhorn/go-common-libs with github.com/c3y1huang/go-common-libs at version v0.0.0-20241114031240-e1117130cd3b.
pkg/consts/preflight.go Added constant AppNameCoreDNS with value "coredns".
pkg/local/preflight/checker.go Added method checkCoreDNS to check CoreDNS deployment configuration; modified Init method for streamlined client configuration; updated Run method.
pkg/remote/preflight/checker.go Updated newClusterRole method to include "deployments" in the Resources field of PolicyRule.
vendor/github.com/longhorn/go-common-libs/kubernetes/deployment.go Added function GetDeployment to retrieve a Kubernetes Deployment resource by name and namespace.
vendor/modules.txt Updated module reference for github.com/longhorn/go-common-libs to new version.

Assessment against linked issues

Objective Addressed Explanation
The DR volume should reattach to an available node and continue the restore process without entering a faulted state (#9752). The changes do not directly address the DR volume issue. It's unclear if the new checks impact this functionality.

Warning

Rate limit exceeded

@c3y1huang has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 22 minutes and 34 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between 77362e7 and af34ac2.


📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 77362e7 and af34ac2.

📒 Files selected for processing (3)
  • pkg/consts/preflight.go (1 hunks)
  • pkg/local/preflight/checker.go (3 hunks)
  • pkg/remote/preflight/checker.go (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • pkg/consts/preflight.go
  • pkg/remote/preflight/checker.go
🔇 Additional comments (5)
pkg/local/preflight/checker.go (5)

56-64: LGTM: Clean and focused client initialization.

The code follows best practices with proper error handling and descriptive error messages.


180-180: LGTM: Appropriate placement of CoreDNS check.

The CoreDNS check is correctly placed before OS-specific checks.


472-482: LGTM: Well-documented function.

The documentation clearly explains the purpose, behavior, and includes a reference to the related issue.


492-495: Remove early return to ensure complete check.

The early return skips checking ready replicas even when the desired replica count is correct. This could miss reporting cases where desired replicas are correct but ready replicas are insufficient.


497-500: 🛠️ Refactor suggestion

Consider potential race condition in replica checks.

There's a potential race condition between checking Spec.Replicas and Status.ReadyReplicas. Consider combining the warnings if both conditions fail to avoid missing states during deployment scaling.

Consider this alternative implementation:

-	if deployment.Spec.Replicas == nil || *deployment.Spec.Replicas < 2 {
-		local.collection.Log.Warn = append(local.collection.Log.Warn, "CoreDNS is set with fewer than 2 replicas; consider increasing replica count for high availability")
-		return
-	}
-
-	if deployment.Status.ReadyReplicas < 2 {
-		local.collection.Log.Warn = append(local.collection.Log.Warn, "CoreDNS has fewer than 2 ready replicas; some replicas may not be running or ready")
-		return
-	}
+	desiredReplicas := int32(2)
+	if deployment.Spec.Replicas == nil || *deployment.Spec.Replicas < desiredReplicas {
+		local.collection.Log.Warn = append(local.collection.Log.Warn, "CoreDNS is set with fewer than 2 replicas; consider increasing replica count for high availability")
+	}
+	if deployment.Status.ReadyReplicas < desiredReplicas {
+		local.collection.Log.Warn = append(local.collection.Log.Warn, "CoreDNS has fewer than 2 ready replicas; some replicas may not be running or ready")
+	}
+	if deployment.Spec.Replicas != nil && *deployment.Spec.Replicas >= desiredReplicas && deployment.Status.ReadyReplicas >= desiredReplicas {
+		local.collection.Log.Info = append(local.collection.Log.Info, fmt.Sprintf("CoreDNS is set with %d replicas and %d ready replicas", *deployment.Spec.Replicas, deployment.Status.ReadyReplicas))
+	}

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?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@c3y1huang c3y1huang force-pushed the 9752-dr-volume-faulted-after-node-reboot branch 2 times, most recently from 038cb0c to 9678468 Compare November 14, 2024 02:59
@c3y1huang
Copy link
Contributor Author

@coderabbitai review

Copy link

coderabbitai bot commented Nov 14, 2024

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🧹 Outside diff range and nitpick comments (2)
go.mod (1)

Line range hint 3-3: Verify Go Version Compatibility

The module specifies Go 1.23, which seems incorrect as the latest stable version is Go 1.22. This might be a typo or an unstable version.

Please update to use a stable Go version (e.g., go 1.22).

pkg/local/preflight/checker.go (1)

471-502: Consider refactoring for better maintainability

  1. Define a constant for minimum required replicas.
  2. Consolidate the replica checks and logging for better flow.
+const minRequiredCoreDNSReplicas = 2

 func (local *Checker) checkCoreDNS() {
 	logrus.Info("Checking if CoreDNS has multiple replicas")

-	daemonSet, err := commonkube.GetDeployment(local.kubeClient, metav1.NamespaceSystem, consts.AppNameCoreDNS)
+	deployment, err := commonkube.GetDeployment(local.kubeClient, metav1.NamespaceSystem, consts.AppNameCoreDNS)
 	if err != nil {
-		local.collection.Log.Error = append(local.collection.Log.Warn, errors.Wrap(err, "failed to check CoreDNS").Error())
+		local.collection.Log.Error = append(local.collection.Log.Error, errors.Wrap(err, "failed to check CoreDNS").Error())
 		return
 	}

-	if daemonSet.Spec.Replicas == nil || *daemonSet.Spec.Replicas < 2 {
-		local.collection.Log.Warn = append(local.collection.Log.Warn, "CoreDNS is set with fewer than 2 replicas; consider increasing replica count for high availability")
-		return
-	}
+	desiredReplicas := int32(0)
+	if deployment.Spec.Replicas != nil {
+		desiredReplicas = *deployment.Spec.Replicas
+	}

-	if daemonSet.Status.ReadyReplicas < 2 {
-		local.collection.Log.Warn = append(local.collection.Log.Warn, "CoreDNS has fewer than 2 ready replicas; some replicas may not be running or ready")
+	if desiredReplicas < minRequiredCoreDNSReplicas {
+		local.collection.Log.Warn = append(local.collection.Log.Warn, 
+			fmt.Sprintf("CoreDNS is set with %d replicas; consider increasing replica count to at least %d for high availability", 
+				desiredReplicas, minRequiredCoreDNSReplicas))
 	}

-	local.collection.Log.Info = append(local.collection.Log.Info, fmt.Sprintf("CoreDNS is set with %d replicas and %d ready replicas", *daemonSet.Spec.Replicas, daemonSet.Status.ReadyReplicas))
+	if deployment.Status.ReadyReplicas < minRequiredCoreDNSReplicas {
+		local.collection.Log.Warn = append(local.collection.Log.Warn, 
+			fmt.Sprintf("CoreDNS has only %d ready replicas; some replicas may not be running or ready", 
+				deployment.Status.ReadyReplicas))
+	}
+
+	local.collection.Log.Info = append(local.collection.Log.Info, 
+		fmt.Sprintf("CoreDNS is set with %d replicas and %d ready replicas", 
+			desiredReplicas, deployment.Status.ReadyReplicas))
 }
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 8379a8a and 9678468.

⛔ Files ignored due to path filters (1)
  • go.sum is excluded by !**/*.sum
📒 Files selected for processing (6)
  • go.mod (1 hunks)
  • pkg/consts/preflight.go (1 hunks)
  • pkg/local/preflight/checker.go (3 hunks)
  • pkg/remote/preflight/checker.go (1 hunks)
  • vendor/github.com/longhorn/go-common-libs/kubernetes/deployment.go (1 hunks)
  • vendor/modules.txt (2 hunks)
🔇 Additional comments (9)
pkg/consts/preflight.go (1)

7-8: LGTM! Well-integrated constant addition.

The new AppNameCoreDNS constant follows the established naming convention and uses the correct lowercase value that matches Kubernetes naming standards. The constant is properly grouped with other app names and will integrate well with the CoreDNS preflight checks.

vendor/github.com/longhorn/go-common-libs/kubernetes/deployment.go (1)

1-11: LGTM: Clean package structure with appropriate imports

The package structure is well-organized with all necessary imports for Kubernetes client operations and logging.

go.mod (1)

7-7: ⚠️ Potential issue

Security & Maintainability Concern: Using Personal Fork as Dependency

Replacing github.com/longhorn/go-common-libs with a personal fork raises several concerns:

  1. Security: Personal forks may not undergo the same security review and testing as the main repository
  2. Maintainability: Forks can become stale or unmaintained
  3. Visibility: No documentation explaining why the fork is necessary

Please clarify:

  • Why is the fork necessary?
  • Are the changes in the fork planned to be contributed back to the main repository?
  • What is the long-term maintenance plan for the forked dependency?
pkg/remote/preflight/checker.go (3)

168-168: LGTM with testing reminder

The RBAC permission change looks good and is necessary for the CoreDNS check functionality. Please ensure that:

  1. The change is tested with various RBAC configurations
  2. The CoreDNS check works as expected in both success and failure scenarios

168-168: Verify minimal RBAC permissions for CoreDNS check

The addition of "deployments" permission is aligned with the PR objective to check CoreDNS replicas. However, let's verify if we can further restrict the scope:

  1. Consider namespace-specific permission instead of cluster-wide
  2. Verify if we need both "daemonsets" and "deployments" permissions
#!/bin/bash
# Description: Check CoreDNS deployment location and usage of daemonsets permission

# Check where CoreDNS is deployed
echo "Checking CoreDNS deployment namespace:"
rg -l "kind:\s+Deployment.*name:\s+coredns" 

# Check if daemonsets permission is still needed
echo "Checking daemonset usage in code:"
rg "daemonsets?" --type go -B 2 -A 2

168-168: Verify complete implementation of CoreDNS check

While the RBAC permission is added here, let's verify the implementation of the actual CoreDNS check:

✅ Verification successful

Let's gather more information about the CoreDNS implementation by examining the identified files.


CoreDNS replica check implementation is complete and well-implemented

The implementation is properly in place with:

  • Complete checkCoreDNS() function in pkg/local/preflight/checker.go
  • Proper constant definition in pkg/consts/preflight.go
  • Well-documented function that checks both desired and ready replicas
  • Appropriate warning messages for both cases (<2 replicas specified or <2 ready replicas)
  • Proper error handling and logging

The RBAC permissions added in the review match the implementation's requirements for accessing deployments.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify implementation of CoreDNS replica check

# Look for CoreDNS-related code
echo "Searching for CoreDNS check implementation:"
rg -l "CoreDNS" --type go

# Look for deployment replica check logic
echo "Searching for deployment replica check logic:"
ast-grep --pattern 'func $CHECK_FUNC($ARGS) {
  $$$
  Replicas $$$
  $$$
}'

Length of output: 356


Script:

#!/bin/bash
# Check CoreDNS-related code in the identified files
echo "Content of pkg/consts/preflight.go with CoreDNS context:"
rg -A 5 -B 5 "CoreDNS" pkg/consts/preflight.go

echo -e "\nContent of pkg/local/preflight/checker.go with CoreDNS context:"
rg -A 10 -B 10 "CoreDNS" pkg/local/preflight/checker.go

# Look for deployment replica checks in these specific files
echo -e "\nLooking for deployment/replica checks:"
rg -A 5 -B 5 "deployment.*replica|replica.*deployment" pkg/local/preflight/checker.go

Length of output: 3909

pkg/local/preflight/checker.go (2)

56-64: LGTM: Proper Kubernetes client initialization

The initialization of the Kubernetes client is well-structured with appropriate error handling and wrapping.


180-180: LGTM: Appropriate placement of CoreDNS check

The CoreDNS check is correctly placed before OS-specific checks since it's a cluster-level verification.

vendor/modules.txt (1)

136-136: Justify the use of a personal fork instead of the official library.

I notice that the PR replaces github.com/longhorn/go-common-libs with a personal fork github.com/c3y1huang/go-common-libs. While this might be necessary for development, there are several concerns:

  1. Security: Using a personal fork instead of the official library could introduce security risks.
  2. Maintenance: Personal forks may not be maintained long-term.
  3. Best Practices: It's generally recommended to contribute changes back to the original repository rather than maintaining a separate fork.

Could you please:

  1. Explain why the fork is necessary
  2. Consider contributing the changes back to the original repository
  3. Document the specific changes made in the fork

Let's verify the changes in the forked repository:

Also applies to: 931-931

pkg/local/preflight/checker.go Outdated Show resolved Hide resolved
pkg/local/preflight/checker.go Outdated Show resolved Hide resolved
@c3y1huang
Copy link
Contributor Author

Test results:

  1. CoreDNS with 1 replica.
    > ./bin/longhornctl-linux-amd64 check preflight --image="c3y1huang/research:longhorn-cli-443"
    INFO[2024-11-14T10:42:39+08:00] Initializing preflight checker               
    INFO[2024-11-14T10:42:39+08:00] Cleaning up preflight checker                
    INFO[2024-11-14T10:42:39+08:00] Running preflight checker                    
    INFO[2024-11-14T10:42:43+08:00] Retrieved preflight checker result:
    ip-10-0-2-6:
      info:
      - Service iscsid is running
      - NFS4 is supported
      - Package nfs-client is installed
      - Package open-iscsi is installed
      - Package cryptsetup is installed
      - Module dm_crypt is loaded
      warn:
      - CoreDNS is set with fewer than 2 replicas; consider increasing replica count for high availability
    ip-10-0-2-21:
      info:
      - Service iscsid is running
      - NFS4 is supported
      - Package nfs-client is installed
      - Package open-iscsi is installed
      - Package cryptsetup is installed
      - Module dm_crypt is loaded
      warn:
      - CoreDNS is set with fewer than 2 replicas; consider increasing replica count for high availability
    ip-10-0-2-187:
      info:
      - Service iscsid is running
      - NFS4 is supported
      - Package nfs-client is installed
      - Package open-iscsi is installed
      - Package cryptsetup is installed
      - Module dm_crypt is loaded
      warn:
      - CoreDNS is set with fewer than 2 replicas; consider increasing replica count for high availability 
    INFO[2024-11-14T10:42:43+08:00] Cleaning up preflight checker                
    INFO[2024-11-14T10:42:43+08:00] Completed preflight checker   
    
  2. CoreDNS with 2 replicas.
    > ./bin/longhornctl-linux-amd64 check preflight --image="c3y1huang/research:longhorn-cli-443"
    INFO[2024-11-14T10:43:45+08:00] Initializing preflight checker               
    INFO[2024-11-14T10:43:45+08:00] Cleaning up preflight checker                
    INFO[2024-11-14T10:43:46+08:00] Running preflight checker                    
    INFO[2024-11-14T10:43:49+08:00] Retrieved preflight checker result:
    ip-10-0-2-6:
      info:
      - CoreDNS is set with 2 replicas and 2 ready replicas
      - Service iscsid is running
      - NFS4 is supported
      - Package nfs-client is installed
      - Package open-iscsi is installed
      - Package cryptsetup is installed
      - Module dm_crypt is loaded
    ip-10-0-2-21:
      info:
      - CoreDNS is set with 2 replicas and 2 ready replicas
      - Service iscsid is running
      - NFS4 is supported
      - Package nfs-client is installed
      - Package open-iscsi is installed
      - Package cryptsetup is installed
      - Module dm_crypt is loaded
    ip-10-0-2-187:
      info:
      - CoreDNS is set with 2 replicas and 2 ready replicas
      - Service iscsid is running
      - NFS4 is supported
      - Package nfs-client is installed
      - Package open-iscsi is installed
      - Package cryptsetup is installed
      - Module dm_crypt is loaded 
    INFO[2024-11-14T10:43:49+08:00] Cleaning up preflight checker                
    INFO[2024-11-14T10:43:50+08:00] Completed preflight checker 
    

longhorn/longhorn-9752

Signed-off-by: Chin-Ya Huang <chin-ya.huang@suse.com>
@c3y1huang c3y1huang force-pushed the 9752-dr-volume-faulted-after-node-reboot branch from 9678468 to 86d0859 Compare November 14, 2024 03:21
@c3y1huang
Copy link
Contributor Author

@coderabbitai review

Copy link

coderabbitai bot commented Nov 14, 2024

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@c3y1huang c3y1huang force-pushed the 9752-dr-volume-faulted-after-node-reboot branch from 86d0859 to dc7a477 Compare November 14, 2024 03:24
@c3y1huang c3y1huang marked this pull request as ready for review November 14, 2024 03:48
@@ -4,6 +4,8 @@ go 1.23

toolchain go1.23.3

replace github.com/longhorn/go-common-libs => github.com/c3y1huang/go-common-libs v0.0.0-20241114031240-e1117130cd3b
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: update after dependent vendor PR merged.

@c3y1huang c3y1huang requested review from derekbit and a team November 14, 2024 03:49
Copy link

@coderabbitai coderabbitai bot left a 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 (2)
pkg/local/preflight/checker.go (2)

472-502: Consider using constants for replica threshold.

The magic number "2" is used multiple times. Consider defining it as a constant for better maintainability.

Add this at the package level:

+const minCoreDNSReplicas = 2

Then use it in the checks:

-if deployment.Spec.Replicas == nil || *deployment.Spec.Replicas < 2 {
+if deployment.Spec.Replicas == nil || *deployment.Spec.Replicas < minCoreDNSReplicas {

-if deployment.Status.ReadyReplicas < 2 {
+if deployment.Status.ReadyReplicas < minCoreDNSReplicas {

501-501: Consider security implications of logging deployment details.

The log message exposes information about the cluster configuration. Consider making this a debug-level log or removing specific numbers.

-local.collection.Log.Info = append(local.collection.Log.Info, fmt.Sprintf("CoreDNS is set with %d replicas and %d ready replicas", *deployment.Spec.Replicas, deployment.Status.ReadyReplicas))
+local.collection.Log.Info = append(local.collection.Log.Info, "CoreDNS has sufficient replicas and is ready")
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 9678468 and dc7a477.

⛔ Files ignored due to path filters (1)
  • go.sum is excluded by !**/*.sum
📒 Files selected for processing (6)
  • go.mod (1 hunks)
  • pkg/consts/preflight.go (1 hunks)
  • pkg/local/preflight/checker.go (3 hunks)
  • pkg/remote/preflight/checker.go (1 hunks)
  • vendor/github.com/longhorn/go-common-libs/kubernetes/deployment.go (1 hunks)
  • vendor/modules.txt (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (5)
  • go.mod
  • pkg/consts/preflight.go
  • pkg/remote/preflight/checker.go
  • vendor/github.com/longhorn/go-common-libs/kubernetes/deployment.go
  • vendor/modules.txt
🔇 Additional comments (2)
pkg/local/preflight/checker.go (2)

56-64: LGTM! Clean and straightforward client initialization.

The simplified Kubernetes client initialization with proper error handling looks good.


180-180: LGTM! Good placement of CoreDNS check.

The CoreDNS check is appropriately placed before OS-specific checks.

pkg/local/preflight/checker.go Outdated Show resolved Hide resolved
pkg/local/preflight/checker.go Show resolved Hide resolved
@roger-ryao
Copy link

Hi @c3y1huang
I have a question: should we change the number of replicas for the CoreDNS deployment in the cluster after running the install preflight? One concern I have is that the default number of replicas for the CoreDNS deployment is 1, but the user's original cluster might have been changed to 3. However, after running Longhorn cli, it might become 2, which could lead to issues.

@c3y1huang
Copy link
Contributor Author

c3y1huang commented Nov 14, 2024

Hi @c3y1huang I have a question: should we change the number of replicas for the CoreDNS deployment in the cluster after running the install preflight? One concern I have is that the default number of replicas for the CoreDNS deployment is 1, but the user's original cluster might have been changed to 3. However, after running Longhorn cli, it might become 2, which could lead to issues.

This PR is proposing to add the CoreDNS check to the longhornctl check preflight. It doesn't change the CoreDNS setup, as that responsibility should remain with the user, since CoreDNS is not managed by Longhorn.

shuo-wu
shuo-wu previously approved these changes Nov 14, 2024
Copy link
Contributor

@shuo-wu shuo-wu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

longhorn/longhorn-9752

Signed-off-by: Chin-Ya Huang <chin-ya.huang@suse.com>
Signed-off-by: Chin-Ya Huang <chin-ya.huang@suse.com>
longhorn/longhorn-9752

Signed-off-by: Chin-Ya Huang <chin-ya.huang@suse.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants