Changes for PE2015.3.0 #9
Conversation
Added a function to find the hostname and port of the classifier Added a fucntion to return all puppetdb hostnames
Add pltraing-rbac module Added a new profile for code_manager that: - creates a service users for code manager - creates a token for that service user - creates a hook on a git server using the token Turns out that the file function in puppet cannot read files in /root. The pe-puppet user needs read permissions on the file and traversal on the directory which giving to /root would probably be a bad idea. So, I just put the file containing the token in /etc/puppetlabs/puppetserver since I'm not sure where would be better.
Moved the webhook resource out of puppetmaster and into zack_r10k to support exchaning code_manager in place of zack_r10k As a result I cleaned up some unnecessary parameters. Installing both the r10k webhook and the code_manager at this time for testing
Prior to this commit, the code manger profile could not complete on the first run because the file function would error out I implemented a new version of the file function that returns nothing when the file does not exist instead of erroring out which allows me to gate creating the webhook on whether there is content in the file. As a result this means that it takes 2 runs to get everything setup but this is preferable over having to manually intervene in some other way if the token file doesn't exist.
README.md
Outdated
- Moved ssh key generation and git deploy key out of the puppetmaster profile and into zack_r10k and code_manager - Swapped code manager into the all_in_one role - Made a 2015.2 all_in_one role if users prefer to use it - Conditionally move all existing code out of environmentpath to allow file sync to sync files - Update the README to compliment the new puppet code
Also, add a table of contents to the README. I generated the table of contents using https://github.com/ekalinin/github-markdown-toc.go
File sync appears to sync everything in the $codedir which inlcudes hiera.yaml. When managing hiera.yaml with puppet code you don't want file sync to overwrite its contents. So, I'm moving it out of $codedir and removing the original hiera.yaml to avoid confusion for users investigating later.
Update config_version.sh to read the r10k_deploy.json file if it exists. If it does not exist it will fall back to the existing logic
npwalker
force-pushed
the
2015_3_prep
branch
from
710ec7e to
56d0908
Compare
Prior to this commit there were two possible webhooks - zack/r10k webhook - code manager I moved these two profiles under git_webhook and choose the correct one based on the version of PE being used. As a safety hatch, I provide the $force_zack_r10k_webhook param on profile::git_webhook in case someone needs to continue using it instead of code manager.
Prior to this commit, if you upgraded from a previous version of the control-repo both code manager and zack/r10k webhook would be running and ready to receive data. This can present problems if the webhook isn't disbled in the git management system is sending data to both receivers. This commit adds rudimentary ability to break the zack/r10k webhook so it can't receive data.
Prior to this commit there was a requirement for the user of this repo to create a RBAC role in order for code manager to work. After this commit an exec statement will curl the RBAC API to create the role one time and hopefully it works otherwise the exec will not run again.
npwalker
force-pushed
the
2015_3_prep
branch
from
e87a0ec to
ad00dd7
Compare
|
All right I think I got a +1 from @glarizza. Unless I hear a reason not to merge this by EOD tomorrow I'm going to hit the big green button. |
Mostly reorganized the README to be 2015.3 first and then have some extra info at the bottom about upgrading from 2015.2. Added a blurb about what the control-repo provides.
|
Just a comment on 1 above: I usually put hiera.yaml into the control repo and then have a resource to drop it from the production environment to the confdir, the reason is because, to me, A.) the control repo should manage EVERYTHING necessary to get a Puppet master up and running, B.) It's easier to read/manage in file format versus using the Hiera module (in my opinion and the customers I've polled) - it's so infrequently changed that having the file there versus a class declaration makes it easier to "find", and C.) hiera_config is a singleton configuration item and is only read once on Puppetserver restart, so because we can't have different copies of it anyways, the easiest thing to do is just ensure it present based on the control repo (and, in the future, if we CAN have a per-environment Hiera config, we're setup for that). |
|
@glarizza Can we open that as a new issue? I think it's worth discussing and probably changing since I don't really like how it takes a puppet run to update hiera in the current format. A few people have mentioned this to me and I think I misunderstood Zack when he told me to use hunner/hiera ( as I think he meant for boot strapping as opposed to long term management). However, I don't want to hold up this PR because I've been using hunner/hiera for quite a while so this isn't a change in functionality. Also, what does "have a resource to drop it from the production environment to the confdir" mean? |
|
@npwalker A file resource to grab the source from /etc/puppetlabs/code/environments/production/hiera.yaml and ensure a file at /etc/puppetlabs/puppet/hiera.yaml, then it bounces the puppetserver service. |
|
And yeah, this shouldn't hold up the PR, just responding to the question I never answered :) |
3 participants
I've been working on this for a while and I want to put it up for PR to get feedback before merging it in.
Some things to consider / discuss:
/etc/puppetlabs/code/hiera.yamlis the correct thing to do move hiera.yaml into the control-repo and manage hiera_config in puppet.conf to point to it? Or should we stick with what I have here which is to just move to/etc/puppetlabs/puppet/hiera.yaml?