WTH - Allow Portainer docker

Why on earth is Portainer now on the ban list. I would expect a lot people who use Docker seriously do so through Portainer.

Portainer is container orchestration software. It can install new containers, change docker settings, change settings of existing containers, etc. None of that stuff is supported and much of it can cause all sorts of strange errors in supervisor.

A supervised install is not a docker install, its an appliance install much like HAOS. The only supported way to run supervisor is if supervisor is managing the system, including docker. That means (among other things):

  1. Docker and the system is set up by the supervised installer or as part of HAOS
  2. The only containers running are Supervisor, its plugins, Core and Addons, nothing else.
  3. The only networks are the ones supervisor makes to support the containers it manages
  4. All containers are started by supervisor with the config it started them in. With the exception of the supervisor container itself as that is started by a host service or by observer

Basically literally everything you can do in portainer is unsupported. If you want to use portainer you should switch to a container installation

2 Likes

Thanks for the response - when will the container installation get Add-on support?

1 Like

Addons are docker containers. So container installation has addon support. Just list the images for the other software you want to install and configure it.

Could we not have a ‘happy to take the risk’ option and disable the checks?

1 Like

That’s existed for a while

# ha res check options -h

This command allows to apply options to an specific check managed by the system.

Usage:
  ha resolution check options [flags]

Aliases:
  options, option, opt, opts, op

Examples:

  ha resolution check options [slug]

Flags:
      --enabled   Enable/Disable check on the system (default true)
  -h, --help      help for options

Global Flags:
      --api-token string   Home Assistant Supervisor API token
      --config string      Optional config file (default is $HOME/.homeassistant.yaml)
      --endpoint string    Endpoint for Home Assistant Supervisor (default is 'supervisor')
      --log-level string   Log level (defaults to Warn)
      --no-progress        Disable the progress spinner
      --raw-json           Output raw JSON from the API
2 Likes

never.

there is really no way to get add-ons without the supervisor functionality.

but as mentioned you can already get the same (similar) functionality as add-ons by just managing the docker containers yourself.

2 Likes

Perhaps my WTH should then be ‘WTH - have a GUI section for changing check options’ ?

Ok actually I have to correct my response. you use ha resolution check options to enable/disable checks. What you’re looking for is to tell Supervisor to ignore its job condition that says the system must be healthy which is a different command:

# ha jobs options -h                                                                                                            ✔  [email protected]  12:05:07 

This command allows you to set configuration options for the internally
Home Assistant Job Manager.

Usage:
  ha jobs options [flags]

Aliases:
  options, option, opt, opts, op

Examples:

  ha jobs options --ignore-conditions healthy


Flags:
  -h, --help                            help for options
  -i, --ignore-conditions stringArray   Conditions to ignore on Job Manager. Use multiple times for ignored conditions.

Sorry about that.

2 Likes

If you change the WTH to that, you’ll be waiting for an eternity. Advanced settings are hidden in SSH to keep beginners from using them. You should know the risks before enabling it, because you wont get support when it inevitably breaks for e.g. if you muck up the containers with portainer.

@mike This is a little bit BS, isn’t it.
Portainer is a UI that makes managing containers easier. But I can do everything I can do in Portainer also from a command prompt using Docker commands, and me having access to SSH or using PuTTY doesn’t make me unsupported.
Using an analogy to bring home the point, in Windows I have access to (amongst other things) the registry and can corrupt my installation in a flash, but Microsoft happily cashes my license subscription without getting emotional about it. They even make additional tools available through guys like SysInternals to help us scratch around in the kitchen. They allow me to run almost everything I want (even Home Assistant) on “their” system, and yet I remain supported.

What am I missing here?

Only one of the ssh addons is able to access the docker cli (notably the community one not the official one). And if you used that to make changes then many of the things you can do would also mark the system as unsupported.

Microsoft has thousands of employees. They can afford to hire tons of people who just sift through bug reports and manually filter out the ones where they have something to fix from the ones where the user shot themselves in the foot.

Nabu casa has about 20 employees. This approach doesn’t work at that scale, those employees would spend all their time dealing with bugs. They needed a way to more quickly separate bugs that require their attention from ones where the user probably shot themselves in the foot. Codifying what is and isn’t supported into the product when possible and marking systems accordingly is the solution.

Nothing stops you from doing it anyway. Just like Microsoft spent time making tools to muck with the registry, ha devs spent time coding in options to allow users to ignore the added checks and do what they want. The HA devs just wanted to make sure they don’t waste time dealing with bugs from these systems that went outside the bounds of what is supported.

Totally makes sense if you ask me.

Supervisor is basically an integrated, customized Portainer within Homeassistant.

However Portainer is something that is not made for Homeassistant.

So having both will introduce a ton of side-effects and possible bugs, e.g. accidently deleting Docker Volumes and downgrading Core Containers that are without knowdlege of Supervisor - bam suddenly everything stops working.

Either go for HAOS/Supervisor install or just go Container + Portainer and die happily afterwards.

There should be no mixture of both worlds. There is absolutely no happy middle there.

Hint: Container based + Portainer is more work but also a lot more flexibility and freedom.

Once you get used to it you’ll likely love it (unless you try to blame the tools for your lack of patience and or knowdlege and tought).

But its not something for the lazy, that’s for sure.

3 Likes

Absolutely they can co-exist. I’m running a supervised install, including Portainer, for the past two years, with no stability issues at all. At least not caused by Portainer. There were to my knowledge no single side-effect, no bugs introduced by Portainer, and I never managed to accidentally delete Volumes, Containers or whatever. I manage my HA upgrades etc. through the HA UI, and use Portainer to manage the other Containers in my stack. I can stop/start or upgrade my Node-Red, Apache, Grafana … Containers when required, create a session in e.g. the Mosquitto Container to listen to or publish MQTT messages (etc.). And if need be I can easily look at the logs of the HA Containers when HA can’t start up, without the need to e.g. use SSH and figure out where the logs are.

Did you ever delete a file by mistake using Windows Explorer? Should we ask Microsoft to remove it from the implementation and make those users unsupported who manage to install it from somewhere?

If a user do things by mistake, don’t blame the tool or claim it can’t be used by those who do know what they’re doing.

1 Like

Hi

in my opinion removing the ability to manage containers from Ui is a big mistake. They should bring it back as soon as possible.

Br
Thomas

As I recall, the old official Portainer Add-on was based on Portainer Version 1. There is a newer unofficial add-on that’s based on Portainer Version 2 if you absolutely must have it.