lindsay

Author Archives: lindsay

New Year, New Home

We have left the Bay Area, and headed North. We have moved to the Greater Seattle area - specifically the Eastside, between Bellevue and Redmond. We’ve given up the old apartment in San Francisco for a larger, nicer house…for a lot less in rent. A lot fewer bars & restaurants, a lot more trees, parks and lakes.

But Why?

The typical Bay Areas response is: “But why??? It rains all the time in the Pacific Northwest!!!!”

A few things:

1. Yes, it rains more here than San Francisco, but not as much as people think. It’s not even in the top 10 cities in the US for annual rainfall. Boston, New York, Washington DC all receive more.

2. Rain is OK. In fact rain is good. You don’t get lush forests through irrigation. You also don’t get clean streets just from street sweepers. 

The main attractions for us are:

  • Much better lifestyle for us. It’s easy to go mountain biking, running, hiking, skiing here.

  • Much lower rent. Yes, rents have gone up a lot here, but it’s still much better value than San Francisco. I pay much less rent here, but I get a nice place, and the Continue reading

New Year, New Home

We have left the Bay Area, and headed North. We have moved to the Greater Seattle area - specifically the Eastside, between Bellevue and Redmond. We’ve given up the old apartment in San Francisco for a larger, nicer house…for a lot less in rent. A lot fewer bars & restaurants, a lot more trees, parks and lakes.

But Why?

The typical Bay Areas response is: “But why??? It rains all the time in the Pacific Northwest!!!!”

A few things:

1. Yes, it rains more here than San Francisco, but not as much as people think. It’s not even in the top 10 cities in the US for annual rainfall. Boston, New York, Washington DC all receive more.

2. Rain is OK. In fact rain is good. You don’t get lush forests through irrigation. You also don’t get clean streets just from street sweepers. 

The main attractions for us are:

  • Much better lifestyle for us. It’s easy to go mountain biking, running, hiking, skiing here.

  • Much lower rent. Yes, rents have gone up a lot here, but it’s still much better value than San Francisco. I pay much less rent here, but I get a nice place, and the Continue reading

CircleCI, Docker and Systemd

I have been battling to get the combination of CircleCI, Docker and systemd to play together. After much frustration, I have a workable solution. Machine Executor, privileged: true, cgroup passthrough, and disabling AppArmor.

Background: CircleCI for Ansible Linting & Checks

In the StackStorm team we use CircleCI with most of our repositories. We check things like code style checks, and run unit tests. With every Pull Request we trigger these checks, and checks must pass before merging. Some repos also use CircleCI for post-merge deployment steps.

We use Ansible and Terraform to manage some of our internal infrastructure. All configurations are stored in Git. All changes to that configuration must be submitted as a Pull Request. All PRs need approval, and all commit checks must pass. We use CircleCI to run these commit checks.

We run multiple checks, but for Ansible playbooks, they include using ansible-lint, and ansible-playbook --syntax-check. We then spin up a Docker container using CircleCI and run some of our playbooks twice, checking that it passes both times, and that the second run records no changes.

Here’s a snippet of some of our CircleCI configuration:

version: 2
jobs:
  build:
    working_directory:  Continue reading

CircleCI, Docker and Systemd

I have been battling to get the combination of CircleCI, Docker and systemd to play together. After much frustration, I have a workable solution. Machine Executor, privileged: true, cgroup passthrough, and disabling AppArmor.

Background: CircleCI for Ansible Linting & Checks

In the StackStorm team we use CircleCI with most of our repositories. We check things like code style checks, and run unit tests. With every Pull Request we trigger these checks, and checks must pass before merging. Some repos also use CircleCI for post-merge deployment steps.

We use Ansible and Terraform to manage some of our internal infrastructure. All configurations are stored in Git. All changes to that configuration must be submitted as a Pull Request. All PRs need approval, and all commit checks must pass. We use CircleCI to run these commit checks.

We run multiple checks, but for Ansible playbooks, they include using ansible-lint, and ansible-playbook --syntax-check. We then spin up a Docker container using CircleCI and run some of our playbooks twice, checking that it passes both times, and that the second run records no changes.

