r10k 1.3.5 → 1.4.0

checksums.yaml

@@ -0,0 +1,15 @@
+---
+!binary "U0hBMQ==":
+  metadata.gz: !binary |-
+    YmQxYWU2Zjk4NzkwODMwNWYyZWMxMTA0NGZmMjg3NGFiNDM1OThlNA==
+  data.tar.gz: !binary |-
+    ZmRiYjU3NDk4ZTA0ZDdiYTYxMDc4YTU2ZTg4MzQ5MjFkYjNmZjVlNw==
+SHA512:
+  metadata.gz: !binary |-
+    YjE4YmM1ZmFlNDA1NWVkODYwMGU4YzQzYjk2OTNhOWY0ZWIwMjFkYjZmZmFk
+    ZWE3ZTA1MzEzNzgxYzNhZmVhMmYzZTQ1YzUwNTRiMTQ1NWU4MmRhMWM4ODBk
+    YWMzMDE3ZmRiYWQzNDA0MzhmNjk0ZTBlYzBkNDdjN2IwYjJmMGM=
+  data.tar.gz: !binary |-
+    MjNiNGJhYmQ1YWNlYjc0MzVhZWNmYzUwNjM2ZWEwMzcwYjZjYjA3OGRhOTAw
+    ZDk4MTQ2ZjlmMWQ5ZDBjNzdiY2RjNjVmY2JiOWQ5MGVmNjRmNjliNWEzNjkx
+    YTQ4YjI1ZWYwZmE1ZTk2NWZiOTczNTUwZTA2OWRiNGZmMmM1NzM=

data/.gitignore

@@ -3,4 +3,4 @@ Gemfile.local
 Gemfile.lock
 .bundle
 bundle
-/.rspec_system
+coverage

data/CHANGELOG.mkd

@@ -1,6 +1,216 @@
 CHANGELOG
 =========
 
