search

noobaa / noobaa-operator

Operator for NooBaa - object data service for hybrid and multi cloud environments :cloud: :wrench:
https://www.noobaa.io
Apache License 2.0
103 stars 101 forks source link

Printing overrided vars in cli command `noobaa diagnostics report` #1445

Closed achouhan09 closed 1 month ago

achouhan09 commented 1 month ago

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.
shirady commented 1 month ago

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

Neon-White commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

@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