* Revert Home Assistant configuration to `/config`
With the new add-on config feature the intention is to provide a good
location for add-on specific configurations. Currently, add-ons such
as Node RED or ESPHome use the Home Assistant config directory because
this location is accessible to the user (via Samba VSCode add-on etc.).
To make it clear to add-on developer that the new intention is to use
add-on specific config, the implementation now bind mounts the add-on
configuration directory to `/config`. And since some add-ons still need
access to the Home Assistant configuration, its config folder is mounted
to `/homeassistant` under the new scheme.
However, users do know the path `/config`, and edit things e.g. through
the SSH or VS Code add-on. Also `/config` is still the
directory from inside the Core container.
For SSH/VS Code add-on we could work around using a symlink, but that
only works as long as these add-ons don't have a add-on config
themselfs.
This all has very high confusion potential, for not much gain. The
renaming is mainly "developer friendly", but not really user friendly.
Let's minimize potential confusion, and keep things where they are.
The Home Assistant config directory stays at `/config, in all cases,
everwhere.
Map the new add-on configuration directory to `/addon_config`.
* Adjust tests/comments
* Don't check if Core is running to trigger rollback
Currently we check for Core API access and that the state is running. If
this is not fulfilled within 5 minutes, we rollback to the previous
version.
It can take quite a while until Home Assistant Core is in state running.
In fact, after going through bootstrap, it can theoretically take
indefinitely (as in there is no timeout from Core side).
So to trigger rollback, rather than check the state to be running, just
check if the API is accessible in this case. This prevents spurious
rollbacks.
* Check Core status with and timeout after a longer time
Instead of checking the Core API just for response, do check the
state. Use a timeout which is long enough to cover all stages and
other timeouts during Core startup.
* Introduce get_api_state and better status messages
* Update supervisor/homeassistant/api.py
Co-authored-by: J. Nick Koston <nick@koston.org>
* Add successful start test
---------
Co-authored-by: J. Nick Koston <nick@koston.org>
* Remove race with watchdog during backup, restore and update
* Fix pylint issues and test
* Stop after image pull during update
* Add test for max failed attempts for plugin watchdog
* Support proxy of binary messages from addons to HA
* Added tests for proxy
* Move instantiation into init
* Mock close method on server
* Add invalid auth test and remove auth mock
* Backup and restore track progress in job
* Change to stage only updates and fix tests
* Leave HA alone if it wasn't restored
* skip check HA stage message when we don't check
* Change to helper to get current job
* Fix tests
* Mark jobs as internal to skip notifying HA
* Working draft for x-remote-user
* Renames prop to remote_user
* Allows to set in addon description whether it requests the username
* Fixes addon-options schema
* Sends user ID instead of username to addons
* Adds tests
* Removes configurability of remote-user forwarding
* Update const.py
* Also adds username header
* Fetches full user info object from homeassistant
* Cleaner validation and dataclasses
* Fixes linting
* Fixes linting
* Tries to fix test
* Updates tests
* Updates tests
* Updates tests
* Updates tests
* Updates tests
* Updates tests
* Updates tests
* Updates tests
* Resolves PR comments
* Linting
* Fixes tests
* Update const.py
* Removes header keys if not required
* Moves ignoring user ID headers if no session_data is given
* simplify
* fix lint with new job
---------
Co-authored-by: Pascal Vizeli <pvizeli@syshack.ch>
Co-authored-by: Pascal Vizeli <pascal.vizeli@syshack.ch>
* Extend container image name validator
The current validator allows certain invalid names (e.g. upper
case), but disallows valid cases (such as ttl.sh/myimage).
Improve the container image validator to support more valid
options and at the same time disallow some of the invalid
options.
Note that this is not a complete/perfect validation still. A much
much more sophisticated regex would be necessary to be 100% accurate.
Also we format the string and replace {machine}/{arch} using Python
format strings. In that regard the image format in Supervisor deviates
from the Docker/OCI container image name format.
* Use an actual invalid image name in config validation
* Add job group execution limit option
* Fix pylint issues
* Assign variable before usage
* Cleanup jobs when done
* Remove isinstance check for performance
* Explicitly raise from None
* Add some more documentation info
