Re: Prerequisites to removing Kube from base image

On 01/09/2017 04:21 PM, Josh Berkus wrote: > Of course, those issues are pretty broad requirements. Realistically, I > don't see getting this done by F26 just because of the outstanding > issues with a containerized install. What are the outstanding issues? I know

[atomic-wg] Issue #186 `switch to overlay2`

vgoyal added a new comment to an issue you are following: `` > When hosted in the cloud, isn't it typical to charge for allocated space > whether it's actively used or not? Not sure, what this has to do with how we partition the storage between rootfs and docker. > > jberkus > If that reason

[atomic-wg] Issue #186 `switch to overlay2`

dustymabe added a new comment to an issue you are following: `` > And what happens if the user doesn't provide anything? That's the "defaults" > case. This is the big question. We are essentially debating over if we should enable `DOCKER_ROOT_VOLUME=yes` by default or not. `` To reply,

Re: Prerequisites to removing Kube from base image

On Mon, Jan 9, 2017 at 1:21 PM, Josh Berkus wrote: > Atomic WG: > > I've filed four issues which I think represent the prerequisites to > making removal of the kubernetes binaries from the base Atomic image work. > > https://pagure.io/atomic-wg/issues?status=Open=remove-kube >

[atomic-wg] Issue #186 `switch to overlay2`

chrismurphy added a new comment to an issue you are following: `` > dustymabe > with DOCKER_ROOT_VOLUME and overlayfs using that then all of /var/lib/docker > would be taken care of. Please let me know if I'm wrong. It'll work on a conventional installation. I'm skeptical it'll work on an

[atomic-wg] Issue #188 `Remove-Kube: produce official containers with Kubernetes components`

jberkus reported a new issue against the project: `atomic-wg` that you are following: `` In order to remove Kubernetes from the AH base image and have a full containerized Kube install, we need to have "official" kubernetes containers produced by the Fedora project. They need to be

[atomic-wg] Issue #189 `Remove-Kube: document new Kubernetes install process`

jberkus reported a new issue against the project: `atomic-wg` that you are following: `` Once we have working, containerized Kubernetes install process, we'll need to write documentation for it. `` To reply, visit the link below or just reply to this email

Prerequisites to removing Kube from base image

Atomic WG: I've filed four issues which I think represent the prerequisites to making removal of the kubernetes binaries from the base Atomic image work. https://pagure.io/atomic-wg/issues?status=Open=remove-kube Of course, those issues are pretty broad requirements. Realistically, I don't see

[atomic-wg] Issue #186 `switch to overlay2`

dustymabe added a new comment to an issue you are following: `` >>dustymabe >>I would like to also point out that one other benefit would be to prevent >>containers from cannibalizing your root partition. > > Not possible by making /var a separate file system, you'd have to use quotas. >

[atomic-wg] Issue #186 `switch to overlay2`

vgoyal added a new comment to an issue you are following: `` > > vgoyal > IIUC, you are saying that use a thin LV for rootfs to work around xfs shrink > issue? People have tried that in the past and there have been talks about > that many a times. There are still issues with xfs on top of thin

[atomic-wg] Issue #186 `switch to overlay2`

jberkus added a new comment to an issue you are following: `` Dusty: Right, and that question comes down to "how much do we care about revertability VS. user experience". It's not an easy question to answer. In the long run, DOCKER_ROOT_VOLUME=no as default is the obvious answer. But for

[atomic-wg] Issue #190 `Remove-Kube: Determine and document migration process`

jberkus reported a new issue against the project: `atomic-wg` that you are following: `` We will need to figure out, and then fully document, a migration process for users of the old built-in Kubernetes binaries to upgrade to F26 with containerized binaries. `` To reply, visit the link below

[atomic-wg] Issue #186 `switch to overlay2`

chrismurphy added a new comment to an issue you are following: `` >dustymabe >Am I missing something? Did I make some bad assumptions somewhere in this test? Nope, works for me as well. /var is still a directory on the ext4 rootfs, but it looks like a new LV Is created at 40% of the free space

Re: About the recent failures of Atomic images on Autocloud

On Mon, Jan 09, 2017 at 10:16:51AM -0500, Dusty Mabe wrote: > > I finally managed to reproduce the error on a local box. After doing the > > reboot like in [1], the tool can not ssh back into the vm. When I tried > > the same on debug mode on, it still fails for some time, and then > > randomly

[Fedocal] Reminder meeting : Fedora Cloud Workgroup

