Base64 encoded values data

[vseregin63]

Have a good day, @karimra!

We try to get power-supply data from arista switch. It work fine, but returned data have a base64 encoded format. I just wanted to know does GNMIC has a built in mechanism for decoding such a values and how to get around this issue?

{
  "source": "arista-switch:6030",
  "subscription-name": "default-1730298262",
  "timestamp": 1730298260456059632,
  "time": "2024-10-30T14:24:20.456059632Z",
  "updates": [
    {
      "Path": "components/component[name=PowerSupply2]/power-supply/state/output-current",
      "values": {
        "components/component/power-supply/state/output-current": "QEYAAA=="
      }
    }
  ]
}

Thnx!

[karimra]

Hi, gnmic is the one changing the received bytes value to base64 as per the json spec. Try adding --format prototext to your command to see the value sent from the router.

[vseregin63]

@karimra, thanx for your extremely fast reaction!

Here is a output with --format prototext key

gnmic -a arista-switch:6030 -u admin -p admin --tls-ca arista.cer --tls-server-name leaf.dc --stream-mode sample sub --path /openconfig-platform:components/component/power-supply/state --sample-interval=30s --format prototext --debug

update: {
  timestamp: 1730360888775378898
  update: {
    path: {
      elem: {
        name: "components"
      }
      elem: {
        name: "component"
        key: {
          key: "name"
          value: "PowerSupply1"
        }
      }
      elem: {
        name: "power-supply"
      }
      elem: {
        name: "state"
      }
      elem: {
        name: "output-power"
      }
    }
    val: {
      bytes_val: "B8\x00\x00"
    }
  }
}

[karimra]

Check if the router returns a different value type if you change the encoding (--encoding ). What type of output are you using?

[LimeHat]

Hi @vseregin63 @karimra

The culprit here is ieeefloat32 format in the original yang model. The encoding is correct and depending on the encoding type the OP will receive either bytes or base64-encoded string.

There's no built-in mechanism AFAIK, but I guess the original question can be rephrased as: can gnmic use a processor to transform this format to another data type?. And the answer to that should be yes. [unless you want to decode it directly for manual cli consumption like in your original output]

The fact that this format is not particularly user friendly has been discussed a few times in the OC community^1, but so far there hasn't been an incentive to make the breaking change to the models.

[vseregin63]

Hi!

@LimeHat, thanks for detailed explanation!

@karimra, i tried to use different encoding types (JSON, BYTES, PROTO, ASCII, JSON_IETF), but it changes nothing in returned data. Our used output type is prometheus. As far as I understood such a base64-encodiing should be implemented in a starlak script (difficult to say if it supported or not). May be gnmic has another useful instruments to get around this?

[karimra]

@vseregin63 this will have to be a new processor to decode/encode base64 strings.

[vseregin63]

Thank you very much! Your information was very helpful