On Tue, Dec 13, 2016 at 9:25 AM, Jason Brooks jbrooks@redhat.com wrote:
On Tue, Dec 13, 2016 at 9:12 AM, Colin Walters walters@verbum.org wrote:
On Tue, Dec 6, 2016, at 12:55 PM, Jason Brooks wrote:
I want to discuss diverging from RHEL AH by not including the kubernetes-node pkg in our downstream image. This would allow users to install a newer version of the kubernetes-node, such as this 1.4.5 version from my copr[3] that I hope to see move into the virt-sig soon.
Right. The disadvantage to this is...that people who have masters set up for 1.3 will need to use layering or a container for node.
If anyone wants a 1.3 master after downstream is released, they'll need to use containers to run it, because we're shipping kube 1.2 right now, and we're set not to include the 1.3 master components in the next downstream.
If might make sense instead to put etcd flannel and kube-master back in, so as not to disrupt people who are using them. We do have the option of the alpha branch for those who want a stripped down host.
If we roll the 1.3 kubelet into the image, people could still run a newer kubelet, but they'd have to use a container or separate binary to do it.
Maybe it's not worth diverging at this point, but since the aims of RHEL AH and of CentOS AH are somewhat different, esp wrt kubernetes, which is now supported only in single node mode for RHEL AH, it's not crazy for the package sets we deploy to be different. The actual rpms wouldn't be diverging, just the selection of them.
I'm uncertain, because it seems like a major point of CentOS Core builds is fidelity, even bug-for-bug, and this is a major difference.
To be clear, you're just talking about -node, not etcd/flannel for example?
Right.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel