Usage of CONFIG in gNMI SetRequest()

[mike-albano]

Attempting a gNMI SetRequest operation, it looks like the SetRequest is using the CONFIG DataType from GetRequest.

For example, using these path and values in the example playbook:

  - name: Update Nodal Configuration (using gNMI SET)
    gnmi_config:
      update:
        - path: /provision-aps/provision-ap[mac=00:11:74:*snip*]/config/hostname
          val: lab-ap.example.com

I get the following traceback:

The full traceback is:
WARNING: The below traceback may *not* be related to the actual failure.
  File "/tmp/ansible_gnmi_config_payload_U0Did_/ansible_gnmi_config_payload.zip/ansible_collections/nokia/grpc/plugins/modules/gnmi_config.py", line 135, in main
  File "/tmp/ansible_gnmi_config_payload_U0Did_/ansible_gnmi_config_payload.zip/ansible/module_utils/connection.py", line 195, in __rpc__
    raise ConnectionError(to_text(msg, errors='surrogate_then_replace'), code=code)
fatal: [192.168.2.2]: FAILED! => {
    "changed": false,
    "code": -32603,
    "invocation": {
        "module_args": {
            "backup": false,
            "backup_options": null,
            "delete": null,
            "prefix": null,
            "replace": null,
            "update": [
                {
                    "path": "/provision-aps/provision-ap[mac=00:11:74:*snip*]/config/hostname",
                    "val": "lab-ap.example.com"
                }
            ]
        }
    },
    "msg": "<_InactiveRpcError of RPC that terminated with:\n\tstatus = StatusCode.UNIMPLEMENTED\n\tdetails = \"unsupported request type: CONFIG\"\n\tdebug_error_string = \"{\"created\":\"@1612416547.477349400\",\"description\":\"Error received from peer ipv4:192.168.2.2:8080\",\"file\":\"src/core/lib/surface/call.cc\",\"file_line\":1067,\"grpc_message\":\"unsupported request type: CONFIG\",\"grpc_status\":12}\"\n>"
}

If I remove "type=config" from here the "unsupported request type: CONFIG" error goes away. I am instead hitting another error, though that error may be completely unrelated (including that below in case it helps):

The full traceback is:
WARNING: The below traceback may *not* be related to the actual failure.
  File "/tmp/ansible_gnmi_config_payload_w6AewL/ansible_gnmi_config_payload.zip/ansible_collections/nokia/grpc/plugins/modules/gnmi_config.py", line 136, in main
  File "/tmp/ansible_gnmi_config_payload_w6AewL/ansible_gnmi_config_payload.zip/ansible/module_utils/connection.py", line 195, in __rpc__
    raise ConnectionError(to_text(msg, errors='surrogate_then_replace'), code=code)
fatal: [192.168.2.2]: FAILED! => {
    "changed": false,
    "code": -32603,
    "invocation": {
        "module_args": {
            "backup": false,
            "backup_options": null,
            "delete": null,
            "prefix": null,
            "replace": null,
            "update": [
                {
                    "path": "/provision-aps/provision-ap[mac=00:11:74:*snip*]/config/hostname",
                    "val": "lab-ap.example.com"
                }
            ]
        }
    },
    "msg": "Ansible gNMI plugin does not support encoding for value: {\"stringVal\": \"tester-05.foo.net\"}"
}

...where tester-05.foo.net is the hostname assigned to the leaf referenced above.

[wisotzky]

Hi @mike-albano

This gNMI Ansible plugin is taking a configuration snapshot before and after the SetRequest is executed. This is required to interwork with Ansible to enable the following features: change indicator, diff-mode and backup. If the device does not support GET type=CONFIG it implies that the OpenConfig gNMI standard is incompletely implemented. Removing the "type=config" would result in the risk, that the node returns both config and state while change indicator/diff-mode result in misleading results.

About the other issue, it would be good to understand, what capabilities your device is supporting. This Ansible plugin supports JSON and JSON IETF encoding - but must be set accordingly.

To have a deeper look, please provide the following:

• Info about vendor, product family, chassis type and release of the DUT
• YANG files
• Response from Capabilities RPC
• Playbook/Hostfile used

Best would be to have access to the DUT to do some basic testing/integration...

/wiso

[mike-albano]

Missed the notification of your reply; thanks for the explanation.

"If the device does not support GET type=CONFIG..."
That is indeed the case. Looking at the GetRequest Type it is true that the Targets in question have not implemented support for this. These Targets are WiFi AP's from Arista & HPE so that explains the issue I'm seeing with the SetRequest.

Since it appears that the functionality relies on this portion of the gNMI Specification being implemented, I'd say this is OK to close.

[wisotzky]

Hi @mike-albano,

any update on the above... If not I would like to close that item.