puppet 3.1.0.rc1 → 3.1.0.rc2

data/COMMITTERS.md

@@ -0,0 +1,185 @@
+Committing changes to Puppet
+====
+
+We would like to make it easier for community members to contribute to Puppet
+using pull requests, even if it makes the task of reviewing and committing
+these changes a little harder.  Pull requests are only ever based on a single
+branch, however, we maintain more than one active branch.  As a result
+contributors should target their changes at the master branch. This makes the
+process of contributing a little easier for the contributor since they don't
+need to concern themselves with the question, "What branch do I base my changes
+on?"  This is already called out in the [CONTRIBUTING.md](http://goo.gl/XRH2J).
+
+Therefore, it is the responsibility of the committer to re-base the change set
+on the appropriate branch which should receive the contribution.
+
+The rest of this document addresses the concerns of the committer.  This
+document will help guide the committer decide which branch to base, or re-base
+a contribution on top of.  This document also describes our branch management
+strategy, which is closely related to the decision of what branch to commit
+changes into.
+
+Terminology
+====
+
+Many of these terms have more than one meaning.  For the purposes of this
+document, the following terms refer to specific things.
+
+**contributor** - A person who makes a change to Puppet and submits a change
+set in the form of a pull request.
+
+**change set** - A set of discrete patches which combined together form a
+contribution.  A change set takes the form of Git commits and is submitted to
+Puppet in the form of a pull request.
+
+**committer** - A person responsible for reviewing a pull request and then
+making the decision what base branch to merge the change set into.
+
+**base branch** - A branch in Git that contains an active history of changes
+and will eventually be released using semantic version guidelines.  The branch
+named master will always exist as a base branch.  All other base branches will
+be associated with a specific released version of Puppet, e.g. 2.7.x and 3.0.x.
+
+Committer Guide
+====
+
+This section provides a guide to follow while committing change sets to Puppet
+base branches.
+
+How to decide what release(s) should be patched
+---
+
+This section provides a guide to help a committer decide the specific base
+branch that a change set should be merged into.
+
+The latest minor release of a major release is the only base branch that should
+be patched. Older minor releases in a major release do not get patched. Before
+the switch to [semantic versions](http://semver.org/) committers did not have
+to think about the difference between minor and major releases.  Committing to
+the latest minor release of a major release is a policy intended to limit the
+number of active base branches that must be managed.
+
+Security patches are handled as a special case.  Security patches may be
+applied to earlier minor releases of a major release.
+
+How to commit a change set to multiple base branches
+---
+
+A change set may apply to multiple releases.  In this situation the change set
+needs to be committed to multiple base branches.  This section provides a guide
+for how to merge patches across releases, e.g. 2.7 is patched, how should the
+changes be applied to 3.0?
+
+First, merge the change set into the lowest numbered base branch, e.g. 2.7.
+Next, merge the changed base branch up through all later base branches by using
+the `--no-ff --log` git merge options.  We commonly refer to this as our "merge
+up process" because we merge in once, then merge up multiple times.
+
+When a new minor release branch is created (e.g. 3.1.x) then the previous one
+is deleted (e.g. 3.0.x). Any security or urgent fixes that might have to be
+applied to the older code line is done by creating an ad-hoc branch from the
+tag of the last patch release of the old minor line.
+
+Code review checklist
+---
+
+This section aims to provide a checklist of things to look for when reviewing a
+pull request and determining if the change set should be merged into a base
+branch:
+
+ * All tests pass
+ * Are there any platform gotchas? (Does a change make an assumption about
+   platform specific behavior that is incompatible with other platforms?  e.g.
+   Windows paths vs. POSIX paths.)
+ * Is the change backwards compatible? (It should be)
+ * Are there YARD docs for API changes?
+ * Does the change set also require documentation changes? If so is the
+   documentation being kept up to date?
+ * Does the change set include clean code?  (software code that is formatted
+   correctly and in an organized manner so that another coder can easily read
+   or modify it.)  HINT: `git diff master --check`
+ * Does the change set conform to the contributing guide?
+
+
+Commit citizen guidelines:
+---
+
+This section aims to provide guidelines for being a good commit citizen by
+paying attention to our automated build tools.
+
+ * Don’t push on a broken build.  (A broken build is defined as a failing job
+   in the [Puppet FOSS](https://jenkins.puppetlabs.com/view/Puppet%20FOSS/)
+   page.)
+ * Watch the build until your changes have gone through green
+ * Update the ticket status and target version.  The target version field in
+   our issue tracker should be updated to be the next release of Puppet.  For
+   example, if the most recent release of Puppet is 3.1.1 and you merge a
+   backwards compatible change set into master, then the target version should
+   be 3.2.0 in the issue tracker.)
+ * Ensure the pull request is closed (Hint: amend your merge commit to contain
+   the string `closes: #123` where 123 is the pull request number.
+
+Example Procedure
+====
+
+This section helps a committer rebase a contribution onto an earlier base
+branch, then merge into the base branch and up through all active base
+branches.
+
+Suppose a contributor submits a pull request based on master.  The change set
+fixes a bug reported against Puppet 3.1.1 which is the most recently released
+version of Puppet.
+
+In this example the committer should rebase the change set onto the 3.1.x
+branch since this is a bug rather than new functionality.
+
+First, the committer pulls down the branch using the `hub` gem.  This tool
+automates the process of adding the remote repository and creating a local
+branch to track the remote branch.
+
+    $ hub checkout https://github.com/puppetlabs/puppet/pull/1234
+    Branch jeffmccune-fix_foo_error set up to track remote branch fix_foo_error from jeffmccune.
+    Switched to a new branch 'jeffmccune-fix_foo_error'
+
+At this point the topic branch is a descendant of master, but we want it to
+descend from 3.1.x.  The committer creates a new branch then re-bases the
+change set:
+
+    $ git branch bug/3.1.x/fix_foo_error
+    $ git rebase --onto 3.1.x master bug/3.1.x/fix_foo_error
+    First, rewinding head to replay your work on top of it...
+    Applying: (#23456) Fix FooError that always bites users in 3.1.1
+
+The `git rebase` command may be interpreted as, "First, check out the branch
+named `bug/3.1.x/fix_foo_error`, then take the changes that were previously
+based on `master` and re-base them onto `3.1.x`.
+
+Now that we have a topic branch containing the change set based on the correct
+release branch, the committer merges in:
+
+    $ git checkout 3.1.x
+    Switched to branch '3.1.x'
+    $ git merge --no-ff --log bug/3.1.x/fix_foo_error
+    Merge made by the 'recursive' strategy.
+     foo | 0
+     1 file changed, 0 insertions(+), 0 deletions(-)
+     create mode 100644 foo
+
+Once merged into the first base branch, the committer merges up:
+
+    $ git checkout master
+    Switched to branch 'master'
+    $ git merge --no-ff --log 3.1.x
+    Merge made by the 'recursive' strategy.
+     foo | 0
+     1 file changed, 0 insertions(+), 0 deletions(-)
+     create mode 100644 foo
+
+Once the change set has been merged "in and up." the committer pushes.  (Note,
+the checklist should be complete at this point.)  Note that both the 3.1.x and
+master branches are being pushed at the same time.
+
+    $ git push puppetlabs master:master 3.1.x:3.1.x
+
+That's it!  The committer then updates the pull request, updates the issue in
+our issue tracker, and keeps an eye on the build status.

data/ext/debian/changelog.erb

@@ -4,6 +4,12 @@ puppet (<%= @debversion %>) hardy lucid natty oneiric unstable sid squeeze wheez
 
  -- Puppet Labs Release <info@puppetlabs.com>  <%= Time.now.strftime("%a, %d %b %Y %H:%M:%S %z")%>
 
+puppet (3.1.0-0.1rc1puppetlabs1) lucid natty oneiric precise unstable sid squeeze wheezy precise; urgency=low
+
+  * Add extlookup2hiera manpage to puppet-common.manpages
+
+ -- Matthaus Owens <matthaus@puppetlabs.com>  Fri, 25 Jan 2013 14:45:14 +0000
+
 puppet (2.7.19-1puppetlabs2) hardy jaunty karmic lucid maverick natty oneiric unstable lenny sid squeeze wheezy precise; urgency=low
 
   * (#16086) Add version parameter to rm_conffile call in puppetmaster preinst and postinst

data/ext/debian/puppet-common.manpages

@@ -1,2 +1,3 @@
 man/man5/puppet.conf.5
 man/man8/puppet.8
+man/man8/extlookup2hiera.8

data/ext/debian/puppet.default

@@ -1,6 +1,8 @@
 # Defaults for puppet - sourced by /etc/init.d/puppet
 
-# Start puppet on boot?
+# Enable puppet agent service?
+# Setting this to "yes" allows the puppet agent service to run.
+# Setting this to "no" keeps the puppet agent service from running.
 START=no
 
 # Startup options

data/ext/debian/puppetmaster.default

@@ -1,11 +1,14 @@
 # Defaults for puppetmaster - sourced by /etc/init.d/puppetmaster
 
-# Start puppetmaster on boot? If you are using passenger, you should
-# have this set to "no"
+# Enable puppetmaster service? 
+# Setting this to "yes" allows the puppet master service to run.
+# Setting this to "no" keeps the puppet master service from running.
+#
+# If you are using Passenger, you should have this set to "no."
 START=yes
 
 # Startup options
 DAEMON_OPTS=""
 
-# What port should the puppetmaster listen on (default: 8140).
+# On what port should the puppet master listen? (default: 8140)
 PORT=8140

data/ext/redhat/puppet.spec.erb

@@ -192,11 +192,7 @@ mkdir -p %{buildroot}%{_sysconfdir}/%{name}/modules
 %{_datadir}/emacs
 %{_datadir}/vim
 %{_datadir}/%{name}
-# These need to be owned by puppet so the server can
-# write to them
-%attr(-, puppet, puppet) %{_localstatedir}/run/puppet
-%attr(0750, puppet, puppet) %{_localstatedir}/log/puppet
-%attr(-, puppet, puppet) %{_localstatedir}/lib/puppet
+# man pages
 %{_mandir}/man5/puppet.conf.5.gz
 %{_mandir}/man8/puppet.8.gz
 %{_mandir}/man8/puppet-agent.8.gz
@@ -232,6 +228,15 @@ mkdir -p %{buildroot}%{_sysconfdir}/%{name}/modules
 %{_mandir}/man8/puppet-resource_type.8.gz
 %{_mandir}/man8/puppet-secret_agent.8.gz
 %{_mandir}/man8/puppet-status.8.gz
+%{_mandir}/man8/extlookup2hiera.8.gz
+# These need to be owned by puppet so the server can
+# write to them. The separate %defattr's are required
+# to work around RH Bugzilla 681540
+%defattr(-, puppet, puppet, 0755)
+%{_localstatedir}/run/puppet
+%defattr(-, puppet, puppet, 0750)
+%{_localstatedir}/log/puppet
+%{_localstatedir}/lib/puppet
 
 %files server
 %defattr(-, root, root, 0755)
@@ -375,6 +380,12 @@ rm -rf %{buildroot}
 * <%= Time.now.strftime("%a %b %d %Y") %> Puppet Labs Release <info@puppetlabs.com> -  <%= @rpmversion %>-<%= @rpmrelease %>
 - Build for <%= @version %>
 
+* Fri Jan 25 2013 Matthaus Owens <matthaus@puppetlabs.com> - 3.1.0-0.1rc1
+- Add extlookup2hiera.8.gz to the files list
+
+* Wed Jan 9  2013 Ryan Uber <ru@ryanuber.com> - 3.1.0-0.1rc1
+- Work-around for RH Bugzilla 681540
+
 * Tue Dec 18 2012 Matthaus Owens <matthaus@puppetlabs.com>
 - Remove for loop on examples/ code which no longer exists. Add --no-run-if-empty to xargs invocations.
 

data/lib/puppet.rb

@@ -155,11 +155,9 @@ module Puppet
   end
 end
 
-# This feels weird to me; I would really like for us to get to a state where
-# there is never a "require" statement anywhere besides the very top of a
-# file. That would not be possible at the moment without a great deal of
-# effort, but I think we should strive for it and revisit this at some point.
-# --cprice 2012-03-16
+# This feels weird to me; I would really like for us to get to a state where there is never a "require" statement
+#  anywhere besides the very top of a file.  That would not be possible at the moment without a great deal of
+#  effort, but I think we should strive for it and revisit this at some point.  --cprice 2012-03-16
 
 require 'puppet/type'
 require 'puppet/parser'

data/lib/puppet/defaults.rb

@@ -682,10 +682,6 @@ EOT
       :desc       => "The default TTL for new certificates. If this setting is set, ca_days is ignored.
       Can be specified as a duration."
     },
-    :ca_md => {
-      :default    => "md5",
-      :desc       => "The type of hash used in certificates.",
-    },
     :req_bits => {
       :default    => 4096,
       :desc       => "The bit length of the certificates.",
@@ -1089,9 +1085,14 @@ EOT
     },
     :dynamicfacts => {
       :default    => "memorysize,memoryfree,swapsize,swapfree",
-      :desc       => "Facts that are dynamic; these facts will be ignored when deciding whether
+      :desc       => "(Deprecated) Facts that are dynamic; these facts will be ignored when deciding whether
       changed facts should result in a recompile.  Multiple facts should be
       comma-separated.",
+      :hook => proc { |value|
+        if value
+          Puppet.deprecation_warning "The dynamicfacts setting is deprecated and will be ignored."
+        end
+      }
     },
     :splaylimit => {
       :default    => "$runinterval",

data/lib/puppet/dsl.rb

@@ -1,11 +1,7 @@
 require 'puppet'
-require 'puppet/dsl/parser'
-require 'puppet/dsl/context'
 
-module Puppet
-  # @since 3.1
-  # @status EXPERIMENTALx
-  module DSL
-  end
+module Puppet::DSL
 end
 
+require 'puppet/dsl/resource_type_api'
+require 'puppet/dsl/resource_api'

data/lib/puppet/dsl/resource_api.rb

@@ -0,0 +1,120 @@
+# This module adds functionality to a resource to make it
+# capable of evaluating the DSL resource type block and also
+# hooking into the scope system.
+require 'puppet/resource/type_collection_helper'
+
+class Puppet::DSL::ResourceAPI
+  include Puppet::Resource::TypeCollectionHelper
+
+  FUNCTION_MAP = {:acquire => :include}
+
+  attr_reader :scope, :resource, :block
+
+  def environment
+    scope.environment
+  end
+
+  def evaluate
+    set_instance_variables
+    instance_eval(&block)
+  end
+
+  def initialize(resource, scope, block)
+    @scope = scope
+    @resource = resource
+    @block = block
+  end
+
+  # Try to convert a missing method into a resource type or a function.
+  def method_missing(name, *args)
+    raise "MethodMissing loop when searching for #{name} with #{args.inspect}" if searching_for_method?
+    @searching_for_method = true
+    return create_resource(name, args[0], args[1]) if valid_type?(name)
+
+    name = map_function(name)
+
+    return call_function(name, args) if Puppet::Parser::Functions.function(name)
+
+    super
+  ensure
+    @searching_for_method = false
+  end
+
+  def set_instance_variables
+    resource.eachparam do |param|
+      instance_variable_set("@#{param.name}", param.value)
+    end
+    @title = resource.title
+    @name ||= resource.title
+  end
+
+  def create_resource(type, names, arguments = nil)
+    names = [names] unless names.is_a?(Array)
+
+    arguments ||= {}
+    raise ArgumentError, "Resource arguments must be provided as a hash" unless arguments.is_a?(Hash)
+
+    names.collect do |name|
+      resource = Puppet::Parser::Resource.new(type, name, :scope => scope)
+      arguments.each do |param, value|
+        resource[param] = value
+      end
+
+      resource.exported = true if exporting?
+      resource.virtual = true if virtualizing?
+      scope.compiler.add_resource(scope, resource)
+      resource
+    end
+  end
+
+  def call_function(name, args)
+    return false unless method = Puppet::Parser::Functions.function(name)
+    scope.send(method, *args)
+  end
+
+  def export(resources = nil, &block)
+    if resources
+      resources.each { |resource| resource.exported = true }
+      return resources
+    end
+    @exporting = true
+    instance_eval(&block)
+  ensure
+    @exporting = false
+  end
+
+  def virtual(resources = nil, &block)
+    if resources
+      resources.each { |resource| resource.virtual = true }
+      return resources
+    end
+    @virtualizing = true
+    instance_eval(&block)
+  ensure
+    @virtualizing = false
+  end
+
+  def valid_type?(name)
+    return true if [:class, :node].include?(name)
+    return true if Puppet::Type.type(name)
+    return(known_resource_types.definition(name) ? true : false)
+  end
+
+  private
+
+  def exporting?
+    @exporting
+  end
+
+  def map_function(name)
+    FUNCTION_MAP[name] || name
+  end
+
+  def searching_for_method?
+    @searching_for_method
+  end
+
+  def virtualizing?
+    @virtualizing
+  end
+end