Use RabbitmqCluster namespace in RabbitmqClusterReference #492
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
knative-prow-robot
added
kind/enhancement
do-not-merge/work-in-progress
knative-prow-robot
added
the
size/L
Codecov Report
@@ Coverage Diff @@
## main #492 +/- ##
==========================================
- Coverage 76.13% 75.97% -0.16%
==========================================
Files 46 46
Lines 2782 2781 -1
==========================================
- Hits 2118 2113 -5
- Misses 538 542 +4
Partials 126 126
Continue to review full report at Codecov.
|
Contributor
Author
|
I've realised the issues with my initial approach. If resources belonging to a single namespace start getting spread, the logical namespace encapsulation gets broken and we would end up with a mess. Resources that should be close to one another aren't, which makes lifecycle events more complicated - especially deletions. It would make a lot more sense to define the I have confirmed it in the type definition too: Let's see what happens with this approach. |
gvmw
changed the title
gvmw
changed the title
knative-prow-robot
added
size/XXL
Contributor
Author
|
I think that I'm going in the wrong direction with deps. Current status: go test -race knative.dev/eventing-rabbitmq/pkg/reconciler/broker
# knative.dev/pkg/client/injection/kube/client
vendor/knative.dev/pkg/client/injection/kube/client/client.go:1236:9: cannot use &wrapAppsV1DeploymentImpl{...} (type *wrapAppsV1DeploymentImpl) as type "k8s.io/client-go/kubernetes/typed/apps/v1".DeploymentInterface in return argument:
*wrapAppsV1DeploymentImpl does not implement "k8s.io/client-go/kubernetes/typed/apps/v1".DeploymentInterface (missing ApplyScale method)
vendor/knative.dev/pkg/client/injection/kube/client/client.go:1253:5: cannot use (*wrapAppsV1DeploymentImpl)(nil) (type *wrapAppsV1DeploymentImpl) as type "k8s.io/client-go/kubernetes/typed/apps/v1".DeploymentInterface in assignment:
*wrapAppsV1DeploymentImpl does not implement "k8s.io/client-go/kubernetes/typed/apps/v1".DeploymentInterface (missing ApplyScale method)
vendor/knative.dev/pkg/client/injection/kube/client/client.go:1400:5: cannot use (*wrapAppsV1ReplicaSetImpl)(nil) (type *wrapAppsV1ReplicaSetImpl) as type "k8s.io/client-go/kubernetes/typed/apps/v1".ReplicaSetInterface in assignment:
*wrapAppsV1ReplicaSetImpl does not implement "k8s.io/client-go/kubernetes/typed/apps/v1".ReplicaSetInterface (missing ApplyScale method)
vendor/knative.dev/pkg/client/injection/kube/client/client.go:1547:5: cannot use (*wrapAppsV1StatefulSetImpl)(nil) (type *wrapAppsV1StatefulSetImpl) as type "k8s.io/client-go/kubernetes/typed/apps/v1".StatefulSetInterface in assignment:
*wrapAppsV1StatefulSetImpl does not implement "k8s.io/client-go/kubernetes/typed/apps/v1".StatefulSetInterface (missing ApplyScale method)
vendor/knative.dev/pkg/client/injection/kube/client/client.go:2697:5: cannot use (*wrapAppsV1beta2StatefulSetImpl)(nil) (type *wrapAppsV1beta2StatefulSetImpl) as type "k8s.io/client-go/kubernetes/typed/apps/v1beta2".StatefulSetInterface in assignment:
*wrapAppsV1beta2StatefulSetImpl does not implement "k8s.io/client-go/kubernetes/typed/apps/v1beta2".StatefulSetInterface (missing ApplyScale method)
vendor/knative.dev/pkg/client/injection/kube/client/client.go:6049:5: cannot use (*wrapCoreV1PodImpl)(nil) (type *wrapCoreV1PodImpl) as type "k8s.io/client-go/kubernetes/typed/core/v1".PodInterface in assignment:
*wrapCoreV1PodImpl does not implement "k8s.io/client-go/kubernetes/typed/core/v1".PodInterface (missing EvictV1 method)
vendor/knative.dev/pkg/client/injection/kube/client/client.go:6170:112: undefined: "k8s.io/api/core/v1".EphemeralContainers
vendor/knative.dev/pkg/client/injection/kube/client/client.go:6174:90: undefined: "k8s.io/api/core/v1".EphemeralContainers
vendor/knative.dev/pkg/client/injection/kube/client/client.go:7808:5: cannot use (*wrapExtensionsV1beta1DeploymentImpl)(nil) (type *wrapExtensionsV1beta1DeploymentImpl) as type "k8s.io/client-go/kubernetes/typed/extensions/v1beta1".DeploymentInterface in assignment:
*wrapExtensionsV1beta1DeploymentImpl does not implement "k8s.io/client-go/kubernetes/typed/extensions/v1beta1".DeploymentInterface (missing ApplyScale method)
vendor/knative.dev/pkg/client/injection/kube/client/client.go:8368:5: cannot use (*wrapExtensionsV1beta1ReplicaSetImpl)(nil) (type *wrapExtensionsV1beta1ReplicaSetImpl) as type "k8s.io/client-go/kubernetes/typed/extensions/v1beta1".ReplicaSetInterface in assignment:
*wrapExtensionsV1beta1ReplicaSetImpl does not implement "k8s.io/client-go/kubernetes/typed/extensions/v1beta1".ReplicaSetInterface (missing ApplyScale method)
vendor/knative.dev/pkg/client/injection/kube/client/client.go:1236:9: too many errors
FAIL knative.dev/eventing-rabbitmq/pkg/reconciler/broker [build failed]After 9db1369, I think the update to |
Contributor
Author
|
This is the commit that bumped I was able to lock it to a specific version by running |
Contributor
Author
|
This was my starting point (no dep updates): 0b22ee9 I ran the following: Everything worked fine, and then I ran the tests: If I downgrade The commit that I have pushed just before this comment should reproduce the same issue. How would you recommend solving this @salaboy? |
gvmw
added a commit
to gvmw/eventing-rabbitmq
that referenced
this pull request
Nov 8, 2021
This has the rest of the context: knative-extensions#492 (comment) Signed-off-by: Gerhard Lazu <[email protected]>
Contributor
Author
|
I've made progress with this, there is a change that needs to happen in messaging-topology-operator: rabbitmq/messaging-topology-operator#256 |
knative-prow-robot
added
the
needs-rebase
gvmw
added a commit
to rabbitmq/messaging-topology-operator
that referenced
this pull request
Nov 10, 2021
This was introduced part of #87, and in the latest eventing-rabbitmq changes it became obvious that the versions started to drift. This discussion explains the problem best: #256 This holds the rest of the context: knative-extensions/eventing-rabbitmq#492 (comment) This change lines up all versions, and the local unit & integration tests pass. My next step is to check if CI remains green, and if the change actually works in the context of eventing-rabbitmq, which is how this started. Signed-off-by: Gerhard Lazu <[email protected]>
gvmw
added a commit
to gvmw/eventing-rabbitmq
that referenced
this pull request
Nov 10, 2021
This has the rest of the context: knative-extensions#492 (comment) Signed-off-by: Gerhard Lazu <[email protected]>
gvmw
force-pushed
the
add-support-for-single-rabbitmq-instance
branch
4 times, most recently
from
3076724 to
9a5a8bc
Compare
Contributor
Author
|
How do I fix the tide error @benmoss? The conflict is showing me an old diff, I have since force pushed a few times and everything applies cleanly. If you run a git diff local, it will look different to the tide output above 🤷🏼♂️ |
gvmw
force-pushed
the
add-support-for-single-rabbitmq-instance
branch
from
9a5a8bc to
ec13c71
Compare
knative-prow-robot
removed
the
needs-rebase
gvmw
force-pushed
the
add-support-for-single-rabbitmq-instance
branch
from
ec13c71 to
2d58c34
Compare
Contributor
Author
|
I am leaving a note for my future self. In case I come across this failure in the future: panic: /ko-app/broker
flag redefined: kubeconfig
goroutine 1 [running]:
flag.(*FlagSet).Var(0xc000090720,
{0x1eaddf0, 0xc0001b4570}, {0x1c48cde, 0xa}, {0x1c9322f, 0x36})
flag/flag.go:879
+0x2f4
flag.(*FlagSet).StringVar(...)
flag/flag.go:762
knative.dev/pkg/environment.(*ClientConfig).InitFlags(0xc0001b4540,
0xc000090720)
knative.dev/pkg@v0.0.0-20211109100843-91d1932616a7/environment/client_config.go:45
+0x134
knative.dev/pkg/injection.ParseAndGetRESTConfigOrDie()
knative.dev/pkg@v0.0.0-20211109100843-91d1932616a7/injection/config.go:32
+0x36
knative.dev/pkg/injection/sharedmain.MainWithContext({0x1eca468,
0xc000362030}, {0x1c5ef4e, 0x1a}, {0xc0006bff60, 0x2, 0x2})
knative.dev/pkg@v0.0.0-20211109100843-91d1932616a7/injection/sharedmain/main.go:125
+0x78
knative.dev/pkg/injection/sharedmain.Main({0x1c5ef4e, 0x1a}, {0xc0006bff60,
0x2, 0x2})
knative.dev/pkg@v0.0.0-20211109100843-91d1932616a7/injection/sharedmain/main.go:105
+0x8f
main.main()
knative.dev/eventing-rabbitmq/cmd/controller/broker/main.go:29
+0x4eRemember that it is related to dependencies being updated, and |
gvmw
force-pushed
the
add-support-for-single-rabbitmq-instance
branch
from
8f10675 to
804e8e5
Compare
…space Signed-off-by: Gerhard Lazu <[email protected]>
gvmw
force-pushed
the
add-support-for-single-rabbitmq-instance
branch
from
34c430a to
0efe550
Compare
knative-prow-robot
removed
the
needs-rebase
./hack/update-deps.sh FTW! Signed-off-by: Gerhard Lazu <[email protected]>
Contributor
|
I'm using this topology and seeing this error on the exchange: |
Contributor
|
Ah, I see #454 (comment) references this annotation, its required for cross-namespace references. Adding the annotation and it seems to work. |
Contributor
|
So this is still WIP, waiting on the e2e test, right? |
Contributor
Author
Yes, that's right. Making slow progress, but getting there. I will commit what I have today (most of it is the |
Contributor
Author
I just remembered that we may want to wait for a messaging-topology release that has the feature which we depend on: rabbitmq/messaging-topology-operator#257 WDYT @benmoss ? |
Contributor
|
For rabbitmq/messaging-topology-operator#257 I think it's fine to just pin our dependency to the commit as you have done, the released version is fine for users to install |
gvmw
added a commit
to gvmw/eventing-rabbitmq
that referenced
this pull request
Nov 22, 2021
For example, running end-to-end tests requires setting up dependencies,
a local KiND cluster, installing operators, waiting for components to be
ready, and then invoking `go test` with many flags. The entire flow is
captured in .github/workflows/kind-e2e.yaml, so how do we run it
locally? I think that there are some scripts which try to set everything
up, but they are not discoverable, pretty sure they diverged from the CI
workflow by now, and are not as composable as the Make equivalent.
So how does it work? Type make and follow along:
build Build binaries with e2e tags
dep-update Update any dependency
e2e-setup Setup environment for e2e testing
env Configure shell env - eval "$(make env)" OR rm .env && make .env && source .env
k9s Terminal ncurses UI for K8s
test-e2e-broker Run Broker end-to-end tests
test-e2e-publish Run TestKoPublish end-to-end tests
test-e2e-source Run Source end-to-end tests
test-unit Run unit tests
To run end-to-end tests, which is what I had to do in the context of
knative-extensions#492 (this PR
is based on that one) I now only need to run the following:
# This only needs to run once:
make e2e-setup
make test-e2e
# I can run just a subset of tests with e.g.:
make test-e2e-broker
This iteration:
- only support Linux & Darwin systems (does not support Windows)
- only supports x84_64 (does not support latest Macs with ARM silicon)
- defaults to the minimum supported K8s version (adding support for
multiple K8s versions was out of scope)
This was only tested on Linux Ubuntu 20.04.3 LTS, and should be tested
on Darwin on Intel. Supporting Darwin on ARM should not be difficult,
but as I don't have access to one, I cannot test.
Signed-off-by: Gerhard Lazu <[email protected]>
5 tasks
Signed-off-by: Gerhard Lazu <[email protected]>
Contributor
Author
|
This is now ready for review. Everything that we need is now in, including end-to-end tests. |
gvmw
added a commit
to gvmw/eventing-rabbitmq
that referenced
this pull request
Nov 24, 2021
For example, running end-to-end tests requires setting up dependencies,
a local KiND cluster, installing operators, waiting for components to be
ready, and then invoking `go test` with many flags. The entire flow is
captured in .github/workflows/kind-e2e.yaml, so how do we run it
locally? I think that there are some scripts which try to set everything
up, but they are not discoverable, pretty sure they diverged from the CI
workflow by now, and are not as composable as the Make equivalent.
So how does it work? Type make and follow along:
build Build binaries with e2e tags
dep-update Update any dependency
e2e-setup Setup environment for e2e testing
env Configure shell env - eval "$(make env)" OR rm .env && make .env && source .env
k9s Terminal ncurses UI for K8s
test-e2e-broker Run Broker end-to-end tests
test-e2e-publish Run TestKoPublish end-to-end tests
test-e2e-source Run Source end-to-end tests
test-unit Run unit tests
To run end-to-end tests, which is what I had to do in the context of
knative-extensions#492 (this PR
is based on that one) I now only need to run the following:
# This only needs to run once:
make e2e-setup
make test-e2e
# I can run just a subset of tests with e.g.:
make test-e2e-broker
This iteration:
- only support Linux & Darwin systems (does not support Windows)
- only supports x84_64 (does not support latest Macs with ARM silicon)
- defaults to the minimum supported K8s version (adding support for
multiple K8s versions was out of scope)
This was only tested on Linux Ubuntu 20.04.3 LTS, and should be tested
on Darwin on Intel. Supporting Darwin on ARM should not be difficult,
but as I don't have access to one, I cannot test.
Signed-off-by: Gerhard Lazu <[email protected]>
Contributor
Author
|
After this is merged, remember to update https://github.com/knative/docs/blob/ad6446431ea4de30bcbf94e8a36bdf43df11943d/docs/eventing/broker/rabbitmq-broker/README.md?plain=1#L92 With the following: annotations:
# This enables a single RabbitMQ cluster to service multiple Brokers
rabbitmq.com/topology-allowed-namespaces: "*" |
Contributor
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: benmoss, gvmw 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:
Approvers can indicate their approval by writing |
knative-prow-robot
added
the
approved
Contributor
Author
|
@embano1 I just checked and nightly builds have picked this change. Let us know if kubectl apply -f https://storage.googleapis.com/knative-nightly/eventing-rabbitmq/latest/rabbitmq-broker.yaml |
gvmw
added a commit
to gvmw/eventing-rabbitmq
that referenced
this pull request
Nov 30, 2021
For example, running end-to-end tests requires setting up dependencies,
a local KiND cluster, installing operators, waiting for components to be
ready, and then invoking `go test` with many flags. The entire flow is
captured in .github/workflows/kind-e2e.yaml, so how do we run it
locally? I think that there are some scripts which try to set everything
up, but they are not discoverable, pretty sure they diverged from the CI
workflow by now, and are not as composable as the Make equivalent.
So how does it work? Type make and follow along:
build Build binaries with e2e tags
dep-update Update any dependency
e2e-setup Setup environment for e2e testing
env Configure shell env - eval "$(make env)" OR rm .env && make .env && source .env
k9s Terminal ncurses UI for K8s
test-e2e-broker Run Broker end-to-end tests
test-e2e-publish Run TestKoPublish end-to-end tests
test-e2e-source Run Source end-to-end tests
test-unit Run unit tests
To run end-to-end tests, which is what I had to do in the context of
knative-extensions#492 (this PR
is based on that one) I now only need to run the following:
# This only needs to run once:
make e2e-setup
make test-e2e
# I can run just a subset of tests with e.g.:
make test-e2e-broker
This iteration:
- only support Linux & Darwin systems (does not support Windows)
- only supports x84_64 (does not support latest Macs with ARM silicon)
- defaults to the minimum supported K8s version (adding support for
multiple K8s versions was out of scope)
This was only tested on Linux Ubuntu 20.04.3 LTS, and should be tested
on Darwin on Intel. Supporting Darwin on ARM should not be difficult,
but as I don't have access to one, I cannot test.
Signed-off-by: Gerhard Lazu <[email protected]>
Contributor
Author
|
Had confirmation this morning from @embano1 that #492 (comment) must go in as soon as knative/docs#4518 gets merged. |
Contributor
Author
|
This should help: knative/docs#4532 |
knative-prow-robot
pushed a commit
that referenced
this pull request
Dec 16, 2021
* Add Makefile for running complicated tasks with a single command
For example, running end-to-end tests requires setting up dependencies,
a local KiND cluster, installing operators, waiting for components to be
ready, and then invoking `go test` with many flags. The entire flow is
captured in .github/workflows/kind-e2e.yaml, so how do we run it
locally? I think that there are some scripts which try to set everything
up, but they are not discoverable, pretty sure they diverged from the CI
workflow by now, and are not as composable as the Make equivalent.
So how does it work? Type make and follow along:
build Build binaries with e2e tags
dep-update Update any dependency
e2e-setup Setup environment for e2e testing
env Configure shell env - eval "$(make env)" OR rm .env && make .env && source .env
k9s Terminal ncurses UI for K8s
test-e2e-broker Run Broker end-to-end tests
test-e2e-publish Run TestKoPublish end-to-end tests
test-e2e-source Run Source end-to-end tests
test-unit Run unit tests
To run end-to-end tests, which is what I had to do in the context of
#492 (this PR
is based on that one) I now only need to run the following:
# This only needs to run once:
make e2e-setup
make test-e2e
# I can run just a subset of tests with e.g.:
make test-e2e-broker
This iteration:
- only support Linux & Darwin systems (does not support Windows)
- only supports x84_64 (does not support latest Macs with ARM silicon)
- defaults to the minimum supported K8s version (adding support for
multiple K8s versions was out of scope)
This was only tested on Linux Ubuntu 20.04.3 LTS, and should be tested
on Darwin on Intel. Supporting Darwin on ARM should not be difficult,
but as I don't have access to one, I cannot test.
Signed-off-by: Gerhard Lazu <[email protected]>
* Tell git to ingore .env and .config paths
We do not want to version-control these
Signed-off-by: Gerhard Lazu <[email protected]>
* Add KiND cluster config
Used in `make kind-cluster`
Signed-off-by: Gerhard Lazu <[email protected]>
* Install gh cli
This comes in handy for checking out PRs, working with Actions, etc.
Signed-off-by: Gerhard Lazu <[email protected]>
* Add descriptions for install-* targets
Allow versions to be changed just-in-time
Signed-off-by: Gerhard Lazu <[email protected]>
* Bump k9s to latest
Signed-off-by: Gerhard Lazu <[email protected]>
* Install kn CLI
After reading the first 6 chapters of Knative in Action, it became
obvious to me that this CLI is essential for working with Knative.
Signed-off-by: Gerhard Lazu <[email protected]>
* Move KO_URL after KO_BIN_DIR
On Windows on WSL with make 4.3 this fails. Not sure why it worked on
Linux with make 4.2.1 as it's clearly wrong. This fixes it.
Signed-off-by: Gerhard Lazu <[email protected]>
* Use make variables that expand only once
Variables declared with := get interpreted a single time while those
with = get evaluated every time they are invoked. We want just once
invocation.
Signed-off-by: Gerhard Lazu <[email protected]>
* Install serving part of the e2e setup
This is the easiest way to setup Sinks (they only need to be
addressable).
Signed-off-by: Gerhard Lazu <[email protected]>
* Install Kourier for ingress part of Knative Serving
Signed-off-by: Gerhard Lazu <[email protected]>
* Respect KUBECONFIG from env & do not hard-code to kind
Enables running against any K8s, helpful when testing against GKE.
Signed-off-by: Gerhard Lazu <[email protected]>
* Bump cert-manager to 1.5.4
This is the version that RabbitMQ messaging-topology-operator v1.2.1 was
tested against.
Related to #370 (comment)
Signed-off-by: Gerhard Lazu <[email protected]>
* Fix missing OPEN
Great spot @benmoss!
Signed-off-by: Gerhard Lazu <[email protected]>
* Make test-e2e depend on KUBECONFIG, no more roundabouts
@benmoss made an excellent point in this comment, and I think that this
change address it.
https://github.com/knative-sandbox/eventing-rabbitmq/pull/525/files#r759457509
Signed-off-by: Gerhard Lazu <[email protected]>
* Remove kind setup scripts
These are now replaced by the Makefile, for context see
#525
Signed-off-by: Gerhard Lazu <[email protected]>
* Use the existing context for the default install
Great suggestion @benmoss!
Signed-off-by: Gerhard Lazu <[email protected]>
* Make install & test-e2e behaviour is more intuitive
install takes care of everything, and test-e2e also runs it - they are
self-contained targets.
The other test-e2e-* targets make assumptions that an install has run
before. The idea is that running a subset of e2e tests should be as fast
as possible, while running the entire e2e should be complete.
Signed-off-by: Gerhard Lazu <[email protected]>
* Make the default help target more helpful for newcomers
That .env is always a gotcha... direnv doesn't make it better.
Signed-off-by: Gerhard Lazu <[email protected]>
* Rename build to test-compilation
I like it @benmoss!
https://github.com/knative-sandbox/eventing-rabbitmq/pull/525/files#r765968362
Signed-off-by: Gerhard Lazu <[email protected]>
* List test-unit-uncached in help
This is something that @ikvmw was mentioning yesterday. Making this
option visibile should help with WTF moments that originate in a stale cache.
Signed-off-by: Gerhard Lazu <[email protected]>
* Use Makefile in kind conformance standalone GitHub Action
The CI will continuously validate that everything is wired up correctly,
and devs using this locally will have the confidence that it just works.
Signed-off-by: Gerhard Lazu <[email protected]>
* Fix envsubst variables in kind.yaml
Signed-off-by: Gerhard Lazu <[email protected]>
* Do not link ko to gcloud
This is only necessary if pushing images to gcr.io, which is what *some*
of us do locally, but not everyone.
Signed-off-by: Gerhard Lazu <[email protected]>
* Uppercase all instances of KiND & K8s
Otherwise weird things happen, like KiND_CLUSTER_NAME vs
KIND_CLUSTER_NAME.
Signed-off-by: Gerhard Lazu <[email protected]>
* Export updated PATH so that all targets work correctly
Signed-off-by: Gerhard Lazu <[email protected]>
* Bump gh, k9s, kn & Knative versions to latest
Signed-off-by: Gerhard Lazu <[email protected]>
* Use make targets in kind e2e test GitHub Action
Signed-off-by: Gerhard Lazu <[email protected]>
* Install standalone broker for standalone conformance tests
Thanks @benmoss for spotting it!
#525 (comment)
Signed-off-by: Gerhard Lazu <[email protected]>
* Separate standalone conformance tests from the regular ones
Signed-off-by: Gerhard Lazu <[email protected]>
* Make test-conformance targets leaner
So that they are less likely to fail in GitHub Actions.
Signed-off-by: Gerhard Lazu <[email protected]>
* Convert standard conformance tests to use make targets
Signed-off-by: Gerhard Lazu <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes
When declaring a new
Brokerof classRabbitMQBroker, use theRabbitmqClusternamespace inRabbitmqClusterReference, otherwise the dependent objects which get declared - i.e.Exchange,Queue,Binding- and are expected to be reconciled by the https://github.com/rabbitmq/messaging-topology-operator will fail to be created.This has more details: #454
/kind bug
Fixes #454