vgoyal added a new comment to an issue you are following:
``
I think I am missing something. So rootfs which used to be 3G by default will
now be 15G by default.
Ok, so for cloud images we will continue to have volume group and when image is
grown, additional space will go in volume group and
vgoyal added a new comment to an issue you are following:
``
So this relies on that fact that atomic users will not use devicemapper graph
driver. If they really need to use devicemapper, they will need to add
additional disk. (Which requires extra effort and planning).
So has this been
vgoyal added a new comment to an issue you are following:
``
@dustymabe Just merged the changes for CONTAINER_ROOT_LV_NAME and
CONTAINER_ROOT_LV_MOUNT_PATH usptream.
If you like, you might want to give it a try.
``
To reply, visit the link below or just reply to this email
vgoyal added a new comment to an issue you are following:
``
Right, ROOT can be confusing. We already have a knob called "ROOT_SIZE" which
specifies the size of rootfs of system.
While one can argue that prefixing ROOT with CONTAINER should remove that
confusion.
So I can live with
vgoyal added a new comment to an issue you are following:
``
> Lets go with
> CONTAINER_LV_NAME
> CONTAINER_LV_MOUNT_PATH
I am fine with these names.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/186
vgoyal added a new comment to an issue you are following:
``
> This script will only set up the thin pool when you are using devicemapper
> right? So the script would only make a thin pool LV when running for dm and
> only make a regular LV when running for overlay. So one type of volume gets
vgoyal added a new comment to an issue you are following:
``
@dustymabe why your comments are appearing twice?
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/186
___
cloud mailing list --
vgoyal added a new comment to an issue you are following:
``
> I would vote that we keep it easy for the user. Why don't we have
> CONTAINER_ROOT_VOLUME=yes instead of DOCKER_ROOT_VOLUME=yes.
Problem with that is that we don't know where to mount the volume after
creation. Right now, we mount
vgoyal added a new comment to an issue you are following:
``
Thinking more about it. I think EXTRA_VOLUME_NAME is more intuitive. Reason
being that this script sets up thin pool volume as well and that's a container
volume too. EXTRA sort of makes it explicit
that this volume is on top regular
vgoyal added a new comment to an issue you are following:
``
We are making docker-storage-setup more generic (to be usable by other
container runtime as well, apart from docker). So in an attempt to do that, we
are introducing new options.
EXTRA_VOLUME_NAME="docker-root-lv"
vgoyal added a new comment to an issue you are following:
``
@dwalsh yes, reset of storage should remove docker-root-lv automatically. If it
does not, then it is a bug which should be taken care of.
Also @chrismurphy mentioned that he tried migrating from devicemapper to
overlay2. I am
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
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
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
vgoyal added a new comment to an issue you are following:
``
> What I'm hearing is the "flip back to devicemapper without repartitioning"
> path doesn't actually exist.
Flipping back to devicemapper will require free space. And that would be
possible only if ext4 and xfs had online shrink
vgoyal added a new comment to an issue you are following:
``
I think you will have to destroy all images and containers stored in overlay
and then setup devicemapper from that freed space.
Having said that, in theory a path might exist. If overlay2 does not use all
free space, then in theory,
vgoyal added a new comment to an issue you are following:
``
Sharing rootfs and overlay2 makes configuration easy. Agreed with that. But 2)
is a requirement. If overlay2 does not work for a user, we want them an option
to go back to devicemapper.
overlay2 is fairly new and is not fully posix
vgoyal added a new comment to an issue you are following:
``
> So I just did a test of using OverlayFS on Fedora Atomic 25 as a cloud-init
> option. This resulted in having the whole disk as one volume, shared with
> the overlay, instead of multiple partitions. That's the desireable default
>
vgoyal added a new comment to an issue you are following:
``
if you use DOCKER_ROOT_VOLUME=yes, that will create a new logical volume,
create xfs filesystem on it, and mount it on /var/lib/docker/. And now if you
are using overlay2 driver, it should put all images, containers and volumes on
vgoyal added a new comment to an issue you are following:
``
Upstream dokcer-storage-setup will continue to have devicemapper as default
graph driver. So for this to work properly on atomic host, we probably require
following two options set in /etc/sysconfig/docker-storage-setup.
vgoyal added a new comment to an issue you are following:
``
If we want to give all the free space to docker by default, then we will also
have to set.
DOCKER_ROOT_VOLUME_SIZE=100%FREE
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/186
21 matches
Mail list logo
