In some cases, building Propellor on the target machine is undesireable; for example, the host has limited memory available, or the load imposed by GHC on CPU / I/O usage is unacceptably disruptive to other services running on the host. When spinning from a compatible host, Propellor could instead have an option to copy the locally-built binary to the target host. I'm not sure exactly how to determine "compatible" in this case, so it would probably have to be left to the user to determine whether they can do it or not.
This is already implemented in propellor, but is currently only used when the remote host doesn't have git installed and apt fails to install it. I've used it for converting non-Debian systems to Debian eg. See Propellor.Spin.sendPrecompiled
Going beyond what's there now is not a feature I need myself, and not a priority for me to implement, but I can help to some extent if you're going to work on it.
Both the controller and host architecture matter of course in determining whether it will work. For example, an i386 controller will produce a propellor bundle that works on amd64. An amd64 controller's bundle may work on an i386 host, but only if its hardware and kernel happen to support 64 bit. The simplest solution I can think of is to send the precompiled binary over to the host and check if it runs there before replacing any older propellor binary with it.
The other question is, how to tell propellor when to use this mode. Some ideas, which build on each other.
--spin --precompiled
Add a
precompiledproperty to the host that needs precompiled propellor. The property can set Info, which --spin can look at to know if it needs to use sendPrecompiled for this host, without needing --precompiledCould also add a property that says a host is the controller for other hosts. So, anytime propellor is run on the controller host, it automatically spins the other hosts. And if the hosts it's spinning have the
precompiledproperty, the controller will honor it.Note that propellor's cron job will probably fail on a precompiled host, since even if it manages to pull changes from the central git repo (unlikely as a precompiled propellor currently isn't set up as a git repo), it can't locally compile them.
So, in order to have a centralized repository with precompiled hosts, you need a controller that can handle sending the updated builds of propellor to them.
Since the controller idea was useful beyond supporting precompiled hosts, I've implemented it first, in Propellor.Property.Spin.controller.
There's a patch implementing this now, in:
I have not found the increased memory too onerous, it's still working down to 500 mb cheap VMs. So I'm looking for details about cases where it causes ghc to use too much memory. http://propellor.branchable.com/forum/recent_propellor_snapshots_cause_ghc_OOMs/
Felix did a lot of work on his precompiled branch. But it's been stalled on getting merged since June.
The blocker has to do with switching a host between precompiled and not, and vice-versa. The two ways to deploy propellor need different contents in the
localdir. Pasting in a couple of my last emails about it:I fear a rm -rf localdir because propellor writes/reads some files inside it to store states between runs etc. In retrospect, it would have been smart to limit all such stuff to a subdirectory of localdir. Moving things now would be the best approach, but probably tricky to implement.
Maybe you could get away with only deleting localdir/.git though.
It seems wrong to do that for the same reason.
I kind of have the feeling that making the local-build/no-local-build decision check for .git was the wrong choice to make, because it's led to all this complexity around deleting parts of /usr/local/propellor.
If we had a better way to make that decision, then sendPrecompiled could just overwrite any existing propellor binary, so conversion from local-compilation to precompilation would be easy.
(Conversion the other way would still be a little problimatic since git clone would fail; it would need to clone to a temporary directory and move everything into place, I suppose.)
So, what would be a better way for propellor to decide if it needs to rebuild itself when run? Could it get away with checking if the local host is configured with precompiled?
These are the cases:
So, seems that case 3 needs to somehow detect that the remote host has a precompiled binary on it, and delete that, as well as arranging for the git push to succeed even when localdir already exists and localdir/.git does not.
Hi!
What's left to be done for this issue. If there is any work to sponsor to have this feature integrated I would gladly do so.
Felix did some more work on this last April, in his precompiled-rebased-2 branch.
In particular, that branch is supposed to handle case #3 above (by a git clone to temp dir and move of the files).
Felix said he had not tested it, and I have not tested it either. If someone can try his branch and confirm that it works, including handling of cases #2 and #3 above, I'd be happy to merge it.
(origin/precompiled has the above branch and has had current master cleanly merged into it, and builds successfully.)
Hi, I'm trying to spin using the
Precompiled.precompiledproperty from theprecompiled, branch after having merged master. The first time trying to spin after adding the property, this error occurs:Subsequent spin attempts produce this error:
I think
Propellor.Spin.sendPrecompiledmight itself be broken, but I can't quite wrap my head around what's going on here. Any ideas? I'm usingcabal 3.0.0.0in Debian Unstable.