Rob Nelson’s 2015 Goals

On January 19th, I graded my efforts in 2014 and promised to document my technical goals for this year.

Learn Ruby

I spend a lot of time with Puppet and R10k and while I’m a decent enough programmer to pick up on what’s going on in general, I really need to grok Ruby at an advanced level. I bought a copy of Eloquent Ruby for the theoretical and I’ve eyeballed a few projects to work on for the practical.

Blog more about Security

One of my primary functions at work is related to security, but I rarely blog about it. That needs to change.

Home Network

1) After moving, I have my servers in a temporary space. Complete the finished space and migrate all the hardware there. Parts are on order and I’m going to add to the breaker box soon!

2) Stand up a complete environment. I’m missing vCO, an IPAM solution, and monitoring. Yes, it’s just my home network, but if I can’t monitor a handful of devices, I can’t monitor hundreds or thousands.

Expand Puppetinabox

Two weeks ago I released my first solo software project, puppetinabox. I’ve laid out some enhancements for it and I’m sure there are deficiencies I’m not aware of. I need to practice some good software development patterns both for myself, and if I want it to be used by others.

Propose a VMworld Talk

Last year, I proposed an Auto Deploy talk. It was not accepted. I won’t make it a goal to have an accepted talk – I have no control over it, after all – but I’d like to put a proposal in again. Topic undecided.

VCAP-DCA

Last year, I obtained by VCP5-DCV. This year, I need to at least get my VCAP-DCA. That means a new study guide, some time in the lab, and a plan to prep, study, take, and pass the exam.

 

These are goals that are important to me. I’m documenting the goals so I can hold myself accountable come next January and see how I progressed.

2014 Recap: How did I do?

Inspired by Scott Lowe’s goals for 2015, I’ve decided to be more rigorous about my own work-related goals. In this post, I’ll give a recap of my unofficial plans for 2014. I never wrote these down or otherwise formalized them, so they are a bit rough.

  • Start a blog

This one I achieved pretty early in the year. I started collecting material during the holiday and started publishing content on February. Grade: Pass

  • Post a Monday morning blog article every week

I had mixed success here. My initial aim really was to have one article a week and I made it for about 10 months, with the help of Jason (@hawkbox), who contributed some Hyper-V content during August. Things started to fall apart in November, though. I participated in the 30in30 challenge for November and didn’t quite make the mark, and it got me away from the weekly post. In December, I didn’t post weekly. So I failed, only hitting this about 70% of the time. Grade: C

However, I consider the results a success. I learned a few things. One, how difficult it is to get content ready every week without fail. I would have done much poorer if Jason had not helped me in August, as I was reaching burnout. Learning new things can be fun, but the pressure to do it continually does suck some of the enjoyment out. It also has a high cost on your free time, you need to spend a lot of it on the blog and it can intrude upon time with family and friends (you’ll note that blog content has been almost nil since the holiday season began, for this reason). Second, a weekly article isn’t needed. I managed to have 100 blog articles in 11 months, which is more than one per week. Some were really short, some very lengthy technical articles, and some were opinion pieces. People found the articles and I get a note from readers once in a while. Thank you all for reading, it really makes it worthwhile.

Even though I missed my original mark, I’ll regrade it as a B as I met the real, unwritten goal – create helpful content and post it on my blog frequently.

  • Learn Puppet

On this goal, I did very well. I wrote some 35+ articles, created three forge modules, and it spawned a project ‘Puppetinabox’. It also had some unrecognized synergy with using and learning Git, which I now feel adept with. I still have a lot of things to learn about Puppet, but my efforts clearly paid off. Grade: A

  • Present publicly

A goal I added midway through the year was to present something publicly. It didn’t matter what, but it had to be in front of real live human beings. I had done an Auto Deploy Deep Dive on the vBrownBag podcast earlier in the year and loved it. A podcast can make you nervous, but no-one can see you and you can’t see the attendees. I wanted to really push myself as I know I’m not good at public speaking. I ended up giving two public presentations. The first was a Virtual Design Master followup at the annual Indianapolis VMUG conference in July and the second was about DevOps for SysAdmins in November at a regular VMUG meeting. I had a lot of fun with both and I think I got past much of my stage fright. I also presented with Byron Schaller both times, who really helped with getting the presentations together. Of course, both presentations were to small groups. I had applied to give my Auto Deploy presentation at VMworld and presenting to (hopefully!) a few hundred people would have been a much different experience. There’s always next year! Grade: B+

For someone without a solid set of goals for the year, I think I did fairly well! I’m going to try and improve on this for 2015 by documenting the goals publicly and posting them here. Stay tuned.

Introducing ‘puppetinabox': bootstrap a lab setup with Puppet

Over the past few days, I’ve been working on a project. I call it puppetinabox and it includes a curated collection of forge modules and user repositories. If you have an existing Linux OS template and basic skills with linux and git, you can quickly deploy a network managed by puppet and r10k. This curated collection can be used as is, to learn Puppet or stand up a basic network, or fork the code and start customizing your network, using it as the foundation for a more complex configuration.

This project grew out of the 12 Days of Commitmas and my own desire to puppetize my home network. Over the holiday break, there was a lot of streaming media going on and I started to see failures on my services. Refreshing the services, which were entirely too coupled on mostly one VM, was looking pretty daunting. Puppetizing the network was slightly daunting, but far preferable to doing it by hand. I decided to put what I had learned and practiced to good use and thus, puppetinabox was born!

