[Feature]: MongoDB version

[JosefRypacek]

What problem are you looking to solve?

I wanted to try docker controller instead of standard linux controller and found out that MongoDB version in docker image is older than I was using before, thus database is not compatible. MongoDB 3.x is also EOL.

Describe the solution that you have in mind

I've slightly modified install.sh and created my own image and it works fine. It would be great if we could select which version of Mongo to use, but I understand it's not typical use of this image.

Additional Context

diff --git a/install.sh b/install.sh
index 2313755..e80a379 100755
--- a/install.sh
+++ b/install.sh
@@ -64,21 +64,9 @@ PKGS=(
   net-tools
   tzdata
   wget
+  gnupg
 )
 
-# add specific package for mongodb
-case "${ARCH}" in
-  amd64|arm64|"")
-    PKGS+=( mongodb-server-core )
-    ;;
-  armv7l)
-    PKGS+=( mongodb )
-    ;;
-  *)
-    die "${ARCH}: unsupported ARCH"
-    ;;
-esac
-
 # add specific package for openjdk
 case "${ARCH}" in
   amd64|arm64|"")
@@ -124,6 +112,12 @@ export DEBIAN_FRONTEND=noninteractive
 apt-get update
 apt-get install --no-install-recommends -y "${PKGS[@]}"
 
+# MongoDB
+wget -qO - https://www.mongodb.org/static/pgp/server-4.4.asc | apt-key add -
+echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/4.4 multiverse" | tee /etc/apt/sources.list.d/mongodb-org-4.4.list
+apt-get update
+apt-get install --no-install-recommends -y mongodb-org
+
 echo "**** Download Omada Controller ****"
 cd /tmp
 wget -nv "${OMADA_URL}"

[mbentley]

Yeah, the ability to use newer versions of MongoDB is a bit of a tricky spot at the moment. With there being armv7l images, it's running an even older version of MongoDB because they stopped supporting 32 bit operating systems a long while ago. Then when it comes to MongoDB as it's packaged, it's still supported by Canonical in the Ubuntu images for amd64 for the 3.x version:

# docker exec -it omada-controller dpkg -l mongodb-server-core
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                Version                                       Architecture Description
+++-===================-=============================================-============-===========================================================
ii  mongodb-server-core 1:3.6.9+really3.6.8+90~g8e540c0b6d-0ubuntu5.3 amd64        object/document-oriented database (server binaries package)

So even though MongoDB might not directly support it with 3.6 going EOL in April of 2021, I will probably stick with MongoDB as packaged from Canonical so I don't have to track vulnerabilities or manage the package versions on my own. I know it's not ideal but I suppose a backup and restore from the controller might achieve the same thing. Not sure if you'd lose metrics or other data from a migration but I am not really sure I want to deviate from my current approach.

[JosefRypacek]

I understand, it's not always a good idea to break something that works. And here I really see issues with 32bit binaries. Still thank you for very graceful response.
I'll probably stick some time with my solution to rebuild image with another repo for newer MongoDB version (unless I do export/import). This can be used as howto for anyone who has the same problem at least.

Please also note that when I upgraded (months ago) MongoDB version to current 4.4, I have problems there. I remember I really had to follow release note, upgrade multiple version gradually a run some some additional commands to change FeatureCompatibilityVersion. This was probably caused because I did not read followed release note from the begining and got into bad state.

[mbentley]

I was thinking about this a bit more today and I was thinking that it could be easy enough to pass a build-arg to tell have it install from the mongodb official repos if it was passed but then again, I was curious if that would be helpful enough - to allow someone to be able to easily build their own image or if it would be expected for me to build images with support for newer mongodb. Adding another image build with the official mongodb might be a bit of a heavy lift in that it would almost double the number of image builds for little value.

Another idea would be just upgrading MongoDB to a newer version for all of the non-armv7l images but your mention of needing to upgrade MongoDB in steps to get it to a modern version is a bit scary from a container perspective as it seems like there would be a big possibility of breaking something if not done correctly. That being said, I haven't looked into it at all.

[JosefRypacek]

I've solved my problem with export/import of my controller in less than 2 hours. Now I'm happy with current state of your container.

I had idea of using separate container for mongodb, so anyone could select preferred version and your container would be smaller. Anyway there is no available image for armv7 on https://hub.docker.com/_/mongo.

As TP-Link states MongoDB v3 is supported, I would stick with it until requirements are changed.

When I did MongoDB upgrade on my linux (no docker) from 3.x to 4.4, I didn't read any release note and it finished in bad state. MongoDB 4.4 couldn't work with data, but it was too late (something has been updated) to revert back to 3.x or 4.0/2 as those versions were unable read the data too.
I had to use (probably, but not sure) 4.2 and use following commands to make it work so auto upgrade process can finish and then upgrade to 4.4 again.

apt install mongodb-org-shell
systemctl stop mongod.service
mongod --dbpath /opt/tplink/EAPController/data/db/
mongo
db.adminCommand( { listDatabases: 1 } )
use xxx
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
db.adminCommand( { setFeatureCompatibilityVersion: "4.2" } )

If upgrade of MongoDB for this container will happen, you should follow release notes and follow upgrade path
3.6 -> 4.0 -> 4.2 -> 4.4 to be safe. I don't know how to easily do it without user's interaction. Most suitable way for me is to use another docker container for mongodb in compose and manually modify mongodb version, restart project, wait for upgrade, verify result and repeat.

[mbentley]

I had idea of using separate container for mongodb, so anyone could select preferred version and your container would be smaller. Anyway there is no available image for armv7 on https://hub.docker.com/_/mongo.

Yeah, that would be great. It's too bad that I don't see a way to externalize it based on how the controller launches Mongo. Only way I could see that working would be if there is some sort of shim in place to tricks it at the moment.

Thanks for the details on the MongoDB upgrade process! I will keep tabs on that for the future.

[mbentley]

I was playing with this to just understand the level of effort in this commit. For amd64, it seems doable by just grabbing binaries for mongo and mongod. It's a bit more tricky with arm64 because Mongo doesn't have binaries that work on Ubuntu 20.04. They have 4.0 with 16.04, 4.2 with 18.04, and 4.4 with 20.04.

I was able to automate the migration too. Definitely nothing that's well tested but I thought it would be good to have something in the case of needing to upgrade; like if there was an update to a dependency.

Regardless, the migration is gonna be a pain if they require anything newer than 3.6!