RocketChat requires version 6.7 for app support but in back end we have Rocket.Chat 6.3.2
-
Hi @nebulon ,
I hope springtime is treating you and @girish well.
RocketChat requires version 6.7 for app support but in back end we have Rocket.Chat 6.3.2 in our Cloudron. This is with Automatic Updates enabled and even after a check for manual updates.
Is there something wrong with our Cloudron that it doesn't get the latest RocketChat versions?
Making the web work for you, Alec
-
N nebulon marked this topic as a question on
-
Maybe @foliovision means the rocket.chat apps ? https://docs.rocket.chat/extend-rocket.chat-capabilities/rocket.chat-marketplace
If so, I think @foliovision is saying that their Rocket.Chat instance is not updating. What Cloudron version are you on @foliovision ? It will be in the Settings page.
-
@girish yes, you've hit the nail on the head. Since our Digital Ocean droplet Cloudron instance was on Ubuntu 18 LTS, very little was still updating.
We had quite a bit of trouble updating to Ubuntu 20 LTS (we didn't do the reinstall as recommended and Martin is still running around after MongoDB issues). What seems to be missing here would be:
- notifications to tell the Cloudron owner/admins that updates are blocked by the version of the server
- better integrated updates. We chose Cloudron as we don't want to administer these servers. Ideally Cloudron would update the core server and not require a full reinstall.
That said, we'll probably limp along under Ubuntu 20 LTS (not sure what's broken on Ubuntu 20, or rather blocked from updates, if you could send me to a list that would be great) until you and @nebulon have Cloudron 8 and Ubuntu 24 LTS under control (there will be teething pains, none of the improvements seem critical to us, we'd like the global email to be rolled back a bit, as with our complete fiasco on InvoiceNinja which still causes pain, constantly checking to make sure you haven't borked our email settings again and we have our hands full with our own open source software FV Player and other WordPress plugins to improve).
Anyway we'll move to Ubuntu 24/Cloudron 8 at some point and hopefully we'll enjoy four years of stability without blocked updates.
-
What's another huge nuisance is that I am required to update Rocket.Chat about 25x to get from 6.3.2 to 6.7.x. I understand that you like to force updates one .1 version at a time to avoid update issues, but for more popular apps, it would make sense to test and allow bigger update jumps, between major versions for instance. I'm also not sure if it's absolutely necessary to go from say 6.4.0 to 6.4.9 in ten steps.
-
@foliovision yeah, with you about distro upgrades. But there is no way to automate distro updates without total control of the hardware and deployment infrastructure (iow, managed service). I wish VPS providers provided this as a service since they are best positioned to do this but they don't. In fact, Digital Ocean has completely broken Ubuntu 18 -> 20 distro upgrade already.
-
As for the "jump to latest" for apps, a workaround is to have an automatic update schedule of every hour or something and just let the updater do it's work in the background. It will catch up in a day or two.
We only support rolling releases because we don't track the development of each upstream app (it's too much work and not much value really). I think to have app specific updating logic, one has to be involved in upstream app development entirely and understand all the consequences of jumping versions. Many apps don't adhere to semver, most have no tests for testing updates. In the past, we have had issues even when jumping patch releases and this is why we don't skip any patch release on Cloudron side for any app.
Finally, if you are feeling brave :-), you can always do
cloudron update --appstore-id appstoreid@package-versionusing the CLI tool to jump releases. We do this for testing primarily and as mentioned we have no idea what happens when you jump releases since it's not tested by anyone (app authors or by us the packagers). -
@foliovision yeah, with you about distro upgrades. But there is no way to automate distro updates without total control of the hardware and deployment infrastructure (iow, managed service). I wish VPS providers provided this as a service since they are best positioned to do this but they don't. In fact, Digital Ocean has completely broken Ubuntu 18 -> 20 distro upgrade already.
@girish said in RocketChat requires version 6.7 for app support but in back end we have Rocket.Chat 6.3.2:
I wish VPS providers provided this as a service since they are best positioned to do this but they don't. In fact, Digital Ocean has completely broken Ubuntu 18 -> 20 distro upgrade already.
@girish What end users of Cloudron like Foliovision would like is to have a recommended hosting provider where Cloudron does everything to make sure everything works all the time (including underlying OS updates). Heck, if you can't do it with an external partner, I'm sure Cloudron could do well with its own servers if your pricing was in the range (could be slightly more expensive) than Digital Ocean/Linode. Most of us would trust Cloudron to do more to keep our data private than any of the US majors.
-
As for the "jump to latest" for apps, a workaround is to have an automatic update schedule of every hour or something and just let the updater do it's work in the background. It will catch up in a day or two.
We only support rolling releases because we don't track the development of each upstream app (it's too much work and not much value really). I think to have app specific updating logic, one has to be involved in upstream app development entirely and understand all the consequences of jumping versions. Many apps don't adhere to semver, most have no tests for testing updates. In the past, we have had issues even when jumping patch releases and this is why we don't skip any patch release on Cloudron side for any app.
Finally, if you are feeling brave :-), you can always do
cloudron update --appstore-id appstoreid@package-versionusing the CLI tool to jump releases. We do this for testing primarily and as mentioned we have no idea what happens when you jump releases since it's not tested by anyone (app authors or by us the packagers).Thank you for the quick answer.
@girish said in RocketChat requires version 6.7 for app support but in back end we have Rocket.Chat 6.3.2:
Finally, if you are feeling brave :-), you can always do cloudron update --appstore-id appstoreid@package-version using the CLI tool to jump releases.
This is not a bad tip, I've only just gotten through all of the manual updates of Kimai, RocketChat, NextCloud and Uptime Kuma (Kimai is still happening).
If one of these multiple version upgrades go wrong, what's the option in terms of rolling back and moving more slowly on a single app basis?
Cloudron is still on deck for not providing useful notifications about when the underlying OS (Ubuntu) is blocking the updates.
-
Newer Cloudron versions should show when a platform update is blocked by an old Ubuntu version. We just can't update already shipped versions.
@nebulon said in RocketChat requires version 6.7 for app support but in back end we have Rocket.Chat 6.3.2:
Newer Cloudron versions should show when a platform update is blocked by an old Ubuntu version. We just can't update already shipped versions.
Glad to hear it. Not having that notification caused us endless trouble with Rocket.Chat over the last six months, including a couple of support requests to you. Your answers were effectively nonsense ("update rocket.chat"), as we could not update Rocket.Chat.
-
F foliovision has marked this topic as solved on
