Knative Client release v0.19.1

This update contains back-ports of bug fixes and an additional kn s390x build.
See the CHANGELOG for full details.

• Fix a race condition when using Kubernetes watches
• Embed the namespace in request body while creating channels
• Add kn s390x binary to the release

Knative Client release v0.18.3

This minor update contains a back-port of a bug fix.
See the CHANGELOG for full details.

• Embed the namespace in request body while creating channels

Knative Client release v0.17.4

This minor update contains a back-port of a bug fix.
See the CHANGELOG for full details.

• Embed the namespace in request body while creating channels

Knative Client release v0.19.0

kn 0.19.0 introduces two new commands (kn service apply and kn service import) and removes some deprecated options, in addition to bug fixes and some other goodies described below.

Meta

The compile dependencies have been updated to Knative Serving 0.19.0 and Knative Eventing 0.19.0. There are no changes in the used API version for communicating with the backend.

Removed deprecated options

The following deprecated options have been removed:

• --async for all CRUD commands. Use --no-wait instead
• --requests-cpu, --request-memory, --limits-cpu and --limits-memory when managing services. The replacement is to use --limit memory=.. and --limit cpu=... (same for --request). Both options can be combined as in --limit memory=256Mi,cpu=500m

kn service apply

A new kn service apply command has been added to allow a declarative management for your Knative service.
This new command is especially useful in can CI/CD context to allow for idempotent operations when creating or updating services.
It works much like kubectl apply and used a client-side 3-way merge algorithm to update service. The kubectl merge algorithm is directly reused here.
As apply operates on Knative's custom resource types, it suffers the same limitation as the client-side merge algorithm in kubectl apply when dealing with CRDs.
I.e. arrays can't be merged but are just overwritten by an update.
This limitation affects all containers specific parameters.

For the future, we plan to add a better merge algorithm that supports a full strategic 3-way merge like the support of kubectl apply has for intrinsic K8s resources.

It is important to note that kn service apply is fundamentally different to kn service update as with kn service apply the full configuration needs to be provided as command-line options or within a declaration file when used with --filename.
With kn service update you only specify the parts to be updated and don't touch any other service configuration.
This characteristic of apply also implies that you always have to provide the image as the only mandatory parameter with kn service apply.

For example:

# Initially apply a service with the given image and env var
kn service apply random --image rhuss/random:1.0 --env foo=bar

# Update the service to add a ying=yang env var to the already existing one
kn service update random --env ying=yang

# Apply a full new configuration. Note that foo=bar will be removed
# because it is not specified here.
kn service apply random --image rhuss/random:1.0 --env ying=yang

kn service import

kn service import is the counterpart to kn service export and allows you to import a Service and all active revision that has been exported.
Active revisions are revisions that are referenced in a traffic-split.

This command is still marked experimental, and there are some known issues in the import how the generation of revision are created.
Please gives us feedback on how we can improve the support for this feature.

Other

The following other features have been added, too:

• An arm64 flavour has been added to the released artefacts, as well as a checksum.txt which caries the sha256sum of all artefacts.
• A channel: prefix has been added for --sink parameters, so that channels can be directly addressed by name.
• Aliases are now appearing correctly in the help messages
• The Client API as a new list filter WithLabel() which can be used when listing services.

---

You can find the full list of changes in the CHANGELOG.

Knative Client release v0.17.3

This minor update contains a back-port of an essential feature addition.
See the CHANGELOG for full details.

• Add channel sink prefix: A channel prefix is now supported with sink flag, for example: --sink channel:NAME.

Knative Client release v0.18.2

This minor update contains a back-port of an essential feature addition.
See the CHANGELOG for full details.

• Add channel sink prefix: A channel prefix is now supported with sink flag, for example: --sink channel:NAME.

Knative Client release v0.18.1

This minor update contains backports of essential fix and some minor feature additions.
See the CHANGELOG for full details.

• Fix for test flake when sync waiting and an intermediate error occurs
• Add WithLabel list filter to serving client lib

Knative Client release v0.17.2

This minor update contains backports of essential fix and some minor feature additions.
See the CHANGELOG for full details.

• Fix for test flake when sync waiting and an intermediate error occurs
• Add WithLabel list filter to serving client lib

Knative Client release v0.18.0

Release 0.18.0 of the Knative client kn comes with some bug fixes plus some additional support for Knative eventing features

Meta

The compile dependencies have been updated to Knative Serving 0.18.0 and Knative Eventing 0.18.0.

Eventing support

The kn channel support has been extended by a kn channel list-types which shows you all the channel types that are available in the cluster.
This information can be used to select the type when creating a channel with kn channel create.

Subscriptions which connect a sink with a channel can now be fully managed with kn subscription commands.

Aliases

For a better user experience we added some aliases for commonly used commands:

command	alias
service	ksvc
service	services
revision	revisions
route	routes
source	sources
broker	brokers
trigger	triggers
channel	channels
subscription	subscriptions
subscription	sub
plugin	plugins
list	ls

Other

Some other minor features has been added:

• You can use now --annotation-service and --annotation-revision to select the part of Knative service where you want to put an annotation on. With --annotation you add an annotation to both parts, the Knative service's annotation and to the annotation of the Pod template used to create revisions.
• A new option --scale-init allows to specify the initial number of pods that should be created when a Knative service is created. By default this number is one, but you can set it to 0 if you don't want to create a pod during service creation.

You can find the full list of changes in the CHANGELOG.

Knative Client release v0.17.1

Release 0.17.0 continues the journey to full Eventing support and adds some additional goodies.

Meta

The compile dependencies have been updated to Knative Serving 0.17.0 and Knative Eventing 0.17.0.

Eventing support

This release adds full support for managing Channel resources. It allows you to specify the channel type during creation and also to add some mappings of GVK coordinates to symbolic names in your configuration.

Plugin Inline Support

It is possible now to create custom variations of kn that can inline golang based plugins into a single binary. See the plugin README for a brief explanation about the mechanics. More documentation and examples pending.

It is important to note, that kn as released from this repository will not inline any plugins. It just provides the hooks for enabling plugin inlining.

New features

Additionally the following features and fixes have been added:

• kn source list use now an own list type for heterogeneous lists
• Client side volume name generation has been fixed
• NAMESPACE header column has been added to kn source list -A
• Add support to combine kn service create --filename with other options
• List only built-in sources if access to CRDs is restricted

You can find the full list of changes in the CHANGELOG