Only disable third party apps for major upgrades #14754
Comments
|
I'd say the probability of having apps break during a major upgrade (ex: 8.0->8.1) is much higher due to API changes / library upgrades, etc. I guess most apps should survive minor upgrades, maybe it's still worth taking the risk not disabling them for minor upgrades. Admins that use the "stable" or "8.0" repo/channel would expect to be able to update automatically without any further interaction. What do you think ? |
|
The problem might come from various workarounds put in place after a dot zero release. Devs will want their apps to work and maybe they'll introduce changes without making them available only for that specific version (their mistake), which means that after an oC upgrade which fixes a problem, the app might stop working and break oC altogether. |
|
Why not doing like piwigo (anothe php webbased service) and its plugins ? All plugins have in metadatas the core version compatibility. When the core is upgraded, there is a warning with a list of plugins still not marked as compliant by the maintainer. If the OC admin still do the upgrade, only the not compliant plugins are disabled... There, for maintainers that have tested during betas, the plugin is already OK when the core release appends and no one is annoyed by the unuseful deactivation. And for the other, the admin is warned, and can wait if it think the plugin is important, and can later check via the upgrade if those plugin have evolved. |
|
@awikatchikaen We do the same. App developer can add the information which core versions are compatible. Unfortunately a lot of (most) app developer don´t maintain this information properly in the apps. |
|
Another solution would be to not include appinfo/routes.php and appinfo/app.php on any upgrades so no thirdparty app code is executed on upgrade. If an app misbehaves this will leave you with a blank screen but after the upgrade, but the upgrade should have been successful. Also if a user reenables an app he will also be greeted with a blank screen. This is just an idea, but couldnt we reengineer the behavior of GNOME or other systems when you change your display resolution? They give you a time window of 15 seconds. If you dont hit ok, they will revert to the previous settings. In terms of ownCloud what about we do the following on upgrade:
|
|
@karlitschek : Then, if a screen is displayed just before upgrade with list of non-compatible apps, some users will delay upgrade and pressurise addons developers to update theirs apps and maintain this information before next big upgrade.... |
|
@awikatchikaen almost no apps add a maximum version so this wont help |
|
I'm coming into this a bit late in the game, but one comment I would have is that the auto-disabler that's currently on 8.0.2 doesn't seem to log the apps that were disabled anywhere... that seems like a pretty large oversight to me if you're auto-disabling part of someone's configuration. |
disabled apps are printed on the terminal in case the console is used - for the web based upgrade the apps are displayed on the screen. Missing piece: #14569 |
|
@DeepDiver1975 Yes, and I saw the apps that were being disabled for a brief moment before the page redirected away. So, #14569 is certainly a step in the right direction. When I got hit by this, I immediately went to the OC log to see what it had disabled, thinking that surely it logged its actions like any well-behaved app.......... |
|
My 2 cents... if OC is to be a cloud for the masses solution, it should warn before doing something like this (despite putting it in the rarely-read docs), and it should be able to tell you what it did after the fact, so you can correct/reconfigure anything that changed. That's just good UX. |
|
@mrlego that was my point when I first complained about it. Rather than taking the easy way out and saying "well, other developers can't be assed to maintain theit projects correctly, so we're going to disable all 3rd party apps and break your OwnCloud install for certain, on the off chance that you have an incompatible app that might break it", the correct response (IMO) would be to warn (and give users the option to disable) when an app has a missing (or unrealistic) max version specified, or lacks compatibility data altogether; and warn of this issue on the download page, as well. Things should only be automatically disabled if the compatibility data says they're incompatible; and when something is automatically disabled, it should be logged and the page displaying the notification should not automatically forward. Let the app developers figure out why people stop using their apps; the problem will solve itself if you simply implement (and enforce) a few simple policies to combat it, rather than embracing it and making the upgrade process a huge PITA and causing people to simply stick with old (and vulnerable) versions of OwnCloud. For all intents and purposes, an OwnCloud installation that loses functionality after an upgrade is just as broken as one that doesn't come back up at all. Someone who is in a hurry might upgrade, see that the page loads afterward, and assume that everything is fine, while it's obvious there's a problem if the page doesn't load after the upgrade; and yes, even the best of us are in a hurry sometimes, so having it simply not load if something is incompatible is preferable in most cases I can think up. Of course, the issue of administrator competence will be raised in argument to my position. Please, save it. Yes, a competent administrator would hold the upgrade until they had time to fully test it, negating that specific argument; but then, the same competent administrator would know how to move 3rd party apps out of the apps directory and move them back in one at a time until it breaks (thereby identifying the offending app). We who have some semblance of competence do not want ou installs breaking after every upgrade; only after those during which an actual problem occurs (though, preferably, not at all). Furthermore, I'll reiterate something I said in my original complaint: apps that were limited to certain users or groups before being disabled are no longer limited after being re-enabled. This has to be done manually; and if an app exposes, say, a company's internal data that they, perhaps, don't want clients seeing (we're talking potentially sensitive data here), that's a security vulnerability right there. All in the name of taking a shortcut during the upgrade process and holding the hands of the incompetent as you walk them off a cliff. |
|
@karlitschek that's the app developer's problem, then. Do a bit of validation in the apps market, read the app's manifest and if it's invalid or missing some compatibility info, note that on the app's page, or, you know, reject the submission until they manage to submit it correctly. Do some basic quality control on the apps that are offered through the OwnCloud market and provide prominent warnings about lack of support for apps from other sources. By providing a simple way for your users to do their own due diligence to determine whether or not an app will work for them, you shift responsibility of ensuring that their OwnCloud installation doesn't break onto the user, where it belongs; more importantly, by clearly identifying and marking (or, better, rejecting) apps that do not follow compatibility guidelines, you shift much of that responsibility to the app developers who want people using their apps and supporting their work via donations. @Raydiation's per-app test idea, coupled with not automatically advancing past the upgrade report, would work as a secondary mechanism to ensure that only the apps that actually fail are disabled, and the admin is properly notified of the action. |
|
Another alternative or next step would be to automatically re-enable the apps that were disabled (and make sure they got reassigned to the proper groups if applicable), and run the upgrade for those apps. This could be done after the core upgrade was successful. |
|
Note that in my personal experience lately I almost always forgot to reenable the apps because I use "zypper update" to update my ownCloud, which also automagically runs "./occ upgrade". Only after I see weird error popups from KDE/Koragnizer I remember that I forgot to reenable calendar/contacts. So I'm all for finding a proper solution for this. |
|
My read on this issue, from everyone's comments in this thread, is that any solution other than the current practice of disabling all 3rd party apps and leaving them that way is an improvement. I like @PVince81's suggestion but (and I'm not familiar with the OwnCloud codebase, so I may be a bit off-base with this) it seems as though it may be one of the more complicated solutions suggested, implementation-wise. That said, it also seems like it would be the most robust, provided that there is some mechanism by which OwnCloud can tell if an app is working that doesn't rely on the developer of the app following some sort of development structure (if everyone could just do that, this wouldn't be an issue, as OwnCloud could just use the min/max version from the app manifest). I still think that using the min/max version from the app's manifest (after some sanity checking) and disabling apps which don't specify the data, or don't pass the sanity check, would be the simplest to implement, and would put pressure on app devs to get their ducks in a row. More details in my previous posts, of course. Even if that option isn't ultimately what gets implemented, I would like to see it discussed here, along with the options posed by @PVince81 and @Raydiation. Some of us are using OwnCloud professionally and not just internally, but as a customer-facing portal. It's really bad to have it (in the customer's eyes) breaking all the time when we update and have to completely reconfigure apps and permissions. |
|
Note, for information: it is not technically possible to detect many of the app errors due to the current app architecture. Loading of apps is done with PHP's "require_once" which doesn't throw exceptions if syntax/code errors are detected, unfortunately. See #5508 and @Raydiation's proposals here #8742 |
|
@PVince81 its possible by simply doing two requests, one which has the app enabled and one which does not load the app but allows you to disable it. That way you can check the http status code and conditionally disable the app |
|
With "request" are you talking about HTTP requests ? |
|
How to move forward ? Defer to 8.2 ? I'll repeat my suggestion: only disable third party apps for major upgrades. Starting with 8.0 it means upgrading from 8.0->8.1->8.2. That path would disable third party apps, because of possible architectural changes that might or might not break apps. I think it could be a good compromise until we get to the core of the issue ? |
|
So an option has been added on the CLI to upgrade without disabling: #16221 Let's keep this ticket here open to continue the discussion. |
|
Should this option be used in the RPM/DEB packages then? There's a related discussion about automatic package updates in #16806 that could possibly be moved in here or to its own bug. |
|
@DeepDiver1975 @Peter-Prochaska @VicDeo I'd be tempted to move to backlog for now, but this is likely going to continue happening with market apps. We'll eventually need to look into a safer way of enabling apps and test-upgrading apps in case they break stuff. |
|
whatever, backlog now... I hope the market will have a stronger validation for app versions, etc, so maybe at some point we could even keep all apps enabled on update. |
|
Crap like this is why I'm spending a few hours this month migrating to a
combination of OneDrive and Exchange. As much as I love the idealism of
having all of my data under my control, that's not the actuality of the
situation with OwnCloud, where I can either choose to remain vulnerable by
not installing updates, or choose to lose access to features and data,
potentially permanently if some app I'm using can't be re-enabled after the
update.
That's not my data under my control, that's my data under the control of a
team of people who don't have my needs at heart.
Microsoft, for all their flaws, at least provides a consistent experience;
and they don't make it too difficult to back up, either.
At least for my small team, the monthly cost per user is much less than the
monthly billable cost lost to maintaining OwnCloud.
Just some food for thought.
…-- Keith
On Thu, Apr 6, 2017 at 10:41 AM, Vincent Petry ***@***.***> wrote:
whatever, backlog now...
I hope the market will have a stronger validation for app versions, etc,
so maybe at some point we could even keep all apps enabled on update.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14754 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEE6EBaiKGekOufrJMWL73KQez9WKJb5ks5rtSOzgaJpZM4DrhsD>
.
|
|
@KeMBro2012 Seems you never have heard from the Just some additional thoughts on your comment: IMHO you're not forced to use ownCloud. And if something is not working for you how you're expecting it, it doesn't give you the right to blame other people like "that's my data under the control of a team of people who don't have my needs at heart." Furthermore ownCloud is Open Source and the beauty of this is that you're free to contribute and fix/implement something which is not working as you're expecting it. You don't have this possibility when using proprietary software like the one of Microsoft.
So how is this related to ownCloud itself? If an app can't be re-enabled after the update then the app has an issue and needs to be fixed by the app developer. Or what was the issue here and how is that related to this issue here? |
|
@kdslkdsaldsal I'm quite aware of that command-line flag, but I am also quite aware that the recommended way of installing and maintaining OwnCloud is via a repository, wherein that command-line flag is useless. Thanks, though 😄 I was in this conversation long before that command-line flag was added to OwnCloud; my last comment here was #14754 (comment) wherein I detail much of what was discussed before that comment. Much like the comment you just replied to, it was also not my first comment here. I tried to be productive, I tried to share ideas, I tried to work with the OwnCloud team toward a solution, and I may even had been willing to spend my own time implementing that solution once the concept had been accepted (more on that later, as it touches on something else you've said here). Where is your useful and productive input, @kdslkdsaldsal? You're absolutely right, I'm not forced to use OwnCloud, which is why I won't be after this month. However, if something is not working as expected and a project is seeking input, it is my place as a user to make my voice heard. For the duration of time during which I choose to use OwnCloud, yes, my data is very much under the control of the OwnCloud dev team and the people who decide which PRs to accept or reject (more on that last bit later, as it pertains to something else you've said here). Until I migrate to another solution, my choices are to remain vulnerable by not upgrading or risk losing functionality (and possibly data which relies on that functionality in order to be properly utilized) during an upgrade. In fact, I will be losing data in the migration, as some of that data is associated with features added by 3rd-party apps which don't really have a parallel elsewhere. So that data remains under OwnCloud's control, as I can't really take it elsewhere; as a result, I lose that data when I go. Such is life. Yes, OwnCloud is Open Source and, in theory, the beauty of that is that I am free to contribute, fix, and implement. The reality, as someone who was once a strong proponent of the Free Software Movement, actually lies somewhere in between that idealism and proprietary software. If I fix this, I already know my fix won't be accepted, as it has already been decided in this thread that the issue wasn't worth fixing. It was stated that things work the way they do because "reasons" and it was not going to change; any PR I might submit to change that would surely be rejected. So yes, while I could still fix it for myself in that case, I will have, then, added an integration task to every update; I would, then, need to integrate my fix into every update that comes after it, and fully test before deploying. At that point, I'm no longer using OwnCloud, but my own personal fork of the project, and the problem I've stated here is that I'm already spending more time than I can afford maintaining my OwnCloud installation. How does your suggestion that I fix it myself help with that? So, no, I really don't have any more opportunity, in any reasonably non-pedantic sense of the word, to fix issues in an Open Source project than I do in a Closed Source project; both require that the maintainer agree that the issue is an issue, be willing to see the issue fixed, and be willing to let me do the fixing. Yes, I can fork the Open Source project, which is something I can't do with Closed Source; but, again, how does that fix my problem? It doesn't; it adds to it, because then I don't just have apps to re-enable after an upgrade, I have upstream patches to integrate and test against my modifications, which would be more work and take up more of my time. There is a reason I chose a pre-existing team-backed project, rather than rolling my own; quite simply, I don't have time for that. Microsoft might not give me the ability to fix issues and add missing features myself, but they do give me a phone number I can call to have that done on a priority basis if I'm paying for it. I've spend 20+ hours on the phone with them over the past 30 days hashing out implementation details for features and fixes in several Office products, including OneDrive and SharePoint, and those are being implemented. Yes, I know, you're gonna say "but then you're paying for it". Yes. I am. Much less than the billable hours I would have to lose to have done it myself, as a matter of fact! You see, I've done the math, and it would cost me much more (in lost billable hours) to maintain my own fork of OwnCloud to incorporate the fix they've already said they don't want than Microsoft's solution will ever cost me. You seem hurt that I'm not contributing my time and code to fix this, but I never heard back from the OwnCloud team on my proposed solution and, thus, never got approval to joint the team and implement that fix. Doing so without first knowing that (pending quality of code, of course) my work would even be accepted simply makes yet more work for me and costs me yet more than I'm already taking issue with. You do see this, right? Perhaps, if some consensus could have been reached regarding how to handle this, it could have been fixed. If the OwnCloud team, themselves, weren't interested in being the ones fixing it, they could have encouraged one of us who raised the issue (it wasn't me, by the way; it seems like you're brand new to this thread, so I just thought I'd point that out) to fix it by accepting one of our proposed solutions as "the way forward". I would have started working on it right then and there. In fact, it would have been a race between at least 3 of us, to see who could build it better, faster. |
|
Huge wall of text, to lazy to answer 😄 . Just two short notes:
Exactly there you can use the command-line flag. The packages from the repositories are not doing the database updates for you so you're free to also use that flag when using the repositories. The main issue i see here was, that too many people raised there voice and started to discuss stuff not even relevant for the main original issue: Don't disable 3rdparty apps for minor updates Some one could have just stepped up in the last two years and just implement that one and i doubt that it would have been rejected (you also don't need to be in the "team" to submit pull requests). Personally i'm using the --no-app-disable command line flag since its introduction and mention in this thread two years ago without any issue during minor updates. So using that flag / option programmatically during minor updates should have been a complete valid fix for this raised issue here. |
|
If someone has time to implement a check to only disable for major releases but not minor releases, I'd be willing to accept it. @DeepDiver1975 will the market have stronger validation to make sure apps have proper deps info and min/max versions ? Side note: since the fork some things that weren't possible before have become possible, so a decision made two years ago can be reconsidered. |
|
also in general times change, so past decisions must be questioned because many factors that might have existed before might not exist any more in the present |
|
While I am still migrating my data away from OwnCloud, I will still
consider assessing my available time to contribute this feature/fix.
I make no promises, as my workload has changed (increased) considerably
since the time when I would have jumped on this without a second thought
(thus why I am now choosing to pay someone else to manage the details), but
I'll do what I can.
Since my issue is primarily a time issue, I hope it is understood that I
lacked the time to bring that decision from two years ago into question, as
I also now lack the time to immediately begin familiarizing myself with the
OwnCloud codebase well enough to quickly and correctly implement this
feature/fix. For that reason, I was leaving the discussion up to everyone
else.
I now find myself in a position where certain pieces of Microsoft software
are the de-facto standard by which I must communicate with a subset of my
clients, and a massive chunk (per user) of OneDrive storage is included in
the licensing of that software, so the reality is that it solves my time
issue at no additional cost (beyond what I'm paying for support in order to
have certain features implemented).
At the end of the day, ideology is important, but practicality wins out.
While I'd love to see my needs met by Open Source software (and in many
areas of my business and personal life, indeed, I do see this), I am
considering *needs*, rather than *wants*, and I must make the decisions
that see those needs best fulfilled.
I'll keep revisiting this until either I find the time to implement the
feature/fix, or someone else beats me to it.
…On Mon, Apr 10, 2017 at 12:05 AM, Vincent Petry ***@***.***> wrote:
also in general times change, so past decisions must be questioned because
many factors that might have existed before might not exist any more in the
present
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14754 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEE6EFpv-rLh2g452IuzyOsvcUX9ddkPks5rudTSgaJpZM4DrhsD>
.
|
|
@KeMBro2012 FYI: #27730 |
|
10.0 will not disable third party apps any more. |
|
@kdslkdsaldsal Thanks, got it.
…On Mon, Apr 24, 2017 at 12:16 PM, Vincent Petry ***@***.***> wrote:
Closed #14754 <#14754>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14754 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEE6EIk4GR8QQQsjkZvwkv1vYSuEQFftks5rzPUYgaJpZM4DrhsD>
.
|
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
See #14026 (comment)
Major upgrades as in the new versioning scheme: 8.0 -> 8.1 is a major upgrade, 8.0.0 -> 8.0.1 isn't.
Not sure what can be done for apps that still break minor updates (not sure which, since there should be no API changes in minor upgrades)
@KeMBro2012 @DeepDiver1975 @karlitschek
The text was updated successfully, but these errors were encountered: