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

Printing overrided vars in cli command noobaa diagnostics report #1445

Merged
merged 2 commits into from
Sep 30, 2024

Conversation

achouhan09
Copy link
Member

@achouhan09 achouhan09 commented Sep 25, 2024

Explain the changes

  1. Printing overriden vars in cli command noobaa diagnostics report.

Output:
Screenshot from 2024-09-25 16-41-49

Testing Instructions:

  1. After installing noobaa try running noobaa diagnostics report cli command to check the status.

@achouhan09 achouhan09 requested review from Neon-White, liranmauda, shirady, a team and vh05 and removed request for a team September 25, 2024 07:17
Copy link
Contributor

@shirady shirady left a comment

Choose a reason for hiding this comment

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

LGTM

pkg/diagnostics/report.go Outdated Show resolved Hide resolved
@shirady
Copy link
Contributor

shirady commented Sep 25, 2024

@achouhan09 Could you please update the testing instructions in the PR?

@Neon-White
Copy link
Contributor

I was just wondering - is there a reason we're only checking the core pod for overrides? I think it'd be very useful and important to check one of the endpoints as well

@achouhan09
Copy link
Member Author

I was just wondering - is there a reason we're only checking the core pod for overrides? I think it'd be very useful and important to check one of the endpoints as well

@Neon-White Yes, make sense. I have added a check for endpoint as well. Thanks

pkg/diagnostics/report.go Outdated Show resolved Hide resolved
pkg/diagnostics/report.go Outdated Show resolved Hide resolved
pkg/diagnostics/report.go Outdated Show resolved Hide resolved
pkg/diagnostics/report.go Outdated Show resolved Hide resolved
@liranmauda
Copy link
Contributor

I was just wondering - is there a reason we're only checking the core pod for overrides? I think it'd be very useful and important to check one of the endpoints as well

I was just wondering - is there a reason we're only checking the core pod for overrides? I think it'd be very useful and important to check one of the endpoints as well

@Neon-White Yes, make sense. I have added a check for endpoint as well. Thanks

@Neon-White @achouhan09 Do we also need to add the proxy check on the endpoint?

@achouhan09
Copy link
Member Author

I was just wondering - is there a reason we're only checking the core pod for overrides? I think it'd be very useful and important to check one of the endpoints as well

I was just wondering - is there a reason we're only checking the core pod for overrides? I think it'd be very useful and important to check one of the endpoints as well

@Neon-White Yes, make sense. I have added a check for endpoint as well. Thanks

@Neon-White @achouhan09 Do we also need to add the proxy check on the endpoint?

Not sure, but for proxy changes I need to update the operator deployment and then it will get reflected to other pods, so for proxy status we can check for any one of the core/endpoint is updated or not. @Neon-White pls correct me if I am wrong.

@Neon-White
Copy link
Contributor

@achouhan09 @liranmauda
"After configuring the cluster-wide proxy, the Operator Lifecycle Manager (OLM) triggers automatic updates to all of the deployed Operators with the new contents of the HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables."

Ideally, this is how users would configure their proxies, which would be a reliable way to detect it.
Depending on how proactive we want to be, it can still be valuable to check the core and endpoint individually, on top of the operator, just in case the customer applied a proxy on them in particular.

@liranmauda
Copy link
Contributor

@achouhan09 @liranmauda "After configuring the cluster-wide proxy, the Operator Lifecycle Manager (OLM) triggers automatic updates to all of the deployed Operators with the new contents of the HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables."

Ideally, this is how users would configure their proxies, which would be a reliable way to detect it. Depending on how proactive we want to be, it can still be valuable to check the core and endpoint individually, on top of the operator, just in case the customer applied a proxy on them in particular.

Great!
@achouhan09 lets merge this PR, and then create a new PR for the proxy to check on both core, and operator

@achouhan09 achouhan09 merged commit 7611fca into noobaa:master Sep 30, 2024
14 checks passed
@achouhan09 achouhan09 deleted the config_js_var branch September 30, 2024 06:25
pkg/diagnostics/report.go Outdated Show resolved Hide resolved
pkg/diagnostics/report.go Outdated Show resolved Hide resolved
pkg/diagnostics/report.go Outdated Show resolved Hide resolved
pkg/diagnostics/report.go Outdated Show resolved Hide resolved
Comment on lines +67 to +90
fmt.Print("Overridden Environment Variables Check (NOOBAA-CORE):\n----------------------------------\n")
foundCoreEnv := false
for _, envVar := range coreApp.Spec.Template.Spec.Containers[0].Env {
if strings.HasPrefix(envVar.Name, "CONFIG_JS_") {
fmt.Printf(" ✔ %s : %s\n", envVar.Name, envVar.Value)
foundCoreEnv = true
}
}
if !foundCoreEnv {
fmt.Printf(" ❌ No overridden environment variables found.")
}
fmt.Println("")

fmt.Print("Overridden Environment Variables Check (ENDPOINT):\n----------------------------------\n")
foundEndpointEnv := false
for _, envVar := range endpointApp.Spec.Template.Spec.Containers[0].Env {
if strings.HasPrefix(envVar.Name, "CONFIG_JS_") {
fmt.Printf(" ✔ %s : %s\n", envVar.Name, envVar.Value)
foundEndpointEnv = true
}
}
if !foundEndpointEnv {
fmt.Printf(" ❌ No overridden environment variables found.")
}
Copy link
Contributor

Choose a reason for hiding this comment

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

This duplication can be a function that gets a kubernetes object and is called twice, once for core sts and a second time for endpoint deployment.
@achouhan09 Create a new PR that consolidates those into a single function.

Comment on lines +19 to +32
coreApp := util.KubeObject(bundle.File_deploy_internal_statefulset_core_yaml).(*appsv1.StatefulSet)
coreApp.Namespace = options.Namespace
if !util.KubeCheck(coreApp) {
log.Fatalf(`❌ Could not get core StatefulSet %q in Namespace %q`,
coreApp.Name, coreApp.Namespace)
}

// Fetching endpoint configurations
endpointApp := util.KubeObject(bundle.File_deploy_internal_deployment_endpoint_yaml).(*appsv1.Deployment)
endpointApp.Namespace = options.Namespace
if !util.KubeCheck(endpointApp) {
log.Fatalf(`❌ Could not get endpoint Deployment %q in Namespace %q`,
endpointApp.Name, endpointApp.Namespace)
}
Copy link
Contributor

Choose a reason for hiding this comment

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

This duplication can be a function that gets a kubernetes object and is called twice, once for core sts and a second time for endpoint deployment.
@achouhan09 Create a new PR that consolidates those into a single function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants