nmstate documentation does not adequately address possible errors with implementation arising from attempted modifications of network state on the primary interface. SPECIFICALLY, the issue arises when we attempt to modify DNS configuration AND specify the primary interface of the node. 

The documentation example provides a summary update that advises we should be defining the option `autodns:false` and specifying a nic to append these changes. HOWEVER, the upstream nmstate.io documentation supplies an example that does NOT require specifying a nic, and in fact, it is not required to implement the changes on the node for a simple DNS update. (adding the nic interface details complicates and blocks implementation).

Primarily the issue arises when we are defining changes similar to the below example:

~~~
spec:
  desiredState:
    dns-resolver:
      config:
        search:
        - domain.net
        - domain.com
        - prefix.example.net
        - example.net
        server:
        - xxx.xxx.xxx.200
        - xxx.xxx.xxx.62
        - xxx.xxx.xxx.78
    interfaces:
    - ipv4:
        auto-dns: false
        dhcp: false
        enabled: true
      name: ens192
      state: up
      type: ethernet
~~~

In the above example, which matches our suggested documentation at: https://docs.openshift.com/container-platform/4.12/networking/k8s_nmstate/k8s-nmstate-updating-node-network-config.html#virt-example-nmstate-IP-management-dns_k8s_nmstate-updating-node-network-config

We understand that we are asking the node(s) to create the dns-resolver entries and we are ALSO making a spec change to the primary interface of the node (ens192) to define the requested `auto-dns: false` change.

However, implementing this is aborted with the following error:

~~~
"nodenetworkconfigurationpolicy":"/worker-ens192-dns-policy","error":"policy has failing enactments, aborting"
~~~

When we refer then to the nmstate.io documentation, the example listed for DNS is much cleaner: https://nmstate.io/examples.html#dns

~~~
---
dns-resolver:
  config:
    search:
    - example.com
    - example.org
    server:
    - 2001:4860:4860::8888
    - 8.8.8.8
~~~

And, when we test this more simplified implementation with my example below, it succeeds (without specifying the primary nic of the host node, which is protected by nmstate to avoid bringing networking offline -- nmstate is not able to bounce the primary interface, which is a required step of any config change).

~~~
apiVersion: nmstate.io/v1 
kind: NodeNetworkConfigurationPolicy 
metadata: 
 name: worker-0-dns-testing 
spec: 
 nodeSelector: 
   kubernetes.io/hostname: worker-0.shrocp4upi412ovn.lab.upshift.rdu2.redhat.com 
 desiredState: 
   dns-resolver: 
     config: 
       search: 
       - sunbro.com 
       server: 
       - 1.1.1.1
~~~

Note that I have not specified any interface that needs to be modified.

I suggest therefore that the documentation is updated to reflect 2 things:

1. modification of the primary interface is not supported/will not succeed, as nmstate operator cannot override the MANAGED status of the primary interface of the host node, and changes on this interface must be updated via machine-config or manually with nmcli/similar locally on the node

2. DNS updates do not (and for simplicities sake) should not require the additional spec options surrounding an interface unless you are ALSO configuring changes for that interface. As our users are primarily being referred to nmstate for dns config changes and do not necessarily want to do more than just update the /etc/resolv.conf file on the host nodes, this is an unnecessary spec change that hinders/blocks rollouts until modified, or they specify a secondary interface that can be bounced (even if no changes were really applied to it) simply because our docs indicate they should be doing that (in error). 

4.12 (all current nmstate.io release docs should be evaluated -- they all refer to this information)

every time

1. see above
2.
3.

nmstate will abort rollout despite matching documentation

documentation should reflect an expected/successful implementation and note caveats regarding possible pitfalls with primary interface modification + DNS being more simple to implement than documented 

see case: 03544289 for speicific use-case and pitfall/stall out