On Fri, 2017-03-17 at 17:02 -0400, Colin Walters wrote:
On Fri, Mar 17, 2017, at 12:09 PM, Philip Withnall wrote:and update it just before polling for updates. However, this is a bit ugly, prone to synchronisation problems between the update processes,Because it involves mutating the remote on disk?Yeah, and hence if the daemon is updating the remotes on disk, another process which is about to do a pull can’t be entirely sure that the remotes.d files are up to date without synchronising state with the daemon.Temporarily replying to just this bit because I want to understand this more - do you *actually* have other processes besides eos- updater which are reading from /etc/ostree/remotes.d? Do you have scripts that call `ostree admin` directly for example? If so, what do they do and why are they separate?
As far as I’m aware we don’t have other processes fiddling with OSTree at the same time — everything is serialised through eos-updater. We do ship some development scripts which use `ostree` directly, but they are just for development work.
Or is what we're talking about in the eos case really just the ugliness of writing to /etc? And if that's the case, do you like the idea of having systemd-style logic for pulling "drop ins" from /run?
It’s the ugliness of writing to anywhere at all (but if we have to write somewhere, /run would be less ugly than /etc), given that the necessary state is already stored in avahi-daemon and the kernel. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part