gnmi_cli is stripping double quotes in TypedValue

[kboyapa1]

I am using the latest gnmi_cli in which Set & Get are taking proto directly. I am seeing a behavior with the json_val or json_ietf_val fields. The quotes(") are stripping by gnmi_cli and server is receiving the json values are as type str. Is there any way we can avoid removing the quotes(") specified in the gnmi_cli's SetRequest and can server receives the same with quotes? (if gnmi_cli is not sending the json val in json format instead sending as string).

When single quote is used around the names in json_val or json_ietf_val, gnmi_cli is reporting a parsing error "unknown field name in gnmi.TypedValue"

When the escape character is used before quotes("), gnmi_cli is sending the request as it is (")

With Double quotes in json_val or json_ietf_val:

For the below gnmi_cli SetRequest update,

./gnmi_cli --address rtxscplp124:20175 --ca_crt /home/kboyapa1/crt/ca-bundle.crt --client_crt /home/kboyapa1/crt/client.crt --client_key /home/kboyapa1/crt/client.key --d="#" --set --proto "update<path<elemname:'eqpt' elem<name:'shelf' key<key:'shelfId' value:'1'>>> val<json_ietf_val:'{"slot":[{"slotID":"FAN1","admin-status":"up"}]}'>>" --with_user_pass

The server is receiving the SetRequest as
Received SetRequest = update {
path {
elem {
name: "eqpt"
}
elem {
name: "shelf"
key {
key: "shelfId"
value: "1"
}
}
}
val {
json_ietf_val: "{slot:[{slotID:FAN1,admin-status:up}]}"
}
}

I am expecting json_ietf_val: '{"slot":[{"slotID":"FAN1","admin-status":"up"}]}' as showed in gnmi specification.

With Single quote in json_val or json_ietf_val:

./gnmi_cli --address rtxscplp124:20175 --ca_crt /home/kboyapa1/crt/ca-bundle.crt --client_crt /home/kboyapa1/crt/client.crt --client_key /home/kboyapa1/crt/client.key --d="#" --set --proto "update<path<elemname:'eqpt' elem<name:'shelf' key<key:'shelfId' value:'1'>>> val<json_ietf_val:'{'slot':[{'slotID':'FAN1','admin-status':'up'}]}'>>" --with_user_pass
username: fujitsu
password: E0704 01:34:14.738653 5057 gnmi_cli.go:180] unable to parse gnmi.SetRequest from "update<path<elemname:'eqpt' elem<name:'shelf' key<key:'shelfId' value:'1'>>> val<json_ietf_val:'{'slot':[{'slotID':'FAN1','admin-status':'up'}]}'>>" : line 1.100: unknown field name "slot" in gnmi.TypedValue

[kboyapa1]

Seems the double quotes in json_ietf_val is stripping in flag.Parse() of gnmi_cli.go main. Can please help how to stop double quotes stripping in gnmi_cli?

The reqProto in executeSet() is @@@@@@@@@@@reqProto = update<path<elemname:'eqpt' elem<name:'shelf' key<key:'shelfId' value:'1'>>> val<json_ietf_val:'{slot:[{slotID:FAN1,admin-status:up}]}'>>

[robshakir]

You will need to escape quotes that are supplied on the command line, for example:

./gnmi_cli --address="192.168.122.150:10162" -insecure -with_user_pass -set -proto "update: <path: <elem: <name: \"interfaces\"> elem: <name: \"interface\" key:<key: \"name\" value:\"Ethernet2\">> elem:<name:\"config\">> val: <json_ietf_val: '{\"description\": \"FOO\"}'>>" 

**user/pass entry trimmed**

response: <
  path: <
    elem: <
      name: "interfaces"
    >
    elem: <
      name: "interface"
      key: <
        key: "name"
        value: "Ethernet2"
      >
    >
    elem: <
      name: "config"
    >
  >
  op: UPDATE
>
timestamp: 1530896508750857701

[kboyapa1]

Thanks @robshakir for your explanation. When I used escape character, I am receiving the escape character also in the request in the server. I am using python for gnmi server implementation. I have printed the SetRequest when my Set RPC is invoked.

When I don't specify the escape character before double quotes, Server is not receiving the double quote. When escape character is supplied for bouble qoutes, server is receiving the escapae character too along with the double quotes. Is this expected?

/gnmi_cli --address rtxscplp124:18777 --ca_crt /home/kboyapa1/crt/ca-bundle.crt --client_crt /home/kboyapa1/crt/client.crt --client_key /home/kboyapa1/crt/client.key --set --proto "update<path<elemname:'eqpt' elem<name:'shelf' key<key:'shelfId' value:'1'>>> val<json_ietf_val:'{"slot":[{"slotID":"FAN1", "admin-status":"down"}]}'>>" --with_user_pass

gnmi server Received the SetRequest as,
Received SetRequest = update {
path {
elem {
name: "eqpt"
}
elem {
name: "shelf"
key {
key: "shelfId"
value: "1"
}
}
}
val {
json_ietf_val: "{slot:[{"slotID":"FAN1", "cardType":"AC00-F011", "admin-status":"up"}]}"
}
}

for the above path element, When the server sends a RPC error The error message in the gnmi_cli is having another escape character for "". Please refer the path shows in gnmi_cli error message.

E0709 08:16:14.565264 64801 gnmi_cli.go:181] target returned RPC error for Set("replace:<path:<elem:<name:"eqpt" > elem:<name:"shelf" key:<key:"shelfId" value:"1" > > > val:<json_ietf_val:"{slot:[{\"slotID\":\"FAN1\", \"cardType\":\"AC00-F011\", \"admin-status\":\"up\"}]}" > > ") : rpc error: code = InvalidArgument desc = /equipment:eqpt/shelf{1}/shelf-role is not configured

[kboyapa1]

I can see the escape character in edit mode but when I submitted the comment all the escape characters are disappearing. I have attached the snapshot of server log.

[gcsl]

I think your log line is rendering correctly by adding the escape characters necessary for the composition in the text proto rendering. If you were to print only the json_ietf_val directly, I suspect you would get what you expect.

…

On Mon, Jul 9, 2018 at 6:35 AM kboyapa1 ***@***.***> wrote: I can see the escape character in edit mode but when I submitted the comment all the escape characters are disappearing. I have attached the snapshot of server log. [image: image] <https://user-images.githubusercontent.com/30464877/42453635-f6e9523c-83aa-11e8-805c-e0dc71f252ac.png> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARfILyY1eyogna__sHV147ZXCGmMcT8jks5uE1wsgaJpZM4VCBuJ> .

[robshakir]

This is normal textproto behaviour to add the escape characters. Please re-open this issue if you continue have problems with a known-good implementation.