2:12 p.m.
On 06/05/2017 02:19 PM, Colin Walters wrote:
On Mon, Jun 5, 2017, at 01:58 PM, Dusty Mabe wrote:
>
> One qualification - we use overlay2 by default, but we are going to be
> placing all of /var/lib/docker/ on its own filesystem:
>
> $ cat /etc/sysconfig/docker-storage-setup
> # Edit this file to override any configuration options specified in
> # /usr/share/container-storage-setup/container-storage-setup.
> #
> # For more details refer to "man container-storage-setup"
> STORAGE_DRIVER=overlay2
> CONTAINER_ROOT_LV_NAME=docker-root-lv
> CONTAINER_ROOT_LV_MOUNT_PATH=/var/lib/docker
> GROWPART=true
Yes. I think I'm proposing we keep that
behavior for F26, and change rawhide to remove the separate LV
by default.
OK. To be clear, all of this is for rawhide and onward, not F26. Got
it.
If we are going to officially make that proposal can we open a ticket
for it in the atomic-wg pagure? I know many of us have talked about
it, but I would like to formalize that as our strategy.
(Hmm, a detail here is that because we frob GROWPART=true
in the kickstart, ostree will from then on think it's user-modified
and not take on new defaults =( Will have to think about fixing that)
I agree that this pattern (modifying things in kickstart) is something
we'll have to think about, but this particular case shouldn't worry us
too much because when you are rpm-ostree upgrading your storage should
have been set up already, right? I guess there are corner cases where
you blow away your storage and start over. For cloud cases you might as
well blow everything away and start over.
> One case this would affect is booting the qcow directly on
kvm/libvirt
> without extending the disk image or adding another disk first.
Yes. And while I'm sure people do that...I think in practice
that use case should go into one of:
- ISO install into VM ("pet"/"elephant" machines)
- vagrant (transient dev/test environments)
(Of course one can the ISO for dev/test and vagrant for pet/elephant machines
too but talking about the "defaults" of the tools here)
Yeah, I think if we go with overlayfs on / by default then this isn't
an issue.
> If the default was to just put overlayfs on the root filesystem
then i
> think this would work fine. If not, then we are basically forcing the
> vagrant user to add another disk for container storage.
Yeah, in fact let me break this out as a sub-proposal - the Vagrant
box for F26 changes to "one big /".
If none of these changes are for f26 then i don't see a reason to
change the vagrant box. One nice thing about the vagrant box being
*somewhat similar* to the cloud base qcow2 is that we have some
overlap for test coverage/finding issues. If we move both the qcow
and the vagrant boxes to "overlayfs on /" for rawhide/f27 will that
be satisfactory?
> Am i correct in my assumption that the patch below only affects
ISO
> installs that don't use a kickstart and just use the defaults?
Not quite; it also affects kickstart users that use `autopart`.
>> + defaultFS = "xfs"
>
> Not used anywhere that I can see
I think this is sucked into the blivet layer - so if the user is choosing
filesystems interactively in the GUI, that's what it'll use for example.
I bet it also comes back to us as `storage.default_fstype`.
Yeah - I see this in pyanaconda/installclass.py
# The default filesystem type to use. If None, we will use whatever
# Blivet uses by default.
defaultFS = None
A few questions:
- Why not stick with the distro default?
- If we have a good reason can we do this in a different commit with a
commit message that is relevant?
> Could this be removed in a separate commit to explain why it is being
> removed?
Broadly we're matching Server. You're correct to call this out though -
it will change to the new Fedora default of 1G (which to me feels
really excessive but we're not yet changing the cloud environment)
Good info for a commit message :)
Dusty