kubeadm repo is soon going to host the codebase for three deliverables:
The main reason for keeping for this approach is to ensure consistent versioning/branching strategy across the three deliverables (1 and 2 must-have, 3 nice to have).
This issue is for deciding how to organize the folder three in order to get this managed properly
Please give a +1 your preferred option or propose a new one.
@neolit123
@ereslibre
@yagonobre
@yastij
@rosti
Proposal 1.
`\`
`\cmd` or `\cli` for kubeadm itself (currently in k/k under `/cmd/kubeadm/*`)
`\operator` for the kubeadm operator
`\kinder` for kinder
Proposal 2.
`\`
`\cmd`
`\cmd\app` for kubeadm app (currently in k/k under `/cmd/kubeadm/app`)
`\cmd\test` for kubeadm test (currently in k/k under `/cmd/kubeadm/test`)
`\cmd\test\kinder` for kinder (currently in k/kubeadm under `/kinder`)
`\cmd\operator` for the kubeadm operator
@fabriziopandini +1 on the first proposal. This would allow us to split things later if needed and control the import tree.
TBD - Should we take ownership of the packaging and release goo from here.
seems natural that we should own the packaging and realease process
@yastij I'm ok for the kubeadm-operator/kinder, not sure about kubeadm because I assume it will continue to be part of the main Kubernetes release package
cc @kubernetes/sig-release
because I assume it will continue to be part of the main Kubernetes release package
from my brief discussion with @justaugustus about this, there is still desire to include kubeadm as part of the release (e.g. tarbals). we need to talk more about this.
@fabriziopandini it might be better to have a umbrella issue in k/kubeadm for kubeadm moving out and the topic in this issue could be part of the discussion there.
@neolit123 fine for me!
folding this into https://github.com/kubernetes/kubeadm/issues/1949 with a note.
Most helpful comment
Proposal 1.