knative / eventing

Event-driven application platform for Kubernetes

Knative Eventing - The Event-driven application platform for Kubernetes

Secure event processing and discovery with CloudEvents

What is Knative Eventing?

Knative Eventing is a collection of APIs that enable you to use an event-driven architecture with your applications. You can use these APIs to create components that route events from event producers (known as sources) to event consumers (known as sinks) that receive events. Sinks can also be configured to respond to HTTP requests by sending a response event.

Knative Eventing is a standalone platform that provides support for various types of workloads, including standard Kubernetes Services and Knative Serving Services.

Knative Eventing uses standard HTTP requests to route events from event producers to event consumers, following the rules set by the CloudEvents specification. This is a standard set up by the CNCF that has wide support for many programming languages, making it easy to create, understand, send, and receive events.

Knative Eventing components are loosely coupled, and can be developed and deployed independently of each other. Any producer can generate events before there are active event consumers that are listening for those events. Any event consumer can express interest in a class of events before there are producers that are creating those events.

What to expect here?

This repository contains an eventing system that is designed to address a common need for cloud native development:

1. Services are loosely coupled during development and deployed independently
2. A producer can generate events before a consumer is listening, and a consumer can express an interest in an event or class of events that is not yet being produced.
3. Services can be connected to create new applications
   • without modifying producer or consumer, and
   • with the ability to select a specific subset of events from a particular producer.

More on Knative Eventing

The high level mission of Knative Eventing is: Enable asynchronous application development through event delivery from anywhere.

For the full mission of Knative Eventing see docs/mission.md.

For complete Knative Eventing documentation, see Knative eventing or Knative docs to learn about Knative.

If you are interested in contributing, see the ready to work issues, CONTRIBUTING.md, DEVELOPMENT.md and Knative working groups.

Interested users should join knative-users.

eventing's Issues

Resource status for Bus, Channel and Subscription

Expected Behavior

The Bus, Channel and Subscription resources should update their status to reflect their current state

Actual Behavior

No status is tracked

Additional Info

Refs #88 (comment)

/assign scothis

Prevent mutation of Bus/Channel references in Channels and Subscriptions

Expected Behavior

When a channel resource is created, it specifies the bus to be provisioned on. That bus will then manage the channel and subscriptions for the channel. The channel should not be able to mutate to later point to a different bus. Instead, the channel should be deleted and a new channel created.

Actual Behavior

When the channel's bus reference is changed from A to B, the channel is concurrently unprovisioned from A and provisioned on B. There is a period where a request for a channel could be routed to a bus that no longer hosts that channel. Likewise, all subscriptions for that channel need to be re-estabilied on the new bus.

Additional Info

The same concerns also apply to how subscription resources reference a channel.

Logically migrating a channel from one bus to another is a deletion and an addition. Since we cannot provide a zero downtime migration, it's better to force the deletion and creation semantics on users.

An admission controller webhook can preform this validation. There is no such webhook in eventing currently, but it can be modeled on the webhook in serving.

Refs #88 (comment)

/assign scothis

We should have a single tool for event encoding

Expected Behavior

Codebase can consistently marshal events to/from HTTP

Actual Behavior

Codebase/demos do not concern themselves with CloudEvents

Create a Bus backed by Kafka

Kafka can provide message broker capabilities for both on-prem and cloud hosted clusters. The bus should be able to:

• connect to a pre-provisioned kafka cluster
• create/delete kafka topics for channels
• create/delete kafka consumer for channel subscriptions
• publish events received on a channel to the kafka topic
• receive events from a kafka consumers and dispatch to the channel subscriber

Unknowns

• how to best manage consumer groups

prow OWNERS file missing

Expected Behavior

prow PR approval process suggests reviewers from OWNERS file

Actual Behavior

No reviewers suggested because there is no OWNERS file

Steps to Reproduce the Problem

1. Create a PR, or look at existing #18 and note that
   under "We suggest the following additional approvers:" there are no suggestions.

OpenAPI schema for API types

We should have OpenAPI validations for the API types to ensure basic type safety and schema. The kubebuilder project can simplify the generation of this schema and make it easy to add additional basic validation rules (what can be expressed as an OpenAPI rule, anyway).

Rename binding to eventing

To more correctly reflect the content, rename the repo to eventing

