Re: ws/ostree: Use atomic product img
by Chris Murphy
On Mon, Jul 3, 2017 at 2:57 PM, Owen Taylor <otaylor(a)redhat.com> wrote:
> I don't have any problem with switching to XFS or getting rid of the /home split. The former should be pretty invisible to users, and split home is more of a trap for users than a help.
>
> But switching to leaving most of the disk unpartitioned seems wrong. With the move to overlay2 for Docker storage, everything you want to do with disk space is inside / - the OS image, your overlay RMs, your docker storage, your home directory. Yes, early adopters of the Atomic Workstation can deal, but long term, we don't want Atomic Workstation to be for the adventurous - we want it to just work.
>
> Yes, it's easier to grow partitions then shrink them, but I don't think that can excuse leaving users out of the box with a less-than-useful partitioning setup.
Short version:
I'd say ideal scenario for Workstation-ostree is two partitions: one
big XFS volume, and one appropriately sized swap. /boot and /home are
directories. But due to an obscure bug [1] this practically means ext4
/boot, XFS for / and /home, and swap; or three partitions. I'd leave
LVM out of it because it doesn't really bring anything to the table,
but whatever.
Long version:
Unpartitioned space
The way this is done now for Server and Atomic Host makes sense for
those use cases. It doesn't make sense for Workstation-ostree. Right
now Workstation and Workstation-ostree make root fs 50G, and the rest
to /home. That needs revisiting for Workstation or Workstation-ostree,
it's just more necessary for Workstation-ostree because platform
libraries and flatpaks are bigger than traditional counterparts.
Partitions v quotas
It's better to use quotas as a limiter, rather than carving things up
with multiple partitions (or LVs). Quotas achieve the same goal, but
can be changed anytime and not having to worry if the user is going to
get wedged into an overfull root fs or home with wasted space on the
other.
Of course the UIs for each filesystem's quota management are children
of satan, but that's a separate convo.
/home as separate partition
I'm skeptical that ostree installations are less fragile than
conventional installs, and obviate separate /home file systems, until
Joe User is doing weird and crazy shiat with it. Anaconda enforces a
reformat for ext4 and XFS root fs. So if /home is a directory, and a
reinstall becomes necessary, it means /home isn't salvageable, it'll
have to be restored from backups.
Anaconda exempts reformat on Btrfs, instead enforcing the creation of
a new subvolume for the root filesystem. Also separate root and home
come in handy on Btrfs for snapshotting them separately, and using
btrfs send/receive (directly or with btrbk) for home only backup and
restore.
Shrinking
Btrfs has online only, atomic grow and shrink, and uses the same
allocation code path for normal reads/writes and balancing, i.e. it's
highly exercised code and integral to its design. XFS can't shrink,
and ext4 only has offline shrink and while ostensibly safe (or else
it's a big bug) it comes with its own risks and inefficiencies in the
resulting layout.
[1] Due to a combination of long delayed allocation on XFS flushing
journal contents to fs metadata, and Plymouth making itself kill
exempt, and systemd being unable to remount-ro, or umount the volume;
when /boot is a dir on rootfs it's possible for bootloader
configuration file changes to only hit the journal and not file system
metadata at reboot time. And the bootloaders do not know how to read a
dirty journal, so they don't see the updated bootloader file at all,
it's missing, so reboot from updates can fail entirely. If you merely
boot some other installation or live media and mount this root fs, the
kernel reads the dirty journal and flushes its contents to fs
metadata, and now everything is fine and the system will boot
normally, xfs_repair isn't even needed. Merely a mount and umount.
https://bugzilla.redhat.com/show_bug.cgi?id=1227736
Technically all file systems are susceptible to this problem when
/boot is a directory and thus remount-ro fails and umount doesn't
happen. But only XFS seems to manifest with a problem. ext4 and Btrfs
must just flush to disk faster (or something).
--
Chris Murphy
6 years, 9 months
Status report on Flatpaks in Fedora Infrastructure
by Owen Taylor
I've just submitted a change proposal for creating Flatpaks out of Fedora package content:
https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks
This is submitted as a F27 change proposal, but it's expected that it will be multiple releases before everything in the final shape. My hope for Fedora 27 is that by the fall packagers will be able to start experimenting with making Flatpaks out of their graphical applications and there will be a small set of applications for users to install.
There is more extensive documentation about the technical plan at:
https://fedoraproject.org/wiki/Workstation/Flatpaks
Building Packages
=================
Flatpaks require rebuilding applications and bundled dependencies to be located with a prefix of /app rather than /usr. We're using the infrastructure created for modules to rebuild packages, and it has worked out very smoothly so far. There are prototype runtime and application modules at:
https://src.fedoraproject.org/cgit/modules/eog.git
https://src.fedoraproject.org/cgit/modules/flatpak-runtime.git
Building Flatpaks out of Packages
=================================
After building the packages, they need to be combined into a Flatpak runtime or application. There is a python script to do this locally in https://pagure.io/flaptak-module-tools, but the goal is do this within the same build pipeline as is used for containers, and I've started prototyping out changes to atomic-reactor.
One element that is needed to built Flatpaks or containers against modules is published composes of modules. This will be provided by the "On Demand Compose Service". Development on this by the modularity team started recently, but seems to be going well.
Distributing Flatpaks
=====================
The goal is to distribute Flaptaks from registry.fedoraproject.org. This requires passing two hurdles:
* Flatpaks are OCI Images, not docker containers, and we don't have OCI Image support in registry.fedoraproject.org (which is an instance of https://github.com/docker/distribution/) There is conceptual agreement to add this upstream, and a pull request that is blocked on finalizing the OCI Image specification.
* For GNOME Software to provide a nice installation interface from the registry rather than an OSTree repository, we need to have a) an index of all flatpaks/containers in the registry b) appstream data for the containers in the registry. The cockpit team has similar requirements for their container installation interface, and we'll collaborate with them in coming up with a solution.
This work is still at the research and discussion phase.
Updates
=======
There is work currently underway to add support to Bodhi for filing updates for containers rather than for packages should carry directly across to Flatpaks. This may be sufficient for F27. However, eventually it seems like we need to have automation, where updates of packages automatically cause updates of containers/flatpaks for those packages. This workflow still needs to be planned out in detail.
6 years, 9 months
Workstation WG meeting recap 2017-Jul-03
by Paul W. Frields
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-2/2017-07-03/workstation...
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-2/2017-07-03/workstation...
Log: https://meetbot.fedoraproject.org/fedora-meeting-2/2017-07-03/workstation...
* * *
=================================
#fedora-meeting-2: Workstation WG
=================================
Meeting started by stickster at 13:00:10 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-2/2017-07-03/workstation...
.
Meeting summary
---------------
* Roll call (stickster, 13:00:15)
* Anaconda (stickster, 13:09:07)
* anaconda has significant redundancy with gnome-initial-setup
(mcatanzaro, 13:10:35)
* AGREED: mcatanzaro to prepare F27 change proposal to remove
redundancy between anaconda and gnome-initial-setup (+1: 5, 0: 0,
-1: 0) (stickster, 13:23:33)
* Removing LibreOffice Draw from Workstation (stickster, 13:28:39)
* LINK: https://pagure.io/fedora-workstation/issue/16 (stickster,
13:28:41)
* AGREED: Drop it (+1: 5, 0: 0, -1: 0) (stickster, 13:32:53)
* ACTION: mcatanzaro file PR for fedora-comps to remove
libreoffice-draw (stickster, 13:33:02)
* fedora-workstation-repositories not in default install (stickster,
13:33:30)
* LINK: https://pagure.io/fedora-workstation/issue/17 (stickster,
13:33:35)
* All other business (stickster, 13:35:15)
* LINK:
https://fedoraproject.org/w/index.php?title=Workstation/VisualIdentity
(ryanlerch, 13:53:04)
* AGREED: ryanlerch to work on Change page, proposal coming soon (q.v.
Anaconda Change above) (stickster, 13:57:07)
Meeting ended at 13:57:12 UTC.
Action Items
------------
* mcatanzaro file PR for fedora-comps to remove libreoffice-draw
Action Items, by person
-----------------------
* mcatanzaro
* mcatanzaro file PR for fedora-comps to remove libreoffice-draw
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* stickster (74)
* mcatanzaro (50)
* otaylor (29)
* juhp_ (16)
* zodbot (12)
* ryanlerch (10)
* bowlofeggs (2)
* rdieter (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
6 years, 9 months