search

IBM / operator-for-redis-cluster

IBM Operator for Redis Cluster
https://ibm.github.io/operator-for-redis-cluster
MIT License
60 stars 34 forks source link

Doesn't build on Windows #92

Open WallucePinkham opened 1 year ago

WallucePinkham commented 1 year ago

This is a GO application, it should be easy to build on Windows.

cin commented 1 year ago

Can you provide some more context please on what you're trying to do? Are you trying to run the operator on Windows containers? TBH, that's not a use case we've ever considered. That said, if there is a valid use case for this, let's discuss. We do accept PRs. :)

WallucePinkham commented 1 year ago

Hi,No, I just want to build and install the operator from a windows machine.The normal ‘go build’ that I am used to using doesn’t work, and the makefile seems to depend on some non-windows commands, like tail.I was unable to find a Windows binary, but I admit I could have searched harder.Regards,Walluce PinkhamOn 8 Feb 2023, at 15:40, Craig Ingram @.***> wrote: Can you provide some more context please on what you're trying to do? Are you trying to run the operator on Windows containers? TBH, that's not a use case we've ever considered. That said, if there is a valid use case for this, let's discuss. We do accept PRs. :)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

cin commented 1 year ago

Understood. I think the closest you can get to running the operator and its components under Windows is by using WSL2 and Kind (or similar tooling).

WallucePinkham commented 1 year ago

Understood, thanks. It’s just a shame because it’s a go application and it should run fine on Windows.Regards,Walluce PinkhamOn 9 Feb 2023, at 19:30, Craig Ingram @.***> wrote: Understood. I think the closest you can get to running the operator and its components under Windows is by using WSL2 and Kind (or similar tooling).

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

cin commented 1 year ago

The operator still needs Kubernetes to do its job -- managing a Redis cluster. Are you trying to get the operator to manage a Redis cluster running remotely or something?

WallucePinkham commented 1 year ago

Hi, yes, the cluster is running remotely, or on k3s, or in minikube or in docker desktop, it doesn’t really matter. All I want to do is to build and install the operator from my windows machine. The rest is 100% standard k8s workflow with kubectl, helm, etc.Regards,Walluce PinkhamOn 9 Feb 2023, at 22:19, Craig Ingram @.***> wrote: The operator still needs Kubernetes to do its job -- managing a Redis cluster. Are you trying to get the operator to manage a Redis cluster running remotely or something?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

cin commented 1 year ago

Ah, I see. I don't see this being a common (or desirable) use case the operator should support. To be frank, you'd be losing all the resiliency and flexibility running on k8s provides. This would also introduce security holes as the operator would be making remote calls to Redis pods and there is no authentication or encryption in place (because all traffic between the operator and pods was designed to be constrained w/in a k8s cluster). I'm also not sure how the operator would even communicate w/the Redis pods as their ports are not exposed to the outside world. You could use hostPorts (but you couldn't share worker nodes if you did) or nodePorts (but then you'd have to have some discovery process in place so the operator would know how to communicate w/the pods) or maybe a proxy (not sure how that would even work); but adding this type of complexity to the operator isn't worth it. You'd also have to enable AUTH and encryption to protect the traffic. It just sounds like a lot of work for little/no gain. I'm not trying to sound harsh here -- just honest.

WallucePinkham commented 1 year ago

Sorry, I think I am not communicating well.I just want to build and install the operator from a windows machine. I don’t want to use WSL because the build agents won’t have that.Thanks for your trouble. It seems I simply have to accept that I will need to find a different operator.Thanks again!Regards,Walluce PinkhamOn 10 Feb 2023, at 17:09, Craig Ingram @.***> wrote: Ah, I see. I don't see this being a common (or desirable) use case the operator should support. To be frank, you'd be losing all the resiliency and flexibility running on k8s provides. This would also introduce security holes as the operator would be making remote calls to Redis pods and there is no authentication or encryption in place (because all traffic between the operator and pods was designed to be constrained w/in a k8s cluster). I'm also not sure how the operator would even communicate w/the Redis pods as their ports are not exposed to the outside world. You could use hostPorts (but you couldn't share worker nodes if you did) or nodePorts (but then you'd have to have some discovery process in place so the operator would know how to communicate w/the pods) or maybe a proxy (not sure how that would even work); but adding this type of complexity to the operator isn't worth it. You'd also have to enable AUTH and encryption to protect the traffic. It just sounds like a lot of work for little/no gain. I'm not trying to sound harsh here -- just honest.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>