As a partner evaluating the Eventing API I want the elafros/eventing API to to describe the v1beta2 API, so that I am seeing the current proposed version

Expected Behavior

This repo should show the v1beta2 version of the Eventing API.

Actual Behavior

This repo shows a variation of the API with extra features that we are considering for inclusion in the API in a future iteration.

Steps to Reproduce the Problem

View
https://github.com/elafros/eventing/blob/master/pkg/apis/bind/v1alpha1/bind_types.go

Change namespace to match that of the knative standard

Expected Behavior

namespaces are consistent. knative-serving-system, hence propose: knative-eventing-system

Actual Behavior

They are not

Additional Info

knative/serving#1034

Align Bind.Spec.Action and Subscription.Spec.Subscriber

Expected Behavior

Bind.Spec.Action and Subscription.Spec.Subscriber both indicate the destination where traffic should be sent. Both Bind and Subscription should use an similar (if not the same) struct, and use the same resolution logic.

Actual Behavior

Bind.Spec.Action is a struct with routeName or channelName, while Subscription.Spec.Subscriber is a string.

Additional Info

Refs #117 (comment)

Change binding example service accounts to be more tightly scoped.

Expected Behavior

Don't give a cluster-admin to binder service account. The README mentions that you shouldn't run in prod, but as pointed out by @scothis , there are people who will not read that :) So, as a follow on PR, we should tighten up the permissions that we use in our examples to be bare minimum.

Actual Behavior

It does.

Cluster- and Namespace- scoped Busses

#117 was evocative of some lessons that @vaikas-google and I have learned in the service-catalog project and I wanted to write them up because I think they are relevant to the question of cluster- or ns- scoped resources for Bus and possibly other resources in the eventing project.

In service-catalog, there is a thing called a 'service broker', which provides a set of 'services' (a capability that can be provisioned/deprovisioned) - which have 'plans' (tier of a service). Initially, we built a cluster-scoped set of resources to model these concepts in the service-catalog. This was a simple model to adopt and allowed us to avoid the problem of potentially having large numbers of namespaces that needed the same resources. It also allowed us to punt on the question of referencing services and plans across namespaces (cross-namespace references are currently a grey area in k8s).

We built this functionality first because it was easiest and convenient. However, we found that this was insufficient for how people wanted to use the catalog. What our users really wanted in the service-catalog project is a rich set of RBAC-driven ACL-filtering capabilities to share services/plans so that users had a view of these resources based on what they were permissioned to see. Unfortunately, there is not an tractable general path to ACL-filtering APIs in kubernetes, and there are some fundamental hurdles:

• k8s authorizers may be entirely external to the cluster and change out of band relative to k8s
• Not all authorizers can report a list of the subjects that are authorized for a resource

The experience that we could deliver (since we had to be backward compatible with the original cluster-scoped resources that we had released) was to have both cluster-scoped and ns-scoped versions of the broker, service class, and plan resources.

• The cluster scoped resources are things everyone in a cluster should be able to see/use
• The ns-scoped resources are used to put highly-privileged things into individual namespaces that should have access to them
• Developers can use ns-scoped resources to build new brokers and test them in the privacy of their own namespace

Note that in this model, access control is meaningful only at the level of a namespace - you cannot acheive further subdivision than the entire collection of a resource in a namespace. There are also two very similar sets of resources that have to be kept in sync - the cost is non-zero for doing two sets of resources.

More recently, in the cluster-registry, we had a similar tension between the cluster and namespace scope. The tension in this case is one of running the cluster registry as an aggregated API vs running as a standalone component. What we ultimately decided to do is:

• Make the Cluster resource (that literally represents a k8s cluster) ns-scoped
• Have a well-known resource to hold the resources that should be available to everyone

I'm not sure if such a setup would be possible for us to use, but thought I would mention it for completeness. I think what this would imply for our API is that all references to the Bus type (as the example that started this braindump) would be implicitly namespace scoped and implicitly to the namespace of the referencing object unless a namespace was explicitly supplied. There are things to think through about how authorization checks would be performed and what failed checks would mean for references across namespaces. The benefit here would be more cohesive API - no jumping between cluster- and ns-scoped variants of the same resource, less API surface to learn, etc. The cost is that this is relatively unexplored territory, and being among the first to do something can be confusing and painful.

