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.
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.
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.
I'm not 100 percent confident this is the correct place for this but feel free to point me to a more appropriate place if there is one.. I'm seeing two separate issues with the latest version of IoT that I was hoping for some assistance with.
1. During boot if DHCP is unavailable it takes a significant amount of time to boot waiting for a timeout to occur. This seems to be related to dracut-network and ignition. The closest thing I could find was a bug report for CoreOS  that seemed to be a way to over ride that behavior but I personally couldn't get it to work. Is there a way to override this behavior? I have a system where an IPMI interface reports as having a link but can't get a DHCP address and thus is forced to wait for a timeout.
2. I can't set a static IP address within the OS even though per the docs  this should be possible (as it was on 31 IoT). Basically once you set a static address and boot there's a new network connection that's activated and utilizing DHCP while the static one is there unused. I've tried deleting the connection ,recreating it, etc and it just doesn't seem to stick.
That is awesome, thank you for doing all of this, Adam! Hoping we get our first
validation event today, will let you know if I see any issues.
----- Original Message -----
> Hey folks!
> I just wanted to post a heads-up that I have finally finished tweaking
> python-wikitcms and the wiki templates themselves to enable the
> creation of release validation events for Fedora-IoT composes. I
> deployed this to production today.
> What this should mean is that the next time a "Fedora 33" IoT compose
> completes, we'll get a validation event created for it and an
> announcement mail will be sent to test-announce@ , just like for
> regular Fedora composes.
> IoT validation events will have only one matrix page, called "General".
> I based the template on the one pwhalen has been using to manually
> create events. This is Paul's page:
> and this is the 'official' Wikitcms matrix template page:
> There will still be a Summary page, even though it doesn't make much
> sense with only one matrix page, just because it'd be a chunk of work
> to disable the use of Summary pages in this situation. I might do that
> IoT composes are slightly "odd" in that they're always built with the
> 'production' type which is meant for release candidate composes, even
> though they're functionally nightlies they don't use the 'nightly'
> type. Because of this, I've had to special-case the handling of IoT
> composes throughout the code, and for wikitcms purposes we will
> essentially treat all IoT composes as if they were nightlies. The
> 'milestone' for IoT validation events will always be "RC" (at least as
> long as the composes are still done this way), and the announcement
> emails will always be the "nightly"-style emails, not the "candidate"-
> style emails.
> Page names, category names etc. follow the same general pattern as
> those for 'normal' validation events, but with "Fedora-IoT" or "IoT" in
> them, so the actual matrix page for an event will be something like
> There will also be a 'current' redirect page:
> categories will exist with similar name modifications, so there'll be a
> and so on.
> I'll also set up testcase_stats for this stream once we have a
> validation page, and I'll hook up openQA result reporting so openQA
> tests that run on IoT composes will report results to the wiki.
> The event creation logic works exactly as for the 'main' release
> stream: relvalconsumer will kick in for every compose that's for the
> 'next' Fedora release (so 33 ATM) and decide whether to create an event
> depending on how long it's been since the previous event and whether
> any 'significant' packages have changed. (I may actually tweak that
> 'significant' package list for IoT, now I think about it.) So just as
> for the 'main' release stream, we'll get new events every few days, on
> average once a week or so. Events can also be manually created if we
> particularly want one for a given compose.
> This is a fairly major change to things so there will likely be some
> rough edges: please report anything you notice, whether it's straight
> up bugs or just things like boilerplate text that doesn't actually
> entirely make sense for an alternate release stream, stuff like that.
> It still hasn't been decided (AFAIK) if IoT will be a release-blocking
> deliverable/primary Edition for Fedora 33, but this change should set
> us up well if it is, and if it isn't, we can just treat this whole
> stream as 'optional extra' testing, it still won't hurt to have the
> Thanks folks!
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net