search

kubernetes-sigs / kustomize

Customization of kubernetes YAML configurations
Apache License 2.0
10.9k stars 2.24k forks source link

Either test on Windows or remove the windows OS release #791

Closed monopole closed 5 years ago

monopole commented 5 years ago

Until we have feature level test suite on windows, this should be removed. People are free to build on windows on their own.

pwittrock commented 5 years ago

FWIW, we build kubectl for windows without tests.

PatrickLang commented 5 years ago

kubelet, kube-proxy, and parts of kubectl (via conformance suit) are tested on Windows on both Azure and GCP

cc @yujuhong and @pjh

brendandburns commented 5 years ago

cc @parispittman @mattfarina

I believe that we should mandate support for all major OSs (indeed Windows is the majority OS by far) for all tools that we are building. The right fix isnt to disable windows, it's for kustomize folks to add tests.

Matt, let's discuss this in sig-arch.

yujuhong commented 5 years ago

kubelet, kube-proxy, and parts of kubectl (via conformance suit) are tested on Windows on both Azure and GCP

For GCE, we tests kubelet/kube-proxy primarily through e2e tests. More tests (e.g., unit tests) should be added in the future. AFAIK I don't think we are testing the kubectl windows binary in those tests since it requires running the tests on a Windows machine. I agree that tests should be added though.

monopole commented 5 years ago

@brendandburns Contributions >> mandates. PR/infrastructure welcome.

mattfarina commented 5 years ago

@monopole Kustomize was merged into kubectl (see https://github.com/kubernetes/kubernetes/pull/73033). How does kustomize in kubernetes-sigs relate to the kustomize that was part of that PR? Some clarity there would help.

@brendandburns are you suggesting a strategy for our client tooling for supported OSes? It might be better to take this to the mailing list to start. So folks can have time to think and talk about it. Did you want to start a thread there?

monopole commented 5 years ago

@mattfarina kubectl depends on some subset of the ~1300 packages in k/k/vendor; ~25 of those now come in from the kustomize repo. We'd be happy to have some PRs putting those kustomize packages through the same Windows qualification process that the other packages are subjected to. Also accepting PRs to enhance the current kubectl-on-Windows release process that @PatrickLang alluded to to cover kustomize functionality. Can someone with more Windows knowledge send PRs, or at lease a link to PRs in this vein (testing kubectl on Windows) that we could use as a model?

brendandburns commented 5 years ago

Hey @monopole you (and anyone else in the project) can't make unanimous decisions about things like this. This is precisely why SIG-Architecture and SIG-Contributor Experience exist.

This needs to be discussed in these forums.

@mattfarina do you want me to start a thread on SIG-Arch/SIG-ContribEx/SIG-CLI?

kenmaglio commented 5 years ago

@brendandburns Thank you for your comments. It's been a struggle for me personally to be 'pounced' on in my PR

How would I join in on the forums?
Follow groups here?

monopole commented 5 years ago

@brendandburns I'm requesting help with Windows testing.

brendandburns commented 5 years ago

@kenmaglio SIG-Arch info is here: https://github.com/kubernetes/community/tree/master/sig-architecture

@monopole trying to parse your comment, who are you requesting help from?

Just to be totally clear: kustomize is a Kubernetes SIG project, this means that it is subject to the standards of the kubernetes project writ large.

Currently, I don't think there is clarity about whether we believe that shipping a windows client binary is a requirement for a Kubernetes command line tool(s). I fairly strongly believe that it should be a requirement, but again, it's not for me to decide, it's a topic for SIG-Arch. in my opinion.

fwiw, if we do decide that shipping a windows binary is an expectation, then it is up to the kustomize engineering owners (SIG CLI) to ensure that there is adequate test coverage before things like a kustomize GA (the prior expectations around this have already been pretty clearly covered in the discussions around requirements for the Windows + k8s GA)

@mattfarina what's the protocol for getting this into SIG-Arch for discussion? Do you want me to add it to an agenda doc? Or should one of the SIG-Arch leads?

mattfarina commented 5 years ago

@brendandburns Sorry I didn't get to this before today's SIG Arch meeting. You can add agenda items to the SIG Arch agenda. The chairs will clean up the listings and add time boxing if not already there. If you have something you want to talk about always feel free to add it to the agenda.

@monopole I'm still not entirely sure of the relationship between kustomize here and the kustomize that was merged into kubectl via https://github.com/kubernetes/kubernetes/pull/73033. Can you elaborate?

I see that TravisCI is used here for testing. Could I suggest using https://www.appveyor.com/ to do Windows testing in the same way? This should be an easy method that follow the current pattern used by this repo.

monopole commented 5 years ago

@brendandburns Filed #834. Would love to have testing on Windows, and help from someone who knew more about the available infra for it.

@mattfarina appveyor might work?! Will try to find time for it. Thanks for the suggestion.

pwittrock commented 5 years ago

Appreciate @monopole taking a hard stand to force taking action and producing stronger validation of the binaries we are producing for Windows and OSX. If someone had done this for kubectl 4 years ago maybe we would be in a better spot w.r.t. kubectl testing on Windows and OSX and avoided some of the issues we have had with both of those platforms.

To provide some context on why this is important - while go does cross compile for multiple platforms, it compiles different source code for each (go supports platform specific source code). We've seen issues in the past where path was used in place of filepath and resulted in undesirable behavior on Windows only and discovered only after a release. Additionally, we've seen bugs in the platform specific cross compilation itself, resulting in OSX builds frequently panicing (only on OSX).

All that said, I suggest we close this in favor of #834, which @kenmaglio has volunteered to tackle (thanks!). I believe this was more about raising awareness on the state of the world and forcing action to make the right things happen than it was about removing support from any platform (which isn't a practical course of action).