Remove static GCP broker data plane yamls

[liu-cong]

Fixes #867

Proposed Changes

• Remove static yamls for GCP broker data plane as now they are created dynamically by brokercell (Create brokercell on demand #1132)
• Copy the SA, role and rolebinding in the 200-rbac.yaml to existing rbac files

Release Note

Remove static GCP broker data plane yamls

Docs

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: liu-cong

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [liu-cong]

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

[liu-cong]

/hold should merge after #1132 is merged

[liu-cong]

This PR removes the config/broker folder as the broker data plane will be dynamically created with brokercell.
@ericlem Let me know if there is anything requried for go mod (I remember you talked about the dummy go file).

cc @nachocano as you are looking at the release yamls

[nachocano]

This PR removes the config/broker folder as the broker data plane will be dynamically created with brokercell.
@ericlem Let me know if there is anything requried for go mod (I remember you talked about the dummy go file).

cc @nachocano as you are looking at the release yamls

Are you planning on cherry-picking this and other broker stuff to 0.15?

[ericlem]

When we merge it into cloudrun-eventing we'll have to remove the entries pointing at the config/broker directories from hack/tools.go (the version in cloudrun-eventing) and the copy_yaml command for it from hack/update-deps.sh (the version in cloudrun-eventing)

[yolocs]

It just occurred to me - would it be useful to keep these yamls somewhere for easier testing?

[liu-cong]

It just occurred to me - would it be useful to keep these yamls somewhere for easier testing?

For consistency I would say no since we don't keep yamls for other dynamically created resources. Is there any specific use case you have in mind?

[yolocs]

@liu-cong I was thinking the case where I want to create a broker data plane manually. But never mind, once we move to brokercell the existing yamls won't work anyway.

[yolocs]

/lgtm

[liu-cong]

I was thinking the case where I want to create a broker data plane manually. But never mind, once we move to brokercell the existing yamls won't work anyway.

Yeah I can see sometimes you want to manually deploy the yamls for troubleshooting for example. We could create a example yaml folder to put these yamls. But I am afraid we will forget to keep them up to date... So better just remove them if we won't maintain them.

[liu-cong]

/unhold

[liu-cong]

/retest

[yolocs]

/hold
It just occurred to me. Will this PR break e2e test?

knative-gcp/test/lib.sh

Line 38 in 848d632

ko apply --strict -f ${CLOUD_RUN_EVENTS_GCP_BROKER_CONFIG} || return 1

[liu-cong]

Will this PR break e2e test?

Indeed it will. And this explains the test failures :)

Also removed the yaml from e2e tests. Let's see if the tests will pass.

[yolocs]

/lgtm

[liu-cong]

/unhold