diff --git a/CHANGELOG.md b/CHANGELOG.md new file mode 100644 index 0000000..8d08520 --- /dev/null +++ b/CHANGELOG.md @@ -0,0 +1,44 @@ +# Change Log + +All notable changes to this project will be documented in this file. + +The format is based on +[Keep a Changelog](http://keepachangelog.com) +& makes a strong effort to adhere to +[Semantic Versioning](http://semver.org). + +Tracking in this Changelog began for this project with the tagging of version 0.1.0. +If you're looking for changes from before this, refer to the project's +git logs & PR history. + +# [Unreleased](https://github.com/puppetlabs/vmpooler/compare/4c858d012a262093383e57ea6db790521886d8d4...master) + +### Fixed + +- Remove unused method `find_pool` and related pending tests +- Setting `max_tries` results in an infinite loop (POOLER-124) +- Do not evaluate folders as VMs in `get_pool_vms` (POOLER-40) +- Expire redis VM key when clone fails (POOLER-31) +- Remove all usage of propertyCollector +- Replace `find_vm` search mechanism (POOLER-68) +- Fix configuration file loading (POOLER-103) +- Update vulnerable dependencies (POOLER-101) + +### Added + +- Allow API and manager to run separately (POOLER-109) +- Add configuration API endpoint (POOLER-107) +- Add option to disable VM hostname mismatch checks +- Add a gemspec file +- Add time remaining information (POOLER-81) +- Ship metrics for clone to ready time (POOLER-34) +- Reduce duplicate checking of VMs +- Reduce object lookups when retrieving VMs and folders +- Optionally create delta disks for pool templates +- Drop support for any ruby before 2.3 +- Add support for multiple LDAP search base DNs (POOLER-113) +- Ensure a VM is only destroyed once (POOLER-112) +- Add support for setting redis server port and password +- Greatly reduce time it takes to add disks +- Add Dockerfile that does not bundle redis +- Add vmpooler.service to support systemd managing the service diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..5d350eb --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,86 @@ +# How to contribute + +Third-party patches are essential for keeping vmpooler great. We want to keep it as easy as possible to contribute changes that +get things working in your environment. There are a few guidelines that we +need contributors to follow so that we can have a chance of keeping on +top of things. + +## Getting Started + +* Make sure you have a [Jira account](http://tickets.puppetlabs.com) +* Make sure you have a [GitHub account](https://github.com/signup/free) +* Submit a ticket for your issue, assuming one does not already exist. + * Clearly describe the issue including steps to reproduce when it is a bug. + * Make sure you fill in the earliest version that you know has the issue. +* Fork the repository on GitHub + +## Making Changes + +* Create a topic branch from where you want to base your work. + * This is usually the master branch. + * Only target release branches if you are certain your fix must be on that + branch. + * To quickly create a topic branch based on master; `git checkout -b + fix/master/my_contribution master`. Please avoid working directly on the + `master` branch. +* Make commits of logical units. +* Check for unnecessary whitespace with `git diff --check` before committing. +* Make sure your commit messages are in the proper format. + +```` + (POOLER-1234) Make the example in CONTRIBUTING imperative and concrete + + Without this patch applied the example commit message in the CONTRIBUTING + document is not a concrete example. This is a problem because the + contributor is left to imagine what the commit message should look like + based on a description rather than an example. This patch fixes the + problem by making the example concrete and imperative. + + The first line is a real life imperative statement with a ticket number + from our issue tracker. The body describes the behavior without the patch, + why this is a problem, and how the patch fixes the problem when applied. +```` + +* Make sure you have added the necessary tests for your changes. +* Run _all_ the tests to assure nothing else was accidentally broken. + +## Making Trivial Changes + +### Documentation + +For changes of a trivial nature to comments and documentation, it is not +always necessary to create a new ticket in Jira. In this case, it is +appropriate to start the first line of a commit with '(doc)' instead of +a ticket number. + +```` + (doc) Add documentation commit example to CONTRIBUTING + + There is no example for contributing a documentation commit + to the Puppet repository. This is a problem because the contributor + is left to assume how a commit of this nature may appear. + + The first line is a real life imperative statement with '(doc)' in + place of what would have been the ticket number in a + non-documentation related commit. The body describes the nature of + the new documentation or comments added. +```` + +## Submitting Changes + +* Sign the [Contributor License Agreement](http://links.puppetlabs.com/cla). +* Push your changes to a topic branch in your fork of the repository. +* Submit a pull request to the repository in the puppetlabs organization. +* Update your Jira ticket to mark that you have submitted code and are ready for it to be reviewed (Status: Ready for Merge). + * Include a link to the pull request in the ticket. +* The Puppet SRE team looks at Pull Requests on a regular basis. +* After feedback has been given we expect responses within two weeks. After two + weeks we may close the pull request if it isn't showing any activity. + +# Additional Resources + +* [Puppet Labs community guildelines](http://docs.puppetlabs.com/community/community_guidelines.html) +* [Bug tracker (Jira)](http://tickets.puppetlabs.com) +* [Contributor License Agreement](http://links.puppetlabs.com/cla) +* [General GitHub documentation](http://help.github.com/) +* [GitHub pull request documentation](http://help.github.com/send-pull-requests/)