Re: [atomic-devel] Changing partitioning defaults discussion

[Dusty Mabe <dusty dustymabe com>]

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