I realize that I'm late to the party here and certainly not demanding any work change course because of this, but I thought I would share my experiences here because they seem relevant. This is a tricky area and one where the UX that k8s can provide currently doesn't exactly match what users seem to want.

go vet warnings

Expected Behavior

go vet should pass

Actual Behavior

# go vet github.com/knative/eventing/...
# github.com/knative/eventing/pkg/event
pkg/event/event.go:58: struct field tag `json":event-id"` not compatible with reflect.StructTag.Get: bad syntax for struct tag pair
# github.com/knative/eventing/pkg/apis/eventing/v1alpha1
pkg/apis/eventing/v1alpha1/bind_types.go:127: struct field tag `json:trigger"` not compatible with reflect.StructTag.Get: bad syntax for struct tag value
# github.com/knative/eventing/pkg/client/clientset/versioned/fake
pkg/client/clientset/versioned/fake/clientset_generated.go:56: literal copies lock value from fakePtr: github.com/knative/eventing/vendor/k8s.io/client-go/testing.Fake

Steps to Reproduce the Problem

Additional Info

last warning is being addressed in kubernetes/kubernetes#60584

Rename this repo to events

Expected Behavior

Actual Behavior

Steps to Reproduce the Problem

Additional Info

[Event Type] Time based event sources (cron, interval, once)

Expected Behavior

As a user, I would like to run an action based on time.
I have 3 use cases:
cron
Run action myaction based on cron syntax (ie "*/5 * * * 5")
With optional parameters with startDate and/or stopDate

interval
Not all interval can be accomplish with cron syntax
Run action myaction based on a minute interval syntax (ie "12")
With optional parameters with startDate and/or stopDate

once
Run action myaction once at specific date (ie. 12/31/2019 23:59)
Delete trigger and rules/subsciption this trigger will never fire again

Additional Info

We should clean binder pods when done.

Expected Behavior

After binding / unbinding, the jobs don't hang around for too long.

Actual Behavior

They never get cleaned up

Steps to Reproduce the Problem

Additional Info

Create Issue and PR templates

Core API objects are renamed to match reviewed APIs

The name of the "Bind" CRD is temporary and very likely to change. We will update all references to "Bind" in one PR but outstanding PRs may break as the rename is merged. We will try to make this global change in less than one month.

GitHub demo events should be usable with any action (currently hard-coded to ElaRoutes)

Expected Behavior

GitHub events should be useable with any aciton

Actual Behavior

GitHub event source directly wires a GitHub webhook to an externally visible Ela route.

Steps to Reproduce the Problem

1. Run GitHub sample

Additional Info

To correctly fix this, the GitHub proxy will be responsible for exposing a "ReceiveAdapter" that will act as the gateway between GitHub and the event system. It should reformat webhook responses as Events and send them to the delivery service.

Events can trigger Functions

Creating Events and Mapping them to Functions should require just a few commands

Create a Google cloud function

gcloud functions ....

List available events (sources and event types)

...

Map events to a function:

kubectl apply -f https://events.elafros.io/example-event-binding.yaml

Create a Bus backed by the Serverless.com Event Gateway

The Serverless.com Event Gateway is capable of dynamically receiving forwarding HTTP requests. This bus could serve as a more robust implementation of the current stub-bus. The bus should be able to:

• connect to a pre-provisioned etcd database
• create/delete a serverless gateway function and subscription for each channel subscription
• receive HTTP events and dispatch to channel subscribers

Unknowns:

• serverless http events route by method and path, while the bus indicates channel by host header
• how to best interact with the configuration api
• how to save identifiers for created functions and subscriptions (Subscription status?)
• is it possible to drive the configuration directly rather then via etcd?

Use Job to run bind and unbind containers

Currently the ContainerEventSource starts a Pod to run bind and unbind containers. This isn't terrible but using a Job has a couple advantages over a Pod:

• Unlike a bare Pod, Pods owned by Jobs are recreated when the nodes they're running on fail or reboot. See https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#bare-pods.
• Jobs have more sophisticated retry handling including completion deadlines and retry limits.

Jobs are otherwise similar to Pods, so the code won't have to change much.

/cc @vaikas-google

Repo is approachable to new contributors

We need some additional material in the repo for it to make sense to people in the community -- initial focus is on potential collaborators

