Skip to main content

  1. cloud-maker 0.8.0

    I didn’t actually test the OVA export I got from fedora2ova, but cloud-maker has been pushed to my cloud-maker repo. Happy Wily Werewolf Release Day!

    The repo is currently designed to run in-place with either of these forms:

    python -m make_provisioner --help
python . provision --help

    I’d like to add a setup.py so it can be published to PyPI and abandoned, but that’s not ready yet.

  2. fedora-pack to be superseded by cloud-maker

    When we last left off, I had sketched out a config file for fedora-pack, then neglected it when I finally accepted that Perl is dying.

    Seven months later, fedora-pack is undergoing a rewrite to Python. It’s equally widespread (or easy to install) and includes a ton of batteries. I’ve always liked that.

    But that’s only half the change. I’ve been trying to simplify and streamline the code, to make it more straightforward even at the expense of some flexibility and testability—there are, after all, no tests, no extensions, and no users. As far as I know.

    That’s resulted in a rather different codebase, because of two realizations:

    1. At work, I don’t use the multi-version capability. What if make_provisioner just installs the platform’s default version? It would have to know a lot less about distros and versions.
    2. At work, our bundled scripts install our own necessary packages (such as git) in addition to the core languages. What if make_provisioner doesn’t bother offering package preinstallation? On the one side of the process is cloud-init, if preinstallation is important. On the other, the runner script can install its own choice of language packages. Now make_provisioner doesn’t even have to care about distros (or features or packages) at all, as long as it can have a distro-agnostic SFX stub.

    Things seem to be going well so far; expect a code dump on github by November. I want to use cloud-maker for work’s AMI builder, instead of a hacked fedora-pack fork, and the Ubuntu 15.10 release will be a good time to change that.

  3. fedora-pack Configuration File Update

    I mentioned last post that I was thinking of going with “a config file of some sort.” Plans have formed to use INI format, and the parser is written. (Between the desires to be pure-perl all the way down and to keep embed size down, I didn’t find any pre-written parsers that suited me on CPAN.)

    So, it’s probably going to end up something like this:

    ; we basically just use this for supervisord, no venv needed
[python2]
min_version = 2.7
with_virtualenv = 0

; legacy app can’t handle `carton exec`
[perl]
with_carton = 0

[php]
min_version=5.4

[main]
install = "php perl python2" ; known to fedora-pack
add_packages = "php5-fpm libmoose-perl" ; known to apt/yum

    As a bonus, the sections organize the options so that languages can define their own options fully independently, without having to avoid naming conflicts in the CLI options.

    fedora-pack will continue to install all the per-language options by default, since actually using them is best practice, as I understand things.

  4. More fedora-pack Options

    I’ve noticed that python-pip and virtualenv packages on Ubuntu Utopic have similar dependencies—but the latter is on *-whl packages and the former is not. Since I use Python but not virtualenv in my own server build, it ‘would be nice’ to skip the automatic installation of it by fedora-pack.

    Of course, in order to support such a thing, fedora-pack clearly needs more options for finer control. Yet, it seems like the global option parser isn’t the perfect place for language-related options, so the App::FedoraPack::System class tree may spawn some additional argument-related functions.

    I may finally go with a config file of some sort. The command line is getting unwieldy already.

sapphirecat's...