Sorry, but, again, all this seems overly strict to me too, especially for an “open source” project. We understand that one of the main goals this past couple of years has been to “dumb down” the project and/or to “Applefy it”, but this is WAY too excessive.
First of all where is it documented that “people updating to HA core 2022.9.2 and having portainer will immediately have an unhealthy installation and further on that they will not be able to update from that point on”? I was not able to find such a warning. I always had an “unsupported” installation for this reason, which I accepted, but not being able to update the software goes a long way. At least make it an option.
Secondly, having HA and various other docker containers on the same host should be a valid option for the users, especially those who have a supervised install. Because what is the point of having a supervised installation if the user cannot use the host for anything else? That’s why we opt for a supervised setup in the first place! I understand the “unsupported” state, but not being able to use the host for anything else unless I accept to have an outdated HA instance is unacceptable to my eyes.
“Inexperienced” users will: a) Either have HA OS installed and (should) not tinker further. b) Or not even know what Portainer is, how to install it out of the HA environment as mentioned above, let alone “play” with it and mess HA. Even then, the project would not be the one to be blamed but the user, doing things without any knowledge.
Anyway, all this should not justify the strict, unrelenting decision for everyone else “either have ONLY HA or have also something else but an outdated HA instance” .
Then I’m sorry to tell you but you made a decision based on a fundamental misunderstanding of the supervised install. As it says very clearly in the ADR:
The operating system is dedicated to running Home Assistant Supervised.
All system dependencies are installed according to the manual.
No additional software, outside of the Home Assistant ecosystem, is installed.
Both supervised and HAOS are only supported as pure appliance installs. Neither was intended to be used alongside myriad other software that is not part of the Home Assistant ecosystem.
All checks and conditions that are added also come with options for advanced users to ignore them. Scroll up in this thread to see the one for this check. If you want to run this way nothing stops you, there’s a built-in option to allow that.
The checks are all added because it has come up in issues forcing developers to spend time digging into things that aren’t bugs. They are user caused from doing unsupported things. So to prevent this from happening again a check is added. Always with a way to ignore but want to make sure everyone is on the same page - “{x} is not supported”. Or in some cases “{x} is deeply problematic (i.e. unhealthy)”
I hear you and I get the part about people still expecting support.
However, wouldn’t it be better to make a habit of declining support when users ask for support for unsupported HA setups?
Perhaps adding some pop-ups everytime HA is restarted; This is an unsupported setup, please do not report tickets occurring on this system, you will not get help.
Also, the support is community driven isn’t it, there might be people willing to give support as long as it is clarified from the user what tweaks has been done?
Why not implement an option where you can disable those checks, making the above statement very clear when doing so?
You very clearly failed to quote one sentence before that: “This installation method can easily be broken if one manages the operating system incorrectly.” All this seems like a simple, clear “recommendation” to me, not a strict “sorry, you will have to accept a new Apple-like environment”, where you will not be able to install anything else along HA. “Take it or leave it”.
Apart from that, is there an answer to my question, where was this BREAKING change clearly documented? Or did it just creep its way in the update just like the myriad other changes that slowly but steadily try to force us to abandon a supervised install?
Who is talking about “support”? All of our installs were “unsupported” almost from day one for this reason. We accepted it, we understand the “recommendation”, we note it. Now we are simply forced to abandon HA supervised or any other software on our hosts. It doesn’t get any more “Apple” than that.
Can’t understand why having Portainer was not deeply problematic for x amount of years and it suddenly is considered such.
If this is your stance then why has anything changed for you?
ha jobs options --ignore-conditions healthy
Done. Still unhealthy and unsupported but no more update errors.
Like I’ve said many times in this thread, there are no unignorable checks. No one is going to stop you from doing whatever you want. The goal is just to inform users of the risks and ensure developers know the situation if a ticket is opened.
EDIT: I guess I should say probably no more update errors. It won’t block you from trying. Whether it works or not I have no idea, depends what all was changed.
EDIT 2: I just realized I hadn’t shared the jobs options thing in this thread. So apologies for that, you couldn’t see it if you scrolled up. There’s a couple similar threads and I forgot where I shared what.
This has been an unproven statement since the day HA decided to make supervised installs obsolete for unknown reasons and immediately took this decision back after a huge community backlash.
How many people asked for “support” and the problem was that they had Portainer installed outside of HA? Are there statistics about that? How much big of a deal is if someone has a couple of containers installed alongside HA? How are we supposed to troubleshoot a failed HA update if the whole HA docker ecosystem does not even start if we do not have Portainer to see what’s going on?
If someone “plays” with HA supervised and some containers alongside it and messes the system: a) They know they’ve done a boo-boo and do not expect “support” from the project. Anyway, it will not be War World III, it’s not software to control hospitals, it’s just a piece of automation software. b) The community could be willing to offer support in those cases too, what’s the big deal? c) Support could and was always rejected in such cases. Now an update of HA is prevented, this is an other whole story.
After this initial failed decision to make supervised installs obsolete, every 5-6 months we have another “change”, which tries to make supervised installs and having other software on the host as inconvenient and/or as difficult and complicated as it gets (=example: Os-Agent, with no easy way to install and update it or at least to have notifications for an update).
The 65th thing I now have to remember to do every time, in order to maintain and update a simple supervised install, which “dared” to have Portainer or any other container installed.
And not just that: Why should I completely lose and abandon a health check for my whole system, which could alert me to a legitimate problem? This is not even a solution. The obvious solution is to allow other containers along side HA, put a HUGE RED FLAG “UNSUPPORTED” somewhere in the GUI, allow HA to update normally and end of story. EVERYONE IS HAPPY: The project is not to blame, we are happy to have our open-source software we adore in an “open-source” and not in an “Apple” state and inexperienced users are informed not to do a boo-boo.
But unfortunately it’s clear as day that the end-goal is not to have EVERYONE HAPPY, but take the project to a completely different path.
And for the third time: Where was this BREAKING change clearly documented? Or did it just creep its way in the update just like the myriad other changes that slowly but steadily try to force us to abandon a supervised install?
@Tryfos and @CentralCommand, this discussion is getting a bit heated…
My last post in this topic (I think), even if I get your points CentralCommand I still believe that this latest change is turning the screw a bit too tight, feels like a new direction to completely stop HA from updating in this manner.
Has it been extensively discussed among “management”, the people deciding the major design steps and future direction?
My only wish is that there would be a new discussion at that level, to consider the pros and cons and be absolutely sure this direction is the correct one to follow.
Can imagine there a lot of users out there who are still scrathing their heads after a failed update today and are posting questions in the support forums.
(I for one had no knowledge of the ignore-conditions option, had to resort to the stop the portainer container)
I’m just trying to voice my disagreement, that’s all. I don’t think I’ve crossed any lines. Of course I’m a little bit worried about where the project I adore is clearly heading. I think everyone should be a little bit worried about that too.
Anyway, I would appreciate it more if someone from the project officially informed us that supervised installs are no longer supported/welcomed/recommended and be done with that. It’s annoying that every 3-5 months they come up with various unannounced “changes”, which try to make supervised installs completely undesirable and put the project to a completely different path. At least let us know!
No, no lines crossed.
Yes, would have saved a large number of users a lot of grief if it had been part of the release notes, completely agree.
Perhaps under the heading Farewell to the following…
It’s in here. But the reality is if you run an unsupported system then you need to assume every release can contain undocumented breaking changes. Breaking an unsupported system isn’t considered a breaking change. There is no effort made to consider what unsupported systems may break and no testing done around that.
The only reason its noted as a breaking change in the release note is because of the now long-deprecated community add-on. Which may have duped people into thinking they were doing supported things.
I’m not sure who you’re referring to as management in this context. But the PR that made this change was put in by pvizelli (creator of HAOS and Supervisor) and approved by Frenck and me (I’m mdegat01 on GitHub). So that is 3 of the top 5 contributors to Supervisor and Frenck and pvizelli in particular show up at the top of every contributor list in the HA ecosystem. I can assure you ludeeus approves as well as its come up in chats, he just didn’t see the PR in time.
And this isn’t a major design change. You’ll notice for example that watchtower marks system as unhealthy as well:
That’s been in there for a while. The only reason portainer wasn’t was because there used to be an addon. But that addon has been deprecated for over a year now and a recent issue was a reminder that portainer should be in this list too.
I would prefer not to have this change at all to be honest. In my view this is a major change for the project and it has to do with the new path it has chosen to follow.
OK not going to lie. Much more passion going on here than I can read. So I updated Ubuntu to the latest, and updated portainer to the latest but same deal. Restarting supervisor as others have stated does not work anymore to update. Couple things:
How do I do this on a Ubuntu docker instance:
ha jobs options --ignore-conditions healthy
Are there clear steps how to drop our entire install into a supported implementation? For me needs to be in a virtual machine.
I think exactly here hides the culprit of all this. Unfortunately it seems to be wishful thinking only. As you have been also active here and here you might have noticed that quite a few users are immoderately overestimating their own skills insisting on a HA Supervised installation and start to rant soon after if it doesn’t work out as expected. Some are not even willing to read the precautions and instructions (I mean thoroughly read, not just quickly skimming through the warnings and instructions).
I am disappointed too not being allowed to install some other docker containers like i.e. Portainer on the same host HA Supervised is running on if I want to keep that native “healthy and supported” HA installation. Besides it can not really being called sustainable to waste that much processing power (and electricity) especially if one runs HA Supervised on something more powerful than a RPI.
But taking the view of the devs and moderators of the forum I can understand their decision to simply limit the amount of docker containers allowed next to HA Supervised, although the consequenses are a bit harsh. As it was already pointed out further up this thread all too many users are simply blaming all others for their own incapabilities
I really wish
since I am sure it would not have taken us into this patronised misery in the first place.
I still don’t quite get it. How would the project be bothered if it flashed a BIG RED FLAG at every, say, reboot, or somehow, that the instance is unsupported and the project does not bear any responsibility for anything if something goes bad.
But NO, instead of that, the “unhealthy state” is tucked away 5456 clicks away, behind Settings-System-Repairs(what?)-3 dots(!!!)- System information. I’d been using HA for ages and I had a problem finding that back when the GUI changed. You may have 1435 containers alongside HA and never realise that its state is “unhealthy”.
In any case the project does not bear any responsibility for anything. It’s just free and open source automation software. Not a commercial, supported, paid and licensed software that runs an airport or a hospital. For God’s sake, this is just an excuse to further wall the garden.
Where are you seeing that? And even if it happened, what’s the big problem about that? Just another post in a thread. That’s why the community is there and will be there. Who cares if a guy just came straight from iOS and now wants to run a supervised install eg. within Proxmox withing a VM within a docker container? He’s just having fun. The project must not bother to answer it or/and fix any problem. And that’s what it did up until now: “-Do you have another container? -Yes. - Sorry, bye-bye”. I can’t see such a big deal here, which should result in such drastic decisions. That’s why we accepted the “unsupported” state. But the inability to update goes a LONG way.
Needless to say, that the proposed “solution” to completely deactivate the health check for the WHOLE setup is not a solution obviously, since we lose an important check for the whole instance for no important reason whatsoever.
Finally, if we go this way without a fight, what’s stopping the developers from blatantly saying in 2-3 months that if “we detect another dreaded, prohibited, abhorrent container alongside HA, HA WILL NOT START/WORK”? Will you also support this decision because “inexperienced users tend to break stuff”?
Sorry if I seem angry or anxious, but, yes, I’m worried when I see my favourite piece of free, open-source software changing paths (if you get what I mean)… And big changes often come gradually and slowly, not in a day or two (if you also get what I mean).
