Bashrc: Gerrit

Gerrit is the code review and git hosting tool used by OpenStack. It is common courtesy to mark a change 'work in progress' when you have submitted it but it is not ready for others to review. Others will see the work in progress bit is set and not waste time reviewing patches that are not ready yet.

The 'git review' tool is good for submitting changes, but then I have to go to the web ui to mark a change as wip. I can use gertty for this, but again that means going and searching it out.

I have added the following function to my .bashrc:

gerrit () {

    if [ $1 = "wip" ]; then
        commit=`git show | grep -m1 commit | cut -d " " -f 2 2>/dev/null`
        if [ -z $commit ]; then
            echo "Not in git directory?"
            return 1
        fi
        gerrit review $commit --workflow -1
        return $?
    fi 
    username=`git config gitreview.username`

    ssh -o VisualHostKey=no -p 29418 $username@review.openstack.org gerrit $*
}






 

This function enables some pretty cool features. It takes as arguments any arguments that the gerrit ssh command line interface takes. Meaning you can do things like these:


$: gerrit ls-projects | grep puppet
openstack-infra/puppet-apparmor
openstack-infra/puppet-dashboard
openstack-infra/puppet-github
openstack-infra/puppet-httpd
openstack-infra/puppet-jenkins
openstack-infra/puppet-kibana
openstack-infra/puppet-pip
openstack-infra/puppet-storyboard
openstack-infra/puppet-vcsrepo
openstack-infra/puppet-vinz
openstack-infra/puppet-yum
openstack-infra/puppet-zuul
openstack/tripleo-puppet-elements
stackforge/puppet-ceilometer
stackforge/puppet-ceph
stackforge/puppet-cinder
stackforge/puppet-designate
stackforge/puppet-glance
stackforge/puppet-heat
stackforge/puppet-horizon
stackforge/puppet-ironic
stackforge/puppet-keystone
stackforge/puppet-manila
stackforge/puppet-monasca
stackforge/puppet-n1k-vsm
stackforge/puppet-neutron
stackforge/puppet-nova
stackforge/puppet-openstack
stackforge/puppet-openstack-cloud
stackforge/puppet-openstack-specs
stackforge/puppet-openstack_dev_env
stackforge/puppet-openstack_extras
stackforge/puppet-openstacklib
stackforge/puppet-sahara
stackforge/puppet-swift
stackforge/puppet-tempest
stackforge/puppet-trove
stackforge/puppet-tuskar
stackforge/puppet-vswitch
stackforge/puppet_openstack_builder
$: gerrit -h
gerrit [COMMAND] [ARG ...] [--] [--help (-h)]

 --          : end of options
 --help (-h) : display this help text

Available commands of gerrit are:

   ban-commit           Ban a commit from a project's repository
   create-account       Create a new batch/role account
   create-group         Create a new account group
   create-project       Create a new project and associated Git repository
   flush-caches         Flush some/all server caches from memory
   gc                   Run Git garbage collection
   gsql                 Administrative interface to active database
   ls-groups            List groups visible to the caller
   ls-members           List the members of a given group
   ls-projects          List projects visible to the caller
   ls-user-refs         List refs visible to a specific user
   plugin              
   query                Query the change database
   receive-pack         Standard Git server side command for client side git push
   rename-group         Rename an account group
   review               Verify, approve and/or submit one or more patch sets
   set-account          Change an account's settings
   set-members          Modify members of specific group or number of groups
   set-project          Change a project's settings
   set-project-parent   Change the project permissions are inherited from
   set-reviewers        Add or remove reviewers on a change
   show-caches          Display current cache statistics
   show-connections     Display active client SSH connections
   show-queue           Display the background work queues
   stream-events        Monitor events occurring in real time
   test-submit         
   version              Display gerrit version

See 'gerrit COMMAND --help' for more information.

We also inspect the first command to see if it is 'wip.' This allows us to create new commands to the gerrit cli without changing any code or having access to the gerrit server. What I've added is the 'wip' command which inspects the local git repository for the latest change, and marks it as wip with gerrit. This changes my workflow to look like this:



$: git review
$: gerrit wip

This is much shorter, more unixy, and doesn't require me to hop out of the terminal. Future improvements would be to identify if you are in a stack of changes and wip all of them.

Leaving Blogger

It's time to join the future and host my own blog. I'm also going to do the regular stuff of evaluating technologies and picking one, developing tools that other people have developed, etc.

