Link to latest openQA failure: [0]

[0] https://openqa.fedoraproject.org/tests/1633182#

Are you not sure that's not the other way around? Grepping the code we've no mention of secure_key but do secure_cookie:

[perobins@localhost zezere (main %)]$ grep -R secure_key
[perobins@localhost zezere (main %)]$ grep -R secure_cookie
zezere/settings.py:SESSION_COOKIE_SECURE = getboolean("global", "secure_cookie", "SECURE_COOKIE")
zezere/default.conf:secure_cookie = yes

I wonder if the version of django changed in Fedora and something changed there, can you verify?

Just for the record - the test that's failing here is the server end of the zezere tests, where we're ultimately checking that we can 'claim' a fresh IoT install. All the server end stuff does not actually run on the compose under test, though, since zezere *server* functionality isn't part of IoT's feature set. The server end stuff just runs on a minimal RPM install of "current Fedora", whatever current Fedora is when the test runs. This test started failing when Fedora 37 was released and our "current Fedora" became 37 instead of 36, so this test started running on 37 not 36. So deploying a zezere server works on F37 but not F36; we can't tell any more precisely than that when it broke, from the openQA results.

So the current state is that deploying zezere on F37 is still failing, and it is because it's looking for `secure_cookie`:

No option 'secure_cookie' in section: 'global'

This doesn't seem to involve django, AFAICS this is all internal to zezere, it's reading its own config file here.

OK, so poking about a bit, this is probably just an issue in the openQA tests. In the openQA tests we run our own zezere server because we don't want to rely on the public one (it makes the tests a bit unpredictable). So there's a dedicated test just for running a zezere server, and it sets up its own config file. That config file doesn't have 'secure_cookie' in it (because when I wrote the test that setting didn't exist at all, it was added in 9bd7b170c8d5baa5c174f06616adae25639a600c ).

It might be nice if zezere's config handling could use defaults for values that aren't set in the config file at all, rather than requiring things to be explicitly set, e.g. by doing `parser["global"]["secure_cookie"] = "yes"` (and similar for other expected values) before reading the config file. Or, it seems like the intent is *kind of* that the `default.conf` file should provide defaults (it seems like settings_external.py expects to find it in the same directory as itself?), but it's not actually installed as part of the zezere package, so maybe it should be?

But I can easily enough update the test's config to include the required setting to resolve the immediate problem.

We're doing a pretty big rewrite so we should address it then, would be great to have an upstream bug report with the details so it's not lost.

This message is a reminder that Fedora Linux 37 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '37'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 37 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

https://github.com/fedora-iot/zezere/issues/138

let's just track this upstream.