Here’s a snippet of some of our CircleCI configuration:

1
2
3
4
5
6
7
8
9
 Continue reading

CircleCI, Docker and Systemd

I have been battling to get the combination of CircleCI, Docker and systemd to play together. After much frustration, I have a workable solution. Machine Executor, privileged: true, cgroup passthrough, and disabling AppArmor.

Background: CircleCI for Ansible Linting & Checks

In the StackStorm team we use CircleCI with most of our repositories. We check things like code style checks, and run unit tests. With every Pull Request we trigger these checks, and checks must pass before merging. Some repos also use CircleCI for post-merge deployment steps.

We use Ansible and Terraform to manage some of our internal infrastructure. All configurations are stored in Git. All changes to that configuration must be submitted as a Pull Request. All PRs need approval, and all commit checks must pass. We use CircleCI to run these commit checks.

We run multiple checks, but for Ansible playbooks, they include using ansible-lint, and ansible-playbook --syntax-check. We then spin up a Docker container using CircleCI and run some of our playbooks twice, checking that it passes both times, and that the second run records no changes.

Here’s a snippet of some of our CircleCI configuration:

1
2
3
4
5
6
7
8
9
 Continue reading

More Ansible Modules for Extreme

We published Ansible modules for Extreme SLX devices earlier this year. Now we have modules covering all the main Extreme Switching & Routing product families - SLX, VDX, MLX, EXOS, VSP.

Available Modules

  • SLX - slxos_command, slxos_config, slxos_facts, slxos_interface, slxos_l2_interface, slxos_l3_interface, slxos_linkagg, slxos_lldp, slxos_vlan
  • VDX - nos_command, nos_config, nos_facts
  • EXOS - exos_command, exos_config, exos_facts
  • VOSS - voss_command, voss_config, voss_facts
  • MLX - ironware_command, ironware_config, ironware_facts

All modules are available in the current GA version of Ansible (2.7), except for voss_config. That one proved a bit trickier for me to write, and I didn’t get it done in time for the 2.7 cutoff. That one is an open Pull Request against the Ansible devel branch. That should get reviewed and merged soon. It will then make its way into the next GA release. You can of course use the code direct from my branch in the meantime.

All modules use the network_cli plugin. See Platform Options for general information about how to use this connection type.

Thanks to Continue reading

More Ansible Modules for Extreme

We published Ansible modules for Extreme SLX devices earlier this year. Now we have modules covering all the main Extreme Switching & Routing product families - SLX, VDX, MLX, EXOS, VSP.

Available Modules

  • SLX - slxos_command, slxos_config, slxos_facts, slxos_interface, slxos_l2_interface, slxos_l3_interface, slxos_linkagg, slxos_lldp, slxos_vlan
  • VDX - nos_command, nos_config, nos_facts
  • EXOS - exos_command, exos_config, exos_facts
  • VOSS - voss_command, voss_config, voss_facts
  • MLX - ironware_command, ironware_config, ironware_facts

All modules are available in the current GA version of Ansible (2.7), except for voss_config. That one proved a bit trickier for me to write, and I didn’t get it done in time for the 2.7 cutoff. That one is an open Pull Request against the Ansible devel branch. That should get reviewed and merged soon. It will then make its way into the next GA release. You can of course use the code direct from my branch in the meantime.

All modules use the network_cli plugin. See Platform Options for general information about how to use this connection type.

Thanks to Continue reading

More Ansible Modules for Extreme

We published Ansible modules for Extreme SLX devices earlier this year. Now we have modules covering all the main Extreme Switching & Routing product families - SLX, VDX, MLX, EXOS, VSP.

Available Modules

  • SLX - slxos_command, slxos_config, slxos_facts, slxos_interface, slxos_l2_interface, slxos_l3_interface, slxos_linkagg, slxos_lldp, slxos_vlan
  • VDX - nos_command, nos_config, nos_facts
  • EXOS - exos_command, exos_config, exos_facts
  • VOSS - voss_command, voss_config, voss_facts
  • MLX - ironware_command, ironware_config, ironware_facts

