1. 25 Mar, 2014 1 commit
  2. 07 Mar, 2014 2 commits
  3. 04 Mar, 2014 4 commits
  4. 27 Feb, 2014 2 commits
  5. 18 Feb, 2014 3 commits
  6. 14 Feb, 2014 1 commit
    • Ken Barber's avatar
      Remove redmine links · 981a457c
      Ken Barber authored
      There were still links to the redmine tracker in our documentation. This patch
      removes them and replaces them with the Jira URL instead.
      Signed-off-by: default avatarKen Barber <ken@bob.sh>
      981a457c
  7. 12 Feb, 2014 3 commits
  8. 10 Feb, 2014 3 commits
  9. 06 Feb, 2014 8 commits
  10. 05 Feb, 2014 7 commits
    • Moses Mendoza's avatar
      (packaging) Replace non-portable shell calls in spec and changelog with ruby · 44f75918
      Moses Mendoza authored
      Prior to this commit, we shelled out to `hostname` and `date` in the redhat
      spec template and the debian changelog, which is poor practice if we expect to
      template that file anywhere else. This commit updates these calls to use their
      most simpl ruby equivalents, though we risk that we may not get a FQDN for
      hostname. This doesn't really matter a ton by rpm standards, so I'm fine with
      it.
      Signed-off-by: default avatarMoses Mendoza <moses@puppetlabs.com>
      44f75918
    • Moses Mendoza's avatar
      (packaging) Evaluate rpm spec file just like debian templates · 168bea7d
      Moses Mendoza authored
      Prior to this commit, we evaluated all of the debian templates when creating a
      tarball, resulting in a 'ext/debian' directory containing usable debian
      artifacts. On the other hand, we didn't bother creating the redhat spec from
      the corresponding template, leaving that as an exercise left to the reader.
      This seems odd. All of our other projects have fully usable spec files in their
      tarball, and puppetdb should to. This also has the added benefit of allowing us
      to control the binding context like we do on debian, instead of letting the
      packaging repo do it. This means we can still mix puppetdb-defined '@'
      variables with 'Pkg::Config' accessors supplied by the packaging repo.
      Signed-off-by: default avatarMoses Mendoza <moses@puppetlabs.com>
      168bea7d
    • Moses Mendoza's avatar
      (packaging) set project to pe-puppetdb when building pe-puppetdb · 1513b669
      Moses Mendoza authored
      Until we split out the packaging of pe-puppetdb from puppetdb, with the new
      packaging system we need to explicitly tell the automation that the project
      we're building is called 'pe-puppetdb' instead of 'puppetdb.'
      Signed-off-by: default avatarMoses Mendoza <moses@puppetlabs.com>
      1513b669
    • Moses Mendoza's avatar
      (packaging) Fully qualify variables supplied by the packaging repo in templates · 8f5b4840
      Moses Mendoza authored
      Part of the variable scoping overhaul within the packaging repo was ensuring
      the data about builds lives inside module Pkg::Config. In other projects, we
      only use variables set by the packaging repo in templates, which means we can
      pass the binding of the packaging repo Pkg::Config class into the template
      engine and keep using "@" variables like we always have. But in puppetdb, we
      mix data supplied by the packaging repo and data supplied by puppetdb itself in
      the same template, which means we can't use just the Pkg::Config scope. Since
      there are far more variables supplied by puppetdb in the templates than the
      packaging repo, we opt to use the puppetdb scope and fully qualify access to
      the variables supplied by the packaging repo, by referencing them as
      Pkg::Config wherever we use them.
      Signed-off-by: default avatarMoses Mendoza <moses@puppetlabs.com>
      8f5b4840
    • Moses Mendoza's avatar
      (packaging) Update template task for new erb_file method · eb6a9365
      Moses Mendoza authored
      The packaging repo will have all utilities split out into different classes for
      sanity's sake, and one of the tools that got an overhaul is erb. This commit
      updates puppetdb to use the new utility.
      eb6a9365
    • Moses Mendoza's avatar
      (packaging) Update top-level Rakefile's version and pe determination · 43b030ba
      Moses Mendoza authored
      Prior to the commit, the versioning in puppetdb would fail from a rake
      perspective if the packaging repo wasn't present. This commit updates it to
      fall back to git describe and if that fails to a hardcoded string, so that we
      always have a version. We also set the @version variable to
      Pkg::Config.version, which is how we access data provided by the packaging repo
      in the new library-format.
      Signed-off-by: default avatarMoses Mendoza <moses@puppetlabs.com>
      43b030ba
    • Ryan Senior's avatar
      Merge pull request #824 from kbarber/maint/1.5.x/repl-host-documentation · 4311ea62
      Ryan Senior authored
      DOCS: Document repl 'host' setting
      4311ea62
  11. 03 Feb, 2014 1 commit
    • Ken Barber's avatar
      Document repl 'host' setting · ae1e74c2
      Ken Barber authored
      The [repl] block also supports setting 'host' to change where the repl service
      is listening to. This documents this setting, while also warning that changing
      it from 127.0.0.1 is not recommended for a production environment.
      Signed-off-by: default avatarKen Barber <ken@bob.sh>
      ae1e74c2
  12. 30 Jan, 2014 4 commits
    • Ryan Senior's avatar
      Merge pull request #823 from... · f24c37f0
      Ryan Senior authored
      Merge pull request #823 from cprice404/bug/1.5.x/PE-2675-change-filter-order-for-distinct-resource-events
      
      Bug/1.5.x/pe 2675 change filter order for distinct resource events
      f24c37f0
    • Chris Price's avatar
    • Chris Price's avatar
      435ca1ab
    • Chris Price's avatar
      (PE-2675) Change the order that filters are applied for events · a3ef1834
      Chris Price authored
      When using the `distinct-resources` flag of an event query, the
      previous behavior was that we would do the filtering of the events
      *before* we would eliminate duplicate resources.  This was not
      the expected behavior in many cases in the UI; for example,
      when filtering events based on event status, the desired behavior
      was to find all of the most recent events for each resource *first*,
      and then apply the filter to that set of resources.  If we did the
      status filtering first, then we might end up in a state where we
      found the most recent 'failed' event and showed it in the UI even
      if there were 'success' events on that resource afterwards.
      
      This commit changes the order that the filtering happens in.  We
      now do the `distinct` portion of the query before we do the filtering.
      
      However, in order to achieve reasonable performance, we need to
      at least include timestamp filtering in the `distinct` query; otherwise
      that portion of the query has to work against the entire table,
      and becomes prohibitively expensive.
      
      Since the existing timestamp filtering can be nested arbitrarily
      inside of the query (inside of boolean logic, etc.), it was not
      going to be possible to re-use that to handle the timestamp filtering
      for the `distinct` part of the query; thus, we had to introduce
      two new query parameters to go along with `distinct-resources`:
      `distinct-start-time` and `distinct-end-time`.  These are now
      required when using `distinct-resources`.
      
      This functionality is fairly specific to PE and should probably
      be separated into a PE-specific query endpoint in the future.
      a3ef1834
  13. 23 Jan, 2014 1 commit