triggermesh / function Goto Github PK

3.0 3.0 1.0 522 KB

License: Apache License 2.0

Makefile 17.47% Dockerfile 1.22% Go 77.62% Shell 3.70%

function's Introduction

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

Installation

To install TriggerMesh, follow the installation instructions.

TL;DR

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.

function's People

Contributors

Stargazers

Watchers

Forkers

ekmixon

function's Issues

No way to read CloudEvent context attributes

Some events contain important information inside CloudEvent context attributes. For example

Google Cloud Storage events contain:

bucketid the bucket where the event originates from
eventtype what happened (create/update/delete)
objectid the name of the object (file) which was modified

Azure Blob Storage events contain:

subject a reference to the blob which was modified, contains the name of the storage container + the file name

If we can't access these, we are in some situations unable to generate a complete payload, depending on the target behind the transformer.

Empty K_SINK propagated to underlying Knative Service when sink isn't ready

I have a Function with the following sink configured:

  sink:
    ref:
      apiVersion: targets.triggermesh.io/v1alpha1
      kind: SlackTarget
      name: chat-notifications

The sink is not ready yet:

$ kubectl get slacktargets.targets.triggermesh.io
NAME                 URL   READY   REASON               AGE
chat-notifications         False   AdapterUnavailable   21m

However, the Function service is created immediately with an empty K_SINK, instead of waiting for the sink to become ready.

This causes unexpected behaviours because, instead of waiting for everything to be up, Triggers immediately fire events at the Function, which replies directly to the sender instead of shipping those events where they were supposed to be sent. As a result, the sender understands that everything went as expected, yet the final destination never received the payload.

It might be safer to report "NotReady" in the Function status if the sink's URL can't be determined, so that subscriptions pause the event flow.