• roadmap
• open issues for anything that is being worked on
• proposals for near-term features / improvements being disussed

Properly setup tide for eventing

Expected Behavior

Tide automatically merges PRs that passed all checks.

Actual Behavior

PRs are merged manually, at any time.

DEVELOPMENT.md links to missing testing page

Expected Behavior

https://github.com/elafros/eventing/blob/master/DEVELOPMENT.md links to test/README.md.

Link should exist or text should be removed.

Actual Behavior

test/README.md does not exist

Steps to Reproduce the Problem

1. Navigate to https://github.com/elafros/eventing/blob/master/DEVELOPMENT.md
2. Click "see the test docs"
3. Get 404

Additional Info

Do not return from Bind until receive adapter is up completely.

Expected Behavior

Bind will not be returned (and hence marked as ready) until it's totally up.

Actual Behavior

Bind (for example k8sevents) will consider creation of a Deployment a success, deployment might not be up yet however.

Steps to Reproduce the Problem

1. Create a binding (sample/k8s_events_function)
2. As soon as you create the binding and it's marked as status ready check the pods for sub* pods
3. They are not ready.

Additional Info

Create presubmit tests

Expected Behavior

Tests are run by prow during presubmit.

Actual Behavior

No tests are run during presubmit.

Steps to Reproduce the Problem

1. Create a PR.
2. No tests are run.

Use eventing-webhook to validate bind action

Expected Behavior

After #111, Bind's Action property can be either a Route or Channel name. It's ambiguous to set both properties, any attempt to set both should be rejected.

Actual Behavior

Both the routeName and channelName can simultaneously be set

verify-codegen should be part of CI

Expected Behavior

Discrepancies between structs and generated informer code should be caught before they get merged into master

Actual Behavior

You scratch your head for 1hr trying to understand what you've done wrong with your yaml file

As a contributor, I want a CODE_OF_CONDUCT.md in the repo, so I know the expectations for behavior in this community.

Expected Behavior

A CODE_OF_CONDUCT.md in the repo.

Actual Behavior

No such file.

Get Prow setup

• bot set up
• OWNERS file
• figure out why LGTMs aren't working
• write down the process we're following for PR review

Determine API contract for Subscriber/Channel parameters/arguments vs monitor behavior

Currently, the API contract for Subscriber and Channel is very hazy with regard to Subscriber/Channel Parameters/Arguments expectations. I've done some initial documenting of today's behavior in:

• #141
• #139
• #137

Currently, the behavior of the Monitor is what drives these APIs - but you should not need to use the monitor to implement a Bus. So, we should determine what the API validation rules and API guarantees are that Bus implementations should have to do vs. what the current behavior of the monitor is.

Events utility is out of date

Expected Behavior

The request encoding of events should conform to Cloud Events 0.1 (to be ratified 2018-04-20).

Actual Behavior

The request encoding does not use the CE- prefix for headers, support %encoding, nor support the "Structured" encoding format approved in 2018-04-19

Steps to Reproduce the Problem

1. Read https://github.com/cloudevents/spec
2. Read pkg/events

Additional Info

README for sample github pull request is out of date.

Expected Behavior

sample README for github pullrequest works

Actual Behavior

it doesn't it's out of date

Steps to Reproduce the Problem

1. Look at the sample, try to run it
2. doesn't work

Additional Info

Bind.Spec.Action should support multiple kinds of actions

Expected Behavior

The eventing framework should support multiple kinds of actions in response to an event

Actual Behavior

Bind.Spec.Action has only the field "ElaRoute"

Steps to Reproduce the Problem

Run GitHub demo

Additional Info

Blocked on #41

Easy Installation

Create a Kubernetes 1.10+ cluster:

gcloud container clusters create events

Deploy the eventing control plane:

kubectl apply -f https://events.elafros.io/eventing.yaml

End to end tests installing Istio is a bit flaky

Expected Behavior

Setting up the istio manifest should just work

Actual Behavior

it seems to fail

Steps to Reproduce the Problem

1. ./test/e2e-tests.sh
2. reports that Istio failed
3. actually didn't seem to fail

Additional Info

TEST Prints out:
Waiting until all pods in namespace istio-system are up......................................................................................................................................................

