[BUG] Complex provider specific config causes gRPC init call to fail

[mansam]

Is there an existing issue for this?

• I have searched the existing issues

Konveyor version

latest

Priority

Undefined (Default)

Current Behavior

Attempting to initialize a provider with complex nested provider specific config results in a protobuf serialization failure:

{
  "name": "k8s",
  "address": "127.0.0.1:8991",
  "proxyConfig": {},
  "initConfig": [{
    "providerSpecificConfig": {
      "groupVersionKinds": [{"group": "apps", "version": "v1", "kind": "Deployment"}, {"group": "", "version": "v1", "kind": "Pod"}, {"group": "", "version": "route.openshift.io/v1", "kind":"Route"}],
      "namespaces": ["konveyor-tackle"]
    },
    "proxyConfig": {
    }
  }]
}

ERRO[0000] unable to init the providers  error="proto: invalid type: map[interface {}]interface {}" provider=k8s

In this example, it's choking on the groupVersionKinds field. I think the proximate cause is something to do with the exact representation the decoder is choosing for the contents of providerSpecificConfig; since it's specified as a map[string]interface{} the decoder has plenty of options. I experimented by changing the yaml.Unmarshal call in provider/provider.go to unmarshal with json.Unmarshal from encoding/json, and that worked, so one representation seems to be acceptable to protobuf and one isn't.

Expected Behavior

The provider specific config is serialized to proto and transmitted across the gRPC interface successfully.

How Reproducible

Always

Steps To Reproduce

Attempt to initialize a provider with deeply nested providerSpecificConfig.

[konveyor-ci-bot]

This issue is currently awaiting triage.
If contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members.