I'm curious how others using Atomic are handling the separation of configuration data between the Atomic host level and the Service level. For example:
A service requires an NFS mount to work (assume we're not using Kube volume stuff for this). Do you:
a. Edit the standard cloud-init config so the Atomic host itself is created special for that service b. Change an existing Atomic host using some external means like Ansible, effectively making it specially created for the service c. Use a privileged container or something like it to configure the Atomic host on-demand when or if the service is deployed to it d. Something else (NFS in a container, with it's own unique challenges)?
My struggle is the trade off between customizing a specific host vs. modifying it on-demand. I'd like to keep a large pool of identical Atomic hosts, and have them become the "special snowflake" for each service only when the service is there. At some level some outside service or manual intervention is needed to provide that config data, but what is your take on where that should live? Should host configs be generic? Entirely separate from service configs? Co-mingled, assuming the host is for the service? Addressing that last point, we could assume the host is created to live and die with the service, so no big deal?
(I realize Kubernetes can manage volume stuff - NFS is just an example).