feat(plugins): Add remote extensions field to a plugin info release

[jonsie]

In spinnaker/orca#3840 I realized I had the cart before the horse on a few items, specifically the basic remote extension point configuration. This will not only allow me to get away from abusing the PreconfiguredJob stuff even more (by allowing for specific remote stage configuration), but also lay some of the ground work for other types of remote extension points.

Adds a remoteExtensions field to a plugin info release. A plugin that is just a remote extension look like this:

{
  "id": "netflix.remote",
  "description": "A remote plugin",
  "provider": "csmalley",
  "releases": [
    {
      "version": "0.0.1",
      "date": "2020-06-16T02:20:14.889Z",
      "requires": "orca>=1.0.0",
      "url": null,
      "sha512sum": null,
      "preferred": false,
      "lastModified": "2020-06-18T23:08:48.899Z",
      "lastModifiedBy": "csmalley",
      "remoteExtensions": [
        {
          "type": "stage",
          "id": "netflix.remote.remoteWait",
          "transport": {
            "http": {
              "url": "http://service.com/remoteWait",
              "config": {}
            }
          },
          "config": {
            "type": "remoteWait",
            "label": "Wait on a remote service",
            "description": "A stage that waits on a remote service",
            "parameters": {
              "waitTime": 30,
              "message": "done!"
            }
          }
        }
      ]
    }
  ]
}

The idea here is that we use the requires field in-conjunction with the remote extension type to determine which service to configure with the specific remote extension and corresponding remote extension configuration.

[jonsie]

stage here corresponds to the RemoteExtension#type field.

[jonsie]

This can be flushed out over time, but for now it's a catch-all for any underlying client configuration we need.

[jonsie]

I think for now a map of the parameter name and the default value will suffice.

[robzienert]

Do like.

PluginInfo is @Valid, so I think it'd be worth adding javax.validation annotations to some of these properties (such as @URL on the url property, etc).

[robzienert]

Rather than define the extension point config type in front50 (making front50 changes required for most remote extensions), I think we should investigate a shared model or service-exposed schema for extension point configs - personally I favor the schema idea:

For any extension point that has a config, say MyRemoteExtensionConfig, we could convert to JSON Schema (or similar) and expose it from something like /plugins/extension-point-configs/. Each config would have a type, as you have it, but structured like {service}/{configType}[@version?][1], allowing front50 to lookup the correct schema when a remote plugin is being published and we want to do some type / constraint validation. This would let us continue to define, in a single place, everything for an extension point.

I don't think we need to change the PR as it exists today, since this is talking about a lot of work - we can always retrofit what you have here after we've got something working end-to-end. 💯

[1] Not sure if version is needed, but probably? 🤷

One problem with this is that services tend to have dependencies on front50, but not the other way around. I think I'd also be OK with services publishing their schemas into front50 on startup (either via HTTP or pubsub - prefer pubsub). 🤷

[jonsie]

Super interesting idea.

I think a version would be needed. Each change to the config schema would need to be versioned, and then if there is a new config schema version a new plugin info release version with the new config schema would need to be published into front50. This is because we will be rolling out remote extensions by version, and we can't really swap out the underlying config schema without some corresponding version bump.

[christopherthielen]

What would schema validation failures gate? Just publishes of new plugins?