I still think a decent compromise would be something similar to the lovelace configuration where there’s a yaml mode and a storage mode.
6 Likes
And for what purpose do you need the secrets-file when there are no more yaml-integrations? I bet you know you shouldn’t use the same passwords for multiple devices for security reasons. Hence you probably have a password manager to keep track of your passwords. So if you change the password of a device (or whatever type of integration), you’ll update your password manager in any case, and ideally it’s just a few clicks to update the integration. Heck, you could even start sharing your secrets-file then (because it’s empty!) 
Well, yeah. There’s no point in describing inputs with self-explaining labels, and the more exotic ones will be explained in the documentation (probably even along with the regular ones).
May I ask why you are doing this? I get that programmatically deploying instances of whatever totally makes sense for certain requirements. But unless you build a new house every few weeks with the exact same hardware, I don’t get how Home Assistant could profit from this approach. For disaster recovery all you really need is a backup of your config-directory. That’s how most of the others are doing it. So please, enlighten me. I never saw use for Ansible in my (private) life, so I’m honestly curious about the benefit you’re getting out of it. 
2 Likes
Thumbs up!
1 Like
Interesting discussion here, lot to think about. Personally I like the UI setup for integrations. I mean I’m perfectly comfortable configuring everything in YAML but it nice to have a UI.
This isn’t to say the UI approach is perfect. As stated repeatedly through this thread, sharing is problematic with the UI approach. The point made that integrations are mostly around credential configuration which isn’t shared is valid but some integrations have more options then that. Still, looking at my own, very few have more then just fields for credentials and a name so I do get it, most are pretty unshareable.
Also I’d say personally my biggest issue with the UI config approach is an inability to return to the UI you used to configure the integration. After you add an integration via the UI and fill out the form there’s no way to return to that form, see what you filled in and change it or clone that config to a new one. This is a hassle and I would like to see that become part of the process if possible.
For future enhancements, I would love the UI approach if some strides could be made in dependency tracking and management. For instance I think a big part of the loss right now is when someone shares a config there’s usually dependencies on some types of integrations. By including those integrations in the share with !secret references you’ve effectively given others the installation instructions. When they import and check config they’ll get a message telling them what secrets are missing so they know what to fill in. This isn’t great but its better then handing a package that’s just missing needed integrations entirely.
With UI configured integrations I could see this being much better though. For instance if a way was provided to import a package or a piece of config that import process could prompt you to fill in needed dependencies at that time. And even better it could take into account the integrations you use . Like just because the author choose to use ‘pushbullet’ notifications or a ‘spotify’ type media player doesn’t mean you have to, you just need to provide a notify service or a media_player entity to satisfy this dependency, any will do. This is often hard to explain when you share config, that integrations are grouped by type and largely interchangeable within that type. A UI based import approach could try and tackle this by guiding you through the process of picking an existing integration of that type or configuring a new one.
Anyway just wanted to put my thoughts down. I really appreciate all the hard work done by all the devs and the community. I am constantly astounded by how easy it is to find solutions to almost any integration or use case I can think of on this site.
6 Likes
These look like auth files to me
Specifically the one called auth…
I’ve had a listen to the latest Podcast today, and at 33:35, Phil (I think) asks;
“With ADR 10, are you solidifying that YAML in some form will be here to stay, that you aren’t going to eventually going to rid of the YAML automations for example”
to which Paulus replies;
"Right, No, Those are not going to go away…..having that to being able to be done in YAML, that’s not going to go away. That’s a really valuable part of, like, what Home Assistant is, and I think it would be silly to remove.”
I hope this remains to be true.
1 Like
I don’t mean disrespect but I believe you miss a huge part of Infra as Code:
-
any device can break at any time, for a critical system (HA is critical to me just like banking systems I design during the day) I want the ability to rebuild quickly, and be sure that I rebuild the same way. Whenever there is a new OS version, new better Hardware, I start my script and go for coffee. Already used twice in one month time.
-
things break more often than it should in IT. If something fails, I want to see the history of changes. Where I work we even have a legal requirement to prove any change done to any system, but on top of that it’s super useful to finds introduced bugs, and revert bad configs.
-
reproductability, I don’t have this yet, but before changing a production system, it’s nice to toy in test environment to rebuild things better, but when my wife calls me in the middle of my changes, I can’t have a half working HA in production with my alarm, hot water and heating systems down.
-
oh and secrets, I come to it, since things are auto-deployed, we don’t just put secrets together with Ansible or Terraform scripts, they all have secret management system, either special encrypted files or a full Vault system. So when I have all config in Git, I would not put the PIN of my alarm on a simple Git in plain text, even if I only use that PIN for that system. Actually, doesn’t even matter if I use different passwords for each service, the hacker would easily get a nice list of all my passwords
You keep coming with the argument “you don’t need that”, well the standard non-IT guy doesn’t, but real ITers need more choice. My point is that HA is leaving behind the ITers behind dropping features. It’s like Linux dropping the command line support for GUI only, “because you don’t need CLI” and we want to support non technical persons who now using Windows or mac.
In the same line of thought I will pretend that you don’t need HA for privacy because Apple HomeKit is already positioning themselves as Privacy conscious, and got banking-grade procedures in place again hacking that no casual users would have home. Even if I believe it I would not use that as an argument. Why? Because I value choice! We live on free countries, noone is making choices for us, that would be as bad as entering my Privacy.
15 Likes
That file exists, but my integration passwords are in .storage/core.config_entries so I don’t see how it is relevant.
So exclude that by adding to gitignore!!! This isn’t hard!
How hard is it to understand the problem? Configuration is together with the passwords, I want to keep my configuration in git but not the passwords. I’m not interested in going through all my configuration through the UI when I reset HA.
1 Like
So don’t! Just keep your passwords seperate to what you upload to github (like you do (just like you do now with secrets.yaml)
For one thing, I am not interested in using an UI to redo my configuration through the UI. The way now is so much better since I don’t need to keep my passwords + configuration options in my password manager.
What I don’t get is why the devs are making such a huge problem of keeping yaml config. It’s too much of a burden for maintainers to keep a few lines of config schema in sync with the config flow and they would quit over that? That just makes no sense at all to me. How often do config schemas change anyway?
There are already a lot of rules for pull requests, nearly a year ago I submitted a one line url fix for an integration but they told me to write a pypi package for it. The broken url is still there. Nobody thought well maybe he won’t stay fixing integrations if we ask that much for a simple fix and I don’t see how keeping both configuration systems in sync would be any different.
If they came with sensible arguments, such as that some things are not possible in yaml such as 2FA, which indeed would be a bit complicated to make it work with yaml, I could kind of understand it. But this explanation makes me really question how maintainable this thing is if that makes maintainers quit.
3 Likes
Passwords and configuration are mixed together in core.config_entries. And no comments are possible in json so I can’t add comments explaining why I choose a specific configuration option. It’s just a vastly inferior system.
1 Like
Thank you Sean! This is the sort of reply I’d hoped @frenck would have given. It sounds to me as though the pain points for the team are
- the inconsistent support in the past for YAML
- quality issues with YAML support in the past
- the impact to the brand image from the above
I agree that 100% YAML support is unrealistic for all integrations. For services which like to assign temporary tokens, YAML isn’t going to be easy to implement compared to a webby that sets it up in real time. But for other things, I see no technical reason why YAML should be refused if:
- There is a commitment from someone to be a sort of “YAML captain” for their pet integration
- The developer and the “captain” can agree on quality/functionality
- The home assistant people learn to message consistently and stick to their word, ie if they say YAML is not going away, they provide a path for those who need YAML to implement it in such a way as to not block the GUI progress.
If you’re looking to have a community, you want to provide people a path to get to where they want to be, not just block them unilaterally as was the case here. An honest description of the pain points in advance of the decision would have been helpful. “Here is the problem we’re encountering, and if people want YAML they will need to give us a proposal to handle these issues or we will begin systematically removing support for it.”
This is how you engage people rather than alienating them. If YAML support was then removed, it would be because none of the people using it were willing and able to support it, not because a bunch of people with no skin in the YAML game made the call behind closed doors and foisted it on the community.
The way contributions have been in the past may be the way they’ll continue in the future, but unless you give the community the opportunity to recognize the problem in advance and step up to fill the gap, you’ll never know. And I think that denial of agency is what has made a lot of people upset about this decision.
9 Likes
There are no auth files. Everything is inside the same bloat
You’re damn right @debackerl. Linux is an excellent example. How many GUI have been developed in the past 20 years to make configuration easier? Yet we still use text editors, CLI because it’s the fastest way.
9 Likes
Just think of Windows, CLI has more or less gone away and then some time ago when Linux showed the power of CLI especially of server-things… PowerShell! And even Windows Server Core - without UI…
So it is really not a light task to make these decisions and the devs behind it had certainly thought some hours about it. But sometimes it may be wise to rethink a decision, at least partly.
My 2 cents…
1 Like
The config flows could be setup to allow re-configuring of an integration.
Example: “Garbage Collection” and “ESXi Status” 3rd party integrations.
1 Like
That’s great! I hope that becomes standard practice as I have definitely wished for that at times with some of my others.
It’s honestly not hard to do so I’m not sure why it isn’t implemented in more integrations. 
1 Like