I've debated doing this many times. I've always felt that I didn't want to be that person who only blogs about blogging. I feel after a couple years of pretty consistent blogging, that I won't totally ignore my blog after putting a lot of effort into it. Plus this is an excuse to build a website, something I am embarrassingly weak in.

I'm pretty sure the next location of my blog will be http://spencerkrum.com but I'm not entirely sure.

Right now the plan is to move to pelican because python and restructured text are both technologies that have crossover with OpenStack, and I like that. What I may end up writing is tooling to pull my old posts out of Blogger.

I have no idea if blogger will let me put a redirect in for my subdomain on their domain. I have to think that literally no one at google works on this now right? After reader went away I was sure this would get the axe and yet it remains...

Guest Post on Puppet-a-day

Today I have been honored to post a guest post on the puppet-a-day community blog. You can find my post here.


Big thanks to @daenney for making the puppet-a-day thing go.

Future posts/projects

There are a list of projects I want to do or see get done, and posts I'd like to write. For lack of better place, I'll simply post the names here and we'll see where it goes.

• Puppet-kick replacement
• Puppet kick really is super dead
• need new daemon/maybe new command line utility
• some kindof daemon that listens for http kicks and fires puppet
• could re-use the kick api, or bold new territory
• /api/status
• can return:
• 'puppet running'
• 'puppet not  running'
• 'puppet last run was: <bool: success> <bool: changes>'
• 'puppet admin disabled'
• /api/run
• async
• can fire a run
• can fire a run against an environment
• maybe noop?
• Fuck on im not dealing with auth.conf. Maybe just a list of dns or fingerprints that are allowed to fire a kick?

• PuppetBoard-like web applications
• CA signing/revoking web appication
• DB-backed, ENC
• Barbican integration
• Use openstack-barbican
• Secret storage as a backend for hiera
• Certificate Authority api, possibly become ref implementation of external CA interaction for puppet
• Ceph Continuation
• continue exploration of ceph tool
• AFS exploration
• continue exploration of AFS/Kerb
• Terraform w/ OpenStack
• It is so freaking close, and yet
• Hodor
• hodor is a dumb script I wrote around nova to get work done 
• GPG mapping
• games i've played with using javascript to visualize the gpg web of trust

These will be done(or not done) in any random order. If you want to see one get done give me some feedback.

Cool diagram tool

So tehmaze wrote a sweet command line graphing utility.

Jason Dixon retweeted this on twitter:

Which led me to do this:

Which is a modified version of what Jason Dixon taught me in this video from pdx devops days:

Diagram: https://github.com/tehmaze/diagram
My line: curl -s 'http://graphite.openstack.org/render/?target=sum(stats_counts.gerrit.event.*)&format=json&from=-24hrs' | json_pp | grep ',' | grep -v \] | tr -d "," | diagram

Puppet Conf 2014!

Puppet Conf is next week. I'll be attending with Krinkle and Blkperl. We will have a table and books to sign at the 'Meet the Authors' event on the first evening.

Hope to see you all there!

Puppet Manifests and operating system updates

This is a post about my opinion on how we should be using the params.pp pattern. It originated from review here.

This is what the code used to look like:

$ruby_bundler_package = 'ruby-bundler'

It worked great on precise. It still does. However, when trusty came out, the changed the name of the package to bundler. This broke the above puppet code.

The fix was simple:


# will install ruby-bundler for all Debian distros
# or for Ubuntu trusty
if ($::operatingsystem == 'Debian') or ($::lsbdistcodename == 'trusty') {
  $ruby_bundler_package = 'bundler'
}
else {
  $ruby_bundler_package = 'ruby-bundler'
}


This is made a little more complicated because it handles Debian in addition to Ubuntu nodes.

However, there is a better way:

# will install ruby-bundler for Ubuntu Precise
# and bundler for Debian or newer Ubuntu distros
if ($::lsbdistcodename == 'precise') {
  $ruby_bundler_package = 'ruby-bundler'
}else {
  $ruby_bundler_package = 'bundler'
}


Instead of adding those names to an ever expanding case statement, this special cases the precise machines. In addition to being shorter, this better future-proofs the code. Inevitably this will be run on Utopic or later Ubuntu versions, and using the trusty package name by default will automatically work on these newer versions.

Now, generally it is best practice in case statements to fail on default, using the else statement like this is a violation of the spirit of that rule. But if statements like this are common in params.pp and will save you time in the future.

You can ask yourself as a follow up, "where else did i special case the new version of the operatingsystem, instead of special casing the old version."