NCLU: the need for declarative semantics


We make use of NCLU primarily through its Ansible module. Because NCLU currently only supports an operational model (e.g. add, delete) for modifying the state of the switch, it makes it difficult to create idempotent playbooks that are independent of current state. This is what makes Ansible modules like the iptables module so nice. We can declaratively specify the the state of a rule as either present or absent, so it does not matter how many times the playbook gets executed, we always land in the desired state.

As a concrete example of a sticking point we currently have. Consider the following simple Ansible NCLU fragment
nclu:
commands:
- add interface swp1 bridge access 10
- add interface swp2 bridge access 10
 - del interface swp3 bridge access 10
 - del interface swp4 bridge access 10
atomic: true

If that play gets run twice in a row it will fail because the bridge state is already set. What would be better would be to have something along the lines of the following.
nclu:
configs:
- interface swp1 bridge access 10
- interface swp2 bridge access 10
state: present

nclu:
configs:
- interface swp3 bridge access 10
- interface swp4 bridge access 10
state: absent

2 replies

Userlevel 5
There were a few releases in the 3.5.0 - 3.5.2 range where a playbook such as the one shown in your top example would fail due to a behavior change introduced on purpose as part of a bug fix but that change has been reverted and should be addressed in 3.5.3+. The NCLU module must always be idempotent and we're committed to making sure that remains true.

I agree that declarative syntaxes can be handy for some use cases. There are other areas where we would like to improve the NCLU Ansible modulel as well... through the use of the "check" "diff" and "validate" options for instance.

Unfortunately we must always weigh what we want to do with the reality of the headcount and resources that we have. This is an area where we will need more developer cycles to properly implement and test new functionality.

I appreciate your taking the time to let us know about your idea!
Hi Eric,

Thanks for the information about the updated behavior in 3.5.3. This morning I updated our base testing images from 3.5.0 to 3.5.3 and our playbooks are now running without issue 🙂

Reply