You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

This article describes the workflow used when updating the puppet configuration, and deploying it to the nodes in the cluster.

Setting up the local git environment

To start modifying our puppet configuration, you would need to clone a couple of git repositories:

  • git@github.com:ntnusky/profile.git
    • This puppet module installs and configures all the profiles in our installation
  • git@github.com:ntnusky/role.git
    • This puppet module defines which profiles a certain role contains. For instance it defines that our compute nodes needs nova and neutron compute, in addition to some baseconfig.
  • git@github.com:ntnusky/r10k.git
    • This repository defines which puppet modules (and versions of these) should be downloaded in which puppet environments.

It is certainly recommended to use git in favor of https, as this enables you to use keys instead of passwords to authenticate.

Create a new development environment in puppet

No modifications should be done directly to production (the ntnuit and skyhigh environment). All changes should be done to a testing environment, and when they are tested they might be merged into master. If a suitable testing environment does not exist it can simply be created by creating a new branch in the r10k repository.

Create a branch in r10k

Make sure to create the new branch based on the master branch:

Create new environment
eigil@breve:~/Repositories/ntnusky/r10k$ git branch
* master
eigil@breve:~/Repositories/ntnusky/r10k$ git branch newEnvironment
eigil@breve:~/Repositories/ntnusky/r10k$ git checkout newEnvironment
Switched to branch 'newEnvironment'
eigil@breve:~/Repositories/ntnusky/r10k$ git push
fatal: The current branch newEnvironment has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin newEnvironment

eigil@breve:~/Repositories/ntnusky/r10k$ git push --set-upstream origin newEnvironment
Total 0 (delta 0), reused 0 (delta 0)
To github.com:ntnusky/r10k.git
 * [new branch]      newEnvironment -> newEnvironment
Branch newEnvironment set up to track remote branch newEnvironment from origin.

Deploy the new environment at the puppetmaster:

To deploy the new environment on the puppetmaster you would use r10k:

Deploy new environment
 root@manager.skylow:~# r10k deploy environment newEnvironment -pv
INFO     -> Deploying environment /etc/puppet/environments/newEnvironment
   ...
INFO     -> Deploying module /etc/puppet/environments/newEnvironment/modules/role
INFO     -> Deploying module /etc/puppet/environments/newEnvironment/modules/profile
   ...
INFO     -> Removing unmanaged path /etc/puppet/environments/production

Have a node follow the new environment (without an ENC):

Which environment a certain host uses in puppet is defined in /etc/puppet/puppet.conf in each host. This file is managed by puppet, so to change the environment you need to update the node-specific hiera file (/etc/puppet/hieradata/nodes/fqdn.yaml) to include the following key:

  • profile::puppet::environment: 'newEnvironment'

After a puppet run the node is configured to follow the new environment, so the next puppet-run at that point will be run using the new environment.

Having a node follow the new environment (with an ENC):

If an ENC is used for puppet (iex. Foreman) the environment is set by the ENC. In this case the value in /etc/puppet/puppet.conf is overridden by the ENC at each puppet run, and the procedure to change environment without an ENC will not work. The value in /etc/puppet/puppet.conf needs to be a valid puppet environment however.

To change the active environment in Foreman you would select the host in the GUI and change it in the drop-down box for "environment".

Change what branches of the profile/role repos are used by a puppet environment

The master branch of the r10k repository should always be a predictable configuration, and it is thus following a certain version of each repository. This includes the role and profile repositories:

Following certain tags
$ egrep "'(profile|role)'" -A2 Puppetfile 
mod 'role',
  :git => 'https://github.com/ntnusky/role.git',
  :tag => 'v0.5.11'
--
mod 'profile',
  :git => 'https://github.com/ntnusky/profile.git',
  :tag => 'v0.5.16'

During development it is more valuable to follow a certain branch of these repositories, and the file should then be updated to something like this:

Following certain tags
$ egrep "'(profile|role)'" -A2 Puppetfile 
mod 'role',
  :git => 'https://github.com/ntnusky/role.git',
  :tag => 'v0.5.11'
--
mod 'profile',
  :git => 'https://github.com/ntnusky/profile.git',
  :branch => 'myProfileBranch'

After the change is performed it should be committed and pushed so it can go live:

Following certain tags
eigil@breve:~/Repositories/ntnusky/r10k$ git add Puppetfile 
eigil@breve:~/Repositories/ntnusky/r10k$ git commit -m "The 'profile' repo is now following the 'myProfileBranch' branch"
eigil@breve:~/Repositories/ntnusky/r10k$ git pull
eigil@breve:~/Repositories/ntnusky/r10k$ git push

At this point all changes commited to that branch of the profile repository will be installed at the puppetmaster when r10k is run.

Make changes, deploy to test, and test them

Make changes in your local repository, commit the changes, perform a git pull, resolve conflicts and perform a git push. When changes are pushed you can run r10k to deploy these changes to your puppet environment. Then test that puppet runs fine, and that your changes are what you expect.

Merge changes into master

When you are happy about your changes in your branch, and you would like to merge the changes into the master branch the recommended procedure is:

  1. Create a pullrequest in the github GUI where your changes are described. Add Eigil Obrestad and Lars Erik Pedersen to the list over reviewers.
  2. Wait for the pullrequest to be merged into master, and a tag to be created.
  3. Make the r10k repo start following the new tag instead of the branch in role/profile repos.
  4. Test that the new r10k config works
  5. Merge the stable r10k config to r10k master.

Deploy new release to production

Whenever there are an upgrade window in the production environment, the procedure is simple.

  • Merge the master branch of r10k to the production branch
  • Deploy with r10k.
  • Wait for puppet, or run it manually
  • Enjoy your newly updated openstack installation.

 

 

  • No labels