Fix bookworm | BUT YOLOUPGRADE MONGODB TO 7.0 - IS IT OKAY ?

[Salamandar]

Problem

• Description of why you made this PR

Solution

• And how do you fix that problem

PR Status

• Code finished and ready to be reviewed/tested
• The fix/enhancement were manually tested (if applicable)

Automatic tests

Automatic tests can be triggered on https://ci-apps-dev.yunohost.org/ after creating the PR, by commenting "!testme", "!gogogadgetoci" or "By the power of systemd, I invoke The Great App CI to test this Pull Request!". (N.B. : for this to work you need to be a member of the Yunohost-Apps organization)

[Salamandar]

!bookwormtestme

[yunohost-bot]

📖

[Salamandar]

!testme

[yunohost-bot]

Meow 🐈

[yalh76]

!bookwormtestme
!testme

[yunohost-bot]

📖

[yunohost-bot]

🎠

[alexAubin]

!testme

[yunohost-bot]

🚀

[yunohost-bot]

📚 🪱

[Thovi98]

BUT YOLOUPGRADE MONGODB TO 7.0 - IS IT OKAY ?

Normally, it's not okay...
https://medium.com/techiee/upgrading-mongodb-across-multiple-versions-8cba199f08e7
(Okay it's on old article but I don't think things have changed)

I cannot test this as I don't have avx support on my server, but I guess we already can test on ci with a test_upgrade_from?

[alexAubin]

I guess we already can test on ci with a test_upgrade_from?

Yeah the corresponding test passes on ci-apps-dev so it looks okayish but it's difficult to know without any actual data / prod to test on x_x

[orhtej2]

My super scientific experiment of installing from master, adding a board with some cards and an attachment, then upgrading from your branch would indicate it works as expected (TM), meaning the board is still there after the upgrade 🥳

My further digging in would however indicate that upgrade is fucked as it keeps the previous version (which curiously restore does not) :{

~$ mongod --version
db version v4.4.29
Build Info: {
    "version": "4.4.29",
    "gitVersion": "f4dda329a99811c707eb06d05ad023599f9be263",
    "openSSLVersion": "OpenSSL 1.1.1w  11 Sep 2023",
    "modules": [],
    "allocator": "tcmalloc",
    "environment": {
        "distmod": "debian10",
        "distarch": "x86_64",
        "target_arch": "x86_64"
    }
}

[orhtej2]

OK, force-upgrading 4.4->7.0 yields:

{"t":{"$date":"2024-05-12T20:28:20.677+02:00"},"s":"F",  "c":"CONTROL",  "id":20573,   "ctx":"initandlisten","msg":"Wrong mongod version","attr":{"error":"UPGRADE PROBLEM: Found an invalid featureCompatibilityVersion document (ERROR: Location4926900: Invalid featureCompatibilityVersion document in admin.system.version: { _id: \"featureCompatibilityVersion\", version: \"4.4\" }. See https://docs.mongodb.com/master/release-notes/6.0-compatibility/#feature-compatibility. :: caused by :: Invalid feature compatibility version value '4.4'; expected '6.0' or '6.3' or '7.0'. See https://docs.mongodb.com/master/release-notes/6.0-compatibility/#feature-compatibility.). If the current featureCompatibilityVersion is below 6.0, see the documentation on upgrading at https://docs.mongodb.com/master/release-notes/6.0/#upgrade-procedures."}}

So upgrade needs to go through each respective MongoDB major version :/

[orhtej2]

By surgically upgrading to 5.0 then 6.0 then 7.x and upgrading setFeatureCompatibilityVersion to 'current' version (not for 7.0 as syntax changed) I got wekan working with MongoDB:

Log: https://paste.yunohost.org/raw/utotunurom
Code: https://github.com/orhtej2/wekan_ynh/tree/no_keep_version

It's a bunch of Gemini hackery + copy/pasted code, but the idea looks sound.