Make configuration directory more organized for clearer backup method

Feature Requests
1

I think it’d be wise to restructure homeassistant’s config folder into three (maybe more depending on need) subfolders: config_pub, config_private, and dynamic. In addition I suggested we completely eliminate the .storage folder. These changes will make it much easier to determine what files are valuable and public, valuable and private, and not valuable for creating backups.

Here’s my reasoning: right now when I go to where /configis in my docker installed ha-core instance I see a ton of different files (especially if i include the files in .storage). It’s hard to tell which of these files fall in the these different categories:

  1. Commit to git, it’s okay if they are seen and are basic backbone configurations.
  2. Backup but not to public git, these have security tokens and other auth related stuff I don’t want exposed.
  3. Don’t back up at all, no reason to because it’s stuff like OZW logs.

For instance, I like to configure my lovelace UI using the GUI, but WHY is it stored in the hidden .storage folder along with a ton of other stuff that shouldn’t be backed up publicly?! This makes no sense to me, why wouldn’t it just store to ui-lovelace.yaml? Or if there is risk of file conflicts between handcrafted lovelace and GUI made ones it can store store to ui-lovelace-gui.yaml and be included with the normal ui-lovelace.yaml.

If every file from config and .storage were separated into their own folders that determined their importance for backing up it would make it so much easier. I simply git commit config_pub, I backup config_private to somewhere safe in cold storage, and I gitignore dynamic because it has stuff like logs that are generated during sessions that I don’t necessarily need permanently.

2

I responded in Discord, but for visibility, there is an ongoing architecture discussion about this already: https://github.com/home-assistant/architecture/issues/370

3

There has been zero movement on that thread for months but i support all the ideas in it. State and configuration shouldn’t mix. Then i propose there be two main folders state and config and within config there would be the public and private and within state there is the static and dynamic.

At the very least it’s an incredible disservice to make the lovelace yaml live in .storage simply because it was configured via the UI; it adds opaqueness and isolates the lovelace yaml from the rest of the configuration yamls.

In the very short term i suggest moving the .storage lovelace file up a level and put it next to ui-lovelace.yaml, renaming the .storage one to lovelace-gui or something along those lines.