rename in-memory channel

[sbezverk]

Signed-off-by: Serguei Bezverkhi sbezverk@cisco.com

Fixes #676

Rename in-memory-channel into in-memory

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: sbezverk
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: grantr

If they are not already assigned, you can assign the PR to them by writing /assign @grantr in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[sbezverk]

/assign @Harwayne

[sbezverk]

/assign @grantr for approval

[knative-prow-robot]

@sbezverk: GitHub didn't allow me to assign the following users: for, approval.

Note that only knative members and repo collaborators can be assigned.
For more information please see the contributor guide

Details

In response to this:

/assign @grantr for approval

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.

[Harwayne]

What happens to existing channels using the in-memory-channel provisioner? Do they keep working because the old CCP is unaltered by the update process?

[sbezverk]

@Harwayne the idea is, as long as CCPs are using old config map name, it should be transparent. I did not find any other dependencies.

[grantr]

Thanks @sbezverk!

What happens to existing channels using the in-memory-channel provisioner?

IIUC, after the upgrade there will be two CCPs each with an identical set of in-memory channel infrastructure. They'll both work, but future upgrades will only affect the new one. In a later release we'd want to delete the old one somehow.

This PR renames a bunch of objects that the operator and developer rarely/never need to know about:
in-memory-channel-controller -> in-memory-controller
in-memory-channel-dispatcher -> in-memory-dispatcher
in-memory-channel-dispatcher -> in-memory-dispatcher
in-memory-channel-dispatcher-config-map -> in-memory-dispatcher-config-map

Would the upgrade be easier if only the CCP object was renamed? We could leave the service accounts, deployments, etc that already exist in place, create a new CCP with the new name, and update the controller/dispatcher to handle both CCP names for this release.

/hold

@Harwayne just mentioned that he has more thoughts on this PR, so I'm holding it to give him time to weigh in.

[grantr]

Moving this out of 0.3 milestone. @Harwayne and @sbezverk have conferred and decided that the path forward is a new PR that allows one controller to handle both the old CCP and a new asynchronous in-memory CCP.

/milestone clear

[Harwayne]

Talked with @grantr and have been convinced that we should try to re-use the existing infrastructure (Deployments, ConfigMap, etc.). Which means that their names shouldn't change. Instead have the single controller control both ClusterChannelProvisioners for one release, then remove the old in-memory-channel in the following release.

[sbezverk]

@grantr small correction. I think we should go with a separate controllers, one in-memory-channel (old) and in-memory controller with async (new) running in parallel for backward compatibility.

[Harwayne]

I think this was superseded by #708. If so, can this PR be closed?

[matzew]

@Harwayne @grantr it's now in_memory ... in here:

https://github.com/knative/eventing/tree/master/cmd/in_memory

I guess... we are good?

[n3wscott]

We have moved to in-memory and now are moving to CRDs over provisioners.
/close

[knative-prow-robot]

@n3wscott: Closed this PR.

Details

In response to this:

We have moved to in-memory and now are moving to CRDs over provisioners.
/close

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.