ausil merged a pull-request against the project: `fedora-atomic` that you are
following.
Merged pull-request:
``
f26: add back in kube/storage clients for now
``
https://pagure.io/fedora-atomic/pull-request/59
___
cloud mailing list -- cloud@lists.fe
jlebon commented on the pull-request: `f26: add back in kube/storage clients
for now` that you are following:
``
> 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
jberkus commented on the pull-request: `f26: add back in kube/storage clients
for now` that you are following:
``
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 pro
dustymabe commented on the pull-request: `f26: add back in kube/storage clients
for now` that you are following:
``
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 in
jasonbrooks commented on the pull-request: `f26: add back in kube/storage
clients for now` that you are following:
``
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) an
walters commented on the pull-request: `f26: add back in kube/storage clients
for now` that you are following:
``
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 l
walters commented on the pull-request: `f26: add back in kube/storage clients
for now` that you are following:
``
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 "
