TIL: Find all merged branches
03 Jan 2018i.e. branches that can be deleted:
git branch --merged
Usually when using Ansible, it will execute the modules specified in the playbooks on the remote host using Python. The Python binary is not selected using the usual /usr/bin/env python
but instead is set in the ansible_python_interpreter
inventory variable. This variable defaults to /usr/bin/python
.
Most of the time when managing Linux hosts, this works perfectly fine, but when using many network automation modules the modules are executed locally on the host where Ansible is running (ansible_connection = local
). On macOS, this is particularly confusing if Python is installed by Homebrew as you will have two Python binaries - one in /usr/bin/python
and one in /usr/local/bin/python
with the latter being preferred by the shell and the first being selected by Ansible. This leads to the confusing situation where Ansible runs will fail with errors about missing Python dependencies but pip list
shows them already installed.
The easiest solution is to setup ~/.ansible.cfg like the following:
Just going to leave this here for when future me can’t remember how to do this.
The logical model within a Cisco ACI fabric is a bit different to what most network administrators are familiar with, so it is often useful to visualise what is going on in a diagram. Usually this is done manually on a whiteboard (because all engineers love whiteboards!), however it would be great to generate these diagrams quickly and in an automated way. So I’ve started on a small tool, aci-diagram, written in Python to do just this.
I have chosen to base the tool on the acitoolkit, which (among other things) is intended to present a simplified object model compared to ACI’s underlying rich and complete model (which is also available through the native REST API if needed).
Using the tool is very simple, the login (username), password, URL (for the APIC) and output filename are required. By default it will create a single diagram that includes all of the tenants on the system but, as that could be quite large, you can use the -t
option to restrict processing to a subset of tenants. For example, this will generate a diagram for a single tenant called “pepsi”:
… and here is the generated diagram:
Similarly, diagrams for multiple tenants can be generated:
… and here is the generated diagram:
#Behind the scenes As mentioned earlier, I am using the acitoolkit for interrogating the ACI system, and the diagrams are based on the toolkit’s simplified object model. At this stage the tool is focused on the application topology related objects in the model:
Once the tool has gathered the objects through the toolkit, it traverses through the hierarchy and adds nodes and edges to a GraphViz graph using the pygraphviz Python wrapper, e.g.:
Finally, GraphViz is called on to draw the graph into the output file, so any format that your GraphViz installation is compiled with is available, e.g. PNG, JPG or PS.
#Future work There is clearly plenty of scope for future work such as expanding the scope of the object model that is supported to include, for example, physical objects such as interfaces, switches and line cards. Currently there is a limitation which means that relationships across tenants will not be drawn in the graph. It would be good to address this, but I think it will take some work in the acitoolkit itself.
As always, I’m keen to hear your feed back on twitter where I am @chrisgascoigne or you can fork and contribute to the code on GitHub.
##Introduction As I mentioned previously, I recently decided to restart my blog (not that I ever wrote particularly much anyway) and initially I thought I’d just restart it on Tumblr where it was previously. However, this is meant to be a technical blog and I expect to be posting code or configuration snippets fairly regularly and I’ve never found Tumblr (or most other blogging tools) to handle this particularly well so I decided to see what other options were available.
After a short amount of searching, I found a number of recommendations to use Jekyll and host the blog on GitHub Pages. This seems like a great solution - GitHub Pages allows me host the entire site for free, while Jekyll allows me to maintain the entire site offline in a local Git repository, with the ability to work on it offline (such as on a plane, like I am now) and just push to GitHub whenever I want to publish. Despite how simple Jekyll is, I further came across Poole, which makes things even easier by bundling up some sample content and a couple of pre-built themes (Hyde and Lanyon).
##Getting Started The first thing you need to do is create a GitHub account if you don’t already have one, so head on over there and do that at GitHub.
Next, you need to fork your chosen starter project (Hyde, Lanyon or Poole) into your account. Just browse to the repository of your choice on GitHub, and click the “Fork” button near the top.
Once you’ve cloned the repository, you need to go into its settings (look on the right hand side of the repository’s page) and rename it to <username>.github.io (replace “username” with your own).
Now you can clone the repository onto your local machine (replace “username” with your own):
Make some initial changes to the sample project - I recommend starting with _config.yml and updating the title, description and author information.
After you’ve made your initial changes, commit them to your repository:
And finally, push your repository to github so that it is live:
Now browse to http://username.github.io/ and see your new blog live.
##Posting The process of creating a new post is relatively simple. In this instance I will also go through the workflow of using a draft post.
To create drafts, first create a _drafts folder in your project, then create a file for your draft post. For example, create the following in _drafts/getting-started.md:
To preview this locally, simply start the jekyll server from your project directory:
Then open http://127.0.0.1:4000/ in your browser.
Once you’re happy with your new post, simply move the .md file into the _posts folder, and rename to <year>-<month>-<day>-post-title.md, e.g. _posts/2014-11-30-getting-started-with-jekyll.md and then commit and push your git repository to github.
##Using a custom domain name If you’re like me, you won’t want to use “username.github.io” for your blog, you’ll want to use a custom domain so that you can move it somewhere else when something new and shiny comes along.
To use your own custom domain, simply add a CNAME record to your domain pointing to “username.github.io”. For example in my esquilax.org domain, I have the following record:
Then, in your _config.yml update the “url” line with the full url of your custom domain, e.g.:
Commit your changes and push to github:
##Summary Hopefully this post will help you understand Jekyll and GitHub Pages, and allow you to get started with this new approach to publishing.
As always, please send me any feedback or questions on twitter, where I am @chrisgascoigne