knative
/
client
mirror of https://github.com/knative/client.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
client/docs
History
Roland Huß 164cb5f362
feature(source binding): Support for Sink Binding as source (#625) 
* feature(source binding): Support for Sink Binding as source

Sink bindings are managed like any other source. Sinks are specified as usual (with prefix and name),
'subjects' (the other end of the binding) is managed via a shortcut notation:

* with name: `<kind>:<apiVersion>:<name>`
* with label selector: `<kind>:<apiVersion>:key1=value1,key2=value2`

With `--subject-namespace` and additional namespace can be provided (shoudl be possible for a sink, too but is not yet)

The implementation already uses the new sink binding from the `sources.knative.dev` group
and hence is a bit inconsistent to the still old usage kf `sources.eventing.knative.dev` for apiserver source and cronjob.

However as we will move over to `sources.knative.dev` very soon (right after v0.12.0) release,
this is was more appropriates.

Still WIP, but eventually fixes #624

Task list:

- [X] create
- [] update
- [] delete
- [] describe
- [] list

* fix(source binding): Added missing commands

Also, it looks like that knative eventing 0.12.0 is still on the old api group.
So I need to move this code to use the legacyclient, too, for the sink binding
and only switch over to the new client for 0.13.0

* feature(source binding): Added missing subcommands

* update
* delete
* list
* describe

* fix(source binding): Removed --subject-namespace as this namespace cant b set.

Tuned describe output a bit.

* feat(source binding) add support for CeOverride

* fix: Worked on review comments

* fix: review comments

* fix: names in binding client
 		2020-01-29 12:08:27 -08:00
..
cmd feature(source binding): Support for Sink Binding as source (#625) 2020-01-29 12:08:27 -08:00
operations Add navigation for management section (#436) 2019-10-08 07:47:36 -07:00
plugins Restructure Docs (#421) 2019-09-30 07:33:45 -07:00
traffic Restructure Docs (#421) 2019-09-30 07:33:45 -07:00
workflows chore(docs): Updates basic workflow doc (#502) 2019-11-13 05:16:27 -08:00
README.md Adds kn nightly and latest release image URL in docs (#466) 2019-10-31 00:51:12 -07:00

README.md

kn

kn is the Knative command line interface (CLI).

Getting Started

Installing kn

You can grab the latest nightly binary executable for:

Put it on your system path, and make sure it's executable.

Alternatively, check out the client repository, and type:

go install ./cmd/kn

To use the kn container image:

  • Nightly: gcr.io/knative-nightly/knative.dev/client/cmd/kn
  • Latest release: gcr.io/knative-releases/knative.dev/client/cmd/kn

Connecting to your cluster

You'll need a kubectl-style config file to connect to your cluster.

  • Starting minikube writes this file (or gives you an appropriate context in an existing config file)
  • Instructions for Google GKE
  • Instructions for Amazon EKS
  • Instructions for IBM IKS
  • Instructions for Red Hat OpenShift.
  • Or contact your cluster administrator.

kn will pick up your kubectl config file in the default location of $HOME/.kube/config. You can specify an alternate kubeconfig connection file with --kubeconfig, or the env var $KUBECONFIG, for any command.

Kn Config

There are a set of configuration parameters you can setup to better customize kn. In particular, you can specify where your kn plugins are located and how they are found. The kn configuration file is meant to capture these configuration options. Let's explore this file's location, and the options you are able to change with it.

Location

The default location kn looks for config is under the home directory of the user at $HOME/.kn/config.yaml. It is not created for you as part of the kn installation. You can create this file elsewhere and use the --config flag to specify its path.

Options

There are two options you can specify in the kn config file and they are related to how kn locates plugins.

  1. pluginsDir which is the same as the persistent flag --plugins-dir and specifies the kn plugins directory. It defaults to: ~/.kn/plugins. By using the persistent flag (when you issue a command) or by specifying the value in the kn config, a user can select which directory to find kn plugins. It can be any directory that is visible to the user.

  2. lookupPluginsInPath which is the same as the persistent flag --lookup-plugins-in-path and specficies if kn should look for plugins anywhere in the specified PATH environment variable. This is a boolean configuration option and the default value is false.

For example, the following kn config will look for kn plugins in the user's PATH and also execute plugin in ~/.kn/plugins.

cat ~/.kn/config.yaml
lookupPluginsInPath: true
pluginsdir: ~/.kn/plugins

Commands

Plugins

Kn supports plugins, which allow you to extend the functionality of your kn installation with custom commands as well as shared commands that are not part of the core distribution of kn. See the plugins documentation for more information.

More information on kn: