systemd-zram generator
by Chris Murphy
Hi,
This is a systemd generator for setting up swap on zram. If a configuration file, /etc/systemd/zram-generator.conf, does not exist, nothing happens. If it does exist, a zram device is created, swap-create(a)zram0.service is created and started, which does mkswap and swapon using the same systemd logic found with either GPT swap autodiscovery (using partition type GUID) and /dev/urandom based swap.
https://github.com/systemd/zram-generator
This has been packaged in Fedora as 'zram-generator'. While zram package works fine and I see no problems with it, I'm liking the idea of converging on zram-generator, to use existing logic, maintenance and bug fixing. It's also an example of a generator made in Rust.
I've found a few issues, reported upstream, but I don't think any of them negatively impact IoT.
https://github.com/systemd/zram-generator/issues
There's maybe a 50/50 chance we'll get this going in Workstation for Fedora 32 in lieu of a conventional swap partition (pretty much what IoT has been doing from the start, correct?). But I expect to propose it as a system-wide change for Fedora 33. The idea is to make the generator available system wide; and then we can discuss whether to:
1. enable it by default, by including a one size fits all configuration; which any edition/spin can opt-out by either deleting the configuration file or substituting it with their own
2. not enable it by default, by not including a configuration file; which any edition/spin can opt-in by including their own configuration file
3. what might possibly make sense as the most universal on size fits all configuration
Based on the anaconda zram setup; the zram package setup; brief discussion upstream, and my own testing, I've arrived at:
Create a zram device the same size as RAM (i.e. 1:1 ratio), with a cap of 2G or 4G.
The rationale is, upstream says a zram device twice that of RAM is sane because expected compression ratio is 2:1. But going above that really makes no sense. Therefore a 1:1 ratio is conservative enough, but it's also reasonable to go with 1:2 (1/2 that of RAM, for the zram device size), depending on what IoT folks experience has been thus far. The ratio will affect small RAM devices more then workstations and servers, which I expect will pretty much always be subject to the cap.
But if this isn't what upstream zram folks want to do, then it's not a big deal to just have a use case specific configuration files.
3 years, 9 months
Revamping the Release Readiness meeting
by Ben Cotton
(Posting to many mailing lists for visibility. I apologize if you see
this more times than you'd like.)
You may have already seen my Community Blog post[1] about changing the
Release Readiness meeting process. The meeting has questionable value
in the current state, so I want to make it more useful. We'll do this
by having teams self-report readiness issues on a dedicated wiki
page[2] beginning now. This gives the community time to chip in and
help with areas that need help without waiting until days before the
release.
I invite teams to identify a representative to keep the wiki page up
to date. Update it as your status changes and I'll post help requests
in my weekly CommBlog posts[3] and the FPgM office hours[4] IRC
meeting. The Release Readiness meeting will be shortened to one hour
and will review open concerns instead of polling for teams that may or
may not be there. We will use the logistics mailing list[5] to discuss
issues and make announcements, so I encourage representatives to join
this list.
[1] https://communityblog.fedoraproject.org/fedora-program-update-2020-08/
[2] https://fedoraproject.org/wiki/Release_Readiness
[3] https://communityblog.fedoraproject.org/category/program-management/
[4] https://apps.fedoraproject.org/calendar/council/#m9570
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
4 years
IoT naming plan
by Ben Cotton
As discussed in yesterday's meeting, here's a draft plan for naming
the IoT edition. Note that this gives Legal a fairly short window to
vet and approve our final names, so I've also prepared a compressed
version (that's still a short window for Legal, but slightly less
short). Either way, we should come to agreement quickly and I'll post
the wiki page first thing Monday (my) morning.
I'm open to other suggestions (e.g. a shorter name suggestion window),
but we do need to move quickly.
## Schedule 1
2 March: Begin collecting name suggestions on the wiki page (bcotton to create)
16 March: End name collection, IoT team removes obvious bad candidates
20 March: bcotton sets up an election in the Elections app (open to
all contributors with CLA+1)
23-30 March: voting period for naming
31 March: top 3 names sent to Red Hat Legal for final vetting
## Schedule 2 (compressed)
2 March: Begin collecting name suggestions on the wiki page (bcotton to create)
16 March: End name collection, IoT team removes obvious bad candidates
17 March: bcotton sets up an election in the Elections app (open to
all contributors with CLA+1)
18-25 March: voting period for naming
26 March: top 3 names sent to Red Hat Legal for final vetting
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
4 years
F-32 branching heads up
by Peter Robinson
Hi All,
For those currently using rawhide and wishing to stay on F-32 just a
reminder that before Friday we'll be branching IoT off just like the
main Fedora is in the process of doing. I'm currently awaiting
mainline to settle but it'll happen soon.
For those that wish to stay on rawhide you don't need to do anything
and on the next compose you'll get F-33 content. For those that wish
to stay on F-32 once the branch is complete (I'll reply to this email)
you just need to run:
sudo rpm-ostree rebase -b fedora/devel/<ARCH>/iot
Will update shortly.
Peter
4 years, 1 month