Hi,
I was wondering: Is it possible to use propellor to generate images only without actually managing any hosts per-se? I couldn't find any documentation on that.
Ideally, I'd also be able to use it directly from a sandbox so that I wouldn't have to even "pollute" the GHC/Cabal "global" (user home dir) database on the development machine. I see that there's support for having the config.hs stored in a different directory than ~/.propellor, but I haven't managed to get it working when I use a sandbox in e.g. ~/foo with the config.hs stored in the same directory. Perhaps that's just a bug? If it's supposed to work I can provide detailed error messages, etc. EDIT: I'd also like to manage the git repository myself -- is that possible?
Sounds like you may want to write a program that uses propellor as a library.
Propellor.Engine.mainPropertiesis a reasonable entry point, just pass it a Host that has the properties you want to run.For example:
Ok, so I've tried to use this to build a Chroot (a reasonable starting point for building containers), using the following program:
It seems that "debootstrap" finishes:
But fails immediately afterwards:
(I should probably have used a different hostname than "whatever", but... whatever :).)
So it seems that the chroot support still expects propellor to be installed on the host system?
I should mention that I've done an extremely small patch to Propellor locally, just to the ChrootBootstrapper instance for ArchLinux to allow it to call debootstrap on Arch Linux -- it seems to exist as a package these days, not sure if it did when that Propellor code was written. Anyway...
The way propellor handles running in a chroot or container is it exports its binary and support files into the container. This way the haskell code can run in a container, rather than being limited to only running shell commands in the container, and without needing ghc in the container.
It does use the hardcoded
localdirfor that. It would certianly be possible to make it use propellor in a different location, perhaps usinggetExecutablePath.Since the git-annex outside the container passes command-line options to the one running inside the container to tell it what to do, using
mainPropertieswould also not work since that does not look at command-line options. It would need to usedefaultMainorprocessCmdLineand dispatch itself, or something..