This change implements the boilerplate RPC stub generation for CIDLC
resource providers. This includes a lot of the marshaling goo required
to bridge between the gRPC plugin interfaces and the strongly typed
resource types and supporting marshalable structures.
This completes the major tasks of implementing CIDLC (pulumi/coconut#133),
and I have most of the AWS package running locally on it. There are
undoubtedly bugs left to shake out, but no planned work items remain.
This is an initial implementation of the Coconut IDL Compiler (CIDLC).
This is described further in
https://github.com/pulumi/coconut/blob/master/docs/design/idl.md,
and the work is tracked by coconut/pulumi#133.
I've been kicking the tires with this locally enough to checkpoint the
current version. There are quite a few loose ends not yet implemented,
most of them minor, with the exception of the RPC stub generation which
I need to flesh out more before committing.
As part of pulumi/coconut#133, we will be doing an IDL dialect of Go
plus a compiler, to support writing resource providers more easily.
This commit includes a design note for how it works.
In order to support output properties (pulumi/coconut#90), we need to
modify the Create gRPC interface for resource providers slightly. In
addition to returning the ID, we need to also return any properties
computed by the AWS provider itself. For instance, this includes ARNs
and IDs of various kinds. This change simply propagates the resources
but we don't actually support reading the outputs just yet.
This "strongly types" the aws.ARN type. In reality, it is simply an
alias for a string at the moment (as this is what it boils down to on
the wire), but this at least gets us some amount of compile-time safety.
This change includes resource IDL definitions for all of AWS API Gateway's
corresponding CloudFormation resource types. There are no actual provider
implementations yet.
This is a sample serverless function, written in Node.js, and exposed
over an HTTP API gateway endpoint.
It even works! (For Kubernetes Fission; the AWS support is dependent
upon projecting the various API gateway resource providers...)
This introduces an http.API abstraction to Mantle and implements it
for Kubernetes Fission. (The AWS implementation will come shortly,
but requires a fair bit of API Gateway elbow grease first.)
This lets you invoke a function in response to an API event:
let func = new mantle.func.Function(
(e, ctx, cb => { ... },
);
let api = new mantle.http.API("/hello", "GET", func);
This change renames two provider methods:
* Read becomes Get.
* UpdateImpact becomes PreviewUpdate.
These just read a whole lot nicer than the old names.
This change introduces TryLoadDynamicExpression. This is similar to
the existing LoadDynamicExpression opcode, except that it will return
null in response to a missing member (versus the default of raising
an exception). This is to enable languages like JavaScript to encode
operations properly (which always yields undefined/nulls), while still
catering to languages like Python (which throw exceptions).
This change flattens the Fission metadata property on the Coconut
side so that it is nicer to consume. Due to struct embedding in Go,
we need to perform translation at the serialization boundary anyway,
so the less-usable approach we had before didn't really buy us anything.
The Fission internal data structures reference one another by
name/URI. Coconut needs the graph with dependencies, however, so
we prefer to model things using real object references in these
situations. (This also makes it much nicer to program.) This
changes to fit the Coconut model better; the provider will then
turn around and present names/URIs to the various APIs.
The order of operations for stderr/stdout monitoring with plugins
managed to hide some important errors. For example, if something
was written to stderr *before* the port was parsed from stdout, a
very possible scenario if the plugin fails before it has even
properly sarted, then we would silently drop the stderr on the floor
leaving behind no indication of what went wrong. The new ordering
ensures that stderr is never ignored with some minor improvements
in the case that part of the port is parsed from stdout but it
ultimately ends in an error (e.g., if an EOF occurs prematurely).
This change introduces an @asset decorator in addition to a Code
asset type. The idea here is that compilers will recognize the
presence of @asset and react by spewing the code as a textual
asset, rather than an AST and/or actually getting compiled into IL.
This change introduces some resource IDL types for the Fission
project (https://github.com/fission/fission), which is a
functions-as-a-service (FaaS) substrate on top of Kubernetes.
It has a single configuration variable,
`kube-fission:config:controller`, which controls the address of
the Fission controller in the target Kubernetes cluster.
Someday, ideally we would rebuild this atop a more general
Kubernetes resource package, and add some sort of discovery of
this controller, to minimize the amount of manual configuration
required and to make it more resilient to self-healing operations.
This is IDL-only. The provider is coming soon.
Right now, we reject dashes in package names. I've hit this a few times and it annoys
me each time. (It would seem to makes sense to permit hyphens in package names, given
that [almost?] every other package manager on Earth does...)
No more! Hyphens welcome!
This change introduces decorator support for CocoJS and the corresponding
IL/AST changes to store them on definition nodes. Nothing consumes these
at the moment, however, I am looking at leveraging this to indicate that
certain program fragments are "code" and should be serialized specially
(in support of Functions-as-lambdas).
This introduces a new experimental cross-cloud package, Mantle. This is part
of getting pulumi/coconut#134 up and running.
For now, there isn't much here, except for configuration of the target cloud and
scheduler, plus the ability to create a cross-cloud function. (OK, it's not truly
cross-cloud yet, since we have only implemented AWS Lambdas.)
Mantle is, of course, a placeholder name. Since this is a higher level
abstraction than the unopinionated core primitives, the name mantle corresponds
to the Earth's upper layers (and I thought "Crust" would be a rather odd name).
