Feature Request: API Client Generation with openapi-generator

[dnoliver]

Hello,

I was trying to get an API Client for golang generated from the OpenAPI specification file video-analytics-serving.yaml. You can run the tool with Docker:

docker run --rm -v ${PWD}:/local openapitools/openapi-generator-cli \
  generate -i https://raw.githubusercontent.com/intel/video-analytics-serving/v0.3.0-alpha/vaserving/rest_api/video-analytics-serving.yaml \
  -g go -o /local/out/go

I already run into a problem with the oneOf tag as described here OpenAPITools/openapi-generator#15 (comment).

Anyways, as I want to just run the example with UriSource and FileDestination, I manually updated the generated API client. It worked. I could get the Models at least:

	conf := openapi.NewConfiguration()
	conf.BasePath = "http://localhost:8080"
	client := openapi.NewAPIClient(conf)

	models, res1, err1 := client.DefaultApi.ModelsGet(nil)
        log.PrintLn(models)

But when I try to get the pipelines, it fails to parse the response. And I think the reason behind that is the Pipeline_parameters definition in the vide-analytics-serving.yaml file.

The definition is more or less empty:

    Pipeline_parameters:
      example:
        default: {}
      properties:
        default: {}

So, when the response containing the following fields arrive to my generated client:

{
        "description": "Object Detection Pipeline",
        "name": "object_detection",
        "parameters": {
            "properties": {
                "cpu-throughput-streams": {
                    "element": "detection",
                    "maximum": 4294967295,
                    "minimum": 0,
                    "type": "integer"
                },
                "inference-interval": {
                    "default": 1,
                    "element": "detection",
                    "maximum": 4294967295,
                    "minimum": 1,
                    "type": "integer"
                },
                "n-threads": {
                    "default": 1,
                    "element": "videoconvert",
                    "type": "integer"
                },
                "nireq": {
                    "default": 2,
                    "element": "detection",
                    "maximum": 64,
                    "minimum": 1,
                    "type": "integer"
                }
            },
            "type": "object"
        },
        "type": "GStreamer",
        "version": "1"
    }

My API Client crash saying:

2020/05/28 16:32:53 json: cannot unmarshal string into Go struct field Pipeline.parameters of type openapi.PipelineParameters

So, this is not a bug, but a request to complete the Pipeline_parameters definition so automatic generated API clients works out of the box :) (for Go at least)

Any opinion?

[nnshah1]

This is great feedback - thank you for posting! We will need to investigate a bit to determine whether we can provide a generic schema that works for any pipeline, or if we would have to dynamically generate the parameter section based on the pipeline template. It's definitely a feature we should have (to be able to generate a client cleanly). If you already have an idea for how you would modify the yml - please feel free to post a merge request. Also please let us know if this blocks your use / evaluation

[dnoliver]

My intention with the Go API client is to ease the integration of this repo with an EdgeX Device Service.

It seems to me that a potential way of providing a Device Service for Video Analytics Serving is to write a Go API client for the service, and use it from the Go EdgeX Device Service SDK, translating REST calls that this service understand into Data and Command methods that EdgeX understand, and reusing all the configuration and metadata capabilities already provided by EdgeX.

At least for an evaluation of the approach, I can get an automatically generated Go API client, and use it to create a Device Service, and at least pull Models data from VAServing into Edge Data Stores. If the Go API Client was more functional, I could also use the Command service to run a pipeline request and get results. But I think it is enough for a proof of concept.

For getting the results, I was thinking on using the File destination, sending the result files to a volume that the Device Service and VAServing shares, and then pushing those results using the EdgeX Data infrastructure. I wonder why VAService does not have a REST API for getting results of pipelines, given that MQTT or Kafka destinations requires an MQTT or Kafka broker.

[akwrobel]

We are not looking at implementing this feature at this time.