With the goal of slimming down the size of our atomic host image and of allowing users the flexibility to choose different component versions, we removed kubernetes and few other packages from the continuous/alpha version of centos atomic host back in august[1].
[1] https://github.com/CentOS/sig-atomic-buildscripts/commit/3ce19d58a5f1d9b5d54...
Fedora made a similar change[2] in Fedora Atomic 25.
[2] https://pagure.io/fedora-atomic/c/219c9bb26426811a5f32188c59682ad70c3283e5
RHEL Atomic host, in the 7.3 version, went halfway and removed the master half of kubernetes, but left the node half of the package in place. When we update the downstream version of CentOS Atomic Host, if we follow the lead of RHEL AH, we'll be pinned to kubernetes 1.3 for the kubelet and kube-proxy, and we'll have to run the master components in containers.
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.
[3] https://copr.fedorainfracloud.org/coprs/jasonbrooks/kubernetes/
The 1.3 kube would still be available in the extras repo (once it's built), and users will have the option of installing that one, if they choose, using package layering. [4]
[4] http://www.projectatomic.io/blog/2016/07/hacking-and-extending-atomic-host/
Either way, we'll need to document this, and I'm working on those docs now.
Jason
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.
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?
On 13 Dec 12:12, Colin Walters 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.
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.
This is not CentOS core. I think if we can provide something that fits the user best than upstream, we should to it.
Maybe however we should adopt another name.
To be clear, you're just talking about -node, not etcd/flannel for example? _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
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 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
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
-
Colin Walters -
Jason Brooks -
Julien Pivotto