ERROR: timeout waiting for pods to come up
NAME READY STATUS RESTARTS AGE
istio-citadel-ff5696f6f-9frnj 1/1 Running 0 6m
istio-cleanup-old-ca-9xth7 0/1 Completed 0 6m
istio-egressgateway-58d98d898c-h4gdh 1/1 Running 0 6m
istio-ingress-6fb78f687f-hsnwd 1/1 Running 0 6m
istio-ingressgateway-6bc7c7c4bc-9m78j 1/1 Running 0 6m
istio-mixer-post-install-54zjs 0/1 Error 0 7m
istio-mixer-post-install-wf4nw 0/1 Completed 0 6m
istio-pilot-6c5c6b586c-7nx8c 2/2 Running 0 6m
istio-policy-5c7fbb4b9f-q7cq7 2/2 Running 0 6m
istio-sidecar-injector-dbd67c88d-2kl9z 1/1 Running 0 6m
istio-statsd-prom-bridge-6dbb7dcc7f-zc6tk 1/1 Running 0 6m
istio-telemetry-54b5bf4847-rtw2n 2/2 Running 0 6m
namespace "default" labeled

But this looks to be a race condition when we're trying to create resources that are not installed yet, looking at the logs:
vaikas@vaikas:~$ kubectl -n istio-system logs istio-mixer-post-install-54zjs
2018-06-14 18:17:22.415929 I | proto: duplicate proto type registered: google.protobuf.Any
2018-06-14 18:17:22.416098 I | proto: duplicate proto type registered: google.protobuf.Duration
2018-06-14 18:17:22.416134 I | proto: duplicate proto type registered: google.protobuf.Timestamp
attributemanifest "istioproxy" created
attributemanifest "kubernetes" created
stdio "handler" created
logentry "accesslog" created
rule "stdio" created
metric "requestcount" created
metric "requestduration" created
metric "requestsize" created
metric "responsesize" created
metric "tcpbytesent" created
metric "tcpbytereceived" created
prometheus "handler" created
rule "promhttp" created
rule "promtcp" created
kubernetesenv "handler" created
rule "kubeattrgenrulerule" created
rule "tcpkubeattrgenrulerule" created
kubernetes "attributes" created
unable to recognize "/tmp/mixer/custom-resources.yaml": no matches for networking.istio.io/, Kind=DestinationRule
unable to recognize "/tmp/mixer/custom-resources.yaml": no matches for networking.istio.io/, Kind=DestinationRule

vaikas@vaikas:~$ kubectl -n istio-system logs istio-mixer-post-install-wf4nw
2018-06-14 18:17:48.339209 I | proto: duplicate proto type registered: google.protobuf.Any
2018-06-14 18:17:48.339310 I | proto: duplicate proto type registered: google.protobuf.Duration
2018-06-14 18:17:48.339341 I | proto: duplicate proto type registered: google.protobuf.Timestamp
attributemanifest "istioproxy" configured
attributemanifest "kubernetes" configured
stdio "handler" configured
logentry "accesslog" configured
rule "stdio" configured
metric "requestcount" configured
metric "requestduration" configured
metric "requestsize" configured
metric "responsesize" configured
metric "tcpbytesent" configured
metric "tcpbytereceived" configured
prometheus "handler" configured
rule "promhttp" configured
rule "promtcp" configured
kubernetesenv "handler" configured
rule "kubeattrgenrulerule" configured
rule "tcpkubeattrgenrulerule" configured
kubernetes "attributes" configured
destinationrule "istio-policy" created
destinationrule "istio-telemetry" created

Make Bus a cluster scoped resource?

Many buses are infrastructure that should be managed by an operations team. For example, the Kafka bus needs to connect to a pre-provisioned Kafka broker.

Expected Behavior

Buses should often be provisioned by a cluster operator. Channels and Subscriptions are created by developers to consume the bus's capabilities. Likewise, resources in different namespaces should be able to consume the same bus without needing to provision the same bus within each namespace.

Actual Behavior

Bus, Channel and Subscription are all namespaced resources, and do not work outside of a single namespace. Likewise, the developer must provision and manage the bus.

Additional Info

We may want developers to be able to create simple buses (like StubBus) without bugging an operator. In that case, we can introduce both a ClusterBus and Bus resources. In the future, we may also want to limit which namespaces have access to a cluster wide bus.

