Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make CLI upgrade the default to avoid timeouts, web UI upgrade only for shared hosters #17091

Closed
PVince81 opened this issue Jun 23, 2015 · 19 comments

Comments

@PVince81
Copy link
Contributor

PVince81 commented Jun 23, 2015

Disambiguation:

  • "updater app": this app https://github.com/owncloud/updater. The app that appear in the admin page and automatically downloads the new tarball and installs it.
  • "update page": whenever an upgrade is due, the updater page appears with a "Start upgrade" button:
    update_page

The problem:

  • When upgrading from the update page (web UI) with a lot of data, it is likely that PHP will run into timeouts and could result in half-migrated instances (ex: encryption keys). So far, it was advised on that page to run a CLI upgrade instead.
  • It is tempting for an admin who sees this page to simply click "Start upgrade" and hope it all works fine.

Goal:

  • goal is to make CLI upgrade the default to reduce accidental timeout issues and only have web UI update page if really necessary (ex: shared hosters where no CLI is available)

Proposal:

  • separate the CLI upgrade from the web UI upgrade
  • make CLI upgrade the default, display a simple page "Upgrade required, please update on the CLI" instead of the regular update page when an update is due
  • only if the updater app is enabled, then show the usual update page, the one with "Start upgrade" button
  • this means that the web UI update page becomes part of the updater app
  • disable the "updater app" by default and have people using shared hosters enable it manually (auto-detect if possible, maybe when installed from the magic owncloud-install.php script)
@karlitschek
Copy link
Contributor

We need to offer both options. A ver prominent hint how it is done via the cli and optionally and only for smaller instances the option via the web interface.
Another important point it that long running upgrade steps have to move into background jobs. This is important for cli AND web upgrades.
We should also look into other solutions like Wordpress why they are able to provide a we b updater for years without problems.

@RobinMcCorkell
Copy link
Member

Ref #14229

@oparoz
Copy link
Contributor

oparoz commented Jun 23, 2015

We should also look into other solutions like Wordpress why they are able to provide a we b updater for years without problems.

AFAIK, a standard Wordpress config doesn't encrypt tens of GBs

@pvince, in your proposal, the web updater should be the preferred option when updating apps, but for that to happen, it first needs to learn about the difference between a core and an app update (#16272)

@PVince81
Copy link
Contributor Author

No. In my proposal the CLI update should be the preferred option.

The update page (see disambiguation above) should only be there for people who have no CLI access (ex: shared hosters) and that could be achieved by having that page being a part of the updater app (see disambiguation above).

The update process (the one from the update page) can know about core and app update, it just doesn't show the correct message.

@RobinMcCorkell
Copy link
Member

Actually, @PVince81's proposal will help massively in reducing the ambiguity surrounding an 'update' or an 'upgrade', if we move the web upgrader to the Updater app. As long as the Updater app is installed by default on all releases (I think it is?) then it's 👍 from me.

@oparoz
Copy link
Contributor

oparoz commented Jun 24, 2015

I disagree with a cli only approach for app updates, unless you disable the app store as well.

  1. User enables app in the Web GUI
  2. Operation triggers an update
  3. User is forced to SSH to his account to perform the upgrade before being able to use oC again

That's just nonsense from a UX point of view.

@oparoz oparoz added the design label Jun 24, 2015
@DeepDiver1975
Copy link
Member

That's just nonsense from a UX point of view.

this is indeed true - so we have to differentiate between core and app updates?

@oparoz
Copy link
Contributor

oparoz commented Jun 24, 2015

I think we should. It's much safer to upgrade oC from the cli and since there are plans to log everything when performing an upgrade, an admin will have quick access to the logs and will be able to fix things quickly.

For apps, a web upgrade is perfectly fine, except if the encryption app wants to make massive changes all the sudden, but that has always been introduced with oC upgrades.

@DeepDiver1975 DeepDiver1975 added this to the 8.2-next milestone Jun 24, 2015
@DeepDiver1975
Copy link
Member

we should have a detailed discussion about this - maybe there is something to do within the cycle of 8.2

@karlitschek
Copy link
Contributor

It's the design goal of ownCloud to provide a solution that can be hosted on a private webspace. We should be able to deliver that.
Like I said. Let's check how other do it. For example Wordpress updates itself completely automatic even without an upgrade button. Background jobs can help to reduce the execution time for an upgrade significantly.

@sergiocallegari
Copy link

The problem is more serious that that indicated at the beginning of this thread.

The problem is that everybody on the internet is given the opportunity to start the upgrade with the button.

This means that when the administrator upgrades owncloud, he cannot know for sure when the updated will be triggered. This is a bad and potentially dangerous situation.

@jancborchardt
Copy link
Member

@karlitschek @DeepDiver1975 @PVince81 I assume this is something for 9.0? Do we have another issue with a lowdown of what we discussed at the conf about the updater process?

@RobinMcCorkell
Copy link
Member

@jancborchardt An implementation is available over at #18782 btw

@DeepDiver1975 DeepDiver1975 modified the milestones: 9.0-next, 8.2-current Sep 16, 2015
@DeepDiver1975
Copy link
Member

upgrade is one big topic for 9.0 - setting milestone accordingly

@ghost ghost modified the milestones: 9.1-next, 9.0-current Feb 23, 2016
@ghost ghost added the old-inactive label Feb 23, 2016
@PVince81 PVince81 modified the milestones: 9.1-current, 9.2-next Jun 14, 2016
@PVince81 PVince81 modified the milestones: 9.2-next, 9.1-current Jun 14, 2016
@PVince81
Copy link
Contributor Author

PVince81 commented Dec 8, 2016

Not sure if we want to do this right now, could do later, or drop the topic.

Thoughts ? @DeepDiver1975 @butonic @pmaier1 @felixboehm

@PVince81
Copy link
Contributor Author

PVince81 commented Dec 8, 2016

probably just a matter of 1md to add an option.
Maybe "setup-install.php" could be made to change that option to allow web UI update.

@pmaier1
Copy link
Contributor

pmaier1 commented Dec 13, 2016

Well, this does not block anything since you can always use OCC to upgrade. If app upgrades can still be done via web (#17091 (comment)) making this default would improve the behavior and guide admins so it should definitely not be abandoned. Moreover I'd regard it as bad practice that anyone can trigger the update via the WebUI. Should be changed!
Priority: If there's time left, we do it, else postpone.

@PVince81 PVince81 modified the milestones: backlog, 10.0 Jan 27, 2017
@PVince81
Copy link
Contributor Author

Moving to backlog for now, unless someone is willing to contribute a PR for this

@stale
Copy link

stale bot commented Sep 20, 2021

This issue has been automatically closed.

@stale stale bot closed this as completed Sep 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants