#59 f26: add back in kube/storage clients for now
Merged 6 years ago by ausil. Opened 6 years ago by dustymabe.
dustymabe/fedora-atomic dusty-f26  into  f26

@@ -112,9 +112,13 @@ 

           "cockpit-docker",

           "cockpit-networkmanager",

           "cockpit-ostree",

+          "kubernetes", "etcd",

+          "flannel",

           "docker",

           "python-docker-py",

           "iscsi-initiator-utils",

+          "glusterfs", "glusterfs-fuse",

+          "ceph-common",

           "oddjob-mkhomedir",

           "oci-register-machine",

           "oci-systemd-hook",

For f26 we will promote containerized kube via system containers [1]
and also experiment with rpm-ostree livefs [2] as a method to add in new
software without a reboot. While we experiment, we will leave in kube
for f26.

[1] http://www.projectatomic.io/blog/2017/05/system-containerized-kube/
[2] https://github.com/projectatomic/rpm-ostree/pull/652

I don't quite understand what livefs has to do with this. If one is doing a major version upgrade from f26 → f27, it's easy to re-layer kube at that time as well now that we have "multiple operation" support since https://github.com/projectatomic/rpm-ostree/releases/tag/v2017.2

Basically:

rpm-ostree rebase fedora/27/x86_64/atomic-host
rpm-ostree install kubernetes

Should work, and clearly major version rebases are going to require a reboot - and that's why I'm not sure what livefs has to do with this.

This is a pretty major change; I'm OK with it but it feels unfortunate. For people who want to use a different Kube, having to override things is going to be annoying. It looks like our prototype Kube system containers currently use the same systemd service names for example.

But, we can work through those issues.

It shouldn't be annoying at all. Our containers use the same systemd service names on purpose -- you drop them into /etc/systemd/system (or system containers does it for you) and they override what's built into the image.

There are only two downsides to this change. We don't get a smaller image (it stays the same as it is now, in f25), and there's a conflict if you want to use package layering to install different versions of kube rpms. I don't think fedora kube rpms are being built by anyone outside of fedora, though, so I don't know how worrisome that should be.

On the livefs point, there are new installs to consider -- bring up a new atomic host, if you want kube layered in, you need to reboot.

I think @jasonbrooks summed it all up pretty well. I was thinking less about the f26 -> f27 path and more about the kubernetes doesn't come by default and i'm starting a new instance path.

as @walters stated we can handle the f26->f27 with rebase followed by install and livefs really has no implication there.

The bigger point is that:

a) we don't have official kube system containers yet.

b) none of our users have tried the containers we do have, so we have no idea how they work in production

Basically:
rpm-ostree rebase fedora/27/x86_64/atomic-host rpm-ostree install kubernetes

Just in case this ticket yields documentation/blog posts or gets referred to by users, one can do this even more efficiently in the latest rpm-ostree:

rpm-ostree rebase fedora/27/x86_64/atomic-host --install kubernetes

For more information, see http://www.projectatomic.io/blog/2017/04/rpm-ostree-v2017.4-released/.

Pull-Request has been merged by ausil

6 years ago
Metadata