Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
branch: master
Commits on Mar 7, 2014
  1. @daniel-pittman

    Merge pull request #151 from bobtfish/puppet_27

    daniel-pittman authored
    Remove puppet 3.x 'unless' keyword
Commits on Dec 17, 2013
  1. @daniel-pittman

    Ensure correct ownership of TorqueBox deployment directory

    daniel-pittman authored
    This ensures that the standalone deployments directory of TorqueBox/JBoss is
    owned by the Razor user.  This is the correct mode for supporting a single
    application deployment, and matches our expected use.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Commits on Dec 2, 2013
  1. @daniel-pittman

    Update to the TorqueBox 3.0.1 binary distribution

    daniel-pittman authored
    This updates the TorqueBox installation to version 3.0.1, which is required
    for the latest release of the software.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
  2. @daniel-pittman

    Revert Puppet file mode management

    daniel-pittman authored
    This reverts the explicit management of file modes through Puppet; that was
    added in addition to setting the umask to our expected value during unpacking
    to try and work around sites with more restrictive than "default"
    umask values.
    
    Unfortunately, it doesn't compass the full complexity of permissions; we need
    to have executable permissions on various files in JBoss, etc, that I don't
    want to hand-maintain lists of just to work around a problem solved at
    the source.
    
    The umask changes are retained, but the permission management changes backed out.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Commits on Nov 26, 2013
  1. @daniel-pittman

    Enforce appropriate umask and permission values

    daniel-pittman authored
    This updates the module to enforce permission values and an appropriate umask
    on all directories related to Razor.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Commits on Oct 14, 2013
  1. @daniel-pittman

    Add an example manifest for installing Razor using `puppet apply`

    daniel-pittman authored
    This is an example of how to use `puppet apply` to install razor-server, with
    a little bit of stuff wrapped around it to make it look less odd, and to try
    and stop people using it in a way that might really hurt them on the master.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
  2. @daniel-pittman

    Added an ISC DHCPd configuration example

    daniel-pittman authored
    This adds an example configuration file for the ISC DHCPd that will make it
    work smoothly with razor-server.  Since we don't automatically configure DHCP
    operation, this should ease integration for some folks.
    
    This is not an example of using Puppet to configure the system, which is left
    as an example for the reader.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
  3. @daniel-pittman

    Remove obsolete test code

    daniel-pittman authored
    This test code was associated with the older version of the Razor module, and
    as is the nature of "bench" testing system configuration, was dominated by
    useless assertions about how the module was structured.
    
    In the rewrite the specs and other tests became essentially useless, and
    rather than rewriting the testing to assert that the manifests contained what
    they contained, they were ignored.
    
    Sadly, I didn't back that up by removing the manifest content, which led to
    user confusion.  So sorry to have done that to y'all.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Commits on Oct 11, 2013
  1. @daniel-pittman

    Bind to wildcard, not loopback, when starting razor-server

    daniel-pittman authored
    Unfortunately, during testing I missed that my init script was binding
    exclusively to the loopback address -- my hosts file had the hostname mapped
    to loopback, so it "worked for me".
    
    This fixes that, by explicitly binding to the wildcard address when starting
    the `standalone.sh`.  How embarrassing.
    
    Thanks to Lucas Harms <lmickh@gmail.com> for helping with this.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
  2. @daniel-pittman

    Create `production.log` to reduce odds of permissions problems

    daniel-pittman authored
    One of the earliest steps that needs to be run when deploying Razor is to
    migrate the database.  This is typically done as root, which means that it
    will create the Sequel/Sinatra log ... as root.
    
    That, in turn, caused a failure when starting the application as a less
    privileged user for the first time.
    
    This commit doesn't fix the problem, as such, but it does create the log file
    during installation, and ensures that the permissions remain correct.
    
    This means that we *should* be less likely to encounter this in practice.
    
    Eventually we need a better solution inside razor-server, but for now this
    should ensure first installations are smooth.
    
    Thanks to Lucas Harms <lmickh@gmail.com> for helping with this.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Commits on Oct 9, 2013
  1. @daniel-pittman

    Move to `razor-server` rather than Ruby/NodeJS Razor

    daniel-pittman authored
    This is a major, incompatible update: the razor module will now install the
    new `razor-server` implementation of Razor, rather than the original
    implementation.  This brings a new and disparate set of dependencies.
    
    This module makes no effort to uninstall the older Razor, aiming instead to
    provide a fresh implementation.  Migration is not currently supported either.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Commits on May 29, 2013
  1. @daniel-pittman

    Merge pull request #139 from daniel-pittman/bug/master/136-peg-older-…

    daniel-pittman authored
    …version-of-express-because-nodejs-backward-compatibility-is-limited
    
    (#136) Remove global nodejs `express` package installation
  2. @daniel-pittman

    (#136) Remove global nodejs `express` package installation

    daniel-pittman authored
    The Razor module installed two versions of the nodejs `express` package, a
    toolkit for writing your own web server on top of a basic HTTP accept loop.
    
    One was installed in the Razor directory, pinned to an older version, and
    fairly boringly functional.  This is the one that is actually used by Razor.
    
    The other was a globally installed "latest" version, which was not actually
    used, was kind of incompatible with the way Razor build its CGI interface, and
    was incompatible with older versions of nodejs on, say, Ubuntu 12.04.
    
    This just removes the global version: it served no actual purpose, other than
    violating the nodejs community standards (throw stuff in your private
    directory, no shared library code), and making Razor more apparently complex.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Commits on May 3, 2013
  1. @daniel-pittman

    Merge pull request #134 from cr3/133

    daniel-pittman authored
    (#133) Razor image provider should not check for errors like other providers
  2. @daniel-pittman

    Merge pull request #131 from cr3/130

    daniel-pittman authored
    (#130) Razor providers should check return value for errors
Commits on Apr 19, 2013
  1. @daniel-pittman

    Revert "Make `tar` installation of stable releases the default"

    daniel-pittman authored
    This reverts commit 9ea9092.
    
    It turns out that the approach I took to solving the problem, while
    attractive, is secretly an attractive nuisance.
    
    It makes it impossible to actually test anything but the released version of
    the code and, in the nature of hitting commit, also called a couple of people
    out to explain why it made their lives miserable also.
    
    This brings us back to the previous state, from which I will proceed forward
    to add tarball support again, and to integrate it in a fashion that doesn't
    lead to quite the same set of failures.
  2. @daniel-pittman

    Merge pull request #126 from daniel-pittman/bug/master/broken-spec-af…

    daniel-pittman authored
    …ter-125-merged
    
    Fix missed use of `git_version` parameter in specs
  3. @daniel-pittman

    Fix missed use of `git_version` parameter in specs

    daniel-pittman authored
    Pull request #125 removed the ability to specify a git source or revision,
    along with other changes; this wasn't reflected in the tests.
    
    This strips out the attempt to use the git version, which wasn't providing any
    particular value in any case.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
  4. @daniel-pittman

    Merge pull request #125 from daniel-pittman/feature/master/124-make-d…

    daniel-pittman authored
    …efault-install-method-user-friendly-not-user-hostile
    
    Make `tar` installation of stable releases the default
  5. @daniel-pittman

    Merge pull request #123 from daniel-pittman/feature/master/122-automa…

    daniel-pittman authored
    …te-the-contributor-list-in-readme-md
    
    Automate rebuilding the contributor list
Commits on Apr 10, 2013
  1. @daniel-pittman

    Make `tar` installation of stable releases the default

    daniel-pittman authored
    This moves away from the previous, legacy, default of installing from git
    head, in favour of installation from the stable release tar file available on
    https://downloads.puppetlabs.com/razor
    
    Like the packages, this will refuse to install over the top of an existing git
    deployment; if `/opt/razor/.git` exists the Puppet module will refuse to run.
    Users should manually remove the directory - or otherwise resolve
    the conflict.
    
    It is safe, and supported, to simply delete the `.git` directory, and then
    install from tar over the existing git deployment.  There should not be any
    data loss from this.
    
    This closes #124.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Commits on Apr 9, 2013
  1. @daniel-pittman

    Automate rebuilding the contributor list

    daniel-pittman authored
    This extends the hacks in the Modulefile to automatically rewrite the
    contributor list in a stand-alone file.  This makes it practical to give
    public credit to the folks who have contributed to the module without human
    error dropping some of them.
    
    Closes #122.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Commits on Apr 2, 2013
  1. @daniel-pittman

    Merge pull request #120 from daniel-pittman/bug/master/image-download…

    daniel-pittman authored
    …-tmpdir-error-after-cache-update
    
    Fix dangling `tmpdir` reference from cache feature
  2. @daniel-pittman

    Fix dangling `tmpdir` reference from cache feature

    daniel-pittman authored
    The added cache feature tried to reference a temporary directory that no
    longer existed; this corrects that bug by excising the additional code.
    
    Since this was unused, no ill effects flow from this.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Commits on Apr 1, 2013
  1. @daniel-pittman

    Merge pull request #119 from daniel-pittman/bug/master/add-net-scp-ge…

    daniel-pittman authored
    …m-for-external-script-broker
    
    Install the `net-scp` gem in addition to `net-ssh`
  2. @daniel-pittman

    Merge pull request #118 from daniel-pittman/bug/master/handle-semver-…

    daniel-pittman authored
    …sorting-in-changelog-tool
    
    Handle SemVer sorting correctly in the changelog generator
  3. @daniel-pittman

    Install the `net-scp` gem in addition to `net-ssh`

    daniel-pittman authored
    The external script broker, recently added to Razor, adds a new dependency on
    the `net-scp` gem in addition to the `net-ssh` library; this extends the later
    with an integration of scp file transfer.
    
    This updates the Ruby manifests to install both gems, which ensures that
    current Razor continues to run correctly.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
  4. @daniel-pittman

    Merge pull request #117 from calavera/cache_rz_image

    daniel-pittman authored
    Cache downloaded images.
Commits on Mar 22, 2013
  1. @daniel-pittman

    Handle SemVer sorting correctly in the changelog generator

    daniel-pittman authored
    The shell changelog generator worked fine, but didn't sort correctly: RC
    versions were sorted after, not before, their parent.  (In part because SemVer
    is a human focused version sort, and it is actually hard to find a portable
    shell implementation of that sorting.)
    
    This replaces it with a small Ruby script that does the same work, but allows
    me to implement a SemVer-correct sorting routine.  It is kind of ugly, because
    the logic is ugly, but it works correctly now.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Commits on Mar 12, 2013
  1. @daniel-pittman

    Git should ignore the CHANGELOG file

    daniel-pittman authored
    The changelog is machine generated, so should be ignored.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
  2. @daniel-pittman

    (#114) Handle 0.6.1-rc1 style RC tags in git

    daniel-pittman authored
    My previous code for automatically generating version numbers, and the
    changelog, worked fine for regular releases, and for the nightly builds, which
    were all that we had ever made of this project.
    
    Now that we have tagged our first RC, a shortfall is exposed: my code
    incorrectly identified an RC version as being a nightly build, and then failed
    during generation of the build number.
    
    This fixes that, by treating anything that isn't in the form "a.b.c-N", where
    N is a number, as an RC version.  Given `git describe` will generate a number
    in the second slot for the "number of commits since the tag", in a nightly
    build repository, this seems the safest choice.
    
    Specifically, we now map:
    
     * 0.6.1-1-foo     => 0.6.2-1-foo       # 0.6.1 to 0.6.2
     * 0.6.2-rc1       => 0.6.2-rc1         # stays the same
     * 0.6.2-rc1-1-foo => 0.6.2-rc2-1-foo   # rc1 to rc2
     * 0.6.2           => 0.6.2             # stays the same
    
    This modifies both the Modulefile and changelog generator, since both
    calculate the next version of the module.
    
    It also extracts the logic for generating the version number into a separate
    Ruby script, since the complexity had grown to the point it was worth the cost
    of factoring that out.
    
    This closes #114, and fixes the currently broken RC build.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Commits on Mar 6, 2013
  1. @daniel-pittman

    Merge pull request #113 from cr3/112

    daniel-pittman authored
    (#112) Added rubygems_update param to razor class.
Commits on Mar 4, 2013
  1. @daniel-pittman

    Merge pull request #111 from jparsonssaffron/master

    daniel-pittman authored
    Quote $@ in templates/razor.erb to avoid whitespace issues
Commits on Mar 1, 2013
  1. @daniel-pittman

    Merge pull request #110 from daniel-pittman/feature/master/108-build-…

    daniel-pittman authored
    …outside-moduledir-should-work
    
    (#108) build outside moduledir should work
Commits on Feb 26, 2013
  1. @daniel-pittman

    Remove duplicate headers from generated changelog

    daniel-pittman authored
    When the HEAD of the module checkout was a final release, such as 0.6.0, the
    changelog generator would emit a duplicate header.  It was treating "0.6.0" as
    the development version, and then as the head of the previous release.
    
    This was technically correct, but useless, since there was no distinction
    between the two, and so the second "in development" changelog contained
    no content.
    
    This simply skips a header when the top and bottom are the same tag, since
    that will always be an empty set.  That eliminates the duplicate header, but
    keeps building a correct changelog when an in-flight version exists.
    
    Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Something went wrong with that request. Please try again.