+1.4.0
+-----
+
+2014/12/2
+
+### User notes
+
+(GH-40) Display expected and actual module versions
+
+When displaying the state of a deployment, modules would report a version but
+would not indicate if that was the expected version or desired version. This has
+been changed so that both the expected and actual module version information is
+displayed. Because determining the actual version for modules can be slow the
+`--detail` flag must be passed to display this information.
+
+(GH-43) Using a relative `moduledir` in the Puppetfile is relative to the Puppetfile
+
+The `moduledir` setting in the Puppetfile could be used to set a custom
+directory for Puppetfile modules, but if a relative path was used it was
+relative to the current working directory. As of 1.4.0 a relative `moduledir`
+setting will be expanded to the Puppetfile, which should make it much easier to
+use a directory other than 'modules' for the Puppetfile installed modules.
+
+(GH-68) Add alias for `r10k deploy display`
+
+The `r10k deploy display` subcommand had unfriendly syntax, and now has an
+alias of `r10k deploy list`.
+
+(GH-92) Support `mod 'owner/module'` for Git and SVN modules
+
+The original implementation of Git and SVN based modules assumed that the module
+name was only the name component, and did not include the owner component of the
+module. Because of this the full module name was added to the path, which meant
+that a Git module or SVN module called `foo/bar` would be created as
+`$moduledir/foo/bar`, after which r10k would check for stale modules, see a
+module called `foo`, and delete it.
+
+This has now been corrected so that all modules may have an owner and name, and
+only the name will be used when constructing the module path.
+
+Issues also closed as part of GH-92:
+
+  * GH-78
+
+(GH-96) Provide output from Git command failures
+
+When r10k encounters an error while running a command, it will always log the
+failed command and the output of the command. This should make it dramatically
+easier to diagnose issues with the underlying commands used by r10k without
+having to re-run the failing r10k command with a myriad of command line flags.
+
+Issues also closed as part of GH-96:
+
+  * GH-46
+  * GH-94
+
+(GH-121) Support for calling an arbitrary script after deployment
+
+Users can now specify a `postrun` setting in `r10k.yaml` to run an arbitrary
+command after an environment deployment finishes. The current implementation is
+fairly simple and isn't passed additional information about the deployment and
+is mainly meant to notify other services that the deployment has completed.
+Future versions of r10k will provide more information to this command so that
+more complex actions can be taken on success and failure.
+
+(GH-155) Allow SVN credentials to be added for modules/environments, disallow interactive SVN
+
+When interacting with SVN modules, r10k could run SVN commands that could try to
+prompt the user for input but were not provided access to stdin. R10k is meant
+to be non-interactive so credentials need to be provided in some manner, but
+cannot be provided directly by the user.
+
+As of 1.4.0 SVN environments and modules can supply a username and password to
+be used when interacting with the SVN remote, and SVN commands are run with
+`--non-interactive` to prevent commands from trying to grab stdin.
+
+**Note**: SVN credentials are passed as command line options, so the SVN
+credentials may be visible in the process table when r10k is running. If you
+choose to supply SVN credentials make sure that the system running r10k is
+appropriately secured.
+
+(GH-169) Perform non-blocking reads on stderr in Subprocess
+
+When using SSH with a Control Master, the first time an SSH connection is
+launched it will persist and will hang onto stderr from the parent process.
+R10k was using blocking IO to read from child processes and assumed that the
+file descriptors would be closed when the launched process exited, and the
+persistent SSH process would cause r10k to hang.
+
+The subprocess code has been updated to perform nonblocking reads of stderr;
+when the child process exits it assumes that even if stderr is held open nothing
+else should be written to it, drains the buffered pipe content and returns with
+that.
+
+This is working around buggy behavior in SSH, but this problem doesn't look like
+it'll go away so the best course of action is to incorporate this fix into
+downstream.
+
+(GH-180) Don't leak FDs when executing subcommands
+
+R10k was not explicitly closing all file descriptors, and on Ruby 1.8.7 these
+would not be closed by the garbage collector, causing file descriptors to leak.
+This has been fixed and all file descriptors should be closed after each
+subprocess is invoked.
+
+Major thanks to Jeremy Asher for discovering and fixing this.
+
+(GH-193) Don't purge environments if environment sources can't be fetched
+
+The original behavior for deploying environments with r10k was to fetch sources,
+deploy environments from those sources, and then clean up any orphaned
+environments. If a source had been fetched before but could not be reached then
+r10k would use the previously fetched branch information to update environments.
+In normal cases this would provide a reasonably robust failure mode.
+
+However, this meant that if no sources had been be fetched or the source remote
+information was typoed, r10k would have no source information, could enumerate
+no environments, and then enter HULK SMASH mode where it would delete all
+unmanaged environments - AKA everything. This is an uncommon failure mode but
+could bite environments that were setting up r10k for the first time.
+
+To resolve this issue, r10k will try to fetch all sources and if any source
+fails to be fetched then r10k will abort the entire deployment. This means that
+r10k will fail very early before any changes have been made which is a safe time
+to fail. If the errors were transitory then r10k can be run again, and if the
+failures are permanent then it's hard to safely update anything and extremely
+dangerous to try to delete any environments.
+
+(GH-202) Different environments cannot manage the same path
+
+R10k allowed for multiple sources to create environments but did not have
+semantics for environments from different sources managing the same path. If
+this happened, the resulting behavior would be undefined and could do any number
+of strange things. The approach to this was by convention and prefixing was
+recommended to avoid this, but it's still not a great approach.
+
+This was resolved by looking for environment collisions before deploying; if
+collisions exist then r10k will abort the deployment.
+
+Note: The commit that fixed this referenced GH-123 instead of GH-202.
+
+(GH-214) Rescue SyntaxError and LoadError when evaluating Puppetfiles
+
+Since Puppetfiles are just a Ruby DSL it's possible to have multiple Puppetfiles
+that are aggregated by using `require` or `load`. However these methods raise
+exceptions that don't descend from `StandardError`, so the normal error handling
+would not catch them, so a malformed Puppetfile could catastrophically crash
+r10k.
+
+Because the Puppetfile is not an actual source file in the conventional sense we
+can recover from these errors and continue, so r10k will now recover from these
+errors. If a SyntaxError or LoadError is raised while evaluating a Puppetfile,
+r10k will rescue them and wrap them in an R10K::Error and then raise that, which
+can be caught and handled as a normal, non-critical exception.
+
+(GH-221) Only deploy modules once for each environment deploy
+
+If an environment was deployed for the first time and `--puppetfile` was
+specified, the initial creation would create the environment and then deploy
+modules, and then the modules would be deployed again because `--puppetfile` was
+separate code. The deploy logic has been refactored to consider `--puppetfile`
+being passed or the environment being created to be equivalent and will only
+deploy modules once.
+
+### Developer notes
+
+`R10K::Environment::Base#sync` is no longer recursive; callers are expected to
+handle recursive updates if needed.
+
+The `R10K::Action` namespace has been added to provide an API to r10k
+functionality. These should be used by any code that wants to interact with r10k
+and should provide an alternative to shelling out to r10k or using `R10K::CLI`
+directly. The individual action objects should be called through
+`R10K::Action::Runner` so that application setup and teardown is handled.
+
+### Thanks
+
+Thanks to the following contributors for their work on this release:
+
+  * [Robert Nelson](https://github.com/rnelson0) for his work on documenting
+    workflows and best practices with r10k and adding convenience aliases for
+    `r10k deploy display`
+  * [Wolf Noble](https://github.com/rmnwolf) for homogenizing markdown file
+    extensions
+  * [Thomas Bartelmess](https://github.com/tbartelmess) for updating the
+    required version of cri
+  * [Theo Chatzimichos](https://github.com/tampakrap) for correcting the license
+    format to conform to SPDX
+  * [Richard Raseley](https://github.com/richardraseley) for writing a
+    quickstart guide for r10k
+  * [Matthew Haughton](https://github.com/3flex) for fixing documentation typos
+  * [Markus Frosch](https://github.com/lazyfrosch) for fixing a regression in
+    how duplicate environments are checked for, before the regression was ever
+    released. Good catch!
+  * [Jeremy Asher](https://github.com/jeremyasher) for fixing file descriptor
+    leaks and hanging on open file descriptors in the Subprocess module. Great
+    sleuthing on this!
+  * [Guzman Braso](https://github.com/guzmanbraso) for adding Debian support
+    and fixing some bugs in the quickstart documentation.
+  * [David Schmitt](https://github.com/DavidS) for fixing markdown syntax errors
+    so that link URLs would render properly in GitHub
+  * [Christophe Bliard](https://github.com/cbliard) for fixing the Puppetfile
+    moduledir setting to treat relative paths as relative to the Puppetfile
+  * [Christoph Föhrdes](https://github.com/cfoehrdes) For fixing a copy/paste
+    error in the Puppetfile documentation
+
+In addition to those who contributed to the code base, thanks to all those that
+reported and commented on issues; user input makes it much easier to make r10k a
+better project!
+
 1.3.5
 -----
 

data/CONTRIBUTING.mkd

@@ -0,0 +1,105 @@
+Contributing
+============
+
+## Bug reports and feature requests
+
+Bug reports and feature requests may be filed on the [GitHub issue
+tracker][github-issue-tracker]. When filing a bug report or feature request,
+please spend a moment to look for existing issue reports and update those with
+additional information if possible.
+
+[github-issue-tracker]: https://github.com/adrienthebo/r10k/issues
+
+### Bug reports
+
+When filing a bug report, include as much relevant detailed information as
+possible. Try to include the following:
+
+  * A descriptive summary of the bug
+  * When the bug first occurred
+  * What sort of events may have triggered the bug
+  * The expected behavior
+  * The actual behavior
+  * Steps to reproduce
+
+If if you're seeing errors or crashes you can run R10K with the `-v debug2` to
+greatly increase the log level and `--trace` to print any stack traces that may
+be caught.
+
+Including a reproduction environment with something like Vagrant is tremendously
+helpful and can greatly speed up the time it takes to fix your issue!
+
+### Feature requests
+
+When filing a feature request, include information about how important the
+feature is, how it would generally be used in your environment, and how often
+this feature would be used by other users as well. Please keep in mind that
+each added feature incurs additional maintenance costs, so feature requests
+should strive to solve a frequent pain point for users or generally make r10k a
+more effective tool for a large number of r10k users.
+
+The policy towards feature requests in r10k has been greatly shaped by Brian
+Granger's post on [features and scope in open source software][features-and-scope].
+
+Try to include the following:
+
+  * A descriptive summary of the feature
+  * How you expect to use this feature
+  * How important this feature is for your environment
+  * How useful this feature would be for other users
+  * Any potential caveats this may have or any issues this feature may have
+
+[features-and-scope]: http://brianegranger.com/?p=249 "Features and Scope in Open Source Software"
+
+## Documentation
+
+Contributing fixes and improvements to the core documentation is a great way to
+help improve R10K. Improvements to the FAQ, example code, and so forth can go a
+long way towards making R10K more approachable for new users and existing users
+alike. For more information about the submission process please see the section
+on [code contributions][#code-contributions].
+
+## Code contributions
+
+This documentation is based on the Project Hydra
+[CONTRIBUTING](https://github.com/projecthydra/hydra-head/blob/master/CONTRIBUTING.md)
+guide.
+
+### Making changes
+
+  * Fork the repository on GitHub
+  * Create a topic branch from where you want to base your work.
+    * For new features, base your code off of 'master'.
+    * For critical bugfixes, base your code off of the appropriate maintenance
+      branch series, eg '1.2.x' or '1.3.x'
+    * To create a new topic branch; `git checkout -b fix/master/my_contribution master`
+    * Please avoid working directly on the 'master' branch.
+  * Make commits of logical units.
+    * Your commit should include a high level description of your work in HISTORY.textile 
+  * Check for unnecessary whitespace with `git diff --check` before committing.
+
+```
+    [code/subsystem] (GH-#) Present tense short summary (80 characters or less)
+
+    More detailed description, if necessary. It should be wrapped to 80
+    characters. Try to be as descriptive as you can, even if you think that
+    the commit content is obvious, it may not be obvious to others. You
+    should add such description also if it's already present in bug tracker,
+    it should not be necessary to visit a webpage to check the history.
+```
+
+  * Make sure you have added the necessary tests for your changes.
+  * Run _all_ the tests to assure nothing else was accidentally broken.
+
+### Submitting changes
+
+  * Push your changes to a topic branch in your fork of the repository.
+  * Submit a pull request from your fork to the project.
+  * Expect to have some further discussion of your submission prior to it being merged.
+
+Please note - code review is an essential part of the code review and submission
+process. In order to keep the code base clean and maintainable questions may be
+asked on implementation decisions and you may be asked to make additional
+changes to the contribution. Remember - feedback is never personal and should be
+given to benefit both the submitter as well as the project receiving the
+contribution.

data/Gemfile

@@ -2,12 +2,8 @@ source 'https://rubygems.org'
 
 gemspec
 
-group(:system) do
-  gem 'rake'
-  gem 'rspec-system', '~> 2.8.0'
-  gem 'rspec-system-serverspec', '~> 2.0.1'
-  gem 'net-ssh', '2.7.0'
-  gem 'vagrant', :git => 'git://github.com/mitchellh/vagrant', :tag => 'v1.4.1'
+group :development do
+  gem 'simplecov', '~> 0.9.1' if RUBY_VERSION > '1.8.7'
 end
 
 if File.exists? "#{__FILE__}.local"

data/README.mkd

@@ -0,0 +1,97 @@
+r10k
+====
+
+Puppet environment and module deployment
+
+[![Build Status](https://travis-ci.org/adrienthebo/r10k.png?branch=master)](https://travis-ci.org/adrienthebo/r10k)
+
+Description
+-----------
+
+[librarian-puppet]: https://github.com/rodjek/librarian-puppet
+[workflow]: http://puppetlabs.com/blog/git-workflow-and-puppet-environments/
+
+R10k provides a general purpose toolset for deploying Puppet environments and
+modules. It implements the [Puppetfile][librarian-puppet] format and provides a native
+implementation of Puppet [dynamic environments][workflow].
+
+Requirements
+------------
+
+R10k supports the following Ruby versions:
+
+  - 1.8.7 (POSIX minimum version)
+  - 1.9.3 (Windows minimum version)
+  - 2.0.0
+  - 2.1.0
+
+R10k requires additional components, depending on how you plan on managing
+environments and modules.
+
+  - Installing modules from the Puppet Forge requires Puppet 3.0.0+ or later.
+  Puppet 2.7 may work, but is generally not recommended as Puppet 2.7 is EOL.
+  - Git is required for creating environments and modules from Git
+  - SVN is required for creating environments and modules from SVN
+
+Installation
+------------
+
+### Rubygems
+
+For general use, you should install r10k from Ruby gems:
+
+    gem install r10k
+    r10k help
+
+### Puppet Enterprise
+
+Puppet Enterprise bundles a copy of Ruby, so if you do not want to use the
+system version of Ruby with r10k, you need to use the bundled PE gem command for
+installation:
+
+    /opt/puppet/bin/gem install r10k
+    r10k help
+
+### Bundler
+
+If you have more specific needs or plan on modifying r10k you can run it out of
+a git repository using Bundler for dependencies:
+
+    git clone git://github.com/adrienthebo/r10k
+    cd r10k
+    bundle install
+    bundle exec r10k help
+
+Usage
+-----
+
+R10k has two primary roles: installing Puppet modules using a standalone
+Puppetfile, and managing Git and SVN based dynamic environments. For more
+information see the topic specific documentation:
+
+  * [Puppetfile Documentation](doc/puppetfile.mkd)
+  * [Environment Deployment Documentation](doc/dynamic-environments.mkd)
+  * [Quickstart](doc/dynamic-environments/quickstart.mkd)
+  * [Common Patterns](doc/common-patterns.mkd)
+  * [Workflow Guide](doc/workflow-guide.mkd)
+
+For more general questions, see the [FAQ](doc/faq.mkd).
+
+Getting help
+------------
+
+  * IRC: r10k has a dedicated channel, `#r10k`, on Freenode where r10k questions
+  can be directed. Questions about r10k can frequently be asked in `#puppet` as well.
+  * Mailing lists: [puppet-users](https://groups.google.com/forum/#!forum/puppet-users)
+  * Q&A: [Puppet Ask](https://ask.puppetlabs.com/questions/)
+
+
+More information
+----------------
+
+The original impetus for r10k is explained at http://somethingsinistral.net/blog/rethinking-puppet-deployment/
+
+Contributors
+------------
+
+Please see the CHANGELOG for a listing of the (very awesome) contributors.