We would like to change the docker container storage to default to
Overlayfs2 in Fedora 26. But we have a problem on Atomic Host and
Fedora Server distributions.
Currently docker-storage-setup defaults to devicemapper and is hard
coded to setup a thinpool of 40% of remaining disk. Otherwise it sets
up loopback devices on the root file system. Devicemapper is nice
since it works with thinpools and can automatically expand the storage
if the disk space is getting used up.
Moving to Overlay, we can more easily use the root file system directly,
which would be fine for Fedora Workstation. We want to preserve the use
of the remaining storage for Overlay on AH and Fedora Server, since
this would give a user flexibility to switch back to using devicemapper
if they had problems with the Overlay driver. We can not as easily
support the expanding disk for Overlay since we will not use using thinpool.
We have looked at options to hard code OverlayFS with the defaults, or
we could just drop a /etc/sysconfig/docker-storage-setup that specified
Overlay and the percentage of remaining space to use for the
/var/lib/docker device. But what is the best way to set different
defaults for AH, Fedora Server and Fedora Workstation.
We would like to discuss with you guys about what you would think is
the best way to handle.
FOSDEM 2017 - Distributions Devroom Call for Participation (new
The Distributions devroom will take place 4 February, 2017 at FOSDEM, in
room K.4.601 at Université Libre de Bruxelles, in Brussels, Belgium.
Distributions are more than just hosted collections of software from
upstreams. Each distribution is responsible for problem-solving in
testing, and releasing software as well as managing the lifecycle of
application in the collection. Additionally, distributions do very
work in ensuring that various versions of upstream software work well
and can co-exist. Distribution are also, often responsible, for
upstream software so that security fixes can be applied more quickly.
We welcome submissions targeted at contributors interested in issues
distributions, especially in the following topics:
- Managing Build/Test/Release processes around shared ideas and
- Lifecycle management, especially in the areas of sandboxing,
containerization, vendoring, and bundling
- Distribution construction tools and infrastructure development and
implementation (building, signing, testing, distribution, etc.)
- Cross-distribution collaboration on common issues, eg: content
infrastructure, and documentation
- Working with vendors and including them in the community
- Building trust and code relationships with the upstream components of
distribution and between distributions
- The future of distributions, emerging trends and evolving user demands
the idea of a platform
- The place of distributions in today's world (including concepts of
containerization, IoT, etc.)
- Onboarding new users and mentorship, facilitating technical growth
- Solving traditional problems like package management, and content
(eg. rpm/dpkg/ostree/coreos )
- Integration technologies like installers, deployment facilitation (
- Principals of Rolling Releases, Long Term Supported Releases (LTS),
gated releases, and calendar releases
Ideal submissions are actionable and opinionated. Submissions may be in
form of 25 or 50 minute talks, panel sessions, round-table discussions,
Birds of a Feather (BoF) sessions.
Due to popular demand, We are extending the CFP for the Distributions
Devroom until Friday 02-December-2016. We plan to maintain the rest of
the schedule (e.g. notification dates) as-is. We look forward to your
Submission Deadline: 02-Dec-2016
Acceptance Notification: 5-Dec-2016
Final Schedule Posted: 11-Dec-2016
How to submit
1.) If you do not have an account, create one here
2.) Click 'Create Event'
3.) Enter your presentation details
4.) Be sure to select the Distributions Devroom track!
What to include
- The title of your submission
- A 1-paragraph Abstract
- A longer description including the benefit of your talk to your target
audience, including a definition of your target audience.
- Approximate length / type of submission (talk, BoF, ...)
- Links to related websites/blogs/talk material (if any)
We will be live-streaming and recording the Distributions Devroom.
at FOSDEM implies permission to record your session and distribute the
recording afterwards. All videos will be made available under the
FOSDEM content license (CC-BY).
If you have any questions, feel free to contact the devroom organizers:
Brian Exelbierd (twitter: @bexelbie) and Brian Stinson (twitter:
for and on behalf of The Distributions Devroom Program Committee
While looking into an issue with how GNOME Software decides which
release to offer an upgrade to when there's more than one plausible
candidate, I noticed something interesting: we do not actually have a
policy on what we 'recommend' people to do in this case.
There's one specifically planned-for (I'm trying hard to avoid using the
word 'supported' here) case where a Fedora user may want to upgrade
across two release versions at once. It's why we do the release cycle
'overlap', where the N-2 release is maintained for a month after the N
release goes stable: we specifically want to allow people not to have to
upgrade every single release, but allow them to upgrade every other
That is, we're generally on record as thinking it's OK to go 23 -> 25 ->
27 -> 29 etc., so long as you do the upgrade within a month of the new
release coming out each time.
However, if you look at our official instructions on upgrading:
(that one just links to the wiki page)
You'll notice we don't explicitly specify *how* you should do this. That
is, if you're currently running Fedora 23, and you want to upgrade to
Fedora 25 next week, are you supposed to:
i) Upgrade to Fedora 24 first, then from Fedora 24 to Fedora 25
ii) Upgrade directly to Fedora 25
It's hard for us to request specific behaviour from gnome-software when
we don't actually know which approach we as a distribution recommend :)
A couple of releases ago, direct N+2 upgrades were written into the
release criteria, which now read:
"For each one of the release-blocking package sets, it must be possible
to successfully complete a direct upgrade from fully updated
installations of the last two stable Fedora releases with that package
openQA tests direct N+2 upgrades of Workstation, KDE, Server and minimal
This is obviously indicative, but still, it only considers clean
installs of the release-blocking package sets. In the real world, people
upgrade with much messier package sets.
As another data point, while updating the 'upgrading with bare dnf' (not
dnf-system-upgrade) instructions a couple of weeks back, I noticed those
instructions recommended the 'upgrade one release at a time' strategy.
So, I guess the questions here are:
1) Which of the two should be our 'officially recommended' approach?
2) Should we also say the other one is OK but just less-recommended, or
specifically discourage it?
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net