Spawned from a discussion with @jordansissel ...
Some context on what "refresh" is about.
TBQH, users should absolutely avoid it unless there's no other mechanism.
ideally every individual resource should be able to know by itself if the state is wrong and if CheckApply needs to Apply something or not.
For legacy reasons in how computers were built, this was not always possible. The canonical example is "when should a service reload?"
In the future we should move toward a service being able to know when one of it's files is out of date. There is some of this in systemd but it's not perfect. TL;DR: the .service file can list any config file it uses and we could use an API to determine when they've changed. We actually should do some of this to see if things are still missing in the API. I originally asked for this so that we could do autoedges between svc and pkg which was never possible till we had systemd.
But you also need to patch each rpm and that's a hassle.
So in the interim, we have Refresh.
but
And I haven't thought about this in a long while because it was an early thing I worked on but there may be a good workaround solution until someone convinces the systemd people to polish this properly:
The svc resource could have a field that lists /etc/whatever/ and /etc/whatever/*.conf and /etc/whatever.conf paths and we could hash those on CheckApply and know for ourselves if something changed.
We'd have to make sure to notice adds and deletions from the initial state as well, but this is doable! And of course we can add autoedges from these entries as well!
One more notification nuked!
Spawned from a discussion with @jordansissel ...
Some context on what "refresh" is about.
TBQH, users should absolutely avoid it unless there's no other mechanism.
ideally every individual resource should be able to know by itself if the state is wrong and if CheckApply needs to Apply something or not.
For legacy reasons in how computers were built, this was not always possible. The canonical example is "when should a service reload?"
In the future we should move toward a service being able to know when one of it's files is out of date. There is some of this in systemd but it's not perfect. TL;DR: the .service file can list any config file it uses and we could use an API to determine when they've changed. We actually should do some of this to see if things are still missing in the API. I originally asked for this so that we could do autoedges between svc and pkg which was never possible till we had systemd.
But you also need to patch each rpm and that's a hassle.
So in the interim, we have Refresh.
but
And I haven't thought about this in a long while because it was an early thing I worked on but there may be a good workaround solution until someone convinces the systemd people to polish this properly:
The svc resource could have a field that lists /etc/whatever/ and /etc/whatever/*.conf and /etc/whatever.conf paths and we could hash those on CheckApply and know for ourselves if something changed.
We'd have to make sure to notice adds and deletions from the initial state as well, but this is doable! And of course we can add autoedges from these entries as well!
One more notification nuked!