Ivan Pepelnjak

Author Archives: Ivan Pepelnjak

Managing the Complexity of Jinja2 Templates in Ansible

One of the first roadblocks you’ll hit in your “let’s master Ansible” journey will be a weird error deep inside a Jinja2 template. Can we manage that complexity somehow… or as one of the participants in our Building Network Automation Solutions online course asked:

Is there any recommendation/best practices on Jinja templates size and/or complexity, when is it time to split single template into function portions, what do you guys do? And what is better in terms of where to put logic - into jinja or playbooks

One of my friends described the challenge as “Debugging Ansible is one of the most terrible experiences one can endure…” and debugging Jinja2 errors within Ansible playbooks is even worse, but there are still a few things you can do.

Read more ...

Managing the Complexity of Jinja2 Templates in Ansible

One of the first roadblocks you’ll hit in your “let’s master Ansible” journey will be a weird error deep inside a Jinja2 template. Can we manage that complexity somehow… or as one of the participants in our Building Network Automation Solutions online course asked:

Is there any recommendation/best practices on Jinja templates size and/or complexity, when is it time to split single template into function portions, what do you guys do? And what is better in terms of where to put logic - into jinja or playbooks

One of my friends described the challenge as “Debugging Ansible is one of the most terrible experiences one can endure…” and debugging Jinja2 errors within Ansible playbooks is even worse, but there are still a few things you can do.

Video: Bandwidth Is Neither Infinite Nor Cheap

After decades of riding the Moore’s law curve the networking bandwidth should be (almost) infinite and (almost) free, right? WRONG, as I explained in the Bandwidth Is (Not) Infinite and Free video (part of How Networks Really Work webinar).

There are still pockets of Internet desert where mobile- or residential users have to deal with traffic caps, and if you decide to move your applications into any public cloud you better check how much bandwidth those applications consume or you’ll be the next victim of the Great Bandwidth Swindle. For more details, watch the video.

You need Free ipSpace.net Subscription to watch the video, and the Standard ipSpace.net Subscription to register for upcoming live sessions.

Video: Bandwidth Is Neither Infinite Nor Cheap

After decades of riding the Moore’s law curve the networking bandwidth should be (almost) infinite and (almost) free, right? WRONG, as I explained in the Bandwidth Is (Not) Infinite and Free video (part of How Networks Really Work webinar).

There are still pockets of Internet desert where mobile- or residential users have to deal with traffic caps, and if you decide to move your applications into any public cloud you better check how much bandwidth those applications consume or you’ll be the next victim of the Great Bandwidth Swindle. For more details, watch the video.

You need Free ipSpace.net Subscription to watch the video, and the Standard ipSpace.net Subscription to register for upcoming live sessions.

Worth Reading: 10 Optimizations on Linear Search

Stumbled upon an article by Tom Limoncelli. He starts with a programming question (skip that) but then goes into an interesting discussion of what’s really important.

Being focused primarily on networking this is the bit I liked most (another case of Latency Matters):

I once observed a situation where a developer was complaining that an operation was very slow. His solution was to demand a faster machine. The sysadmin who investigated the issue found that the code was downloading millions of data points from a database on another continent. The network between the two hosts was very slow. A faster computer would not improve performance.

The solution, however, was not to build a faster network, either. Instead, we moved the calculation to be closer to the data.

Lesson learned: always figure out the real problem and what the most effective way of solving it as opposed to pushing the problem down the stack or into the cloud.

Worth Reading: 10 Optimizations on Linear Search

Stumbled upon an article by Tom Limoncelli. He starts with a programming question (skip that) but then goes into an interesting discussion of what’s really important.

Being focused primarily on networking this is the bit I liked most (another case of Latency Matters):

I once observed a situation where a developer was complaining that an operation was very slow. His solution was to demand a faster machine. The sysadmin who investigated the issue found that the code was downloading millions of data points from a database on another continent. The network between the two hosts was very slow. A faster computer would not improve performance.

