Umami update 1.37.0 (package version 1.6.0) won't start, errors in logs

[jdaviescoates]

@echokos I understand your sentiment, but disagree.

It's impossible to know the future and any app could potentially change resulting in something like this happening (although it's obviously more likely with less mature apps).

But regardless of this existing issue I'd hate for Umami not to be on Cloudron because it's great! So easy to get up and running and works really nicely.

[nebulon]

I agree, such situations where upstream leaves us with no good path to migrate existing instances are pretty bad. We usually spend much time on finding ways to migrate, as it is indeed part of what we see as value we provide. In this case however @girish was next to me for quite some time trying to find a way, but after explaining the introduced mismatch of table foreign key constraint ids, it simply wasn't possible.

Depending on the case, we sometimes create a new appstore id for the app package to avoid existing installations to break on update, but it also means there won't be any more updates and users are still stuck

[d19dotca]

This is a difficult one. I feel like to some degree I've lost my use of Umami now, because I can't upgrade properly and it doesn't seem easy enough to deploy a copy of the latest version and migrate the data to it. That's not Cloudron's fault at all, I'm just very surprised this issue wasn't taken more seriously by the upstream developers. Guess I'll have to stick to Matomo for a while longer.

I had been using Umami (in addition to continuing with Matomo) for the past 2 or 3 months, hoping to cut over to it fully for my clients in another month or so and ditch Matomo after they had about 90 days of data, but that seems unlikely with the breaking changes they made to Umami and being unable to proceed without losing data. Unless I've misunderstood something about the situation (fingers crossed I may have and there's maybe a way I've overlooked to migrate / upgrade), but I'm guessing that's not the case and may need more time to review.

[robi]

@d19dotca Rough indeed.

You could think about using two instances and a cut-over by installing a new Umami, copying over the config file, then cutting over traffic to the new instance, keeping the old one around a bit, in case you need the data, which will become less useful over time and ready for cleanup in a month or two.

[echokos]

@nebulon Umami now has updated their software that seemingly solves a lot of people's former migration issues. Any word on when an updated Cloudron package will come containing their most recent build (1.39.5 from November '22)?

[girish]

@echokos Umami is at the latest since nov - https://forum.cloudron.io/topic/6936/umami-package-updates/19 . It has upstream version 1.39.5

[echokos]

@girish Thanks. The pop-up when I click upgrade shows:

[girish]

@echokos Which version of Cloudron are you running ? It's in the Settings page.

On the demo cloudron, it shows:

[echokos]

@girish Platform version: v7.3.4 (Ubuntu 20.04.4 LTS)

[echokos]

@girish I see the issue - it's not available for my upgrade path for some reason. I had to lock my current version at package version 1.51 due to the upgrade issues. However, the current version of Umami should fix the upgrade issues - it's just not avaialble as an upgrade for me in Cloudron... it's forcing the new version to be a new install only.

[girish]

@echokos Ah, I see what you are saying. Maybe you can try update via the CLI (please take a backup of current umami before you do this):

cloudron update --appstore-id is.umami.cloudronapp@2.3.0 --app umami.domain.com

This will allow you to jump versions.

[echokos]

@girish That worked! And the migration worked properly. Thank you!