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

Revert Home Assistant configuration to /config #4697

Merged
merged 2 commits into from
Nov 11, 2023

Conversation

agners
Copy link
Member

@agners agners commented Nov 11, 2023

Proposed change

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 and use 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. The path is also in documentations and how-to's.

For SSH/VS Code add-on we could work around using a symlink (pointing /config -> /homeassistant e.g. as suggested in home-assistant/addons#3304), 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, everywhere.

Map the new add-on configuration directory to /addon_config.

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New feature (which adds functionality to the supervisor)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

  • This PR fixes or closes issue: fixes #
  • This PR is related to issue:
  • Link to documentation pull request:
  • Link to cli pull request:

Checklist

  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • The code has been formatted using Black (black --fast supervisor tests)
  • Tests have been added to verify that the new code works.

If API endpoints of add-on configuration are added/changed:

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`.
@agners agners marked this pull request as ready for review November 11, 2023 12:22
@agners agners merged commit 16b71a2 into main Nov 11, 2023
22 checks passed
@agners agners deleted the revert-config-naming-to-avoid-confusion branch November 11, 2023 12:41
agners added a commit to home-assistant/developers.home-assistant that referenced this pull request Nov 11, 2023
@github-actions github-actions bot locked and limited conversation to collaborators Nov 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants