The symlink served for a good discussion point around change impact, but
in the end having it makes for a more confusing experience overall both
to new users cloning the control-repo to get started and also to anyone
accustomed to "site". A new user won't miss "site". A symlink will muddy
the waters over the change for long-time users. Better for clarity to be
all-in and not include a symlink.
Prior to this commit, we placed modules local to a users installation
in the `site` directory. This was just a convention and the name
`site` doesn't clearly convey what it is for.
After this commit, we place modules local to a users installation in
the `site-modules` directory. This makes it more clear to users
that this is a directory that modules go i. When users start
with bolt they won't even know what a control-repo is and
renaming site to site-modules gives them a better idea of why
they should put their modules with tasks in them. Also see:
https://tickets.puppetlabs.com/browse/BOLT-1108
This commit moves the "where did all the previous code go" section to
the bottom as it's been a while since that change was made. Nowadays,
people new to Control Repositories will find this and won't understand
the reference as they never knew about previous versions.
Now the README starts right away with information on what this project
is and how to use it.
Also cleaned up some of the Markdown syntax to make it easier to read.
This is mainly a style and readability change.
Prior to this, on masters whose hostname is actually their FQDN, the
config_version script would show the entire FQDN. On nodes with really
longs FQDN's, it was not very nice to look at.
This takes the hostname of the master, splits it on dots (.) and takes
the first segment.
Now this: compile-master-02.int.lab.dmz.company-name.net-production-48fd18ab
Is this: compile-master-02-production-48fd18ab
Prior to this, the config_version.rb script (used for r10k) attempted to
use the system ruby to parse the script. This caused problems on Puppet
masters that don't have `ruby` in PATH.
This fixes that by hardcoding the puppet-agent's ruby in the shebang.
Prior to this, modules that were deployed with r10k into the ./modules
directory weren't being ignored by git.
When doing local development or testing, it's nice to be able to run
'r10k puppetfile install' to pull down modules from the Puppetfile.
After this commit, those modules won't be tracked by git.
This commit enables the control repo to use Hiera 5 environment-level
hiera hierarchy. This means adding a hiera.yaml to the repo, and moving
hieradata/ => data/.
We should do this to the control-repo template new customers base off of
because in a Hiera 5 world, the global hiera.yaml should be very minimal
(possibly even ONLY having the console level), and everything else
(nodes, common) belongs in the environment hiera.yaml.
This control-repo template is how people start using Puppet. It should
reflect using our most modern technologies.
Prior to this, the config_version script just showed the commit ID of
the version of code being compiled. This commit includes the compiling
Puppet master's hostname and environment name in the config_version.
This is very useful for debugging when a Puppet master is failing and
you have multiple masters behind a load balancer.
The output of config_version now looks like this:
pupmaster01-production-ac9785273a10
Prior to this commit, if you used windows bash git when you clone
down the repo these files would get incorrect permissions which
make them unexecutable.
After this commit, due to some windows bash git magic I don't
understand it appears that adding the shebang to the beginning of
the file causes windows bash git to change the permissions to
so the file is executable.
This resolves https://github.com/puppetlabs/control-repo/issues/40
Prior to this commit, we mitigated issues with hiera-eyaml causing
a memory leak by setting max_requets_per_instance to 0
After this commit, we go back to the default for
max_requests_per_instance because the hiera-eyaml memory leak
has been resolved for months if you use the newest version
Prior to this commit, the control-repo was an example of the
structure of a control repo but it also included puppet code to
help setup code manager and instructions to get that all setup
in a very specific way.
This was great for users that wanted to follow those instructions
exactly but wasn't great for people just looking for an example to
start from.
After this commit, the control-repo will be just an example once
again and a new repo somehwere else will pop up to provide the
explicit instructions on how to use the example with code manager.
There are links added to puppetlabs/control-repo to a new repo
that will have a version of the code that once lived in
puppetlabs/control-repo
Prior to this commit, there was a stash profile in the site dir
of this control-repo.
After this commit, the profile has been moved to it's own repo
where it can be used more generally and not tightly coupled to this
repository.
Prior to this commit, there was a gitlab profile in the site dir
of this control-repo.
After this commit, the profile has been moved to it's own repo
where it can be used more generally and not tightly coupled to this
repository.
As a result, the gitlab role has been removed from this repository
as well.
Prior to this commit, the puppetmaster profile was embedded in this
control-repo.
After this commit, the puppetmaster profile is moved out into its
own module.
