Reproducible configuration for modern setups

Feature Requests
1

We are using Home Assistant Core in a more enterprise-y way than probably most do, we actually do use Home Assistant at our work office. This means that:

  • Home Assistant Core is running as pods on OpenShift (Kubernetes) in two different stages (test and prod)
  • Configuration changes are tracked in our GitHub repository
  • A CD pipeline applies configuration first in test and then, if tested ok, it is applied to prod

This setup is missing two key components which I would like to suggest as feature requests:

  1. All configuration is reproducible
  2. Provide a health endpoint without authentication

1: This was partly already suggested by at least this feature request by @ebbe. Unfortunately commenters didn’t really understand what the requester was asking for. There’s a trend that components don’t work in the classic Home Assistant way anymore (configuring Home Assistant and integrations in configuration.yaml) and rather only provide an integration via web interface. The same applies to the basic information in Home Assistant which, according to its documentation, should be configurable via variables. This does not work anymore because of the onboarding process.
What I’m suggesting is this:

  • Make the onboarding process configurable including basic information and authentication
  • Encourage integrations to provide the means of configuring via configuration.yaml

2: This one’s rather small compared to the first request. Usually in order for Kubernetes to know if an application is running properly a health endpoint (e.g. /health) is provided by the app. In Home Assistant, this would be /api. However, this endpoint expects an authorization token and this token can only be obtained if the application is already running. This leads to two different Kubernetes deployments that have to be maintained, one without and one with the health check because the health check only works if the Authorization header could be correctly provided

It’d be really awesome if these suggestions could be considered for future development of Home Assistant.

2

I use Home Assistant Core version 105.2 and I’m still able to configure this basic information in configuration.yaml.

Can you please show me some integrations, which you are not able to configure through configuration.yaml? As far as I understand HA goes in the direction to make everything configurable through the frontend, BUT keep the possibility to configure it manually. I could be wrong.

3

I just tested this again. I use a minimal configuration.yaml containing the following lines:

homeassistant:
  name: REDACTED
  latitude: REDACTED
  longitude: REDACTED
  elevation: REDACTED
  unit_system: REDACTED
  time_zone: REDACTED

frontend:
config:
history:
logbook:

Name, longitude and so on contain valid values. I delete everything else (most notably the .storage directory), start Home Assistant and arrive at the onboarding screen. First it asks me to set up a login, then it asks me how I would like to name my home and where I live. What I would expect is the onboarding process to take what I already configured in the configuration.yaml, which it does not do.
Did you configure something else as well? Am I doing something wrong?

Most prominently the ESPHome integration. To be honest I’m not aware of any other integrations that do this as well, but I don’t know that many. Nevertheless it’d be great if I’m mistaken here and ESPHome is just an exception.

4

I think you need to add it to the configuration.yaml after the initial onboarding process. I assume the initial onboarding overwrites the configuration.

You are right about the ESP Home integration. I don’t know much about the ESP Home, but couldn’t you just copy over the .storage folder as well? This should contain all your devices and you shouldn’t need to setup anything over the UI.

5

The whole purpose of my feature request is to make the onboarding process obsolete if all necessary information is provided in the configuration.yaml.

There’s several reasons why this is bad. The configuration.yaml should be the single source of truth. We want to configure everything in it and then deploy it via CD pipeline. The mixture with the .storage directory makes everything unreliable because

  • we don’t know how the configuration in .storage should look like in advance
  • we don’t know if the configuration syntax in .storage changes
  • we have to delete/ignore everything sensible such as auth information etc.
  • we want to configure everything in advance and not first have to click in a web interface
6

This is a very sensible request and I second it. I’m working on a first time setup of HA, and would really appreciate to being able to define basic config info like name, lat, long, etc in the configuration.yaml initially, and skip the onboarding process all together.