triggermesh / aws-custom-runtime

Knative Function Using the AWS Lambda Runtime API

The TriggerMesh Cloud Native Integration Platform consists of a set of APIs which allows you to build event-driven applications. Implemented as a set of Kubernetes CRDs and a Kubernetes controller, it gives you a way to declaratively define your event sources and event targets, in addition to potential actions needed in your applications: content-based event filtering, event splitting, event transformation and event processing via functions.

Getting Started

• Guides
• Documentation

Installation

To install TriggerMesh, follow the installation instructions.

TL;DR

Register TriggerMesh APIs by deploying the Custom Resources Definitions:

kubectl apply -f https://github.com/triggermesh/triggermesh/releases/latest/download/triggermesh-crds.yaml

Deploy the platform:

kubectl apply -f https://github.com/triggermesh/triggermesh/releases/latest/download/triggermesh.yaml

Namespaced installation

By default, TriggerMesh works with resources across all namespaces in the Kubernetes cluster. This requires permissions provided by ClusterRoles and ClusterRoleBindings. If cluster-wide permissions are not desired, TriggerMesh can be configured to run in a single namespace. To get the namespace-scoped installation, first, deploy the CRDs:

kubectl apply -f https://github.com/triggermesh/triggermesh/releases/latest/download/triggermesh-crds.yaml

And then, using kubectl's "kustomization" feature, install customized manifests:

kubectl apply -k config/kustomization/namespaced/

Controllers created with this command won't reconcile resources outside the triggermesh namespace, ClusterRoleBindings will have the namespace scope.

Contributing

Please refer to our guidelines for contributors.

Commercial Support

TriggerMesh Inc. offers commercial support for the TriggerMesh platform. Email us at [email protected] to get more details.

License

This software is licensed under the Apache License, Version 2.0.

Additionally, the End User License Agreement included in the EULA.pdf file applies to compiled executables and container images released by TriggerMesh Inc.

aws-custom-runtime's Issues

Prometheus metrics exporter

KLR Functions should export basic metrics such as Events processing count, latencies, etc.

Add C++ example

https://aws.amazon.com/blogs/compute/introducing-the-c-lambda-runtime/

Replace task queues with channels

Add Rust example

https://aws.amazon.com/blogs/opensource/rust-runtime-for-aws-lambda/

Add circleCI build and automated release on tag

Add example for nodejs function

Add example for Python function

Please Update README.md

README.md is

aws-custom-runtime/README.md

Line 145 in be9735d

RESPONSE_WRAPPER: CLOUDEVENTS

But, implementation is

aws-custom-runtime/main.go

Line 75 in be9735d

ResponseFormat string `envconfig:"response_format"`

Get rid of hardcoded version tag from buildtemplates

and make them fetch latest release
Update CI config after its done

Fix task id matching

ISSUE: TM Function does not handle inner reference response

Per the triggermesh docs ->

"Functions may be used to implement custom event flow logic"

Expectation:

Using a function to do a custom/complex transformation before reaching an inner processing ksvc will perform the transformation and return the result of the ksvc.

Reality:

It does the custom transformation, but the response is nil.

https://github.com/triggermesh/aws-custom-runtime/blob/main/pkg/sender/sender.go#L56

Simple Example

# perform modification (only user code part) to attestation input
apiVersion: extensions.triggermesh.io/v1alpha1
kind: Function
metadata:
  name: custom-tsf
  namespace: default
spec:
  runtime: python
  public: true
  entrypoint: main
  sink:
    ref:
      name: example-inner
      namespace: default
      kind: Service
      apiVersion: serving.knative.dev/v1
  code: |
    def main(payload, context):
        payload['metdata'] = 'some change'

        return payload

hitting this function will always return nil, because it sends to an inner ksvc, I do not think you should have to create a sinkbinding or assume the broker for the inner ksvc each time to return the event...I think it should match the flow of a transformation which returns it to the same broker the transformation reads from (same with a filter).

It just seems like the function is unique in this regard, and it breaks expectations.

AWS_LAMBDA_RUNTIME_API is hardcoded and can't be overwritten

If InternalAPIport is changed to something else than 80 (which is the default value), functions are not starting because AWS_LAMBDA_RUNTIME_API is hardcoded to be just 127.0.0.1.

AWS_LAMBDA_RUNTIME_API should probably be 127.0.0.1:<InternalAPIport>?

Relates to triggermesh/knative-lambda-runtime#48

RUST build fails

bash example works great.

rust fails at:

docker run --rm --user "$(id -u)":"$(id -g)" -v "$PWD":/usr/src/myapp -w /usr/src/myapp rust:1.30.0 cargo build -p lambda_runtime --example basic --release
...
 Downloading backtrace-sys v0.1.24
 Downloading rustc-demangle v0.1.9
 Downloading cc v1.0.25
 Downloading ryu v0.2.6
   Compiling lambda_runtime_client v0.1.0 (/usr/src/myapp/lambda-runtime-client)
error: Edition 2018 is unstable and only available for nightly builds of rustc.

error: Could not compile `lambda_runtime_client`.

To learn more, run the command again with --verbose.

Handle error endpoints

Add unittest

Don't log debug information at info level

The log entries generated by these calls are very very expensive to store:

aws-custom-runtime/main.go

Line 152 in bf63bce

log.Printf("<- %s\n", task.id)

aws-custom-runtime/main.go

Line 176 in bf63bce

log.Printf("-> %s %d\n", resp.id, resp.statusCode)

Update CI

CI pipeline must include test run and linter checks, release procedure, etc.

Add K_SINK support

aws-custom-runtime: add CI infrastructure