All modules are available in the current GA version of Ansible (2.7), except for voss_config. That one proved a bit trickier for me to write, and I didn’t get it done in time for the 2.7 cutoff. That one is an open Pull Request against the Ansible devel branch. That should get reviewed and merged soon. It will then make its way into the next GA release. You can of course use the code direct from my branch in the meantime.

All modules use the network_cli plugin. See Platform Options for general information about how to use this connection type.

Thanks to Continue reading

Ansible – Don’t be Afraid of a Little Python

This year I’ve written several Ansible modules. It wasn’t that hard, yet some people claimed they had been waiting “years” for those modules. There was nothing stopping anyone else doing it, yet they hadn’t. There’s a weird reticence amongst network engineers to learn or write any code, even when it could make a large difference to their job. People either do nothing, or they create complex Ansible playbooks to work around their reluctance to write Python. It’s not that scary. Why don’t people put in a bit of effort?

Don’t be Afraid of a Little Python

Ansible playbooks use YAML, a somewhat human-readable markup language. These are instructions for “what” Ansible should do - e.g. “Use the Cisco ios_config module to ensure that this configuration line is present."

The underlying modules use Python. These are the “how” - they take the instructions from the playbooks, and turn those into device connections to devices, making configuration changes, checking state, etc.

Some people look at these modules as a mystery black box that only the vendor can write. They think that the only way they can interact with Ansible is via playbooks.

This leads to two situations:

1/ Twiddling thumbs Continue reading

Ansible – Don’t be Afraid of a Little Python

This year I’ve written several Ansible modules. It wasn’t that hard, yet some people claimed they had been waiting “years” for those modules. There was nothing stopping anyone else doing it, yet they hadn’t. There’s a weird reticence amongst network engineers to learn or write any code, even when it could make a large difference to their job. People either do nothing, or they create complex Ansible playbooks to work around their reluctance to write Python. It’s not that scary. Why don’t people put in a bit of effort?

Don’t be Afraid of a Little Python

Ansible playbooks use YAML, a somewhat human-readable markup language. These are instructions for “what” Ansible should do - e.g. “Use the Cisco ios_config module to ensure that this configuration line is present."

The underlying modules use Python. These are the “how” - they take the instructions from the playbooks, and turn those into device connections to devices, making configuration changes, checking state, etc.

Some people look at these modules as a mystery black box that only the vendor can write. They think that the only way they can interact with Ansible is via playbooks.

This leads to two situations:

1/ Twiddling thumbs Continue reading

Ansible – Don’t be Afraid of a Little Python

This year I’ve written several Ansible modules. It wasn’t that hard, yet some people claimed they had been waiting “years” for those modules. There was nothing stopping anyone else doing it, yet they hadn’t. There’s a weird reticence amongst network engineers to learn or write any code, even when it could make a large difference to their job. People either do nothing, or they create complex Ansible playbooks to work around their reluctance to write Python. It’s not that scary. Why don’t people put in a bit of effort?

Don’t be Afraid of a Little Python

Ansible playbooks use YAML, a somewhat human-readable markup language. These are instructions for “what” Ansible should do - e.g. “Use the Cisco ios_config module to ensure that this configuration line is present."

The underlying modules use Python. These are the “how” - they take the instructions from the playbooks, and turn those into device connections to devices, making configuration changes, checking state, etc.

Some people look at these modules as a mystery black box that only the vendor can write. They think that the only way they can interact with Ansible is via playbooks.

This leads to two situations:

1/ Twiddling thumbs Continue reading

CCIE – Should I Renew?

It is 6 years since I passed the CCIE Lab Exam. The dreaded email has arrived:

CCIE: Your CCIE status is ‘suspended’ and you need to recertify in twelve months.

Time to re-evaluate what the CCIE means to me. Should renew it? Should people start out on the CCIE track now? My opinions have shifted over the years.

Should I Renew?

I’ve been through this cycle a few times now. I’m getting closer to Emeritus, but it’s still a few years away.