The solution, however, was not to build a faster network, either. Instead, we moved the calculation to be closer to the data.

Lesson learned: always figure out the real problem and what the most effective way of solving it as opposed to pushing the problem down the stack or into the cloud.

The Stupidity of Trying to Be Like Google

Someone recommended me a fantastic book on corporate stupidity. Here’s just one of the million small gems it contains:

For instance, many companies conclude that they need to be more innovative. To increase their rates of innovation, they look at firms well known for being innovative, such as Google, then dispatch their executives to Silicon Valley to visit tech companies’ corporate campuses in the hope that they will learn something.

Not surprisingly, the book authors observed the same behavior in those companies as I did a while ago when I was still teaching SDN workshops:

They often ignore the fact that Google is an entirely different sector to them, and the lessons in view probably of limited value. They also overlook that even if they do learn something, actually implementing it within their organization is likely to be difficult, if not impossible.

Finally a warning: that book will make you laugh or cry hysterically (or both), so take it in small daily doses.

The Stupidity of Trying to Be Like Google

Someone recommended me a fantastic book on corporate stupidity. Here’s just one of the million small gems it contains:

For instance, many companies conclude that they need to be more innovative. To increase their rates of innovation, they look at firms well known for being innovative, such as Google, then dispatch their executives to Silicon Valley to visit tech companies’ corporate campuses in the hope that they will learn something.

Not surprisingly, the book authors observed the same behavior in those companies as I did a while ago when I was still teaching SDN workshops:

They often ignore the fact that Google is an entirely different sector to them, and the lessons in view probably of limited value. They also overlook that even if they do learn something, actually implementing it within their organization is likely to be difficult, if not impossible.

Finally a warning: that book will make you laugh or cry hysterically (or both), so take it in small daily doses.

Automation Story: Zero-Touch Provisioning

Zero-Touch Provisioning (ZTP) is a solved problem if you believe the networking vendors… and yet numerous network automation projects involve at least some ZTP functionality. It seems that smart organizations investing in premium people (instead of premium vendors) prefer the Unix way of solving problems: take a number of small versatile tools, and put them together to build a solution that fits your requirements.

Anne Baretta did exactly that and combined Oxidized, FreeZTP, Ansible and custom web UI to build a ZTP solution that addresses the needs of his organization.

Keep reading

Notes

Automation Story: Zero-Touch Provisioning

Zero-Touch Provisioning (ZTP) is a solved problem if you believe the networking vendors… and yet numerous network automation projects involve at least some ZTP functionality. It seems that smart organizations investing in premium people (instead of premium vendors) prefer the Unix way of solving problems: take a number of small versatile tools, and put them together to build a solution that fits your requirements.

Anne Baretta did exactly that and combined Oxidized, FreeZTP, Ansible and custom web UI to build a ZTP solution that addresses the needs of his organization.

Keep reading

Notes

Should I Go with VXLAN or MLAG with STP?

TL&DR: It’s 2020, and VXLAN with EVPN is all the rage. Thank you, you can stop reading.

On a more serious note, I got this questions from an Johannes Spanier after he read my do we need complex data center switches for NSX underlay blog post:

Would you agree that for smaller NSX designs (~100 hypervisors) a much simpler Layer2 based access-distribution design with MLAGs is feasible? One would have two distribution switches and redundant access switches MLAGed together.

I would still prefer VXLAN for a number of reasons:

Read more ...

Should I Go with VXLAN or MLAG with STP?

TL&DR: It’s 2020, and VXLAN with EVPN is all the rage. Thank you, you can stop reading.

On a more serious note, I got this questions from an Johannes Spanier after he read my do we need complex data center switches for NSX underlay blog post:

Would you agree that for smaller NSX designs (~100 hypervisors) a much simpler Layer2 based access-distribution design with MLAGs is feasible? One would have two distribution switches and redundant access switches MLAGed together.

I would still prefer VXLAN for a number of reasons:

1 … 106 107 108 109 110 … 176