2017-02-10 18:08:06 +01:00
|
|
|
#!/bin/sh
|
|
|
|
|
# This script regenerates all Protobuf/gRPC client files.
|
|
|
|
|
#
|
|
|
|
|
# For now, it must be run manually, and the results are checked into source control. Eventually we might choose to
|
|
|
|
|
# automate this process as part of the overall build so that it's less manual and hence error prone.
|
|
|
|
|
#
|
|
|
|
|
# To run this script, the following pre-requisites are necessary:
|
|
|
|
|
#
|
|
|
|
|
# 1) Install the latest Protobuf compiler from https://github.com/google/protobuf/releases.
|
|
|
|
|
# 2) Add the `protoc` binary to your PATH (so that it can be found below).
|
|
|
|
|
# 3) Install the Golang Protobuf compiler by running this command from your Go workspace (also on your PATH):
|
|
|
|
|
# go get -u github.com/golang/protobuf/{proto,protoc-gen-go}
|
|
|
|
|
#
|
|
|
|
|
# The results are checked into bin/; at this moment, they need to be copied to their final destinations manually.
|
|
|
|
|
set -e
|
|
|
|
|
|
Implement resource provider plugins
This change adds basic support for discovering, loading, binding to,
and invoking RPC methods on, resource provider plugins.
In a nutshell, we add a new context object that will share cached
state such as loaded plugins and connections to them. It will be
a policy decision in server scenarios how much state to share and
between whom. This context also controls per-resource context
allocation, which in the future will allow us to perform structured
cancellation and teardown amongst entire groups of requests.
Plugins are loaded based on their name, and can be found in one of
two ways: either simply by having them on your path (with a name of
"mu-ressrv-<pkg>", where "<pkg>" is the resource package name with
any "/"s replaced with "_"s); or by placing them in the standard
library installation location, which need not be on the path for this
to work (since we know precisely where to look).
If we find a protocol, we will load it as a child process.
The protocol for plugins is that they will choose a port on their
own -- to eliminate races that'd be involved should Mu attempt to
pre-pick one for them -- and then write that out as the first line
to STDOUT (terminated by a "\n"). This is the only STDERR/STDOUT
that Mu cares about; from there, the plugin is free to write all it
pleases (e.g., for logging, debugging purposes, etc).
Afterwards, we then bind our gRPC connection to that port, and create
a typed resource provider client. The CRUD operations that get driven
by plan application are then simple wrappers atop the underlying gRPC
calls. For now, we interpret all errors as catastrophic; in the near
future, we will probably want to introduce a "structured error"
mechanism in the gRPC interface for "transactional errors"; that is,
errors for which the server was able to recover to a safe checkpoint,
which can be interpreted as ResourceOK rather than ResourceUnknown.
2017-02-19 20:08:06 +01:00
|
|
|
GO_MURPC=../go/pkg/murpc
|
2017-02-10 18:28:46 +01:00
|
|
|
GO_PROTOFLAGS="plugins=grpc"
|
|
|
|
|
JS_MURPC=../js/src/murpc
|
|
|
|
|
JS_PROTOFLAGS="import_style=commonjs,binary"
|
|
|
|
|
|
|
|
|
|
echo Generating Protobuf/gRPC SDK files:
|
|
|
|
|
echo \\tGo: $GO_MURPC [$GO_PROTOFLAGS]
|
|
|
|
|
echo \\tJS: $JS_MURPC [$JS_PROTOFLAGS]
|
|
|
|
|
|
|
|
|
|
mkdir -p $GO_MURPC $JS_MURPC
|
|
|
|
|
protoc --go_out=$GO_PROTOFLAGS:$GO_MURPC --js_out=$JS_PROTOFLAGS:$JS_MURPC *.proto
|
|
|
|
|
|
|
|
|
|
echo Done.
|
2017-02-10 18:08:06 +01:00
|
|
|
|