My Openstack CLI clients stopped working, this is how I fixed them

Recently I have been working a lot on a backup solution at work, which has been a painful experience to say the least. Why? Simply because there is no solution that meets my ideal requirements. These are pretty precise: Open Source Openstack Swift as a backend File level restores Scalable Lightweight An idiot must be able to restore a file Not a source of truth about my infrastructure Automated restore testing A nice bonus would be volume level backups of Openstack Cinder.

It’s a process that strikes fear into the hearts of Sysadmins everywhere. This weekend I finally got round to upgrading the Openstack cluster in my lab to Kilo. As I have no spare machines lying around (Intel NUC/HP Microserver/similar donations welcome) I did it in place. Did it go well? Mostly... My base was a Juno install from Packstack. If your Juno install was different, then YMMV, but the idea should transfer.

Currently all the major exercise GPS units are proprietory. I think we need an open alternative.

I am a fan of Gitlab. While Github is great, and I use it heavily, one should never be 100% reliant on the whims of a for-profit company. After all, their agenda is not the same as mine and could chang in the future. I also use it for projects at work where we do not necessarily want to allow public access. Sending emails however is a little complicated. A good email server needs DNS and and SMTP properly configured.

I recently got myself a new saddle. The one that came with my Felt F95 was starting to rattle on its rails which was driving me, and my riding buddies, insane. We are all engineers, so OCD is a shared problem we have. Anyway, while scanning through my favourite non-local bike shop I came across the Selle Italia Q-Bik Flow, for only €15. Buying something as personal as a saddle online is always a risk, but I figured that at the price it was not that much of a risk.

I'm back playing with Openstack again. The day job once again Openstack based, and as of last week my lab is all Openstack too. While oVirt is awesome, I felt like a change. Anyway, the meat of today's problem comes from the day job. I have some instances deployed via heat that have multiple Cinder volumes attached to them, these then need to be mounted in a certain way. The syntax for attaching a cinder volume to an instance is:

Installing a Puppetmaster is a bit of a chicken-egg problem. We want to have our environment as automated and slick as possible, but we currently have no tools installed to to so. So what do we actually need to install and configure for our Puppet master: Puppet Hiera R10k Git This is the minimum, from this it can go ahead and dogfood itself in my prefered fashion. I do this with a bit of bash that I threw together during a meeting.

As promised in the previous post, I thought I would share my Sensu/Puppet config. This is based on the Puppet infrastucture I decribed here so everything goes into Hiera. For reasons best known to me (or my DHCP server) my Sensu host is on 192.168.1.108. First your Puppetfile tells R10k to install the Sensu module, plus a few more: mod 'nanliu/staging' mod 'puppetlabs/rabbitmq' mod 'sensu/sensu' mod 'redis', :git => 'https://github.com/chriscowley/chriscowley-redis.git', :commit => '208c01aaf2435839ada26d3f7187ca80517fa2a8 I tend to put my classes and their parameters in Hiera.

Talking to a few people there seems to be a little confusion over the various stages in the deployment pipeline. Specifically there seems to be a little confusion over 3 things: Orchestration Provisioning Configuration Management These seem to have got rather mixed up of late. I will put the blame squarely at the doors of marketing departments because, well, why not… I should probably add that these are my opinions. It is all a little grey, but this makes sense to me.