--
You received this message because you are subscribed to the Google Groups "steering" group.
To unsubscribe from this group and stop receiving emails from it, send an email to steering+u...@kubernetes.io.
To view this discussion on the web visit https://groups.google.com/a/kubernetes.io/d/msgid/steering/CANw6fcHzi%2B2s4z2o41Pd%3DFcdLnJNYWGdeXMZ%2BqCvfWvYQDRqLg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/kubernetes.io/d/msgid/steering/CAH16Sh%2B6nw6SULXkX%2BYu0RahjbvhzA9AfXnpvv%2BM5Sb8d37f6Q%40mail.gmail.com.
Yeah – this seems to be really complicated. Agree on KEP.
There are some places where clearly things are too vendory. We don’t want the project docs to be overly tied to any single commercial product. (less so with other openly governed oss projects)
But there are places where we *should* have some pointers. Specifically I’m thinking about installing networking as part of a kubeadm cluster. That documentation is super useful and it does a decent job of pointing to external solutions without making it be about those solutions. See how the vendor specific content is restricted to a set of tabs without any favorites: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network.
We should focus on making users successful first and being “pure” second.
Joe
To view this discussion on the web visit
https://groups.google.com/a/kubernetes.io/d/msgid/steering/CAHHNuYfHnmNjpEGjz2%2BbyDzwDLzr%2B%3DeZvmCDDhYTCPBJ7UJ6wQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/kubernetes.io/d/msgid/steering/FD671155-AED2-43C1-9A85-0D704877B675%40vmware.com.