A command to force a refresh of gitfs remote repositories other than restarting the salt master would be quite useful.
I definitely agree, this needs to be implemented.
Do you mean a full reload, or just updating the existing remotes? Because they are updated every 60 seconds by default, or whatever the loop_interval value is set to in the master config.
What is the difference between full reload and updating? I assume the former would pick up new gitfs remotes/remove old ones? If so that can wait for a restart.
The refreshing of existing remotes is useful when testing changes so you can ensure it has refreshed without waiting for a minute before testing any changes without having to restart salt-master every time. Setting loop interval lower could work while testing, but I'm hesitant to do that in the long term especially with github gitfs remotes included. Being able to have a post-commit hook for example trigger a refresh would be quite handy.
@nvx I actually completely agree with your use case. Being able to force the refresh without waiting the 60 seconds is very useful when testing. This isn't high priority, but would definitely be useful.
Should not the command
salt-run fileserver.update
do that?
Unfortunately, with gitfs there seems to be a bug at the moment...
Yes, there does indeed. I've heard reports of this from others, too. Although there have been some changes there, have you tested with the new 0.17.1 release, @olenz?
I reported issue #7937 about the problem. But in principle, fileserver.update is the Right Thing(tm) to do, is it?
Ah, yes, salt-run fileserver.update should indeed solve @nvx's original issue. Keep us posted if that's not the case, @nvx.
Closing.
FWIW - gitfs remote updating either via loop_interval or fileserver.update do not work in 2014.1.13. I gave up waiting last night for 2014.7.0 pkgs in official Ubuntu (the salt-testing pkgs seem incomplete as salt-cloud was missing or having dep. issues) - thus, I installed 2014.7.0 last night and then figured out how to get gitfs and pygit2 with ssh urls working and now I do see my git remotes updating properly when changing are pushed out to individual repos (though I only have 1 gitfs_remote at the moment). I've had too many issues for my use case in 2014.1.13 so I'm glad Helium seems to be a lot more stable and consistent with the documentation and expected behavior.
Posting this here since I haven't found an issue close to this particular problem and maybe it will help someone.
@terminalmage Is there a way to add new git repositories using the salt-run fileserver.update without restarting salt master?
@sametimesolutions Unfortunately not. The reason for this is that fileserver updates are executed in a loop in a "maintenance" thread (which also handles various other housekeeping tasks), and this thread is initialized when the master starts.
I haven't tested it, but since the fileserver.update runner is executed via salt-run, it might be reading the master opts anew each time it is run, in which case it might be able to pick up new repos added to gitfs_remotes. However, the maintenance thread would still not know about these changes until the salt-master service is restarted, so it would not automatically update.
would be pretty sweet to auto update;
fyi - @sametimesolutions - i keep my gitfs_remotes.conf file in a separate file under master.d in my salt-formula repo. whenever that dir changes i have salt-master restart.
Looks like this issue can be closed by following info
https://docs.saltstack.com/en/latest/topics/tutorials/gitfs.html#refreshing-gitfs-upon-push
@tjyang No, this feature request is to refresh the entire gitfs configuration, not to update the repos.
Err, no it's not?
This was enough to close this issue:
salt-run fileserver.update
Of course https://docs.saltstack.com/en/latest/topics/tutorials/gitfs.html#refreshing-gitfs-upon-push is the logical extension of that and more or less what I have running these days since fileserver.update was fixed!
Ahh yes, I was reading from this comment which was much later.
Also, it seems like this was closed nearly 3 years ago anyway, so there's no need to close it.
Most helpful comment
Should not the command
do that?
Unfortunately, with gitfs there seems to be a bug at the moment...