Dear all, You are kindly invited to the meeting: Fedora Cloud Workgroup on 2017-01-11 from 17:00:00 to 18:00:00 UTC At fedora-meetin...@irc.freenode.net The meeting will be about: Standing meeting for the Fedora Cloud Workgroup Source:

[atomic-wg] Issue #186 `switch to overlay2`

vgoyal added a new comment to an issue you are following: `` > Flipping from one to the other will take free space somewhere for the 'atomic > storage export/import' operation to temporarily store docker images and > containers to. > A way around the xfs lack of shrink issue is to put the

About the recent failures of Atomic images on Autocloud

Hi, I finally managed to reproduce the error on a local box. After doing the reboot like in [1], the tool can not ssh back into the vm. When I tried the same on debug mode on, it still fails for some time, and then randomly allows to ssh again. I could not reproduce this using the same images

Re: About the recent failures of Atomic images on Autocloud

On 01/09/2017 08:31 AM, Kushal Das wrote: > Hi, > > I finally managed to reproduce the error on a local box. After doing the > reboot like in [1], the tool can not ssh back into the vm. When I tried > the same on debug mode on, it still fails for some time, and then > randomly allows to ssh

[atomic-wg] Issue #186 `switch to overlay2`

jberkus added a new comment to an issue you are following: `` So, to summarize: 1. The main reason given for keeping "two partitions" by default with docker-storage-setup is so that users can easily switch back to devicemapper if there are critical issues with OverlayFS. 2. However, there is

[atomic-wg] Issue #186 `switch to overlay2`

jberkus added a new comment to an issue you are following: `` @dwalsh see comments above about why those tools won't actually work in practice. If we can work around those, then that changes things. But right now what I'm hearing is "you can switch back, but only if you have unallocated

[atomic-wg] Issue #186 `switch to overlay2`

jberkus added a new comment to an issue you are following: `` Also, using partitioning to limit Docker's space consumption only makes sense if we can somehow automagically "right-size" the two partitions. In our current code, it doesn't matter how much space docker eats up, because we've only

[atomic-wg] Issue #186 `switch to overlay2`

dwalsh added a new comment to an issue you are following: `` @jberkus The tools will work fine if you just want to start fresh and blow away your container images. ``` atomic storage reset ``` Should delete everything, then you change your default backend using ``` atomic storage modify

[atomic-wg] Issue #186 `switch to overlay2`

jberkus added a new comment to an issue you are following: `` @dwalsh aha. The current docks emphasize export/import, so I thought it was required. Lemme test that, but if it works that's a powerful argument for maintaining dual partitions for backwards compatibility. If we're doing that,

[atomic-wg] Issue #186 `switch to overlay2`

dwalsh added a new comment to an issue you are following: `` I disagree with 2. We have tools that allow you to switch back to devicemapper if their is partioning, which is why we want to keep partitioning. If this was easy to switch from no partioning to partitioned, then I would agree

[atomic-wg] Issue #186 `switch to overlay2`

dustymabe added a new comment to an issue you are following: `` > The main reason given for keeping "two partitions" by default with > docker-storage-setup is so that users can easily switch back to devicemapper > if there are critical issues with OverlayFS. I would like to also point out that

[atomic-wg] Issue #186 `switch to overlay2`

dustymabe added a new comment to an issue you are following: `` >> The main reason given for keeping "two partitions" by default with >> docker-storage-setup is so that users can easily switch back to devicemapper >> if there are critical issues with OverlayFS. > > I would like to also point

[atomic-wg] Issue #186 `switch to overlay2`

dustymabe added a new comment to an issue you are following: `` > If we're doing that, though, is there anything we can do about sizing the > rootfs better? there is the `ROOT_SIZE` variable in docker-storage-setup that allows you to specify the size of the root partition. We could

[atomic-wg] Issue #186 `switch to overlay2`

chrismurphy added a new comment to an issue you are following: `` >vgoyal >IIUC, you are saying that use a thin LV for rootfs to work around xfs shrink >issue? People have tried that in the past and there have been talks about that >many a times. There are still issues with xfs on top of thin

[atomic-wg] Issue #187 `Remove-Kube: Make fully containerized install work`

jberkus reported a new issue against the project: `atomic-wg` that you are following: `` This is one of several issues which need to be overcome in order to remove Kubernetes from the base Atomic Host image. This issue is a tracking issue for the various technical problems and bugs which