Changes to copyfile functionality.
by Marcus Lauer
It seems to me that there are at least three improvements which
should be made to copyfile:
1. If the file on the overlord and minion are the same, that file should not
be copied. This saves bandwidth/processing time.
2. Overwriting the file on the minion should be atomic, e.g. the file on the
overlord should be copied to a tempfile on the minion then moved to overwrite
the target file as a final step. Right now if funcd dies or something goes
wrong mid-copy you end up with half a file on the minion.
3. There should be an option (off by default) such that if the file which has
been copied over to the minion is not identical to the file on the overlord it
is re-copied, or at least does not overwrite the file on the minion. This
won't work for some files (busy logfiles) but for most files it seems like an
extra bit of reliability which most people would want in most situations.
I submitted a patch (though not a git-patch... my bad!) back in
January 2011 which implements #1, but imperfectly. The overlord still has to
send a (small) packet to the minion for each 60KB chunk of target file.
Would anyone be bothered terribly if I worked on #2 and #3? While I am
at it I will try to find a way to fix up my patch for #1 as well. There is
some overlap between these patches. Both will involve calculating an MD5 hash
of the file on the overlord, for example.
P.S. Is the new mailing list on fedorahosted.org live yet? I am
sending this message to both just in case.
--
Marcus
11 years, 6 months
RFC: Func's new direction
by Steve Salevan
Hey guys,
I apologize for being a bit out of the loop over the past few weeks, but I
wanted to drop in with a bang with my first func-related RFC. I've spent a
fair bit of time recently thinking about where next to take Func, as
development has stalled, but it has a wide array of users, almost all of
whom have experience in hacking it into submission.
If there's anything that I've learned about systems management software in
my experience, hacking like this is in its very nature, and the more of it
that happens in the upstream community, the more capable the tool ends up
becoming. As the project's new maintainer, my first goal is to get these
sorts of commits going again, to start a flow of project improvements that
fundamentally round out in a better tool for all of us. Towards this end,
it occurs to me that it's pretty damn hard to contribute to Func, as e-mail
patch submission is a bit awkward and not very conducive to the sorts of
technical discussions we should be having when new code is presented.
Thus, for my first move, I'm thinking about moving Func to github, as that
pull request feature of theirs makes upstream interaction a fair bit
simpler and allows us to conduct code reviews, which will help us keep the
code tight going out. My second thought is that it's about time we brought
you guys into the fold as committers if you've spent serious time improving
Func, so if you've submitted several substantial patches/pull requests, you
will gain commit access.
Finally, to get project development going, I've found that setting a
roadmap with goals helps drive development, so here's a rough draft of what
I'm thinking about feature-wise for Func 0.30, alongside their respective
priorities (0==highest):
0 - Improve client-side daemon stability
0 - Prevent forks from listening on :51234
1 - Improve forking system, prevent zombie fork processes
1 - Make certmaster daemon more stable, and fix bug which causes it to
issue malformed certs
2 - Improve delegation parallelism
If you have any ideas for the roadmap, and/or would be interested in taking
ownership in something, let me know, as open discussions like this will
drive Func going forward, and I can promise beer and committer status :)
Thanks much for the read, let me know what you think about all this, and
have a great weekend!
--
Steve Salevan
steve(a)tumblr.com
11 years, 7 months
Patch: Fix warnings for md5 in filetracker module
by Erinn Looney-Triggs
Since md5 was deprecated in Python 2.5 warnings have been issued, this
is just a little annoying. The attached patch fixes this, there were
several approaches I could have taken, but I felt that this was the best
one.
Tested with python 2.4 (RHEL 5) and python 2.6 (RHEL 6).
Input is welcome,
-Erinn
11 years, 7 months
Patch to add a getfile command module
by Marcus Lauer
This command module makes it possible to call "getfile" from the
command line. It is a fairly straightforward adaption of the command module
for copyfile.
Usage:
func (minions) getfile -l localdir -r remotefile
Both -l and -r are required. If either is omitted then the command prints the
help text. The local directory will be created if it does not already exist.
--
Marcus
11 years, 7 months