It's been a while since I last updated my blog. As I'd like to share more in 2020, I thought that a good first post might be to update you all on what I've been working on the last 5 years.
It's 2017 and my blog was starting to look a little dated so I decided it was time for a face-lift. While I was at it, I overhauled the way I deploy my blog too.
It's 2017 and my blog was starting to look a little dated so I decided it was time for a face-lift. While I was at it, I overhauled the way I deploy my blog too.
This post is a Zombie that I'm resurrecting from my drafts. I"m not doing any Java these days, but hopefully this post might be useful to somebody
In my quest to get better code coverage for the OVSDB project in OpenDaylight I started to look at increasing coverage for the REST API. It's pretty difficult to test this in an efficient way (lines of code) and frameworks like Robot would have been easier to use. The disadvantage with using an external test framework is that code coverage (using a plugin like JaCoCo) would not be logged. Therefore I harnessed my Junit-Jitsu and found a solution that lives in the JVM
Lets take a very simple example REST API
GET, PUT: /v2/foo
The solution uses the following components
The parameterized runner will run run a test multiple times given a bunch of parameters. This way we can write one test, specifiy our parameters in YAML and let JUnit do the hard work!
Here's a sample YAML file:
---
- name: testGetAllFoo
operation: GET
uri Continue readingThis post is a Zombie that I'm resurrecting from my drafts. I"m not doing any Java these days, but hopefully this post might be useful to somebody
In my quest to get better code coverage for the OVSDB project in OpenDaylight I started to look at increasing coverage for the REST API. It's pretty difficult to test this in an efficient way (lines of code) and frameworks like Robot would have been easier to use. The disadvantage with using an external test framework is that code coverage (using a plugin like JaCoCo) would not be logged. Therefore I harnessed my Junit-Jitsu and found a solution that lives in the JVM
This post is a Zombie that I'm resurrecting from my drafts. I"m not doing any Java these days, but hopefully this post might be useful to somebody
In my quest to get better code coverage for the OVSDB project in OpenDaylight I started to look at increasing coverage for the REST API. It's pretty difficult to test this in an efficient way (lines of code) and frameworks like Robot would have been easier to use. The disadvantage with using an external test framework is that code coverage (using a plugin like JaCoCo) would not be logged. Therefore I harnessed my Junit-Jitsu and found a solution that lives in the JVM
Netlink is a Linux Kernel interface that is used to talk Networking between Kernel processes, or from userland to Kernel processes. This post documents how I tamed Netlink and make working with it in Golang easier.
If you want to create an interface, set an MTU, set an IP address etc... on a Linux machine then you have to talk Netlink to do it. For Golang, there are a number of libraries, but this one seems to be gaining a lot of traction recently. Honorable mentions go to Tenus and Docker's libcontainer.
Now, this library is good, but it isn't complete and some of the behavior I need is missing. So how does one go about implementing it you might ask?
Here's my process:
iproute2 source codeThe iproute2 utility is insanely useful - it replaces ifconfig and route for those with memories long enough.
In my case, the feature I wanted was here and I could take a look at the exact message structure required :)
Once I'd written my tests and code, I wasn't surprised to see that things were not working.
strace will get you part of the way, but it's Continue reading
Netlink is a Linux Kernel interface that is used to talk Networking between Kernel processes, or from userland to Kernel processes. This post documents how I tamed Netlink and make working with it in Golang easier.
If you want to create an interface, set an MTU, set an IP address …
Netlink is a Linux Kernel interface that is used to talk Networking between Kernel processes, or from userland to Kernel processes. This post documents how I tamed Netlink and make working with it in Golang easier.
I've been thinking about running Docker on CoreOS and Project Atomic lately... While the deployment model would be pretty different to what we are used to, I have 50% of the work already done in docker-ovs so I was interested to see if my containers would work on a system with the Open vSwitch kernel module loaded...
As I'm a Mac User, I use boot2docker for all my docker-related things. It's also pretty easy to change the kernel config to allow the Open vSwitch module to be loaded.
Clone my fork
git checkout openvswitch
Build the iso
docker build -t boot2docker . && docker run --rm boot2docker > boot2docker.iso
Run boot2docker with the new iso
boot2docker destroy
boot2docker init --iso="`pwd`/boot2docker.iso"
boot2docker up
Load the Open vSwitch kernel module
boot2docker ssh
sudo modprobe openvswitch
exit
Run an Open vSwitch container
docker run -t -i --privileged=true davetucker/docker-ovs:2.1.2 /bin/sh
export OVS_RUNDIR=/var/run/openvswitch
sed -i s/nodaemon=true/nodaemon=false/g /etc/supervisord.conf
supervisord
Test it out
ovs-vsctl add-br br0
ovs-vsctl show
# This didn't work before
ovs-dpctl show
This isn't a thorough test. I'd like to create some traffic and see the Continue reading
I've been thinking about running Docker on CoreOS and Project Atomic lately... While the deployment model would be pretty different to what we are used to, I have 50% of the work already done in docker-ovs so I was interested to see if my containers would work on a system with the Open vSwitch kernel module loaded...
I've been thinking about running Docker on CoreOS and Project Atomic lately... While the deployment model would be pretty different to what we are used to, I have 50% of the work already done in docker-ovs so I was interested to see if my containers would work on a system with the Open vSwitch kernel module loaded...
It's now been 3 months since I transitioned from Networking to Software. This is a retrospective piece on my reasons for giving up on Networking.
You might be reading this thinking:
"another networking guy moving to software... network engineering is doomed".
If you are, stop thinking right now. There is one important thing about my story that is very different. I've been writing software for longer than I have been doing networking albeit not in a professional capacity. Software Engineering is where my passion lies right now and let me explain why...
DevOps for Networking is still, very slowly, becoming reality. Elsewhere DevOps is very much in full swing. Tools like:
Vagrant, Packer, Puppet, Chef, SaltStack, Ansible, Fig, Docker, Jenkins/TravisCI, Dokku, Heroku, OpenShift (the list goes on)...
have redefined how I work and being in an environment where I can build things with them day to day is a dream come true for me.
I get gersburms just thinking about building Continous Integration/Continous Delivery Pipelines, Automated creation of Dev/Test environments and Configuration as Code.
Software-Defined Networking was the turning point in my career. It enabled me to make the switch in career paths Continue reading
It's now been 3 months since I transitioned from Networking to Software. This is a retrospective piece on my reasons for giving up on Networking.
I was finally catching up on a number of posts I'd saved to read later and noticed the prevalent use of "Northbound" and "Southbound". I'm now starting to question whether these terms are necessary or accurate.
Let's start with the Oxford English Dictionary definition of these terms.
northbound | ˈnɔːθbaʊnd | adjective travelling or leading towards the north: northbound traffic.
southbound | ˈsaʊθbaʊnd | adjective travelling or leading towards the south: southbound traffic | the southbound carriageway of the A1.
As our interfaces are static and can't travel one can assume the intent of these adjectives in our context is to indicate that the interfaces are leading in the specified direction.
Categorizing an API by directionality is rather perplexing IMHO.
Specify directionality without a reference point is misleading For example, OVSDB is a northbound API for Open vSwitch but southbound API for an SDN controller.
For SDN controllers, there are two types of interfaces:
User-Facing or Application-Facing (formerly Northbound)
This API is designed to expose higher-order functions in such a way that they can easily be consumed by humans and programmers.
By this logic, we can include any "
I was finally catching up on a number of posts I'd saved to read later and noticed the prevalent use of "Northbound" and "Southbound". I'm now starting to question whether these terms are necessary or accurate.
It's now been 3 months since I transitioned from Networking to Software. This is a retrospective piece on my reasons for giving up on Networking.
I was finally catching up on a number of posts I'd saved to read later and noticed the prevalent use of "Northbound" and "Southbound". I'm now starting to question whether these terms are necessary or accurate.
Tom Hollingsworth wrote a great post on whether or not we need to redefine "Open". My response was too long for a comment, so here it is!
The first item is just a point of clarification. While the terms "Open Source" and "Free Software" are often used interchangeably there is a difference.
The two terms describe almost the same category of software, but they stand for views based on fundamentally different values. Open source is a development methodology; free software is a social movement. - Richard Stallman
You can read the full article here but the TL;DR version is that while a high percentage of Open Source software is Free Software, the definition of Open Source is less strict about guaranteeing freedoms.
...with that out of the way, let's move to "open"
I like the Wikipedia description of "openness":
Openness is an overarching concept or philosophy that is characterized by an emphasis on transparency and free unrestricted access to knowledge and information as well as collaborative or cooperative management and decision making rather than a central authority. - Wikipedia
It highlights some key terms which our "open" things should be adhering Continue reading
Tom Hollingsworth wrote a great post on whether or not we need to redefine "Open". My response was too long for a comment, so here it is!