My career has shifted over the last few years. I work for a Network Vendor, but networking is only part of what I do. I am a Product Manager, focused on automation. I spend very little time looking at network devices, or CLI. I spend my time talking to customers, updating roadmaps, writing Python, reviewing Pull Requests.

My future will be working with technologies like Serverless Computing, IoT, and Edge.

CCIE R&S doesn’t cover any of that.

It is unlikely that I will ever work as a traditional hands-on network engineer again. Not impossible, but unlikely. I doubt that any future employer will care about whether I have a current CCIE certification. At this point my experience Continue reading

CCIE – Should I Renew?

It is 6 years since I passed the CCIE Lab Exam. The dreaded email has arrived:

CCIE: Your CCIE status is ‘suspended’ and you need to recertify in twelve months.

Time to re-evaluate what the CCIE means to me. Should renew it? Should people start out on the CCIE track now? My opinions have shifted over the years.

Should I Renew?

I’ve been through this cycle a few times now. I’m getting closer to Emeritus, but it’s still a few years away.

My career has shifted over the last few years. I work for a Network Vendor, but networking is only part of what I do. I am a Product Manager, focused on automation. I spend very little time looking at network devices, or CLI. I spend my time talking to customers, updating roadmaps, writing Python, reviewing Pull Requests.

My future will be working with technologies like Serverless Computing, IoT, and Edge.

CCIE R&S doesn’t cover any of that.

It is unlikely that I will ever work as a traditional hands-on network engineer again. Not impossible, but unlikely. I doubt that any future employer will care about whether I have a current CCIE certification. At this point my experience Continue reading

IXP Graphs are an Eyesore

Too many IXPs (and networkers in general) are using horrible outdated methods of graphing data. These are an ugly eyesore, and should be updated to something from this century. Big IXPs in particular have no excuse: they have the resources to do better.

IXPs: Invest, Spend, Drop Prices?

Two years ago Dave Temkin from Netflix presented at NANOG 67, talking about The Real Cost of Public IXPs (warning: PDF).

This caused a bit of a stir. As El Reg put it:

[According to Dave Temkin] The internet exchange industry is ripping customers off, charging too much for features people don’t need, and spending millions on staff salaries, unnecessary marketing and social events.

You can argue amongst yourselves as to how much IXPs should invest, how closely their port prices should track transit costs, etc. Or maybe you just like all the free drinks, dammit.

I think that if they’re going to spend money rather than reduce prices, they should spend it on something I care about: Data visualization. Most IXPs traffic graphs are an eyesore, they’re outdated, and it’s time they were fixed.

Ugly Eyesores

Here’s some typical traffic graphs from some of the biggest IXPs in the world:

DE-CIX

Continue reading

IXP Graphs are an Eyesore

Too many IXPs (and networkers in general) are using horrible outdated methods of graphing data. These are an ugly eyesore, and should be updated to something from this century. Big IXPs in particular have no excuse: they have the resources to do better.

IXPs: Invest, Spend, Drop Prices?

Two years ago Dave Temkin from Netflix presented at NANOG 67, talking about The Real Cost of Public IXPs (warning: PDF).

This caused a bit of a stir. As El Reg put it:

[According to Dave Temkin] The internet exchange industry is ripping customers off, charging too much for features people don’t need, and spending millions on staff salaries, unnecessary marketing and social events.

You can argue amongst yourselves as to how much IXPs should invest, how closely their port prices should track transit costs, etc. Or maybe you just like all the free drinks, dammit.

I think that if they’re going to spend money rather than reduce prices, they should spend it on something I care about: Data visualization. Most IXPs traffic graphs are an eyesore, they’re outdated, and it’s time they were fixed.

Ugly Eyesores

Here’s some typical traffic graphs from some of the biggest IXPs in the world:

DE-CIX

Continue reading

GitHub Microsoft – It’s OK

Microsoft buys GitHub, and most of the press has been pretty positive, even from those you might not expect.

But , of course there’s the usual herp-derp comments, and a big spike in moving repos to Gitlab

Most of those repositories will be inconsequential single-user repos, but it is still so much wasted effort. If your knee-jerk reaction is to immediately stop doing real work, and move your code somewhere else, you haven’t been paying attention. The world has moved on.