Refs slack and #88

/kind discussion
cc @vaikas-google @evankanderson @grantr

Event sources should be decoupled from actions

Expected Behavior

Any EventSource should only have to know about a single service with a single interface. They should not be expected to understand the quirks of each particular action nor need to wait for an action to succeed/fail.

Actual Behavior

Our current demo wires GitHub events directly to Elafros routes

Steps to Reproduce the Problem

Follow the GitHub demo

Additional Info

This is a back-filed issue for #40

as a developer, I would like a glossary so I can map specific terms to concepts

A lot of the naming is in flux, so it would be good to keep our own glossary of terms and then we can do renaming consistently when we settle on good terms for the eventing concepts (which are currently called different things by different platforms/companies).

Also, event later, I think it would help folks who are new to the project to have a glossary of terms

Determine format and add validation for Parameter/Argument names

This issue is to determine the format of and add validations for the name fields of Parameters and Arguments. My initial suggestion would be to use the same validation formats as secret and configmap keys. These were initially very restrictive but have been relaxed to allow users to use them in the way they liked.

Do not allow EventSource / EventType to be deleted if there are bindings to them.

Expected Behavior

If there's a binding, you should not be able to remove an event source since you can lose the bind container.

Actual Behavior

you can delete an event source even if there's a binding referring it.

Steps to Reproduce the Problem

1. create an event source / event type
2. create a binding referring those
3. delete event source
4. binding is left orphaned

Additional Info

Registering Event Sources & Event Types

In de-coupling of services that generate events and services that consume events, it accelerates developer velocity to be able to list the available event sources and see what types are available. This also allows for reporting errors (or warnings) during development and deployment.

Create a Bus backed by Google Cloud Pub/Sub

For GKE/GCP hosted clusters, Cloud Pub/Sub provides message broker capabilities in a hosted environemnt. The bus should be able to:

• create/delete pub/sub topics for channels (namespaced appropriately)
• create/delete pub/sub subscriptions for channel subscriptions
• publish events received on a channel to the pub/sub topic
• receive events from pub/sub subscriptions and dispatch to channel subscribers

/kind enhancement
/assign scothis

It should be possible to pass secret values for Arguments

It's currently possible only to provide a literal, inline value for an Argument. It should also be possible to pass a value that comes from a secret key. Possible API:

<snip>
  arguments:
  - name: MY_ARGUMENT
    secretValue:
      name: my-secret
      key: my-key

Build fails when forked after rename

May need to rename the repo back to "binding" until the naming decision is made or go through with the src code renaming now. I vote for the former.

Add ability to specify Service Account a Bind should run

Expected Behavior

There could be different Service Accounts that a particular bind action should run as. There's no way to specify this currently.

Actual Behavior

Can't specify a different Service Account. This should probably be a new field in the Bind crd.

Introduce a ClusterEventSource / ClusterEventType

Expected Behavior

As per discussion in the eventing channel and other forums. There's an expectation that there should be a way for an Operator to create "blessed" EventSources that are shared between all users of a cluster. You could achieve this today by having a well known namespace, but the consensus is that a Cluster* makes it more clear that these are possibly more vetted. We should still keep the existing namespaced EventSource / EventType to ensure that developers can experiment, or departmens and so forth can install Event Sources that are not visible outside the scope that they want to restrict it to.

stocks sample always display "stock not found"

Expected Behavior

Stock price should be displayed.

Actual Behavior

Stocks sample always display "stock not found".

Steps to Reproduce the Problem

1. Run the sample against a knative serving cluster (just follow the instructions in the README file).

Additional Info

Will found this issue while trying the samples. The root cause is that the app is unable to access external APIs. He also figured out the solution: you need to add a ServiceEntry with api.iextrading.com as a host for it to work, otherwise every external API call will fail.

This service entry makes it work:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
 name: iextrading
spec:
 hosts:
 - api.iextrading.com
 ports:
 - number: 443
   protocol: HTTPS

Add .bazelrc

Expected Behavior

Builds on Mac for K8s cluster on Linux

Actual Behavior

Builds fine but controller image crashes on start (CrashLoopBackOff)

Steps to Reproduce the Problem

1. bazel run :everything.apply
2. kubectl -n bind-system get pods

Additional Info