Cloudron updates
-
I am a bit annoyed this post got overrun.
I want to make it clear that I am not chastising or belittling.
I am just hoping to have either further clarification or a feature added to delay the "Unstable" releases.
I understand that unstable doesn't mean that something is being rolled out on purpose that is going to break everything, but I operate solely a prod server, not a dev environment. So having an unstable rollout can be detrimental.
I am essentially hoping for some assistance as to how to navigate this
I am open to any ideas or suggestions
-
@privsec no worries, let me clarify this a bit more and maybe you can tell us if any changes are to be made.
-
When we make a release, it's already pretty well tested. We don't do beta/alpha releases. We also don't publish a release which is half baked. As you know, Cloudron instances are totally stand alone and we don't have access to people's servers. Most of them also auto-update. This means that releasing something untested will hose servers left and right. This will be catastrophic for us.
-
Now we have gazillion Cloudron installations. If we make a release available to everyone at the same time, then the support burden for us too high even if say 100 servers fail to update properly. For whatever reason - disk space, some DNS issue, nodejs release tarball couldn't be downloaded, docker hub is down etc.
-
For this reason, we roll out releases slowly. The strategy is simply to roll these out alphabetically (domain name based) over the course of a month or so. In the past, a release was not "visible" to others. For example, if we are rolling out "a", then people with domain starting "t" cannot even see the release and cannot update.
-
We were told, people wanted to apply an update and help test and they couldn't wait. For this reason, we allowed domains starting with "t" to update, but it will show a warning that this is a pre-release and unstable. This simply prevents non-enthusiasts (specifically, 99% of cloudron users, who are not on this forum and haven't read all these things and never will) from updating. This message needs to a bit scary, otherwise from our experience they will update.
Happy to clarify further. I am not sure what behavior is wanted at this point. Is it that you don't want to update until all other Cloudrons in the world have updated? Even we don't know/keep track when all Cloudrons updated. Only idea I can think of is to disable automatic updates and update when you see a blog post from us about the release or something like that.
-
-
@girish speaking for myself, I’d love the ability to auto-update apps (or set it based on each app so some won’t auto-update) while keeping the actual Cloudron server version a manual update. Not sure if that’s a good idea or not but I’d rather allow some to update and others to not. Much like I mark some plugins as “trusted” in MainWP for managing all my WordPress installs where it auto-updates within 48 hours, and some plugins as “untrusted” which means it requires manual intervention before updating. That same concept could maybe be applied within Cloudron.
But otherwise I think it’s not too bad the way it is… if people don’t like auto-updates then disable it. Simple as that. But I do think there could be improvements to the update mechanism to allow for more granularity.
PS - sorry you have to deal with the occasional a**hole like ‘yeku’ above. They do not represent the vast majority of us who are very happy a project like Cloudron exists in the first place.
-
@d19dotca said in Cloudron updates:
@girish speaking for myself, I’d love the ability to auto-update apps (or set it based on each app so some won’t auto-update) while keeping the actual Cloudron server version a manual update. Not sure if that’s a good idea or not but I’d rather allow some to update and others to not. Much like I mark some plugins as “trusted” in MainWP for managing all my WordPress installs where it auto-updates within 48 hours, and some plugins as “untrusted” which means it requires manual intervention before updating. That same concept could maybe be applied within Cloudron.
But otherwise I think it’s not too bad the way it is… if people don’t like auto-updates then disable it. Simple as that. But I do think there could be improvements to the update mechanism to allow for more granularity.
PS - sorry you have to deal with the occasional a**hole like ‘yeku’ above. They do not represent the vast majority of us who are very happy a project like Cloudron exists in the first place.
I would like something like this.
-
@privsec For disabling some app auto-updates, I actually just realized this is already possible...
But yes, I'd still like to see this for the actual Cloudron software platform updates to disable that automatically but keeping the apps automatic.
-
I think the current roll out strategy (auto-update alphabetical with the possibility to manually update) is very flexible on both Cloudron end and user end and so makes perfect sense. However it seems like some people running prod servers may be worried about bugs introduced in new major or minor releases. And it is true that at least the first patch release iron out the biggest annoyance introduced in new major/minor releases.
Personally as a maintainer of several instances, I would like to still have auto-update enabled (so I don't have to remember to do it), but for the most sensitive instances be able to wait until some of the bugs have been found by early tester and iron out by Cloudron Super Hero Devs
So, as well as what @d19dotca proposed, would it be possible to add a platform update option to auto-update platform only after the first patch release (so basically auto-update except for version x.y.0)? (Like Cloudron does with Nextcloud where major release updates are pushed only after the first patch release)
Hell my brain fused reading Yeku's posts, @girish @nebulon sorry you had to deal with that, FWIW I'd like to say that it feels to me you have definitely built a strong community of happy users around your software and it felt we're all working here as part of a big team.
-
-
-
-