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
_______________________________________________
cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
