Cloudron updates
-
The 7.4.0 cloudron update was listed as an unstable production release, so I did not update to it on my prod server.
I log on this morning and see that the update was then forced.
Why did this occur?
Unstable prod releases should not ever be forced installed for obvious reasons.
-
The 7.4.0 cloudron update was listed as an unstable production release, so I did not update to it on my prod server.
I log on this morning and see that the update was then forced.
Why did this occur?
Unstable prod releases should not ever be forced installed for obvious reasons.
@privsec said in Cloudron updates:
Why did this occur?
Presumably because you have auto updates enabled in Settings -> Updates?
As I understand it, automatic updates are rolled out slowly alphabetically and until it gets to your my.domain - up until that point if you check for updates manually it'll still say it's "unstable" (even if it's already automatically been rolled out on other my.domain).
Although I'm not certain on this, so perhaps @staff could clarify?
-
@privsec said in Cloudron updates:
Why did this occur?
Presumably because you have auto updates enabled in Settings -> Updates?
As I understand it, automatic updates are rolled out slowly alphabetically and until it gets to your my.domain - up until that point if you check for updates manually it'll still say it's "unstable" (even if it's already automatically been rolled out on other my.domain).
Although I'm not certain on this, so perhaps @staff could clarify?
@jdaviescoates said in Cloudron updates:
@privsec said in Cloudron updates:
Why did this occur?
Presumably because you have auto updates enabled in Settings -> Updates?
I do have auto updates turned on, but unstable updates for both apps and cloudron should not be included as an autoupdate
-
@privsec said in Cloudron updates:
Why did this occur?
Presumably because you have auto updates enabled in Settings -> Updates?
As I understand it, automatic updates are rolled out slowly alphabetically and until it gets to your my.domain - up until that point if you check for updates manually it'll still say it's "unstable" (even if it's already automatically been rolled out on other my.domain).
Although I'm not certain on this, so perhaps @staff could clarify?
@privsec said in Cloudron updates:
I do have auto updates turned on, but unstable updates for both apps and cloudron should not be included as an autoupdate
I edited my post above to add this:
@jdaviescoates said in Cloudron updates:
As I understand it, automatic updates are rolled out slowly alphabetically and until it gets to your my.domain - up until that point if you check for updates manually it'll still say it's "unstable" (even if it's already automatically been rolled out on other my.domain).
-
The 7.4.0 cloudron update was listed as an unstable production release, so I did not update to it on my prod server.
I log on this morning and see that the update was then forced.
Why did this occur?
Unstable prod releases should not ever be forced installed for obvious reasons.
@privsec said in Cloudron updates:
Unstable prod releases should not ever be forced installed for obvious reasons.
also, to clarify, we don't have a concept of unstable prod releases i.e not in the way a user might think of it. That they upgrade and everything is broken left and right and is half baked.
-
G girish referenced this topic on
-
@privsec said in Cloudron updates:
Unstable prod releases should not ever be forced installed for obvious reasons.
also, to clarify, we don't have a concept of unstable prod releases i.e not in the way a user might think of it. That they upgrade and everything is broken left and right and is half baked.
@girish How about allowing users to auto-update Cloudron X days after a new release is available? For example, some people might choose 2 days, others 10 days, and still others 30 days.
I will be intentionally harsh because you guys seem arrogant and ignorant.
The lack of this simple yet valuable feature is one of a plethora of examples of Cloudron's very poor marketing. Marketing? Yes! That feature is a marketing feature because it enables customers to say, "Oh wow! Instead of a bunch of myopic, arrogant, and self-centered nerds running this project, this company seems to actually care about the user experience."
For Cloudron to grow faster, you guys need to improve your marketing.
-
@girish How about allowing users to auto-update Cloudron X days after a new release is available? For example, some people might choose 2 days, others 10 days, and still others 30 days.
I will be intentionally harsh because you guys seem arrogant and ignorant.
The lack of this simple yet valuable feature is one of a plethora of examples of Cloudron's very poor marketing. Marketing? Yes! That feature is a marketing feature because it enables customers to say, "Oh wow! Instead of a bunch of myopic, arrogant, and self-centered nerds running this project, this company seems to actually care about the user experience."
For Cloudron to grow faster, you guys need to improve your marketing.
-
@girish How about allowing users to auto-update Cloudron X days after a new release is available? For example, some people might choose 2 days, others 10 days, and still others 30 days.
I will be intentionally harsh because you guys seem arrogant and ignorant.
The lack of this simple yet valuable feature is one of a plethora of examples of Cloudron's very poor marketing. Marketing? Yes! That feature is a marketing feature because it enables customers to say, "Oh wow! Instead of a bunch of myopic, arrogant, and self-centered nerds running this project, this company seems to actually care about the user experience."
For Cloudron to grow faster, you guys need to improve your marketing.
-
@yeku that escalated quickly in tone for no apparent reason.
If you miss a feature or something isn't clear, like what "unstable release" in the Cloudron context means, you may just ask, and we will try to sort things out.
@nebulon First, see https://forum.cloudron.io/topic/8939/i-suggest-you-offer-scheduled-phone-call-video-call-technical-support-in-english-for-x-us-dollars-per-hour I am displeased that I haven't received a meaningful response yet.
Second, "For the others, it says the release is unstable because we want to discourage them from updating it." is inane and ignorant. Up means up, down means down. One should not indicate "up" when one means "down." We aren't communicating using Cloudron's super special version of English on this forum. We are using standard English. Don't call a release unstable if it's not unstable. Why not simply follow my sage advice and allow users to choose the number of days before auto-updates are applied?
Third, "there's already a way to set the update schedule - https://docs.cloudron.io/updates/#update-schedule ?" is precisely the sort of ignorant and arrogant response I deplore. My suggestion was much better, yet it was not properly addressed.
Here's the current marketing slogan you guys seem to be currently embracing, "Hi, we're Cloudron! We do things the way we like; we blithely ignore excellent user suggestions because well, ummmm, errrrr, we are ignoramouses!"
-
@nebulon First, see https://forum.cloudron.io/topic/8939/i-suggest-you-offer-scheduled-phone-call-video-call-technical-support-in-english-for-x-us-dollars-per-hour I am displeased that I haven't received a meaningful response yet.
Second, "For the others, it says the release is unstable because we want to discourage them from updating it." is inane and ignorant. Up means up, down means down. One should not indicate "up" when one means "down." We aren't communicating using Cloudron's super special version of English on this forum. We are using standard English. Don't call a release unstable if it's not unstable. Why not simply follow my sage advice and allow users to choose the number of days before auto-updates are applied?
Third, "there's already a way to set the update schedule - https://docs.cloudron.io/updates/#update-schedule ?" is precisely the sort of ignorant and arrogant response I deplore. My suggestion was much better, yet it was not properly addressed.
Here's the current marketing slogan you guys seem to be currently embracing, "Hi, we're Cloudron! We do things the way we like; we blithely ignore excellent user suggestions because well, ummmm, errrrr, we are ignoramouses!"
@yeku if you have feature requests or suggestions, we have a forum category for this at https://forum.cloudron.io/category/97/feature-requests
As you will see, there are lots of things on our list which are of different priority for the various different use-cases our users have. Of course ideally we have time for every request asap, but that is not how it is.
To avoid further unexpected updates in your case, you can also completely disable automatic updates.
-
@yeku if you have feature requests or suggestions, we have a forum category for this at https://forum.cloudron.io/category/97/feature-requests
As you will see, there are lots of things on our list which are of different priority for the various different use-cases our users have. Of course ideally we have time for every request asap, but that is not how it is.
To avoid further unexpected updates in your case, you can also completely disable automatic updates.
-
@girish Yep, don’t feed the troll.
-
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
-
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.
-
-
@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.
-
-
@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.
@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.
-
-
@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.
