Permalink
Commits on Sep 12, 2016
  1. Merge pull request #161 from steveax/maint-add-maintainers

    smcclellan committed on GitHub Sep 12, 2016
    (maint) add maintainers file
  2. (maint) add maintainers file

    steveax committed Sep 12, 2016
Commits on Nov 12, 2015
  1. Merge pull request #160 from alejandrobednarik-olx/master

    HelenCampbell committed Nov 12, 2015
    Added Ubuntu 14.04 support for libarchive
  2. Merge pull request #152 from bobtfish/custom_java_package

    HelenCampbell committed Nov 12, 2015
    Allow specfying custom java package
Commits on Mar 30, 2015
Commits on Dec 18, 2014
  1. Merge pull request #159 from jbondpdx/master

    underscorgan committed Dec 18, 2014
    FM-1523: Added module summary to metadata.json
Commits on Nov 21, 2014
Commits on Sep 22, 2014
Commits on Jul 3, 2014
  1. Merge pull request #158 from smcclellan/add-changelog

    smcclellan committed Jul 3, 2014
    Add existing CHANGELOG file
  2. Add existing CHANGELOG file

    smcclellan committed Jul 3, 2014
    The CHANGELOG file will no longer be generated by the Modulefile due to an
    issue with the way it was being created. This switches to a manual process.
    
    Fixes https://tickets.puppetlabs.com/browse/RAZOR-282
  3. Merge pull request #157 from apenney/modulefile-change

    hunner committed Jul 3, 2014
    Switch over to using metadata.json.
  4. Switch over to using metadata.json.

    Ashley Penney committed Jul 3, 2014
Commits on May 28, 2014
  1. Allow specfying custom java package.

    fhats committed with bobtfish Oct 23, 2013
    Some people don't take upstream's default Java packages and are likely to
    be re-packaging java themselves with a different package name, and
    therefore will want to use their custom package which is not named
    'java'.
Commits on Mar 7, 2014
  1. Merge pull request #151 from bobtfish/puppet_27

    slippycheeze committed Mar 7, 2014
    Remove puppet 3.x 'unless' keyword
Commits on Dec 17, 2013
  1. Ensure correct ownership of TorqueBox deployment directory

    slippycheeze committed Dec 17, 2013
    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. Update to the TorqueBox 3.0.1 binary distribution

    slippycheeze committed Dec 2, 2013
    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. Revert Puppet file mode management

    slippycheeze committed Dec 2, 2013
    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. Enforce appropriate umask and permission values

    slippycheeze committed Nov 26, 2013
    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. Add an example manifest for installing Razor using `puppet apply`

    slippycheeze committed Oct 14, 2013
    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. Added an ISC DHCPd configuration example

    slippycheeze committed Oct 14, 2013
    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. Remove obsolete test code

    slippycheeze committed Oct 14, 2013
    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. Bind to wildcard, not loopback, when starting razor-server

    slippycheeze committed Oct 11, 2013
    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. Create `production.log` to reduce odds of permissions problems

    slippycheeze committed Oct 11, 2013
    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. Merge pull request #144 from daniel-pittman/update-to-razor-server

    lutter committed Oct 9, 2013
    Move to `razor-server` rather than Ruby/NodeJS Razor
  2. Move to `razor-server` rather than Ruby/NodeJS Razor

    slippycheeze committed Oct 3, 2013
    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. Merge pull request #139 from daniel-pittman/bug/master/136-peg-older-…

    slippycheeze committed May 29, 2013
    …version-of-express-because-nodejs-backward-compatibility-is-limited
    
    (#136) Remove global nodejs `express` package installation
  2. (#136) Remove global nodejs `express` package installation

    slippycheeze committed May 29, 2013
    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. Merge pull request #134 from cr3/133

    slippycheeze committed May 3, 2013
    (#133) Razor image provider should not check for errors like other providers
  2. (#133) Razor image provider should not check for errors like other pr…

    Marc Tardif committed May 3, 2013
    …oviders
    
    This change reverts checking for errors in the image provider because
    the image action of the razor command does not return PSON unlike the
    other actions. Instead, the image provider now returns the output of
    the razor command and always succeeds, like before.
    
    Ideally, the image provider should look at the return value and raise a
    Puppet::Error when failing to add an image. However, the razor command
    always seems to return 0 and the output is awkward to parse. So, the
    changes to the image provider should be reverted for now until the Razor
    project is updated accordingly.
    
    Closes #133
  3. Merge pull request #131 from cr3/130

    slippycheeze committed May 3, 2013
    (#130) Razor providers should check return value for errors
Commits on May 2, 2013
  1. (#130) Razor providers should check return value for errors

    Marc Tardif committed May 1, 2013
    This change modifies the create and destroy methods in the rz_broker,
    rz_image, rz_model and rz_policy providers to raise a Puppet::Error
    when an error occurs. This is achieved by passing the output to the
    parse method in the PuppetX::PuppetLabs::Razor class. If the output
    contains a 'response' key, it is returned, if it contains a 'result' key,
    a Puppet::Error exception is raised with it, otherwise a Puppet::Razor
    exception is raised with the whole output.
    
    The reason for this change is to enable Puppet manifests using
    Razor resources to actually get an error when the razor command
    fails. Otherwise, the error is simply ignored and the user has to
    reverse engineer the problem from the side effects of the failure.
    
    Note that this change moves the parse method in PuppetX::PuppetLabs::Razor
    from being private to public, so that it can be re-used in the
    providers. Also note that it did not implement the behavior for the rz_tag
    provider because it is much more complicated, having to potentially
    manage multiple tags. This can be handled in a separate pull request.
    
    This pull request fixes issue #130.
Commits on Apr 19, 2013
  1. Revert "Make `tar` installation of stable releases the default"

    slippycheeze committed Apr 19, 2013
    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. Merge pull request #126 from daniel-pittman/bug/master/broken-spec-af…

    slippycheeze committed Apr 19, 2013
    …ter-125-merged
    
    Fix missed use of `git_version` parameter in specs
  3. Fix missed use of `git_version` parameter in specs

    slippycheeze committed Apr 19, 2013
    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>