Skip to content

Printing overrided vars in cli command noobaa diagnostics report#1445

Merged
aayushchouhan09 merged 2 commits intonoobaa:masterfrom
aayushchouhan09:config_js_var
Sep 30, 2024
Merged

Printing overrided vars in cli command noobaa diagnostics report#1445
aayushchouhan09 merged 2 commits intonoobaa:masterfrom
aayushchouhan09:config_js_var

Conversation

@aayushchouhan09
Copy link
Member

@aayushchouhan09 aayushchouhan09 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.

@aayushchouhan09 aayushchouhan09 requested review from a team, Neon-White, liranmauda, shirady 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

@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

@aayushchouhan09
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

@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?

@aayushchouhan09
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.

Signed-off-by: Aayush Chouhan <achouhan@redhat.com>
@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

Signed-off-by: Aayush Chouhan <achouhan@redhat.com>
@aayushchouhan09 aayushchouhan09 merged commit 7611fca into noobaa:master Sep 30, 2024
@aayushchouhan09 aayushchouhan09 deleted the config_js_var branch September 30, 2024 06:25
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