In the last blog we looked at PCE for centralized path-computation and PCEP as a communication protocol between PCE and PCC.We also looked at brief demo of PCE sending ERO’s (IP or SR Node labels) to the PCC(Head end). In this Blog post we will particularly try to focus at Traffic Engineering (SR-TE) aspects of […]
The post Yet Another Blog About Segment Routing, Part3: SR-TE appeared first on Packet Pushers.
In the last blog we looked at PCE for centralized path-computation and PCEP as a communication protocol between PCE and PCC.We also looked at brief demo of PCE sending ERO’s (IP or SR Node labels) to the PCC(Head end). In this Blog post we will particularly try to focus at Traffic Engineering (SR-TE) aspects of […]
The post Yet Another Blog About Segment Routing, Part3: SR-TE appeared first on Packet Pushers.
The Go test coverage implementation is quite ingenious: when asked to, the Go compiler will preprocess the source so that when each code portion is executed a bit is set in a coverage bitmap. This is integrated in the go test tool: go test -cover enables it and -coverprofile= allows you to write a profile to then inspect with go tool cover.
This makes it very easy to get unit test coverage, but there's no simple way to get coverage data for tests that you run against the main version of your program, like end-to-end tests.
The proper fix would involve adding -cover preprocessing support to go build, and exposing the coverage profile maybe as a runtime/pprof.Profile, but as of Go 1.6 there’s no such support. Here instead is a hack we've been using for a while in the test suite of RRDNS, our custom Go DNS server.
We create a dummy test that executes main(), we put it behind a build tag, compile a binary with go test -c -cover and then run only that test instead of running the regular binary.
Here's what the rrdns_test.go file looks like:
// +build Continue reading
A situation you could really face:
Would you run this search? It’s a difficult question, but ultimately Continue reading
First step: a joint offering with Affirmed Networks.
The post Worth Reading: Learning QoS from RFCs appeared first on 'net work.
Ahhh, a new year.
While 2015 was certainly a big year for us as we joined the Red Hat family, in many ways we’re still right at home with our roots deeply planted in the ways of open source. That means we’re listening (as we always do) to our customers and community members about what what they see as their problems to solve and goals to achieve in the year ahead.
Here’s a bit of what we see:
DevOps! It’s everywhere! If ever there was a buzzword to officially deserve the “jumped the shark” label, this might just be it. General understanding of DevOps as a practice that can potentially accelerate IT project delivery has permeated most IT departments, from the smallest of businesses to the most daunting of large enterprises, sometimes from the grassroots level, and sometimes from the top down.
Thankfully, along with this recognition, people are increasingly recognizing that DevOps isn’t simply tools -- that building a healthy organizational culture is a significant part of their journey. Many organizations are beginning to recognize that it’s not a lightswitch, or a flat-out reorg. The idea that small wins can matter when bringing DevOps practices into your Continue reading
Ahhh, a new year.
While 2015 was certainly a big year for us as we joined the Red Hat family, in many ways we’re still right at home with our roots deeply planted in the ways of open source. That means we’re listening (as we always do) to our customers and community members about what what they see as their problems to solve and goals to achieve in the year ahead.
Here’s a bit of what we see:
DevOps! It’s everywhere! If ever there was a buzzword to officially deserve the “jumped the shark” label, this might just be it. General understanding of DevOps as a practice that can potentially accelerate IT project delivery has permeated most IT departments, from the smallest of businesses to the most daunting of large enterprises, sometimes from the grassroots level, and sometimes from the top down.
Thankfully, along with this recognition, people are increasingly recognizing that DevOps isn’t simply tools -- that building a healthy organizational culture is a significant part of their journey. Many organizations are beginning to recognize that it’s not a lightswitch, or a flat-out reorg. The idea that small wins can matter when bringing DevOps practices into your Continue reading
We’re now going to take a look at grabbing a file from the hard drive written in YAML syntax. YAML is arguably the most human readable data serialization format which makes it really easy for coders and non-coders alike to work with.
We’re going to build on the last Jinja2 example. Instead of creating the templates and variables directly in python. We’re going to load them instead from files on our computer.
This may seem like a small detail, but this allows us to deconstruct the building of our configurations, meaning that different people can be responsible for different components of the configuration. As with anything, if you can break a complex process down into several smalller less complex tasks, the whole thing starts to feel easier.
We’ll start by loading the required libraries
import yaml
from jinja2 import Environment, FileSystemLoader, Template
Essentially, this set’s the path which will define the directory where the templates will be loaded from. In this case, I’m setting it to load from the same directory.
ENV = Environment(loader=FileSystemLoader('./'))