Add documentation for Brokers changing channel provisioners.#996
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Harwayne The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/assign @Abd4llA |
|
@Harwayne: GitHub didn't allow me to assign the following users: Abd4llA. Note that only knative members and repo collaborators can be assigned. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/assign @matzew |
evankanderson
left a comment
There was a problem hiding this comment.
A few comments/questions.
Should this be moved to knative/docs at some point?
|
|
||
| If `spec.channelTemplate` is specified: | ||
| 1. Delete the `Broker`. | ||
| 1. Create the `Broker` with the updated `spec.channelTemplate`. |
There was a problem hiding this comment.
So the Broker won't reconcile the channel based on the channel template?
Should it?
There was a problem hiding this comment.
It won't.
As to whether it should, I'm not entirely sure. I didn't do it because I was worried about a single small change meaning that all in-flight events are irrevocably dropped. I left a TODO in the code to figure it out so that if we decide we want the change, we know where to do it.
| 1. Delete the `Broker`. | ||
| 1. Create the `Broker` with the updated `spec.channelTemplate`. | ||
|
|
||
| If `spec.channelTemplate` is not specified: |
There was a problem hiding this comment.
Is this specifically for the default Broker, or is is this intended as a general solution?
There was a problem hiding this comment.
General solution. Incidentally, it is the only one that will work with the injected default Broker, because the injected default does not specify spec.channelTemplate.
There was a problem hiding this comment.
Isn't this a bit all very manual? and might be error prone ?
There was a problem hiding this comment.
It is manual. What errors would it be prone to?
When implementing Broker, I made the decision not to update Channels even if the Broker's spec.channelTemplate changed because it would drop all in flight events. We can revisit that decision and have it updated on the fly. The code change would be quite small and there is already a comment in the place it would occur (see #996 (comment)).
If someone really wants to cause an update on the fly, they can delete the Channels backing the Broker manually. The Broker controller will create new ones with the updated template. But I don't want to document this as I consider it an implementation detail that may change in the future.
|
|
||
| ### ClusterChannelProvisioner | ||
|
|
||
| `Broker`'s use their `spec.channelTemplate` to create their internal `Channel`s, which dictate the durability guarantees of events sent to that `Broker`. If `spec.channelTemplate` is not specified, then the [default provisioner](https://www.knative.dev/docs/eventing/channels/default-channels/) for their namespace is used. |
|
|
||
| #### Setup | ||
|
|
||
| Have a `ClusterChannelProvisioner` installed and set as the [default provisioner](https://www.knative.dev/docs/eventing/channels/default-channels/) for the namespace you are interested in. For development, the [`in-memory` `ClusterChannelProvisioner`](https://github.com/knative/eventing/tree/master/config/provisioners/in-memory-channel#deployment-steps) is normally used. |
There was a problem hiding this comment.
I don't know exactly which linter rules we use, so I just leave it to the sock puppet to fix within a day of submission.
|
Ping. I think I've addressed all the comments. If this documentation is still desired, I'd like to get it in. |
|
/lgtm |
Co-authored-by: serverless-qe <serverless-support@redhat.com>
Proposed Changes
Release Note