Docker installations should have state.yaml mounted persistently

[davidski]

bifrost/docker-compose.yaml

Lines 7 to 10 in 8a316ea

	volumes:
	# If you followed the guide on our readme, these paths work out of the box
	- ./config.yaml:/app/config.yaml
	- ./certs:/app/certs

The current suggested docker compose file doesn't have a persistent mapping for the state.yaml file. Since the state.yaml has the entertainment groups (among other Hue-specific bits) included in it, if the container is recreated that persistent information will be lost.

I've addressed this by copying out the state.yaml from a running bifrost container and then mounting it just like the config.yaml. There may be a chicken-and-egg problem for new installs when the state.yaml does not exist, but I think touching the state.yaml before container creation may fix that.

I believe there are other issues about moving the binary into a separate location than the config, which would allow mounting the subdirectory as a persistent volume, solving this as well.

Thanks for the project! ❤️

[chrivers]

Thank you for reporting this! Feedback like this is always helpful.

There's actually a rarely-used feature in the config file, that allows specifying the location of both the certificate, and the state file.

So I think a good solution could be changing the example config to put those files in a directory (along with the config file, which we then need a way to specify the location of), and then mounting in that entire directory.

That would also solve #80 and #72, which are somewhat related :)

As for the people who have suggested configuring entirely via environment variables, that is not happening. A future web interface for Bifrost needs to be able to change the configuration, and that can only (reasonably) happen if we can write new configuration.

I'll keep this open until we have a solution for this, but it seems doable to support a command-line argument (or environment variable) to point to a configuration file 👍

[davidski]

Adding in a note for anyone else that comes across this issue. Using the config option to change the state file location to something in a subdirectory, such as "data/state.yaml" and then mounting /app/data as a volume allowed me to get this to work smoothly. Mounting the file explicitly, such as mounting /app/state.yaml rather than the subdirectory, does not work. As I understand it, file mounting uses different interfaces which causing some file watcher handles not to be available. In the case of bifrost, mounting the statefile directly caused odd permission errors.

TL;DR, change the statefile location to a subdirectory, mount the entire subdirectory, and you'l be fine. 😄

[chrivers]

Thanks for the helpful note 👍

Yes, I imagine it's because I'm careful to atomically replace the state file when updating (i.e., write the new content to another file, and then rename that file over state.yaml)

But because state.yaml and the temp file actually live on different mounts, this suddenly breaks - even though writes are allowed.

And yeah, there aren't really any other ways to fix this, than mount a dir instead of a file.

I'll do an overall cleanup pass at some point, and try to fix a bunch of these documentation papercuts.