Puppetinabox includes everything required to provide puppet, puppetdb, r10k, dns and dhcp services, a yum repository, and a build server. The only thing you need to provide is a gateway device and you have a functional network. If you already have a working network and you want to puppetize it, never fear – you can tweak the provided material to fit or use puppetinabox to start refreshing the services one at a time.

I created the puppetinabox GitHub organization to house all the repositories. You can read the documentation here. I’d love to hear what you think, whether this will help you or what improvements might make it better. Let me know in comments, on twitter, or as a GitHub issue. If anyone is graphically inclined, I could really use a nice looking avatar for the organization, too!

If you’d like some more information, I presented on the 1/15/2015 vBrownBag DevOps Series. Watch the video and check out the slides!

Puppet rspec tests with Hiera data

I’ve covered puppet unit tests with rspec and beyond before. What if you need to go even further and test data from hiera? There’s a way to do that with rspec as well, and it only requires a few extra lines to your spec config – plus the hiera data, of course.

Use hiera in your class

We’ve covered a number of ways to use hiera in your class. You can use hiera lookups (hiera(), hiera_hash(), etc.) and automatic parameter lookups with classes. We’ll look specifically at hiera_hash() and the create_resources() it is commonly paired with. You cannot simply test that create_resources() was called because you need to know the resulting title of the generated resource. Here’s a simple DHCP profile class I created:

class profile::dhcp {
  # DHCP service and host reservations
  include dhcp::server
  $dhcp_server_subnets = hiera_hash('dhcp_server_subnets', undef)
  if ($dhcp_server_subnets) {
    create_resources('dhcp::server::subnet', $dhcp_server_subnets)
  }

  $dhcp_server_hosts = hiera_hash('dhcp_server_hosts', undef)
  if ($dhcp_server_hosts) {
    create_resources('dhcp::server::host', $dhcp_server_hosts)
  }
}

Continue reading

Updating your git fork from the original repo

Over the 12 days of #Commitmas, you may have submitted a Pull Request (PR) to Matt Brender’s 12-days-of-commitmas repository. I’ve done the same thing. Once the PR is merged, your fork is out of sync with the main repository. If you do more development on your fork, you may start to run into conflicts when you submit the next PR.

Adding additional remotes

When you set up your fork, github (bitbucket, etc.) helpfully provides you with the repository’s remote information in HTTPS or SSH format (see Jonathan Frappier’s article on forking for more information). After you clone your fork’s repo, you’ll have a single remote called origin. You can see your remotes with git remote -v.

git remotes fig 1

We can handle PRs through the github interface, but that doesn’t help us keep things in sync (well, you could delete your fork and make a new one, but that’s a lot of work and wipes out any pending changes you’ve made, so we’ll consider that unfeasible). The best way to manage this is to add the original repo as another remote. The remote can be called anything you want. We will call it upstream, a common pattern with github users.

git remotes fig 2

As you may remember, you provide the keyword origin to your push statement. That’s not a magic word, it’s referring to the remote to which you are pushing your commit history to. Most of the time you don’t have rights to push to someone else’s repo, but git push upstream <branch> is a legitimate git command. You can also use the upstream remote with other commands.

Fetch and Pull

You can fetch the latest information from the remove with git fetch upstream. This will pull down all references and branch names. You can then git pull upstream master to fast-forward apply all changes in the upstream’s master branch to your current branch. I made sure to make sure I’m in my own master branch before I began, but you could do this in any branch – great if you started some edits based off master and a few PRs have been applied since.

git remotes fig 3

Once you’re done, don’t forget to push changes to YOUR remote. You don’t technically need to do it, but if you work on another machine, you’d have to perform the whole clone/remote add/fetch/pull process again.

git remotes fig 4

Now you’re able to see all the changes made in the repo and you’re able to base new branches off the up-to-date contents of your master branch!

Using git amend for quick corrections

Now that you know how to rewrite your git history with rebase, let’s take a look at amending your commits. An amend is much simpler and, for the case of typos or other minor corrections you discover immediately after a commit, sometimes much more appropriate.

For the setup, we’re going to add some markdown to the 12-days-of-commitmas repository’s README.md, but with incorrect tags. A URL is of the format “[text to display](url://to/visit)”. It’s easy to get this backwards or to use the same tags on both sides of the URL. Here, I’ve used square braces for the URL and commited it anyway. Whoops!

git amend fig 1

Continue reading

Using git rebase to rewrite history

As part of The 12 Days of #Commitmas, we’re all practicing our git-fu. I’ve learned a bit about rebasing that I’d like to show you now.

Why are we rebasing?

The definition, from man git-rebase, is “Forward-port local commits to the updated upstream head.” Clear as mud, if you ask me. Another way of putting it is that a rebase moves a branch to a new base commit. Let’s say you create a new branch from master on the 1st of the month and make two changes, then a week goes by. A half dozen changes have been made to master and your branch doesn’t have it. You can rebase your commits against the current master rather than the original master. Underneath the hood, git is rewriting the project history to achieve all of this. All the commits are actually new. This means the checksums for commits are unique (we’ll look at why that matters in a moment).

This is great for integrating your feature against the master and maintaining a linear history. There’s another reason we might want to rebase, though – maintaining a clear history.

Continue reading