Remote processes need to be considered in the OpenAPI spec

[francbartoli]

I'd like to declare a process as executed remotely, something like:

process:
    allOf:
       - $ref: 'processSummary.yaml'
       - type: object
         required:
           - id
         properties:
            provider:
              type: string
            inputs:
              type: array
              items: 
                 $ref: 'inputDescription.yaml'
            outputs:
              type: array
              items: 
                 $ref: 'outputDescription.yaml'
            links:
              type: array
              items:
                 $ref: 'link.yaml'

provider might be simply local or remote with the name (for instance Google Earth Engine or GeoScope) of the cloud infrastructure

[christophenoel]

Some comments:

1. From my point of view, the nominal case for a WPS implementation is that your server supports various profiles for the processes: e.g. it may support Java processes, Python processes, BPEL workflow processes, but also Docker contains executed locally, or containers executed on Google Cloud, Amazon, Azure... The remote backend is specific to your WPS implementation, and all my docker containers will be executed on the same specific cloud (for a given implementation). I admit you can imagine having different processes with totally different implementations, but it sounds not the nominal case.
2. Despite this is process specific (process description) or server specific (capabitilies document), this information (the remote backend / cloud server, etc.) is not an execution mandatory input, but only a document information intended to the user.
   --> such information is intended to be included either in a ows:Metadata element, or in the generic ows:additionalProperties element and do not require a modification to the spec.

My two cents...

[gfenoy]

Now I think I understand better this issue.

It does not seem to be only related to providing informations of where the service has been run on or can be run but also give the opportunity to the client to choose which host will run the service effectively. So the client can use this initial information provided in the DescribeProcess to decide where to run the service.

I think this is a great addition which should also be investigated for WPS 2.0 version (the previous one) probably as an extension as explained y Benjamin.

[christophenoel]

At least, the remote host can be specified in a process input, as any other execution parameter.

[francbartoli]

@gfenoy also an additional explanation could be that the client has to be aware of some sort of authentication to run specific processes. For example, in Google Earth Engine if you want to execute a process through their API you have to provide a service account but I would imagine the same sort of mechanism for other providers.
Likely it might end up with an extension in the processSummary

[bradh]

@francbartoli What kind of information would the user/consumer (or different kinds of users/consumers, if there are several) need to have to make an sensible choice?

I worry that this is an "unbreak it" option, where if the process can only really work locally (or remotely - one but not the other; or on a specific machine), and we offer the option, then the user needs to guess the right answer. It seems better to just hide the complexity as much as possible.

The authentication part is different - that should be a mandatory parameter if a service needs it. If you are providing a facade, then maybe the facade encapsulates that.

[christophenoel]

I think the required information would strongly depends on the implementation: some would require an endpoint (some several), a user and password, or a token. We have also identified (in TB14 NExtGen) that CPU/RAM resources assigned could be driven by the user).

Therefore, the Process Description simply needs to include the required Cloud/Grid/Kubernetes input description specific to the server, and the user will be able to submit this info.

 "inputs" : [
        {
          "id" : "kubernetesEndpoint",
          "title" : "Kubernetes Endpoint URL",
          "formats" : [
            {
              "mimeType" : "text/plain",
              "default" : true
            }
          ],
          "minOccurs" : 1,
          "maxOccurs" : 1,
          "LiteralDataDomain" : {
            "dataType" : "String"
          }
        },
        {
          "id" : "kubernetesToken",
          "title" : "Kubernetes Token",
          "formats" : [
            {
              "mimeType" : "text/plain",
              "default" : true
            }
          ],
          "minOccurs" : 1,
          "maxOccurs" : 1,
          "LiteralDataDomain" : {
            "dataType" : "String"
          }
        },
        {
          "id" : "kubernetesCluster",
          "title" : "Kubernetes Cluster id",
          "formats" : [
            {
              "mimeType" : "text/plain",
              "default" : true
            }
          ],
          "minOccurs" : 1,
          "maxOccurs" : 1,
          "LiteralDataDomain" : {
            "dataType" : "String"
          }
        },

[francbartoli]

@spacebel that's interesting, I still believe that qualifying the provider (local/remote) which will execute your process is a benefit

[bpross-52n]

Discussion will continue here: #47