Back in 2014 I wrote Keep an Open Mind:

I get frustrated because these people aren’t paying attention to what Microsoft has been doing. They have come a very long way since the 2002 Bill Gates email setting security as the top priority. It’s a big ship to turn, and it took time. Their overall security model and practices are far better than they were, and stability is no longer an issue. Their business strategy is very different now too.

But poor Continue reading

Don’t Rely on Long Support Lifecycles

I hate long support lifecycles for hardware and software. Yes, you should be able to buy a new iPhone or switch and use it for 3+ years. But some people want 10+yrs of support, and wail and moan when vendors end support. This is wrong. It drives up costs & complexity, and makes your systems less robust, not more. It’s a false sense of security. Plan to buy smaller & cheaper, and upgrade frequently.

Why Vendors Don’t Like Them

Vendors don’t want to do long support lifecycles. They will do them, because people pay for it, but there comes a point where they put a line in the sand. “Sorry, that system is now EoL.”

Why?

  • Costs: Testing software and hardware combinations is hard work. Add many years of released hardware & software combinations, and it gets much harder. More racks of gear & more permutations == more costs.

  • Complexity: It’s hard enough to test against a small set. But now you have to deal with obscure systems acquired from a third party 7 years ago? Complexity == time and money.

  • Motivation: Hands up who wants to work on legacy systems? Exactly. It’s hard to motivate engineers to support Continue reading

Culture Shifts and Work Travel Learnings

I’ve seen a few Twitter threads recently about learning to live with the sudden plenty of working for tech companies. If you didn’t grow up that way, the adjustment takes time. It made me think about a few things I’ve learnt about corporate travel, and mistakes I’ve made along the way. People who grew in the corporate world instinctively know stuff I had to learn. Here’s some of the mistakes, and learnings:

Sudden Change of Scene

There’s been a few threads recently on Twitter related to the concept of “growing up poor, and learning how to adapt to working in well-paid industries.”

Here’s an example thread:

Read the thread - there’s some gems in there. Stuff like these hit home for me:

Cloud Not Just Someone Else’s Computer

Cloud computing is a lot more than “someone else’s computer” and it annoys the hell out of me when people keep trotting out this tired old excuse. There is much more to service delivery than compute power. You do yourself and your customers a disservice if you don’t do your research.

A few years ago it was fashionable to dismiss cloud as “just someone else’s computer”, e.g.:

There’s T-shirts:

Someone else's Computer T-Shirt

You can even buy coffee mugs.

In a time when most cloud computing was Infrastructure as a Service, there was an element of truth to it. But…

Times Change

The problem is that there’s still people thinking this. Check these recent tweets.

These people don’t realize that the world has moved on a long way. There is much more to cloud computing than just “someone else’s computer.”

Consider a simple example, like email. To provide email services from “my computer” I also need power, cooling, rack space, servers, storage, networking, operating system, software, application configuration and maintenance, etc…not to mention the operational expertise to keep it all going.

If Continue reading

Ansible for Extreme Devices

Here’s something I’ve been working on recently: Ansible modules for Extreme SLX switches & routers. Ansible is a popular automation framework, and with good reason: it has a low barrier to entry. Time to usefulness is short. But you need device-specific modules to work with networking devices. Finally we have some modules for SLX. Read on for how to use them.

This blog is not an intro to Ansible in general. There’s plenty of good intros out there. This is specifically about demonstrating Ansible with SLX switches.

Background

Ansible is an agent-less configuration management system. It uses “playbooks”, written in YAML, to define desired configuration state. “modules” written in Python translate this into whatever is needed to configure the system, application, database or network device.

Ansible has been making great strides in adding network automation capabilities. But we haven’t had any modules for working with ~Brocade~ Extreme devices. That is now changing.

PaulQuack has contributed MLXe (Ironware) modules, which will go GA in Ansible 2.5 (due for release in March 2018). And I’ve been working on modules for the SLX, with my colleagues. These have not yet been merged upstream, but it’s Open Source, so you can grab Continue reading

1 2 3 4 5