Jerikan: A configuration management system for network teams | Hacker News Reader

Jerikan: A configuration management system for network teams

vincent.bernat.ch

45 pointstodsacerdoti12 comments

Highly recommend avoiding this--it's needlessly complicated abstraction on top of Ansible. Just write your own playbooks using the network modules in Ansible, they're really easy to use and will be a lot cleaner than this. You can manage as little or as much of the config for your network devices as you want, and the real beauty of Ansible shines when you do event-based network changes like new VLAN propagation or responding to security threats by blocking addresses.

Hey! I am one of the author of the article. This is not really an abstraction on top of Ansible. Just a tool to generate configuration files from templates as Ansible is pretty bad at this (slow, not providing a line number in case of problem, variable lookup quite rigid). Then, it's just regular Ansible using network modules to deploy the result.

We push the opinion you need to manage the whole configuration to avoid getting out-of-sync with their expected state or putting the state inside your device. Once you are able to manage the whole configuration, the things you describe are possible: propagate a VLAN, adding IP to an access-list, etc. The other way around is not true.

Template rendering performance has always been one of my gripes with ansible. Have you ever taken up the challenge to debug/profile it, and get to the bottom of that seemingly obscene slowness? (It's one of those things I always plan to finally do whenever it affects me, but tend to forget or "postpone" as soon as I move beyond that one particularly slow task...)

No, I didn't try. For me, the fact that modules serialize Python code into a zipfile then execute it makes it really hard to have something efficient. I also don't understand why RedHat is not helping Mitogen which could help solve this without breaking everything (as it suppresses a lot of the steps, even on localhost).

If you're interested in this kind of thing, check out BundleWrap, an under-appreciated gem of configuration management tools. I've been using it as I set up my Raspberry Pi Kubernetes cluster, and it's a joy.

https://bundlewrap.org/

YAML, Jinja... why again!?

I can haz function library?

>inb4 muh idempotence

Seriously, idempotence != YAML.

So honest question, if not YAML and JINJA, what would you want? More end devices are beginning to have configuration APIs but managing legacy network devices still requires SSHing in to make a change, thus all the templating components. My partner and I are trying to make a vendor neutral management tool to abstract all the templating and present an API but it's a hard problem with so many different vendors out there.

Unrelated but I've been experimenting with having a central KV store to host network state for physical devices (Cisco, Arista, etc) and when the state is updated, the network devices are updated (via a templating engine with SSH or API calls to end devices) but even with that it still takes templates to write the config.

> So honest question, if not YAML and JINJA, what would you want?

I've mentioned it. I want functions. I don't care what they do. They may as well construct some data model under the hood. But I want real programming language, not templating YAML.

Are you suggesting Dahl or Jsonnet ?

If he wants json, I will build it

It doesn't really have to be any such fancy configuration dialect, even though I think they are much better than YAML with Jinja abominations you can find in Ansible or K8s Helm.

All that is needed are functions that can either directly contact the remote or build data model with which the tool will later do its magic.

See e.g. how you define infrastructure with Pulumi. It's just an example. I'm not advocating it. In fact, I have zero experience with it. But the point is, that it looks like imperative programming, but you're actually just building some model. You can employ language that's more functional. It doesn't matter.

Everytime someones mentions idempotence as a selling point of YAML abominations, they're mistaken. :-)

> >inb4 muh idempotence

Mocking anyone who might disagree with you is unlikely to help convince people.

Reply on news.ycombinator.com